قنوات الحالة

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

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

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

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

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

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

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

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

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

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

قنوات الدفع

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

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

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

قنوات الحالة

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

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

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

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

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

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

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

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

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

فتح القناة

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

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

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

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

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

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

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

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

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

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

إغلاق القناة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. الحيوية

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

2. الأمان

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

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

3. النهائية

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

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

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

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

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

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

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

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

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

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

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

المدفوعات

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

قنوات الحالة

• فهم حلول قابلية التوسّع للطبقة الثانية في إيثريوم: قنوات الحالة، وبلازما، وتروبيت (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)

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