حتى الآن، لا تزال أسطورة الرفاهية في دائرة العملات/صناعة blockchain مستمرة، والمجال المهم التالي المتمثل في "خلق الثروة" هو التركيز على "مسار اللعبة". يعقد مشروع XAI حدث Odyssey. إذا كنت مهتمًا، فيرجى المشاركة في مقالتي هذه على الساحة: دليل المبتدئين بدون تكلفة لحدث XAI Game Public Chain Odyssey.
في هذه المقالة سأقدم لكم شرحًا تفصيليًا لعقدة Sentry الخاصة بسلسلة ألعاب XAI العامة! هذه المقالة تقنية نسبيًا، لذا إذا كنت مهتمًا بكسب المال، فيجب عليك قراءتها بعناية. لأنه فقط إذا فهمت "المنطق" بنفسك وقمت بتحسين معرفتك، يمكن أن تتاح لك الفرصة لكسب المال!
إذا كنت تريد رؤية تفاصيل Sentry مباشرة، اقرأ الجزء الأول فقط ولا حاجة لباقي الأجزاء. وإذا كنت تريد دورة منطقية مغلقة، فستحتاج لقراءة الجزء الثاني والثالث والرابع!
أود أن أؤكد أن Xai تحصل على دعم تقني مباشر من Offchain Labs. هذا الدعم غير قابل للتصور بالنسبة لسلاسل Orbit الأخرى! وهو أيضاً عنصر حاسم ضمن خطة Xai الاستراتيجية كلعبة داخل منظومة Arbitrum.
الجزء الأول: شرح عقد Sentry
عقد Sentry هو عقد مراقبة لمتابعة بروتوكول Xai rollup، وإذا تم اقتراح كتلة خاطئة فسيرسل تنبيهاً (بأي طريقة يختارها مشغله) لكي يتمكن الآخرون من التدخل. الهدف من عقد Sentry هو حل مأزق المُتحققين (يُنظر شرح مأزق المُتحققين في الجزء الرابع).
انقر هنا لعرض فيديو التقديم:
تشغيل عقد Xai بنقرة واحدة والحصول على رموز Xai!
يمكن تشغيل عقد Sentry على أجهزة كمبيوتر محمولة للمجتمع أو أجهزة مكتبية أو حتى على خوادم سحابية. طالما أن العقد يعمل، تحدد خوارزمية احتمالية ما إذا كان مشغل العقد سيحصل على مكافآت esXai من الشبكة. ومن خلال الرهان على Xai، يمكن زيادة احتمال أن تفوز الخوارزمية. إذا لم تكن تعرف esXai، فشارك في هذه المقالة التي كتبتها في المربع (الساحة): XAI مشروع "اقتصاديات الرمز" — شرح
١. كيف تعمل عقد Sentry
يتعلق تحدّي بروتوكول Attention v2 بعدة مشاركين، من بينهم سلسلة Xai و"السلسلة الأم" (Arbitrum One)، وتحدّيُ (مُتحققٌ) موثوق به، وXai Sentries ومفتاح الترخيص الخاص بها، وعقد Referee (الحَكَم). ينشئ المُحدّي زوج مفاتيح BLS، ويسجّل المفتاح العام في عقد الحَكَم، ثم يوقّع الإقرارات التي يقوم بها المُتحققون ضمن بروتوكول Xai rollup على Arbitrum One. تُتحقق هذه التواقيع من قبل عقد الحَكَم وتُسجّل كتحديات مرتبطة بالادعاء (الإقرار).
يمكن لـ Xai Sentry تسجيل نفسها لدى عقد الحَكَم عن طريق شراء مفتاح ترخيص Sentry، وذلك ليصبح لديها أهلية لنشر ادعاءات حول الادعاء. تحصل على جذر حالة الادعاء الصحيح، والذي سيكون الجذر اللاحق الذي يحتوي على الادعاء المراد نشره. إذا تحقق شرط ما، فإنها تنشر ادعاءً عن الادعاء عن طريق استدعاء عقد الحَكَم. إذا تم إنشاء وتأكيد ادعاء لاحق، وقامت Sentry بنشر الادعاء الصحيح، فإن Sentry تتواصل مع عقد الحَكَم لنشر معاملة استرداد/إرجاع (redemption). قبل دفع المكافأة إلى Sentry، يتحقق عقد الحَكَم من عدة شروط.
يضمن هذا البروتوكول أن كل ادعاء يجب أن يستهلك بالكامل رسائل صندوق الوارد الموجودة وقت إنشاء ادعائه السابق. وهذا يعني أنه بمجرد إنشاء ادعاء، يصبح جذر الحالة للحالات اللاحقة الصحيحة مُحدداً بالكامل، ويمكن لأي عقدة حسابه. وهذا يشجع كل Sentry على تحديد جذر الحالة اللاحق الصحيح. تعتمد مكافأة Sentry على معرف تصريح حالة الـ Sentry وجذر الحالة اللاحق وقيمة تحدّي لا تصبح معروفة إلا بعد أن يصبح جذر الحالة اللاحق مُحدداً بالكامل.
٢. من يمكنه تشغيل العقد؟
يمكن لأي شخص تشغيل عقد Sentry بمجرد تنزيل برنامج محدد وتثبيته وتشغيله. لكن للحصول على مكافآت الرموز، يجب شراء ما لا يقل عن مفتاح ترخيص Sentry واحد.
يجب على المشتري اجتياز فحص KYC بنجاح لضمان أن:
ليس في الولايات المتحدة
لم يُفرض عليها أي عقوبات OFAC أمريكية (تظهر OFAC كقائمة عقوبات أمريكية)
لن تحصل عقد Sentry التي لا تعمل أو لا تملك تمويلاً كافياً لدفع رسوم الغاز (GAS) على مكافآت، حتى لو كانت لديها مفاتيح ترخيص. لذلك سيرغب المشغّلون في التأكد من أن عقدهم لديها أموال، وأنها متصلة بالإنترنت وتعمل.
٣. عقد Referee (الحَكَم)
Referee (الحَكَم) هو عقد ذكي مصمم لفرض مجموعة من القواعد المحددة مسبقاً، والتحقق من مصادر الإرسال، وتوزيع المكافآت على الفائزين داخل النظام. عقد الحَكَم هو مكوّن محوري في منظومة Xai، إذ يدير ويتحقق من الإقرارات التي يقدمها عقد Sentry داخل الشبكة. وله عدة وظائف رئيسية:
3.1 تقديم ادعاء
يتيح عقد الحَكَم لعقد Sentry تقديم ادعاءات إلى التحدّي. لا يمكن استدعاء هذه الميزة إلا بواسطة مالك مفتاح ترخيص Sentry أو العنوان الذي تم تفويضه من قبل هذا العقد. تتحقق هذه الميزة مما إذا كان التحدّي ما يزال مفتوحاً للتقديم، وما إذا كان NodeLicense قد قدم ادعاءً لهذا التحدّي بالفعل.
٣.٢ استلام المكافأة
يتضمن العقد وظيفة تسمح للمستخدم بمطالبة مكافأة عن الإقرار الناجح. تتحقق هذه الوظيفة مما إذا كان التحدي قد أُغلق للتقديم، كما تتحقق مما إذا كان مالك مفتاح عقدة الحارس (Node Key) قد أكمل فحص KYC. إذا تحققت هذه الشروط وكان الإقرار يطابق شروط الدفع، فسيتم إرسال المكافأة إلى المستخدم.
٣.٣ إنشاء تجزئة الادعاء والتحقق من الدفع.
للعقد وظيفة تتيح إنشاء معرف ترخيص Sentry ومعرف التحدّي وتجزيئة challengersSignedHash داخل التحدي، بالإضافة إلى تجزئة جذر الحالة اللاحقة. ثم يتحقق من أن التجزئة أقل من عتبة معينة، وتُحسب هذه العتبة بناءً على إجمالي عدد تراخيص Sentry التي تم سكها. إذا كانت التجزئة أقل من العتبة، فإن الادعاء يحقق شروط الدفع.
يضمن عقد الحَكَم، عبر التحقق من الإقرارات ومنح المكافآت للإقرارات الناجحة، تكامل شبكة Xai، وبالتالي يحفّز عقد الحراسة (Sentry) على المراقبة الدقيقة والمجتهدة للشبكة.
٤. مكوّن Challenger (مُحدّي)
التحدّي (Challenger) هو كيان موثوق ضمن منظومة Xai. ينشئ زوج مفاتيح BLS ويقوم بتسجيل المفتاح العام في عقد الحَكَم. عندما يقوم المُتحقق بتقديم ادعاء ضمن بروتوكول Xai rollup، يستخدم المُحدّي مفتاحه الخاص لتوقيع الادعاء ويرسل التوقيع إلى عقد الحَكَم. يتحقق عقد الحَكَم من التوقيع ويسجله كتحدي مرتبط بالادعاء. تضمن هذه العملية سلامة الإقرارات التي تتم في بروتوكول Xai rollup.
٥. المفاتيح (ترخيص مفاتيح عقدة الحارس Sentry، مبنية على NFT)
مفتاح ترخيص Sentry هو رمز غير قابل للاستبدال وفريد (NFT) ويلزم لتشغيل عقد Sentry في شبكة Xai. يعمل الترخيص كدليل على الأهلية لتقديم ادعاءات العقد واستلام المكافآت. يتم سكّ هذا الترخيص عبر إرسال الكمية الصحيحة من ETH، وتحدد سعر السّك آلية عتبة تصاعدية.
يلعب ترخيص العقد (Node License) دوراً حاسماً داخل عقد الحَكَم. عندما يريد العقد تقديم ادعاء إلى التحدّي، يجب أن يقدّم معرف ترخيص Sentry الخاص به. يتحقق عقد الحَكَم من صحة ترخيص Sentry وأن العقد هو مالك ترخيص Sentry أو أنه مشغل (operator) مفوض (كما ورد في قسم KYC أعلاه). إذا تحققت هذه الشروط، يتم تقديم ادعاء العقد إلى التحدّي.
عند مطالبة المكافآت عن الإقرارات الناجحة، يعمل ترخيص Sentry أيضاً. يتحقق عقد الحَكَم مما إذا كان مالك ترخيص Sentry قد أكمل KYC وما إذا كان الإقرار مطابقاً لشروط الدفع. إذا تم استيفاء هذه الشروط، تُرسل المكافأة إلى مالك ترخيص Sentry.
وخلاصة القول، فإن ترخيص Sentry هو عنصر رئيسي في شبكة Xai، إذ ينظم تشغيل عقد Sentry وتقديم الإقرارات وتوزيع المكافآت.
٦. تنزيل العقد وتشغيلها
لتشغيل عقد Sentry، يحتاج المستخدم فقط إلى تنزيل حزمة برمجية محددة. يمكن استخدام هذه الحزمة في تطبيق سطح المكتب على جهاز الكمبيوتر أو في أدوات سطر الأوامر. ببساطة، هذه التطبيقات هي أدوات تسهّل تشغيل برنامج Sentry. هدف هذه الحزمة هو إنجاز تلقائي لكل ما يلزم لتشغيل Sentry، بحيث يصبح الإعداد والاستخدام بسيطين للغاية، حتى لو لم تكن تفهم التقنية.
يساعد هذا الحِزم المستخدمين على إنجاز مهام مثل إعداد النظام وإدارته والتفاعل مع الأجزاء الأخرى، ويأتي بواجهة سهلة الاستخدام تمكن المستخدم من رؤية الإعدادات وتعديلها بسهولة. باستخدام هذه الحزمة، يمكن للمستخدمين التركيز أكثر على كيفية تشغيل النظام بشكل أفضل وكسب المزيد من مكافآت الرموز. يمكن للمستخدمين اختيار تشغيل هذه الحزمة كتطبيق سطح مكتب أو باستخدام أدوات سطر الأوامر، وكلاهما سهل للغاية، ما يجعل عملية التشغيل سلسة.
٧. وظائف محفظة Sentry
في منظومة Xai، تلعب محفظة Sentry دوراً محورياً في التفاعل بين عقد Sentry وعقد الحَكَم الذكي. تعمل المحفظة كوسيط/وكيل وسيط، مسؤولاً عن تقديم ادعاءات نيابةً عن الـ Sentry المعني. ويتم ذلك عبر وظائف محددة في عقد الحَكَم لا يمكن استدعاؤها إلا بواسطة مالك مفاتيح ترخيص Sentry أو العناوين التي يوافق عليها على هذا العقد.
يمكن لمحفظة Sentry إرسال ادعاءات إلى التحدّي عبر استدعاء دالة submitAssertionToChallenge في عقد الحَكَم. تتحقق هذه الدالة مما إذا كان التحدّي لا يزال مفتوحاً للتقديم، وما إذا كان NodeLicense قد قدم ادعاءً لهذا التحدّي بالفعل.
يمكن لمحفظة Sentry أيضاً استلام المكافأة عن الإقرارات الناجحة عبر استدعاء دالة claimReward في عقد الحَكَم. تتحقق هذه الدالة مما إذا كان التحدّي قد تم إغلاقه للتقديم، كما تتحقق مما إذا كان مالك ترخيص Sentry قد أكمل فحص "KYC". إذا تم استيفاء هذه الشروط وكان الإقرار يحقق شروط الدفع، فسيتم إرسال المكافأة إلى مالك ترخيص Sentry.
وخلاصة القول، تعمل محفظة Sentry كمُرسال تُسهّل التفاعل بين العقد والمحكّم، مما يضمن التشغيل السلس لشبكة Xai.
٨. تصريح الترخيص
العلاقة بين عدد التراخيص وإمكانية تقديم العقد (submit) هي علاقة أساسية. على الرغم من أنه من الممكن أن يرتبط عقد واحد بعدة تراخيص، يجب فهم أن عدد التراخيص يؤثر مباشرة على قدرة العقد على الإرسال. وبشكل جوهري، ولضمان حصص إرسال عادلة، يتم الحفاظ على نسبة التراخيص إلى مثيلات العقد عند 1:1. باتباع المبادئ أعلاه، يبني النظام نهجاً منظماً لترخيص حقوق الإرسال والتشغيل العام للعقد داخل النظام البيئي.
٩. متطلبات البرمجيات والأجهزة لعقد Sentry
برنامج Sentry يدعم سطح المكتب بنظام Windows وMac وLinux (يتطلب 64 بت). فيما يلي الموارد الحالية المطلوبة لتشغيل برنامج Sentry الذي يمكنه تشغيل حتى 100 مفتاح ترخيص:
4 جيجابايت RAM
2 نواة CPU
60 جيجابايت مساحة قرص
معالج x86/X64 (يدعم معالجات ARM مثل Apple M1/M2)
اتصال إنترنت مستقر
عند إضافة مفاتيح إضافية إلى العقد، يجب نظرياً أن تزداد القدرة العتادية. ومع ذلك، ليس إلزامياً تخصيص آلة منفصلة لكل مفتاح. من المتوقع أن القدرة على التوسع للنظام يمكن أن تستوعب عشرات المفاتيح على آلة واحدة، أو ربما أكثر.
ملاحظة: قد تتغير هذه المتطلبات الخاصة بالأجهزة.
10. مكافآت الشبكة المتوقعة لعقد Sentry
اطّلع على نموذج اقتصاديات رمز XAI: XAI مشروع "اقتصاديات الرمز" — شرح
فيما يلي ثلاث حالات لتقدير مكافآت Xai التي قد يحصل عليها عقد Sentry. تفترض هذه الحالات الشروط التالية:
مجموع XAI وesXAI لن يتجاوز أبداً 2,500,000,000. وبما أن نظام Xai البيئي ديناميكي، فمن غير الممكن توقع مكافآت الرموز الشهرية لكل مفتاح Sentry بدقة.
يتم حرق 100% من الغاز، لذلك لا يمكن ضمان أن العرض دائماً تضخمي؛ ومن الممكن أن يكون انكماشياً.
لن يبيع صندوق Xai Foundation أكثر من 50,000 مفتاح Sentry (ويمكن للعقد تحميل عدة مفاتيح). ومن المتوقع أن يستغرق ذلك 2-3 سنوات. سيزداد سعر مفاتيح Sentry مع مرور الوقت.
كما يمكن أن تتقلب كمية esXAI الشهرية لكل مفتاح Sentry حسب عدد المشاركين المراهنين في النظام البيئي.
تعني الجداول الثلاثة أدناه أن عدد مفاتيح العقد (Node Keys) المُفعّلة في الشبكة والمكافآت المتوقعة الشهرية لكل مفتاح من الرموز تختلف بحسب أحجام التداول المختلفة لرموز XAI وesXAI:
تقدير الحالة A: إذا كان العدد الإجمالي للرموز المتداولة هو 750,000 XAI وesXAI، فسيحصل كل مفتاح Sentry على مكافأة esXAI وفقاً للجدول التالي:
تقدير الحالة B: إذا كان العدد الإجمالي للرموز المتداولة هو 1,250,000,000 XAI وesXAI، فسيحصل كل مفتاح Sentry على مكافأة esXAI وفقاً للجدول التالي:
تقدير الحالة C: إذا كان العدد الإجمالي للرموز المتداولة هو 2,187,500,000 XAI وesXAI، فسيحصل كل مفتاح Sentry على مكافأة esXAI وفقاً للجدول التالي:
الجزء الثاني: XAI تم تطويرها وصيانتها بواسطة Arbitrum (ARB)، لذا يتعين علينا شرح بعض جوانب بنية Arbitrum:
1. Arbitrum Nitro
كل سلاسل Arbitrum مبنية على Arbitrum Nitro، وهي البنية التحتية الأساسية لكل السلاسل في النظام البيئي. يشغّل Nitro نسخة متفرعة من Geth ويستخدم WebAssembly كآلة افتراضية أساسية لأدلة الاحتيال.
2. Arbitrum Anytrust
Anytrust هو بروتوكول ضمن Arbitrum تتم إدارته عبر مجموعة مُرخصة تُسمى "لجنة توافر البيانات" (DAC). يقلل هذا البروتوكول رسوم المعاملات عبر إدخال افتراض ثقة إضافي حول توافر البيانات، بدل استخدام آلية توافر بيانات دون ثقة تعتمد على Ethereum.
٣. مقدمة Arbitrum Layer 2 التي قد تكون تعرفها
Arbitrum Nova مثال على سلسلة AnyTrust؛ وArbitrum One هي سلسلة بديلة تطبق بروتوكول Arbitrum Rollup دون ثقة تماماً (كما أنها تستهلك L1-gas أكثر). كلتا السلسلتين مبنيتان على Nitro.
٤. سلسلة Orbit
يتيح Arbitrum Orbit لطرف ثالث إنشاء rollup Arbitrum مُدار ذاتياً وسلاسل AnyTrust الخاصة به. يوفّر Arbitrum تقنيات Rollup وAnyTrust لتحقيق أقصى مرونة عند بناء سلاسل Orbit. وكما هو الحال مع جميع السلاسل داخل منظومة Arbitrum، تُبنى سلاسل Arbitrum Rollups وArbitrum Anytrust Orbit باستخدام Nitro كتقنية أساسية.
٥. فهم أساسيات Xai
في هذا السياق، دعونا نفهم Xai. تعمل Xai كسلسلة Arbitrum Orbit باستخدام تقنية Anytrust لتحقيق أعلى سرعة بأقل تكلفة. على عكس أغلب سلاسل Orbit "الإدارة الذاتية"، تستفيد Xai من دعم تقني مباشر من Offchain Labs. هذا الدعم غير قابل للتصور بالنسبة لسلاسل Orbit الأخرى! وهو جزء حاسم من خطة Xai الاستراتيجية كلعبة داخل منظومة Arbitrum.
الجزء الثالث: بعد أن أصبحت لديك هذه المفاهيم، لنتعمق أكثر في بنية النظام.
١. AnyTrust: بنية تحتية للبلوك تشين تُحدث ثورة
ضمن إطار AnyTrust، باعتباره نسخة متقدمة من تقنية Arbitrum Nitro، تستخدم Offchain Labs ابتكاراً لمعالجة بعض أكثر تحديات البلوك تشين إلحاحاً. يمنح AnyTrust منظوراً جديداً عبر إدخال افتراضات ثقة خفيفة، مما يقلل التكاليف بشكل ملحوظ مع الحفاظ على توافر بيانات قوي وأمان قوي.
٢. تقليل التكاليف عبر افتراضات الثقة
في قلب بروتوكول Arbitrum، يحتاج كل عقد Arbitrum (بما في ذلك المُتحققون الذين يتحققون من صحة سلسلة التحقق ويقومون بالرهان على النتائج الصحيحة) إلى الوصول إلى بيانات كل معاملة من معاملات طبقة ثانية (L2) الموجودة في "صندوق وارد" Arbitrum. تقليدياً، ضمن Arbitrum rollup، يتم ضمان الوصول إلى البيانات عبر نشر البيانات على الطبقة الأولى (L1) الخاصة بـ Ethereum في شكل calldata، وهذا يولد كمّاً كبيراً من رسوم غاز Ethereum، وهي الجزء الأكبر من التكلفة في Arbitrum.
٣. مرونة Ketsets
تلعب Ketsets دوراً محورياً داخل بنية AnyTrust. فهي تحدد عدد التواقيع المطلوبة لمفاتيح عامة لأعضاء اللجنة وبيانات توفر البيانات المتاحة (DACert). وتمنح Ketsets المرونة لتغيير أعضاء اللجنة وتمكنهم من تحديث مفاتيحهم عند الحاجة.
٤. شهادات توافر البيانات (DACerts)
في AnyTrust، هناك مفهوم أساسي هو شهادة توافر البيانات (DACert). تتضمن DACert تجزئة كتلة البيانات ووقت انتهاء الصلاحية ودليلاً على أن N-1 من أعضاء اللجنة قد وقعوا على (التجزئة، وقت الانتهاء). ويتضمن هذا الدليل تجزئة مجموعة مفاتيح (key set) المستخدمة في التوقيع، وخرائط بت تُشير إلى أي أعضاء اللجنة وقعوا، وتوقيع تجميعي BLS على منحنى BLS12-381 يثبت أن الموقّعين قد وقعوا.
بسبب افتراض الثقة 2-of-N، يُعد DACert دليلاً يبيّن أن بيانات الكتلة ستكون متاحة على الأقل لدى عضو واحد صادق في اللجنة حتى وقت انتهاء الصلاحية المحدد. يشكّل افتراض الثقة هذا أساس موثوقية وأمان توافر البيانات ضمن إطار AnyTrust.
٥. آلية نشر بيانات مزدوجة
يقدم AnyTrust طريقة مزدوجة لنشر كتل البيانات على L1. بالإضافة إلى النشر التقليدي للكتل كاملة البيانات، يسمح بنشر DACerts، وهي شهادات تثبت توافر البيانات. يقوم عقد صندوق وارد L1 بالتحقق من صلاحية DACerts، بما في ذلك Ketsets الصالحة المشار إليها ضمن DACert المرجعية.
يتولى كود L2 مسؤولية قراءة البيانات من صندوق الوارد، وتم تصميمه للتعامل بسلاسة مع نوعي تنسيق البيانات. عند مواجهة DACert، يجري فحوصات الصلاحية، بما في ذلك التأكد من أن عدد الموقّعين يلبي متطلبات Ketsets، والتحقق من توقيعات التجميع، والتأكد أن وقت الانتهاء يتجاوز الطابع الزمني الحالي لـ L2. تضمن DACerts الفعّالة إمكانية الوصول إلى كتل البيانات، وأن كود L2 يمكنه استخدامها.
٦. خوادم توافر البيانات (DAS)
يشغل أعضاء اللجنة خوادم توافر البيانات (DAS)، وهي توفر API رئيسيتين:
(1) واجهة API للـ Sequencer: مُصممة خصيصاً لمدير التسلسل (sequencer) على سلسلة Arbitrum. يتيح هذا JSON-RPC للـ sequencer تقديم كتل البيانات إلى DAS بغرض التخزين.
(2) REST API: مصمم لزيادة إمكانية الوصول، يسمح بروتوكول مبني على RESTful HTTP(S) باسترجاع كتل البيانات عبر التجزئة. وهو قابل للتخزين المؤقت بالكامل، ويمكن عند النشر دمجه مع خوادم وكيلة للتخزين المؤقت أو شبكات CDN لتعزيز قابلية التوسع والحماية من هجمات DoS المحتملة.
٧. تفاعل الـ Sequencer-اللجنة
عندما ينوي مُرتّب Arbitrum نشر حزمة بيانات عبر اللجنة، فإنه يرسل البيانات ووقت انتهاء الصلاحية إلى جميع أعضاء اللجنة بالتوازي عبر RPC. يقوم كل عضو في اللجنة بتخزين البيانات وتوقيع (تجزئة، وقت انتهاء الصلاحية) باستخدام مفاتيح BLS وإرجاع التوقيع ومؤشر نجاح إلى المُرتّب. بمجرد جمع توقيعات كافية، يجمع المُرتّب هذه التوقيعات ليُنشئ DACert صالحاً على أساس (التجزئة، وقت انتهاء الصلاحية). ثم يتم نشر DACert هذا إلى عقد صندوق الوارد على L1 ليصبح متاحاً لبرمجيات سلسلة AnyTrust التابعة لـ L2. إذا لم يستطع المُرتّب جمع توقيعات كافية ضمن نطاق الوقت المحدد، فإنه يتبع سياسة "الارتداد إلى rollup" حيث ينشر البيانات الكاملة مباشرة على سلسلة L1. تتقن برمجيات L2 التعامل مع نوعي تنسيق نشر البيانات (عبر DACert أو عبر البيانات الكاملة)، وتعالج كل تنسيق بشكل مناسب. باختصار، يمثل AnyTrust ابتكاراً رائداً داخل منظومة Offchain Labs، وهو يمثل تقدماً حاسماً في معالجة كفاءة التكلفة فيما يتعلق بتوافر البيانات والأمان وبنية البلوك تشين التحتية. وبافتراض ثقة مدروس وبطريقة جديدة لنشر البيانات، يمهد AnyTrust الطريق لحلول بلوك تشين أكثر قابلية للتوسع وقابلية للوصول والأمان.
الجزء الرابع: بعد أن أصبحت لديك هذه المفاهيم، سنشرح لماذا عقد Sentry مهم: مشكلة التحقق من الغش، ولماذا يكون مأزق المُتحققين أكثر صعوبة مما تتوقعه، والحل!
المؤلف: Ed Felten، كبير العلماء في Arbitrum
في أنظمة البلوك تشين، هناك نمط تصميم شائع يتمثل في أن يقوم طرفٌ بعملٍ ما ويقوم بإيداع ضمان مقابل السلوك الصحيح، ثم نُشرك آخرين للتحقق من هذا العمل وأخذ هذا الضمان إذا وجدوا أن العامل قد غشّ. يمكنك تسمية ذلك بنمط تصميم "ادعاء-تحدّي". نفعل هذا في Arbitrum، وقد شاهدت مؤخراً في الأخبار اقتراحات مثل Optimistic Rollup أيضاً.
قد تتأثر هذه الأنظمة بمأزق المُتحققين، وبشكل أساسي يمكنك ملاحظة التالي: إذا كنت تعرف أنهم لن يغشوا، فإن التحقق من عمل شخص ما لن يكون له أي معنى؛ لكن إذا لم تتحقق، فسيكون لديهم دافع للغش. إذا كنت مصمماً، فستريد إثبات أن نظامك متوافق مع الحوافز— أي أنه إذا تصرف الجميع بما يتماشى مع حوافزهم، فلن يحدث الغش. وهذه فكرة بديهية قد تضللك. إن المشكلة أصعب بكثير مما يبدو، وسنرى ذلك عندما نفكك حوافز الأطراف المختلفة أدناه.
نموذج بسيط للغاية
أولاً، نبني أبسط نموذج يمكن بناؤه. نفترض أن لدينا لاعبين: يقدم المدّعي ادعاءً قد يكون صحيحاً وقد يكون خاطئاً. يمكن للمُتحقق التحقق من ادعاء المدّعي، أو يمكنه اختيار عدم فعل أي شيء، على الأغلب اعتماداً على فرضية أن المدّعي قد يكون يقول الحقيقة. نفترض أن تكلفة التحقق للمُتحقق هي C، وإذا تحقّق ووجد أن المدّعي يغش، يحصل المُتحقق على مكافأة R. (تشمل R جميع المنافع التي يحصل عليها المُتحقق بسبب التقاط الغش. وهذا يشمل المنافع التي تُحقق خارج النظام، وأي منافع ناتجة عن زيادة الثقة في النظام). إذا غش المدّعي دون أن يُقبض عليه، فسوف يخسر المُتحقق L، على سبيل المثال لأن المدّعي الغشاش يمكنه احتيالاً أخذ شيء ذي قيمة من المُتحقق.
الآن يتعين علينا القلق بشأن تهديدين: الرشوة والكسل. الرشوة هي احتمال أن يقوم المدّعي برشوة المُتحقق حتى لا يتحقق، مما يسمح للمدّعي بالغش دون أن يتم اكتشافه. يمكننا منع ذلك عبر ضمان أن المدّعي يودع ضماناً كبيراً جداً؛ يكون هذا الضمان أكبر من القيمة الإجمالية في النظام، ويتم دفعه إلى المُتحقق عند اكتشاف الغش. بهذه الطريقة لن يرغب المدّعي في دفع رشوة تتجاوز مكافأة المُتحقق R. هذا يمنع الرشوة لكنه يتطلب نظاماً مؤمناً بالكامل (fully collateralized)، ما قد يكون مكلفاً للغاية.
تهديد آخر هو الكسل: خطر أن يقرر المتحققون عدم التحقق من عمل المدّعي. (تذكر أن المتحققين قد يقولون إنهم يتحققون، لكنهم في الحقيقة لا يفعلون ذلك). لننظر إلى حوافز المتحققين لمعرفة ما إذا كانت هذه استراتيجية معقولة.
افترض أن المدّعي يغش باحتمال X. الآن تكون منفعة المُتحقق كما يلي:
إذا قام المُتحقق بالتحقق: RX - C
إذا لم يتحقق المُتحقق: -XL
فقط عندما تكون فائدة التحقق أكبر من فائدة عدم التحقق يكون التحقق جديراً بالاهتمام، أي عندما كان X > C/(R+L). ولدي خبر سيّئ: يمكن للمدّعي أن يغش عشوائياً، بحيث يكون احتمال الغش أقل من C/(R+L)، ولن يقوم المدققون (التحققون) مطلقاً بالتحقق لأنهم لن يجدوه يستحق الجهد، وبالتالي فلن يُقبض على المدّعي أبداً وهو يمارس الغش.
لنضع أرقاماً. إذا كانت تكلفة كل تحقق لكل معاملة هي 0.10 دولار، وكان المُتحقق إذا اكتشف الغش يحصل على مكافأة قدرها 75 دولاراً، بينما إذا فشل في اكتشاف الغش سيخسر 25 دولاراً، فإن المدّعي يمكنه الغش 1000 مرة دون أي عقوبة. إذا أردنا تشغيل هذا النظام لآلاف المعاملات، فلدينا مشكلة كبيرة. في هذا النموذج، لا يمكننا بالطبع أن نجعل احتمال الغش يقترب من الصفر. كل ما يمكننا فعله هو أن نأمل أن تؤدي زيادة الضمان المقدم (over-collateralization) إلى جعل المقام C/(R+L) أكبر.
هذه نتيجة متينة بشكل مُفاجئ — لكن بطريقة سيئة. فهي لا تعتمد إطلاقاً على حوافز المدّعين. طالما أن المدّعي يستطيع الحصول على ميزة غير صفرية من الغش الناجح، يمكنه أن يفعل ذلك باحتمال ما، عالماً بأن المُتحققين لن يجدو التحقق مُجدياً من حيث الجهد. كما لا تعتمد هذه النتيجة على مقدار الوقت الذي نعطيه للمتحققين للقيام بالعمل، أو ما إذا كنا ندفع (للمتحققين المزعومين) أجراً. ربما تتساءل الآن: المشكلة هي أن هناك مُتحققاً واحداً فقط. هل إضافة المزيد من المتحققين يقلل احتمال الغش؟ بشكل مُفاجئ، لا يفعل ذلك.
إضافة متحققين لا تساعد في منع الغش
مرة أخرى، لنضع أبسط نموذج ممكن. الآن لدينا مُتحققان يقومان بخطوات مستقلة. كل مُتحقق يدفع C إذا قام بالتحقق، وإذا قام أيٌّ منهما بالتحقق ونجح في التقاط غش المدّعي فستُدفع مكافأة R للمُتحقق الناجح، أما إذا قام كلاهما بالتحقق فستُقسم المكافأة بالتساوي بين الشخصين. (إذا أحببت، في حالة تحققهما معاً يمكنك إعطاء أحدهما كامل مكافأة R عشوائياً. هذا لا يؤثر على استراتيجيات أي شخص أو النتائج.) وكما في السابق، يخسر كل مُتحقق L إذا غشّ المدّعي دون أن يتم القبض عليه.
لا يزال الأمر كما هو: إذا كان المدّعي يغش لمدة أقل من C/(R+L)، فلن يكون التحقق مجدياً لأن فائدة التحقق أقل من فائدة عدم التحقق. والواقع أن مشكلة الحوافز أسوأ من قبل، لأن تكلفة التحقق لكل مُتحقق تبقى C، لكن المكافأة المتوقعة التي يلتقطها المُحقق الناجح من الغش تكون أقل من R، لأن المكافأة تُقسَّم أحياناً — والمكافأة المتوقعة ستكون بين R/2 وR. إذا كانت المكافأة المتوقعة تساوي bR حيث b بين 0.5 و1، فيمكن للمدّعي أن يغش حتى bR/(bR+L) من الزمن— أي C/(bR+L) — وهذا يزيد من الغش غير المكتشف مقارنة بوجود مُتحقق واحد فقط! (قد تبدو الرياضيات أعقد قليلاً لأن قيمة b تعتمد على استراتيجية المُتحققين، والتي تعتمد بدورها على b، لكن من المفترض أن يكون واضحاً أنهم سيحتاجون أحياناً إلى تقسيم المكافأة. كما أن القيمة الفعلية لـ L تنخفض أيضاً، لأن مُتحققاً لا يقوم بالتحقق قد لا يخسر L بسبب تحقق الآخرين.)
هناك فائدة حقيقية لإضافة مُتحققين إضافيين وهي منع الرشوة. مع وجود مُتحققين اثنين، يجب على المدّعي دفع رشوة أكبر من R لكل مُتحقق، ما يجعل الرشوة مضاعفة التكلفة وبالتالي يسمح بإيداع 50% فقط بدل الإيداع الكامل. لكن المقابل هو أن عدد حالات الغش يزيد.
لن أشرح كل الرياضيات هنا، لكن ضمن افتراضات معقولة، فإن إضافة مُتحقق من واحد إلى اثنين قد يؤدي إلى زيادة الغش غير المكتشف بنسبة 50%.
إضافة المزيد من المتحققين تجعل الأمور أسوأ!
يمكنك إضافة المزيد من المتحققين، وستصبح الأمور أسوأ. مع زيادة عدد المتحققين، سيحتاج المتحققون إلى القلق أكثر بشأن تقسيم المكافأة بطرق متعددة، لذلك تنخفض المكافأة المتوقعة لكل مُتحقق ناجح تدريجياً، مما يؤدي إلى ارتفاع احتمال قيام المدّعي بالغش بأمان تدريجياً. ومن هذا المنظور، فإن أسوأ حالة هي أن كل شخص في العالم قد يصبح متحققاً. وليست الأمور سيئة بلا حدود، لأن كلما زاد عدد المتحققين أصبحت الأمور أسوأ أكثر وأكثر، لكنها بالتأكيد لن تمنع الغش — حتى لو أنها قد تلغي فعلياً مخاطر الرشوة.
هل أنت متأكد أن نظامك متوافق مع الحوافز؟
إذا كان لديك نظام مناسب لهذا النوع من النماذج، وتعتقد أنه متوافق مع الحوافز، فستحتاج إلى التفكير بعناية في السبب. تحديداً، تحتاج إلى تفسير لماذا يقوم المتحققون بعمل التحقق حتى لو كانوا يعتقدون أن المدّعي لا يُرجح أن يغش. ليس كافياً وجود عقوبة كبيرة للغش فقط. ليس كافياً وجود مكافأة لالتقاط الغش فقط. ليس كافياً وجود عدد كبير من المتحققين — بل قد يجعل الأمور أسوأ. فلماذا يكون نظامك محصّناً؟
ينطبق هذا التحدّي على أنظمة مثل Optimistic Rollup. وعندما نتحدث عن Arbitrum، ينطبق الشيء نفسه علينا أيضاً.
وبناءً على ما سبق، فإن أساليب التحقق التقليدية من الحوافز لم تُفضِ إلى النتيجة المرجوة — توجد نسبة ثابتة للغش؛ فالتحققون الذين تكون نسبة الغش لديهم أقل من هذه النسبة سيعتبرون أن التحقق غير مجدٍ. باختصار:
لدينا لاعبان: مدّعٍ يقدم ادعاءً إما صحيحاً أو خاطئاً، ومُتحقق يمكنه التحقق من هذا الادعاء لكن مع تكلفة حسابية. إذا قام المُتحقق بالتحقق، تكون منفعةُه RX - C، وإذا لم يتحقق فتكون منفعةُه -XL، حيث R مكافأة التقاط الغش، وC تكلفة التحقق، وL خسارة المُتحقق بسبب عدم اكتشاف الغش، وX احتمال غش المدّعي (يختاره المدّعي). تُظهر بعض الحسابات الجبرية أنه إذا كان X < C/(R+L)، فلن يبذل المُتحقق جهداً للتحقق، وبذلك يستطيع المدّعي الهروب من كمية كبيرة من الغش.
لحل هذه المشكلة وإنشاء سيناريو يكون فيه مُتحقق مدفوع بالحوافز يقوم دائماً بالتحقق، يتعين علينا تغيير حوافز المُتحققين. المشكلة الأساسية في النموذج الأصلي هي أن الحوافز التي تدفع المُتحقق للقيام بالتحقق تكون متناسبة مع X، أي مع احتمال الغش. لذلك يمكن للمدّعي جعل هذه الأجزاء صغيرة ما دام لا يغش كثيراً. إذا أردنا حافزاً للقيام بالتحقق بغض النظر عن كل شيء، نحتاج إلى إنشاء حافز تحقق مستقل عن سلوك المدّعي — أو حافز/عدم حافز لعدم التحقق.
يُحاول TrueBit تحقيق ذلك بإضافة ادعاءات خاطئة عمداً إلى مجموعة الادعاءات؛ وبشكل جوهري يستبدل X بـ X مع إضافة ثابت. توجد بعض المشكلات في هذا الأسلوب. (تحتوي الورقة الأصلية لـ Arbitrum على قسم حول مشكلة الحوافز الخاصة بـ TrueBit.)
تحدّي الاهتمام
نستخدم نهجاً مختلفاً نُسميه "تحدّي الاهتمام". فكرته هي أنه إذا كان المدّعي يقوم بحساب قيمة f(x)، فإنه ينشر أولاً x وتحدّياً مُشفّراً. ولكي يستجيب المُتحققون بشكل صحيح للتحدّي، عليهم معرفة f(x). لا ينشر المدّعي f(x) إلا بعد حدوث التحدّي — وعندها يكون المُتحققون قد أنهوا فعلياً العمل الشاق المتمثل في حساب f(x)، لذا لا تكون لديهم دوافع الكسل. (مزيد من التفاصيل حول البروتوكول أدناه.)
لتقليل عدد المعاملات على السلسلة التي نحتاجها، سننظم الأمور بحيث يكون استجابة المُتحققين الصحيحة للتحدّي غالباً صامتة. ولكن في حالات نادرة، سيتعين على المُتحقق نشر معاملة صغيرة على السلسلة. إذا قدّم المُتحقق إجابة خاطئة — أي نشر عندما كان يفترض أن يبقى صامتاً، أو العكس — فسيفقد إيداعاً صغيراً.
لنعدّل نموذج الحوافز الأصلي ليشمل تحدي الاهتمام. نحتاج إلى معلمتين جديدتين (يمكننا اختيار أيهما): P، وهي نسبة الوقت التي يستجيب فيها المتحقق بشكل صحيح من لحظة نشر الإجابة/المعلومة، وA، وهي غرامة إذا أعطى المتحقق إجابة خاطئة. الآن تكون منفعة المتحقق كما يلي:
إذا كان التحقق: RX - C
إذا لم يتحقق: -LX - PA
الملاحظة الأساسية هي أنه طالما كان PA > C، فإن التحقق هو الاستراتيجية المثلى، بغضّ النظر عن قيمة X (احتمال الغش).
التكلفة منخفضة جداً
لتقييم التكلفة، دعونا نأخذ مثالاً ملموساً. نفترض أنه يوجد ادعاء واحد كل خمس دقائق، وأن تكلفة التحقق هي 0.001 دولار. إذا ضبطنا احتمال P على 0.3%، فسيتعين على المُتحقق دفع وديعة قدرها 3 دولارات. الآن، تكون تكلفة المُتحقق لكل ادعاء عبارة عن رسوم غاز قدرها 0.0003 دولار (0.10 دولار كتكلفة غاز لنشر رده غير الصامت، مضروبة في احتمال 0.3% أنه سيحتاج إلى نشر الرد)، بالإضافة إلى تكلفة فائدة تقريباً قدرها 0.0003 دولار على وديعته البالغة 3 دولارات لمدة خمس دقائق، بإجمالي تكلفة قدرها 0.0006 دولار لكل ادعاء.
توسيع إضافة مُتحققين متعددين
يتوسع تحدّي الاهتمام جيداً عندما يكون هناك عدة متحققين. إذ يرسل البروتوكول تحدياً يؤثر بشكل مختلف على كل مُتحقق، ما يجبر كل واحد منهم على حساب f(x بنفسه. يمر كل مُتحقق بالتكلفة نفسها (في مثالنا، 0.0006 دولار لكل ادعاء).
في نظام مفتوح، يكون أي شخص مؤهلاً للتحقق من الحساب. لذلك يمكنك السماح لأي شخص بالتسجيل كمتحقق ووضع الإيداع الصغير المطلوب. سيمنحهم ذلك الأهلية لتلقي الاهتمام بالتحدي، وقد يحصلون على تعويض من مطوري الـ dapp. يمكن لأي شخص أن يثير تحدياً ضد ادعاء غير صحيح من المدّعي، لكن فقط المتحققين المسجلين هم من سيتعرضون للتحدي المُثقل/المطالبة بالتحقق.
التفاصيل التقنية للبروتوكول
بعد أن فهمنا ما الذي يمكن أن يفعله تحدّي الاهتمام لنا، لنتعمق في التفاصيل التقنية لكيفية عمله.
لكل مُتحقق مفتاح خاص k ومفتاح عام g^k يقابله، ويُعرّف ضمن مجموعة مناسبة. جميع مفاتيح كل مُتحقق العامة معروفة للجميع. كما سنعتمد على دالة تجزئة مناسبة H.
لإصدار تحدي لحساب f(x)، حيث تكون الدالة معروفة مسبقاً، يقوم المدّعي بتوليد قيمة عشوائية r ثم ينشر (x, g^r) كـ تحدي.
يجب على المتحقق الذي لديه المفتاح الخاص k أن يستجيب للتحدّي، ولا يرسل معاملة صغيرة إلا عندما يكون H(g^r^k, f(x)) < T، حيث T هي عتبة يتم اختيارها بشكل مناسب. لاحظ أن حساب الهاش يتطلب معرفة f(x). كما لاحظ أن الحساب يمكن فقط للمدّعي (الذي يعرف r) وللمتحقق المحدد (الذي يعرف مفتاحه الخاص k) لأنه لا أحد سوى هذين يمكنه حساب g^r^k. كذلك، يجب معرفة f(x) لحساب الهاش.
بعد أن ينشر المتحققون استجاباتهم للتحدّي لفترة من الوقت، يمكن للمدّعي أن ينشر f(x). إذا لم يوافق أي متحقق، فسيتم تحديه كما هو الحال دائماً. عند هذه النقطة، يمكن للمدّعي توجيه الاتهام لأي متحقق قدم استجابة غير صحيحة؛ ويجب على المدّعي نشر r لإثبات اتهامه. يمكن للمعدنين أو العقود التحقق مما إذا كانت الاتهامات صحيحة، ومعاقبة المخطئ/المخالف؛ لكن إذا لم يتم قبول f(x) المزعومة في النهاية على أنها صحيحة، فسيتم تجاهل الاتهامات. إذا تم تغريم أي متحقق، فسوف يحصل المدّعي على نصف الأموال المصادرة، وسيتم حرق النصف الآخر.
تمنح هذه الطريقة المتحققين الحوافز الصحيحة. معرفة كيفية استجابة مُتحقق للتحدي يتطلب معرفة المفتاح الخاص للمُتحقق وكذلك f(x)، لذلك يرغب كل مُتحقق في حساب f(x). لا يمكنه تنفيذ البروتوكول بأمان ما لم يكن هو نفسه يحسب f(x). استجابات المتحققين الآخرين لا تفيد في تحديد f(x) لأنها تعتمد على مفاتيحهم الخاصة. إذا اعتمد مُتحقق على الآخرين لإخبارِه بـ f(x)، فلن تكون لديه طريقة للتحقق من القيمة المزعومة (باستثناء حساب f(x) بنفسه)، وإذا كانت الإجابة خاطئة فسيتعرض المتحقق لخطر العقوبة. بل وحتى أن هناك طرفاً لديه حافز لتضليل المتحققين بشأن المعلومات المتعلقة بـ f(x) — وهو المدّعي، الذي يستفيد من أخطاء المتحققين، وقد يستخدم هذه الأرباح لرشوة "أصدقاء" المتحققين لإمداد المتحقق بمعلومات خاطئة.
التحسين والخلاصة
هناك عدة حيل تجعل هذا البروتوكول أكثر كفاءة. مثلاً، يمكننا ربط ادعاء واحد بالتحدّي التالي، وإدراجه في معاملة واحدة على السلسلة، بحيث لا يزيد التحدّي عدد المعاملات. إذا كان P صغيراً (مثل 0.3% في مثالنا) وكان عدد المتحققين ليس كبيراً، فإن المُتحققين سيحتاجون إلى كتابة معاملات على السلسلة بشكل نادر، وبذلك يكون الأثر الإجمالي للبروتوكول على عدد معاملات السلسلة ضئيلاً للغاية.
بفضل التنفيذ الذكي، يجب أن تكون تكلفة هذا البروتوكول منخفضة جداً مقارنة بالتكلفة الأولية لنشر ادعاءات على السلسلة. في مثالنا، فإن إضافة تحدّي الاهتمام إلى بروتوكول ادعاء-تحدّي الحالي تضيف تكلفة إجمالية أقل من 1%.
وعائدات هذا الأمر ملموسة — فنحصل على بروتوكول تحقق متوافق مع الحوافز، دون أن يتأثر بمأزق المُتحقق. طالما أن واحداً على الأقل من المتحققين عقلاني، فإن ادعاءات المدّعين ستتم مراجعتها دائماً.
لمزيد من المعلومات حول المشروع، راجع: سلسلة ألعاب بلوك تشين Xai: مكتبة بيانات منصة Binance Square