قنوات الحالة

تتيح قنوات الحالة للمشاركين إجراء معاملات آمنة خارج السلسلة مع إبقاء التفاعل مع شبكة إيثيريوم الرئيسية في حده الأدنى. يمكن لنظراء القناة إجراء عدد غير محدود من المعاملات خارج السلسلة مع تقديم معاملتين فقط على السلسلة لفتح وإغلاق القناة. يتيح ذلك قدرة معالجة عالية جدًا للمعاملات ويؤدي إلى خفض التكاليف على المستخدمين.

المتطلبات الأساسية

يجب أن تكون قد قرأت وفهمت صفحاتنا حول توسيع نطاق إيثيريوم وطبقة 2 (L2).

ما هي القنوات؟

تواجه سلاسل الكتل العامة، مثل إيثيريوم، تحديات في قابلية التوسع بسبب بنيتها الموزعة: يجب تنفيذ المعاملات على السلسلة بواسطة جميع العقد. يجب أن تكون العقد قادرة على التعامل مع حجم المعاملات في كتلة باستخدام أجهزة متواضعة، مما يفرض حدًا على قدرة المعالجة للمعاملات للحفاظ على لامركزية الشبكة. تحل قنوات سلسلة الكتل هذه المشكلة من خلال السماح للمستخدمين بالتفاعل خارج السلسلة مع الاستمرار في الاعتماد على أمان السلسلة الرئيسية للتسوية النهائية.

القنوات هي بروتوكولات نظير إلى نظير بسيطة تسمح لطرفين بإجراء العديد من المعاملات بينهما ثم نشر النتائج النهائية فقط على سلسلة الكتل. تستخدم القناة علم التشفير لإثبات أن البيانات الموجزة التي تولدها هي حقًا نتيجة لمجموعة صالحة من المعاملات الوسيطة. يضمن عقد ذكي "متعدد التوقيعات" توقيع المعاملات من قبل الأطراف الصحيحة.

باستخدام القنوات، يتم تنفيذ تغييرات الحالة والتحقق من صحتها من قبل الأطراف المعنية، مما يقلل من الحوسبة على طبقة التنفيذ في إيثيريوم. يقلل هذا من الازدحام على إيثيريوم ويزيد أيضًا من سرعات معالجة المعاملات للمستخدمين.

تُدار كل قناة بواسطة عقد ذكي متعدد التوقيعات يعمل على إيثيريوم. لفتح قناة، يقوم المشاركون بنشر عقد القناة على السلسلة وإيداع الأموال فيه. يوقع كلا الطرفين بشكل جماعي على تحديث الحالة لتهيئة حالة القناة، وبعد ذلك يمكنهم إجراء المعاملات بسرعة وبحرية خارج السلسلة.

لإغلاق القناة، يقدم المشاركون آخر حالة متفق عليها للقناة على السلسلة. بعد ذلك، يوزع العقد الذكي الأموال المقفلة وفقًا لرصيد كل مشارك في الحالة النهائية للقناة.

قنوات نظير إلى نظير مفيدة بشكل خاص للحالات التي يرغب فيها بعض المشاركين المحددين مسبقًا في إجراء معاملات بتردد عالٍ دون تكبد نفقات عامة واضحة. تندرج قنوات سلسلة الكتل تحت فئتين: قنوات الدفع وقنوات الحالة.

قنوات الدفع

أفضل وصف لقناة الدفع هو "دفتر أستاذ ثنائي الاتجاه" يحتفظ به مستخدمان بشكل جماعي. الرصيد الأولي لدفتر الأستاذ هو مجموع الودائع المقفلة في العقد على السلسلة خلال مرحلة فتح القناة. يمكن إجراء تحويلات قناة الدفع بشكل فوري ودون تدخل سلسلة الكتل الفعلية نفسها، باستثناء إنشاء أولي لمرة واحدة على السلسلة وإغلاق نهائي للقناة.

تتطلب التحديثات على رصيد دفتر الأستاذ (أي حالة قناة الدفع) موافقة جميع الأطراف في القناة. يُعتبر تحديث القناة، الموقع من قبل جميع المشاركين في القناة، نهائيًا، تمامًا مثل معاملة على إيثيريوم.

كانت قنوات الدفع من بين أقدم حلول التوسع المصممة لتقليل النشاط المكلف على السلسلة لتفاعلات المستخدمين البسيطة (مثل تحويلات ETH، والمبادلات الذرية، والمدفوعات الصغيرة). يمكن للمشاركين في القناة إجراء كمية غير محدودة من المعاملات الفورية والخالية من الرسوم فيما بينهم طالما أن المجموع الصافي لتحويلاتهم لا يتجاوز الرموز المودعة.

قنوات الحالة

بصرف النظر عن دعم المدفوعات خارج السلسلة، لم تثبت قنوات الدفع فائدتها في التعامل مع منطق انتقال الحالة العام. تم إنشاء قنوات الحالة لحل هذه المشكلة وجعل القنوات مفيدة لتوسيع نطاق الحوسبة ذات الأغراض العامة.

لا تزال قنوات الحالة تشترك في الكثير مع قنوات الدفع. على سبيل المثال، يتفاعل المستخدمون من خلال تبادل رسائل (معاملات) موقعة باستخدام علم التشفير، والتي يجب على المشاركين الآخرين في القناة توقيعها أيضًا. إذا لم يتم توقيع تحديث الحالة المقترح من قبل جميع المشاركين، فإنه يُعتبر غير صالح.

ومع ذلك، بالإضافة إلى الاحتفاظ بأرصدة المستخدم، تتتبع القناة أيضًا الحالة الحالية لتخزين العقد (أي قيم متغيرات العقد).

يجعل هذا من الممكن تنفيذ عقد ذكي خارج السلسلة بين مستخدمين. في هذا السيناريو، تتطلب التحديثات على الحالة الداخلية للعقد الذكي فقط موافقة النظراء الذين أنشأوا القناة.

في حين أن هذا يحل مشكلة قابلية التوسع الموصوفة سابقًا، إلا أن له آثارًا على الأمان. على إيثيريوم، يتم فرض صحة انتقالات الحالة بواسطة بروتوكول الإجماع الخاص بالشبكة. يجعل هذا من المستحيل اقتراح تحديث غير صالح لحالة عقد ذكي أو تغيير تنفيذ العقد الذكي.

لا تتمتع قنوات الحالة بنفس ضمانات الأمان. إلى حد ما، قناة الحالة هي نسخة مصغرة من الشبكة الرئيسية. مع وجود مجموعة محدودة من المشاركين الذين يفرضون القواعد، تزداد احتمالية السلوك الضار (مثل اقتراح تحديثات حالة غير صالحة). تستمد قنوات الحالة أمانها من نظام تحكيم في النزاعات يعتمد على .

كيف تعمل قنوات الحالة

في الأساس، النشاط في قناة الحالة هو جلسة من التفاعلات التي تشمل المستخدمين ونظام سلسلة الكتل. يتواصل المستخدمون في الغالب مع بعضهم البعض خارج السلسلة ويتفاعلون فقط مع سلسلة الكتل الأساسية لفتح القناة، أو إغلاق القناة، أو تسوية النزاعات المحتملة بين المشاركين.

يوضح القسم التالي سير العمل الأساسي لقناة الحالة:

فتح القناة

يتطلب فتح قناة من المشاركين الالتزام بأموال في عقد ذكي على الشبكة الرئيسية. تعمل الوديعة أيضًا كحساب افتراضي، بحيث يمكن للأطراف المشاركة إجراء المعاملات بحرية دون الحاجة إلى تسوية المدفوعات على الفور. فقط عندما تصبح القناة نهائية على السلسلة، يقوم الأطراف بتسوية حساباتهم مع بعضهم البعض وسحب ما تبقى من حسابهم.

تعمل هذه الوديعة أيضًا كضمان لضمان السلوك الصادق من كل مشارك. إذا ثبتت إدانة المودعين بأفعال ضارة خلال مرحلة حل النزاع، يقوم العقد باقتطاع وديعتهم.

يجب على نظراء القناة توقيع حالة أولية يتفقون عليها جميعًا. يعمل هذا كبداية لقناة الحالة، وبعد ذلك يمكن للمستخدمين البدء في إجراء المعاملات.

استخدام القناة

بعد تهيئة حالة القناة، يتفاعل النظراء من خلال توقيع المعاملات وإرسالها إلى بعضهم البعض للموافقة عليها. يبدأ المشاركون تحديثات الحالة بهذه المعاملات ويوقعون تحديثات الحالة من الآخرين. تتكون كل معاملة مما يلي:

• رقم فريد، والذي يعمل كمعرف فريد للمعاملات ويمنع هجمات إعادة التشغيل. كما يحدد الترتيب الذي حدثت به تحديثات الحالة (وهو أمر مهم لحل النزاعات)

• حالة القناة القديمة

• حالة القناة الجديدة

• المعاملة التي تؤدي إلى انتقال الحالة (على سبيل المثال، ترسل أليس 5 ETH إلى بوب)

لا يتم بث تحديثات الحالة في القناة على السلسلة كما هو الحال عادةً عندما يتفاعل المستخدمون على الشبكة الرئيسية، وهو ما يتماشى مع هدف قنوات الحالة لتقليل البصمة على السلسلة. طالما أن المشاركين يتفقون على تحديثات الحالة، فهي نهائية مثل معاملة إيثيريوم. يحتاج المشاركون فقط إلى الاعتماد على إجماع الشبكة الرئيسية في حالة نشوء نزاع.

إغلاق القناة

يتطلب إغلاق قناة الحالة تقديم الحالة النهائية المتفق عليها للقناة إلى العقد الذكي على السلسلة. تتضمن التفاصيل المشار إليها في تحديث الحالة عدد تحركات كل مشارك وقائمة بالمعاملات المعتمدة.

بعد التحقق من أن تحديث الحالة صالح (أي أنه موقع من قبل جميع الأطراف)، يجعل العقد الذكي القناة نهائية ويوزع الأموال المقفلة وفقًا لنتيجة القناة. يتم تطبيق المدفوعات التي تمت خارج السلسلة على حالة إيثيريوم ويتلقى كل مشارك الجزء المتبقي من الأموال المقفلة.

يمثل السيناريو الموصوف أعلاه ما يحدث في الحالة المثالية. في بعض الأحيان، قد لا يتمكن المستخدمون من التوصل إلى اتفاق وجعل القناة نهائية (الحالة السيئة). قد يكون أي مما يلي صحيحًا بالنسبة للموقف:

• يصبح المشاركون غير متصلين بالإنترنت ويفشلون في اقتراح انتقالات الحالة

• يرفض المشاركون التوقيع المشترك على تحديثات الحالة الصالحة

• يحاول المشاركون جعل القناة نهائية من خلال اقتراح تحديث حالة قديم للعقد على السلسلة

• يقترح المشاركون انتقالات حالة غير صالحة ليوقع عليها الآخرون

كلما انهار الإجماع بين الأطراف المشاركة في قناة، يكون الخيار الأخير هو الاعتماد على إجماع الشبكة الرئيسية لفرض الحالة النهائية والصالحة للقناة. في هذه الحالة، يتطلب إغلاق قناة الحالة تسوية النزاعات على السلسلة.

تسوية النزاعات

عادةً، تتفق الأطراف في القناة على إغلاق القناة مسبقًا وتوقع بشكل مشترك على انتقال الحالة الأخير، والذي يقدمونه إلى العقد الذكي. بمجرد الموافقة على التحديث على السلسلة، ينتهي تنفيذ العقد الذكي خارج السلسلة ويخرج المشاركون من القناة بأموالهم.

ومع ذلك، يمكن لطرف واحد تقديم طلب على السلسلة لإنهاء تنفيذ العقد الذكي وجعل القناة نهائية—دون انتظار موافقة نظيره. إذا حدثت أي من المواقف التي تكسر الإجماع الموصوفة سابقًا، يمكن لأي من الطرفين تشغيل العقد على السلسلة لإغلاق القناة وتوزيع الأموال. يوفر هذا انعدام الحاجة للثقة، مما يضمن أن الأطراف الصادقة يمكنها الخروج بودائعها في أي وقت، بغض النظر عن أفعال الطرف الآخر.

لمعالجة خروج القناة، يجب على المستخدم تقديم آخر تحديث حالة صالح للتطبيق إلى العقد على السلسلة. إذا تم التحقق من ذلك (أي أنه يحمل توقيع جميع الأطراف)، فسيتم إعادة توزيع الأموال لصالحهم.

ومع ذلك، هناك تأخير في تنفيذ طلبات الخروج لمستخدم واحد. إذا تمت الموافقة بالإجماع على طلب إنهاء القناة، فسيتم تنفيذ معاملة الخروج على السلسلة على الفور.

يأتي التأخير في عمليات خروج المستخدم الواحد بسبب احتمالية حدوث أفعال احتيالية. على سبيل المثال، قد يحاول أحد المشاركين في القناة جعل القناة نهائية على إيثيريوم من خلال تقديم تحديث حالة أقدم على السلسلة.

كإجراء مضاد، تسمح قنوات الحالة للمستخدمين الصادقين بالطعن في تحديثات الحالة غير الصالحة من خلال تقديم أحدث حالة صالحة للقناة على السلسلة. تم تصميم قنوات الحالة بحيث تتفوق تحديثات الحالة الأحدث والمتفق عليها على تحديثات الحالة الأقدم.

بمجرد أن يقوم أحد النظراء بتشغيل نظام حل النزاعات على السلسلة، يُطلب من الطرف الآخر الرد في غضون مهلة زمنية (تسمى نافذة التحدي). يتيح ذلك للمستخدمين الطعن في معاملة الخروج، خاصة إذا كان الطرف الآخر يطبق تحديثًا قديمًا.

مهما كانت الحالة، يتمتع مستخدمو القناة دائمًا بضمانات نهائية قوية: إذا كان انتقال الحالة الذي بحوزتهم موقعًا من قبل جميع الأعضاء وهو التحديث الأحدث، فإنه يتمتع بنهائية مساوية لمعاملة عادية على السلسلة. لا يزال يتعين عليهم الطعن في الطرف الآخر على السلسلة، ولكن النتيجة الوحيدة الممكنة هي جعل الحالة الصالحة الأخيرة، التي يمتلكونها، نهائية.

كيف تتفاعل قنوات الحالة مع إيثيريوم؟

على الرغم من وجودها كبروتوكولات خارج السلسلة، إلا أن قنوات الحالة تحتوي على مكون على السلسلة: العقد الذكي المنشور على إيثيريوم عند فتح القناة. يتحكم هذا العقد في الأصول المودعة في القناة، ويتحقق من تحديثات الحالة، ويحكم في النزاعات بين المشاركين.

لا تنشر قنوات الحالة بيانات المعاملات أو التزامات الحالة على الشبكة الرئيسية، على عكس حلول توسيع النطاق من طبقة 2 (L2). ومع ذلك، فهي أكثر ارتباطًا بالشبكة الرئيسية من، على سبيل المثال، السلاسل الجانبية، مما يجعلها أكثر أمانًا إلى حد ما.

تعتمد قنوات الحالة على بروتوكول إيثيريوم الرئيسي فيما يلي:

1. الحيوية

العقد على السلسلة المنشور عند فتح القناة مسؤول عن وظائف القناة. إذا كان العقد يعمل على إيثيريوم، فإن القناة متاحة دائمًا للاستخدام. على العكس من ذلك، يمكن أن تفشل السلسلة الجانبية دائمًا، حتى لو كانت الشبكة الرئيسية تعمل، مما يعرض أموال المستخدمين للخطر.

2. الأمان

إلى حد ما، تعتمد قنوات الحالة على إيثيريوم لتوفير الأمان وحماية المستخدمين من النظراء الضارين. كما نوقش في الأقسام اللاحقة، تستخدم القنوات آلية إثبات الاحتيال التي تتيح للمستخدمين الطعن في محاولات جعل القناة نهائية بتحديث غير صالح أو قديم.

في هذه الحالة، يقدم الطرف الصادق أحدث حالة صالحة للقناة كإثبات احتيال للعقد على السلسلة للتحقق منها. تمكن إثباتات الاحتيال الأطراف التي لا تثق ببعضها البعض من إجراء معاملات خارج السلسلة دون المخاطرة بأموالهم في هذه العملية.

3. النهائية

تُعتبر تحديثات الحالة الموقعة بشكل جماعي من قبل مستخدمي القناة جيدة مثل المعاملات على السلسلة. ومع ذلك، فإن جميع الأنشطة داخل القناة لا تحقق نهائية حقيقية إلا عندما يتم إغلاق القناة على إيثيريوم.

في الحالة المتفائلة، يمكن لكلا الطرفين التعاون وتوقيع تحديث الحالة النهائي وتقديمه على السلسلة لإغلاق القناة، وبعد ذلك يتم توزيع الأموال وفقًا للحالة النهائية للقناة. في الحالة المتشائمة، حيث يحاول شخص ما الغش عن طريق نشر تحديث حالة غير صحيح على السلسلة، لا تصبح معاملته نهائية حتى تنقضي نافذة التحدي.

قنوات الحالة الافتراضية

التنفيذ البسيط لقناة الحالة سيكون نشر عقد جديد عندما يرغب مستخدمان في تنفيذ تطبيق خارج السلسلة. هذا ليس غير عملي فحسب، بل إنه يلغي أيضًا فعالية التكلفة لقنوات الحالة (يمكن أن تتراكم تكاليف المعاملات على السلسلة بسرعة).

لحل هذه المشكلة، تم إنشاء "القنوات الافتراضية". على عكس القنوات العادية التي تتطلب معاملات على السلسلة لفتحها وإنهائها، يمكن فتح قناة افتراضية وتنفيذها وجعلها نهائية دون التفاعل مع السلسلة الرئيسية. بل من الممكن تسوية النزاعات خارج السلسلة باستخدام هذه الطريقة.

يعتمد هذا النظام على وجود ما يسمى بـ "قنوات دفتر الأستاذ"، والتي تم تمويلها على السلسلة. يمكن بناء القنوات الافتراضية بين طرفين فوق قناة دفتر أستاذ موجودة، حيث يعمل مالك (أو مالكو) قناة دفتر الأستاذ كوسيط.

يتفاعل المستخدمون في كل قناة افتراضية عبر مثيل عقد جديد، مع قدرة قناة دفتر الأستاذ على دعم مثيلات عقود متعددة. تحتوي حالة قناة دفتر الأستاذ أيضًا على أكثر من حالة تخزين عقد واحدة، مما يسمح بالتنفيذ المتوازي للتطبيقات خارج السلسلة بين مستخدمين مختلفين.

تمامًا مثل القنوات العادية، يتبادل المستخدمون تحديثات الحالة لتقديم آلة الحالة. ما لم ينشأ نزاع، لا يلزم الاتصال بالوسيط إلا عند فتح القناة أو إنهائها.

قنوات الدفع الافتراضية

تعمل قنوات الدفع الافتراضية بناءً على نفس فكرة قنوات الحالة الافتراضية: يمكن للمشاركين المتصلين بنفس الشبكة تمرير الرسائل دون الحاجة إلى فتح قناة جديدة على السلسلة. في قنوات الدفع الافتراضية، يتم توجيه تحويلات القيمة من خلال وسيط واحد أو أكثر، مع ضمانات بأن المستلم المقصود فقط هو من يمكنه تلقي الأموال المحولة.

تطبيقات قنوات الحالة

المدفوعات

كانت قنوات سلسلة الكتل المبكرة عبارة عن بروتوكولات بسيطة سمحت لمشاركين بإجراء تحويلات سريعة ومنخفضة الرسوم خارج السلسلة دون الحاجة إلى دفع رسوم معاملات عالية على الشبكة الرئيسية. اليوم، لا تزال قنوات الدفع مفيدة للتطبيقات المصممة لتبادل وإيداع الإيثر والرموز.

تتمتع المدفوعات القائمة على القنوات بالمزايا التالية:

1. قدرة المعالجة: كمية المعاملات خارج السلسلة لكل قناة غير مرتبطة بقدرة المعالجة لإيثيريوم، والتي تتأثر بعوامل مختلفة، خاصة حجم الكتلة ووقت الكتلة. من خلال تنفيذ المعاملات خارج السلسلة، يمكن لقنوات سلسلة الكتل تحقيق قدرة معالجة أعلى.

2. الخصوصية: نظرًا لأن القنوات موجودة خارج السلسلة، لا يتم تسجيل تفاصيل التفاعلات بين المشاركين على سلسلة كتل إيثيريوم العامة. يتعين على مستخدمي القناة التفاعل على السلسلة فقط عند تمويل وإغلاق القنوات أو تسوية النزاعات. وبالتالي، فإن القنوات مفيدة للأفراد الذين يرغبون في معاملات أكثر خصوصية.

3. زمن الوصول: يمكن تسوية المعاملات خارج السلسلة التي يتم إجراؤها بين المشاركين في القناة على الفور، إذا تعاون كلا الطرفين، مما يقلل من التأخير. في المقابل، يتطلب إرسال معاملة على الشبكة الرئيسية انتظار العقد لمعالجة المعاملة، وإنتاج كتلة جديدة بالمعاملة، والوصول إلى إجماع. قد يحتاج المستخدمون أيضًا إلى انتظار المزيد من تأكيدات الكتلة قبل اعتبار المعاملة نهائية.

4. التكلفة: قنوات الحالة مفيدة بشكل خاص في المواقف التي ستقوم فيها مجموعة من المشاركين بتبادل العديد من تحديثات الحالة على مدى فترة طويلة. التكاليف الوحيدة المتكبدة هي فتح وإغلاق العقد الذكي لقناة الحالة؛ سيكون كل تغيير في الحالة بين فتح وإغلاق القناة أرخص من سابقه حيث يتم توزيع تكلفة التسوية وفقًا لذلك.

يمكن أن يؤدي تنفيذ قنوات الحالة على حلول طبقة 2 (L2)، مثل التجميعات، إلى جعلها أكثر جاذبية للمدفوعات. في حين أن القنوات تقدم مدفوعات رخيصة، فإن تكاليف إعداد العقد على السلسلة على الشبكة الرئيسية خلال مرحلة الفتح يمكن أن تصبح باهظة الثمن—خاصة عندما ترتفع رسوم الغاز. تقدم التجميعات القائمة على إيثيريوم رسوم معاملات أقل (opens in a new tab) ويمكن أن تقلل النفقات العامة للمشاركين في القناة عن طريق خفض رسوم الإعداد.

المعاملات الصغيرة

المعاملات الصغيرة هي مدفوعات منخفضة القيمة (على سبيل المثال، أقل من جزء من الدولار) لا يمكن للشركات معالجتها دون تكبد خسائر. يجب على هذه الكيانات الدفع لمقدمي خدمات الدفع، وهو ما لا يمكنهم القيام به إذا كان الهامش على مدفوعات العملاء منخفضًا جدًا لتحقيق ربح.

تحل قنوات الدفع هذه المشكلة عن طريق تقليل النفقات العامة المرتبطة بالمعاملات الصغيرة. على سبيل المثال، يمكن لمزود خدمة الإنترنت (ISP) فتح قناة دفع مع عميل، مما يسمح له ببث مدفوعات صغيرة في كل مرة يستخدم فيها الخدمة.

بخلاف تكلفة فتح وإغلاق القناة، لا يتكبد المشاركون تكاليف إضافية على المعاملات الصغيرة (لا توجد رسوم غاز). هذا وضع مربح للجانبين حيث يتمتع العملاء بمرونة أكبر في المبلغ الذي يدفعونه مقابل الخدمات ولا تفقد الشركات المعاملات الصغيرة المربحة.

التطبيقات اللامركزية

مثل قنوات الدفع، يمكن لقنوات الحالة إجراء مدفوعات مشروطة وفقًا للحالات النهائية لآلة الحالة. يمكن لقنوات الحالة أيضًا دعم منطق انتقال الحالة التعسفي، مما يجعلها مفيدة لتنفيذ التطبيقات العامة خارج السلسلة.

غالبًا ما تقتصر قنوات الحالة على التطبيقات البسيطة القائمة على الأدوار، حيث يسهل ذلك إدارة الأموال الملتزم بها في العقد على السلسلة. أيضًا، مع وجود عدد محدود من الأطراف التي تقوم بتحديث حالة التطبيق خارج السلسلة على فترات، فإن معاقبة السلوك غير النزيه أمر مباشر نسبيًا.

تعتمد كفاءة تطبيق قناة الحالة أيضًا على تصميمه. على سبيل المثال، قد يقوم المطور بنشر عقد قناة التطبيق على السلسلة مرة واحدة ويسمح للاعبين الآخرين بإعادة استخدام التطبيق دون الحاجة إلى الانتقال إلى السلسلة. في هذه الحالة، تعمل قناة التطبيق الأولية كقناة دفتر أستاذ تدعم قنوات افتراضية متعددة، كل منها يقوم بتشغيل مثيل جديد للعقد الذكي للتطبيق خارج السلسلة.

حالة الاستخدام المحتملة لتطبيقات قناة الحالة هي ألعاب بسيطة ثنائية اللاعبين، حيث يتم توزيع الأموال بناءً على نتيجة اللعبة. الفائدة هنا هي أن اللاعبين لا يضطرون إلى الوثوق ببعضهم البعض (انعدام الحاجة للثقة) وأن العقد على السلسلة، وليس اللاعبين، هو الذي يتحكم في تخصيص الأموال وتسوية النزاعات (اللامركزية).

تشمل حالات الاستخدام المحتملة الأخرى لتطبيقات قناة الحالة ملكية أسماء ENS، ودفاتر أستاذ الرموز غير القابلة للاستبدال (NFT)، وغيرها الكثير.

التحويلات الذرية

اقتصرت قنوات الدفع المبكرة على التحويلات بين طرفين، مما حد من قابليتها للاستخدام. ومع ذلك، سمح إدخال القنوات الافتراضية للأفراد بتوجيه التحويلات من خلال وسطاء (أي قنوات نظير إلى نظير متعددة) دون الحاجة إلى فتح قناة جديدة على السلسلة.

توصف المدفوعات الموجهة عادةً بأنها "تحويلات متعددة القفزات"، وهي ذرية (أي إما أن تنجح جميع أجزاء المعاملة أو تفشل تمامًا). تستخدم التحويلات الذرية عقود القفل الزمني المجزأة (HTLCs) (opens in a new tab) لضمان تحرير الدفع فقط في حالة استيفاء شروط معينة، مما يقلل من مخاطر الطرف المقابل.

عيوب استخدام قنوات الحالة

افتراضات الحيوية

لضمان الكفاءة، تضع قنوات الحالة حدودًا زمنية لقدرة المشاركين في القناة على الرد على النزاعات. تفترض هذه القاعدة أن النظراء سيكونون دائمًا متصلين بالإنترنت لمراقبة نشاط القناة والطعن في التحديات عند الضرورة.

في الواقع، يمكن للمستخدمين قطع الاتصال بالإنترنت لأسباب خارجة عن إرادتهم (مثل ضعف الاتصال بالإنترنت، أو عطل ميكانيكي، وما إلى ذلك). إذا انقطع اتصال مستخدم صادق بالإنترنت، يمكن لنظير ضار استغلال الموقف من خلال تقديم حالات وسيطة قديمة لعقد التحكيم وسرقة الأموال الملتزم بها.

تستخدم بعض القنوات "أبراج المراقبة"—وهي كيانات مسؤولة عن مراقبة أحداث النزاع على السلسلة نيابة عن الآخرين واتخاذ الإجراءات اللازمة، مثل تنبيه الأطراف المعنية. ومع ذلك، يمكن أن يضيف هذا إلى تكاليف استخدام قناة الحالة.

عدم توفر البيانات

كما أوضحنا سابقًا، يتطلب الطعن في نزاع غير صالح تقديم أحدث حالة صالحة لقناة الحالة. هذه قاعدة أخرى مبنية على افتراض—أن المستخدمين لديهم إمكانية الوصول إلى أحدث حالة للقناة.

على الرغم من أن توقع قيام مستخدمي القناة بتخزين نسخ من حالة التطبيق خارج السلسلة أمر معقول، إلا أن هذه البيانات قد تُفقد بسبب خطأ أو عطل ميكانيكي. إذا لم يكن لدى المستخدم نسخة احتياطية من البيانات، فلا يمكنه سوى أن يأمل ألا يقوم الطرف الآخر بجعل طلب خروج غير صالح نهائيًا باستخدام انتقالات حالة قديمة بحوزته.

لا يضطر مستخدمو إيثيريوم إلى التعامل مع هذه المشكلة لأن الشبكة تفرض قواعد على توفر البيانات. يتم تخزين بيانات المعاملات ونشرها بواسطة جميع العقد وتكون متاحة للمستخدمين لتنزيلها إذا لزم الأمر وعند الضرورة.

مشكلات السيولة

لإنشاء قناة سلسلة كتل، يحتاج المشاركون إلى قفل الأموال في عقد ذكي على السلسلة طوال دورة حياة القناة. يقلل هذا من سيولة مستخدمي القناة ويقصر القنوات أيضًا على أولئك الذين يمكنهم تحمل إبقاء الأموال مقفلة على الشبكة الرئيسية.

ومع ذلك، يمكن لقنوات دفتر الأستاذ—التي يديرها مزود خدمة خارج السلسلة (OSP)—أن تقلل من مشكلات السيولة للمستخدمين. يمكن لنظيرين متصلين بقناة دفتر أستاذ إنشاء قناة افتراضية، والتي يمكنهم فتحها وجعلها نهائية بالكامل خارج السلسلة، في أي وقت يريدون.

يمكن لمزودي الخدمات خارج السلسلة أيضًا فتح قنوات مع نظراء متعددين، مما يجعلها مفيدة لتوجيه المدفوعات. بالطبع، يجب على المستخدمين دفع رسوم لمزودي الخدمات خارج السلسلة مقابل خدماتهم، وهو ما قد يكون غير مرغوب فيه للبعض.

هجمات الإزعاج (Griefing attacks)

تعد هجمات الإزعاج سمة شائعة للأنظمة القائمة على إثبات الاحتيال. لا يفيد هجوم الإزعاج المهاجم بشكل مباشر ولكنه يسبب إزعاجًا (أي ضررًا) للضحية، ومن هنا جاء الاسم.

إثبات الاحتيال عرضة لهجمات الإزعاج لأن الطرف الصادق يجب أن يرد على كل نزاع، حتى النزاعات غير الصالحة، أو يخاطر بفقدان أمواله. يمكن لمشارك ضار أن يقرر نشر انتقالات حالة قديمة بشكل متكرر على السلسلة، مما يجبر الطرف الصادق على الرد بالحالة الصالحة. يمكن أن تتراكم تكلفة تلك المعاملات على السلسلة بسرعة، مما يتسبب في خسارة الأطراف الصادقة في هذه العملية.

مجموعات المشاركين المحددة مسبقًا

حسب التصميم، يظل عدد المشاركين الذين يتألفون من قناة الحالة ثابتًا طوال فترة حياتها. وذلك لأن تحديث مجموعة المشاركين من شأنه أن يعقد تشغيل القناة، خاصة عند تمويل القناة، أو تسوية النزاعات. كما أن إضافة أو إزالة المشاركين سيتطلب نشاطًا إضافيًا على السلسلة، مما يزيد من النفقات العامة للمستخدمين.

في حين أن هذا يجعل قنوات الحالة أسهل في الفهم، إلا أنه يحد من فائدة تصميمات القنوات لمطوري التطبيقات. يفسر هذا جزئيًا سبب التخلي عن قنوات الحالة لصالح حلول توسيع النطاق الأخرى، مثل التجميعات.

المعالجة المتوازية للمعاملات

يرسل المشاركون في قناة الحالة تحديثات الحالة بالتناوب، ولهذا السبب تعمل بشكل أفضل مع "التطبيقات القائمة على الأدوار" (على سبيل المثال، لعبة شطرنج ثنائية اللاعبين). يلغي هذا الحاجة إلى التعامل مع تحديثات الحالة المتزامنة ويقلل من العمل الذي يجب أن يقوم به العقد على السلسلة لمعاقبة ناشري التحديثات القديمة. ومع ذلك، فإن أحد الآثار الجانبية لهذا التصميم هو أن المعاملات تعتمد على بعضها البعض، مما يزيد من زمن الوصول ويقلل من تجربة المستخدم الإجمالية.

تحل بعض قنوات الحالة هذه المشكلة باستخدام تصميم "مزدوج الاتجاه بالكامل" (full-duplex) يفصل الحالة خارج السلسلة إلى حالتين "أحاديتي الاتجاه" (simplex)، مما يسمح بتحديثات الحالة المتزامنة. تعمل مثل هذه التصميمات على تحسين قدرة المعالجة خارج السلسلة وتقليل تأخيرات المعاملات.

استخدام قنوات الحالة

توفر مشاريع متعددة تطبيقات لقنوات الحالة التي يمكنك دمجها في تطبيقاتك اللامركزية (dapps):

• Connext (opens in a new tab)
• Perun (opens in a new tab)
• Raiden (opens in a new tab)
• Statechannels.org (opens in a new tab)

قراءات إضافية

قنوات الحالة

• فهم حلول توسيع نطاق طبقة 2 (L2) لإيثيريوم: قنوات الحالة، وبلازما، وTruebit (opens in a new tab) – جوش ستارك، 12 فبراير 2018
• قنوات الحالة - شرح (opens in a new tab) 6 نوفمبر 2015 - جيف كولمان
• أساسيات قنوات الحالة (opens in a new tab) District0x
• قنوات حالة سلسلة الكتل: أحدث ما توصلت إليه التكنولوجيا (opens in a new tab)

هل تعرف موردًا مجتمعيًا ساعدك؟ قم بتعديل هذه الصفحة وأضفه!