حالة دليل الاحتيال في ETH L2

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

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

نظام "المرحلة" ل Rollup هو إطار لتقييم مستوى أمانه بشكل تقريبي ، من المرحلة 0 إلى المرحلة 2. في ال Rollup الرئيسي حاليًا ، تحققت Arbitrum و Optimism فقط من المرحلة 1 ، بينما يظل معظم Rollup التفاؤلي الآخر في المرحلة 0 حتى الآن.

في هذا السياق، ظهرت بعض المشاكل:

منذ إطلاق Optimistic Rollup قبل ثلاث سنوات، لماذا لم يصل أي مشروع إلى المرحلة 2 العليا حتى الآن؟ متى يمكن التوقع بأن يصل Optimistic Rollup إلى المرحلة 2؟

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

1.2. مقارنة بين التفاؤلي رول اب و زد كي رول اب

كما هو معروف، فإن سرعة إثيريوم بطيئة وتكلفة الغسيل الأموال عالية. يعمل باحثو ومطورو مجتمع إثيريوم على حل هذه المشكلة. بعد استكشاف حلول مثل المشاركة والبلازما، اتفق المجتمع في النهاية على أن Rollup هو الطريقة الرئيسية لتحقيق التوسع. لذلك، ظهرت Rollup مثل Arbitrum و Optimism و zkSync. وفقًا لبيانات L2Beat، هناك حاليًا حوالي 40 Rollup يعملون، بالإضافة إلى بعض الحلول مثل Validium و Optimium التي تتبنى نظام alt-DA لتحقيق مزيد من التوسع، مما يرفع العدد الإجمالي إلى حوالي 41. بالإضافة إلى ذلك، من المتوقع أن يتم إطلاق حوالي 80 سلسلة Rollup جديدة.

（الوضع الحالي L2 | المصدر: L2Beat)

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

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

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

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

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

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

لضمان القدرة على حل مشاكل مثل L1 审查等攻击的之意 بأمان، يكون وقت الإستجابة لسحب Optimistic Rollup عادة حوالي أسبوع واحد.

1.3. لماذا نحتاج إلى دليل على الاحتيال؟

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

بدون دليل قوي على آلية الاحتيال ، لا يمكن ل Optimistic Rollup أن يرث أمان Ethereum بالكامل. على سبيل المثال ، في نظام المدققون الحالي المصرح به في Arbitrum ، إذا تواطأ جميع المدققون ، فيمكنهم سرقة جميع الأموال في عقد الجسر. وبالمثل ، في مجموعات التحديثات المستندة إلى OP Stack مثل Base ، يمكن ل alAuditorون ضار واحد سرقة الأموال لأنه لم يتم بعد تنفيذ آلية إثبات الفشل بدون إذن على الشبكة الرئيسية.

لذلك، يلعب دليل على الاحتيال دورًا حاسمًا في أمان Optimistic Rollup ، وأي نظام يفتقر إلى آلية دليل على الاحتيال الكاملة يشكل خطرًا على أصول المستخدم.

سيتم تقييم المخاطر التي تواجهها جميع تقنيات Optimistic Rollup المختلفة وفحص تنفيذ آليات الاحتيال الخاصة بها ومزاياها وعيوبها.

1.4. الانتقال إلى المرحلة 2: "إزالة العجلات الداعمة"

لعب دليل على نظام الاحتيال دورا رئيسيا في مساعدة Optimistic Rollup على تحقيق المرحلة 2. يتم استخدام إطار المرحلة المقترح من Vitalik ، والذي يتم تشغيله حاليا بواسطة L2Beat ، لتقييم مستوى أمان عمليات التراكم.

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

إليك الاهداف التفصيلية لكل مرحلة من المرحلة 0 إلى المرحلة 2:

كما ذكر في النص السابق ، فمن الضروري لتحقيق مرحلة 1 أو مرحلة 2 من Optimistic Rollup تنفيذ نظام مناسب لدليل على الاحتيال وآلية التحدي. وبناءً على هذه المعايير ، يجب أن يتوفر في نظام دليل على الاحتيال الذي يلبي متطلبات المرحلة 2 السمات التالية:

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

في الجزء الثاني من هذا المقال، سنستكشف كيف حاولت مجموعة متنوعة من البروتوكولات تحقيق هذه الوظائف.

2. دليل على الاحتيال - المفهوم والتوهم

2.1. كيف يتم تنفيذ دليل الاحتيال؟

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

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

دليل على الاحتيال和质疑بروتوكول通常包括以下步骤：

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

2.2. 常见误解：دليل على الاحتيال与质疑不会التراجع链

需要注意的是，即使发生دليل على الاحتيال和质疑，链也不会被التراجع。دليل على الاحتيال确保的是“الجسر合约中的资金不会被恶意提取”，而不涉及不正确状态转换的التراجع。

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

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

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

2.3. حالة واقعية: شكوك في أبريل 2024 حول Kroma

من خلال حالات الشك العملية، يمكن رؤية أن الشبكة الفرعية لن تتمالك الأمور، وسيتم استبدال أو حذف الجذر الناتج فقط. حتى الآن، لا يُعرف حالات ناجحة معروفة الوقوع على الشبكة الرئيسية، باستثناء حالة Kroma في أبريل 2024، وهو نوع من ال Rollup المختلط يعتمد على OP Stack ويستخدم ZK Proof of Failure.

Kroma هو OP Stack based Rollup ، لديها نظام توثيق خاص بها ونظام مدققون بدون إذن. في 1 أبريل 2024 ، واجهت مشكلة في مصدر L1 لمنظم Kroma ، مما أدى إلى إنشاء كتلة غير صحيحة بواسطة المنظم. بعد تقديم جذر الإخراج الخاطئ من قبل المدققون الذين لاحظوا هذا الوضع ، تم تشكيل 12 شخصًا يشككون في هذا الإخراج.

أحد المشككين نجح في استدعاء وظيفة proveFault وحذف الناتج الخاطئ.

نجح المشكك في تنفيذ وظيفة proveFault | المصدر:etherscan

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

免责声明：دليل على الاحتيال还是故障证明？

دليل على الاحتيال يُشار إليه أيضًا باسم دليل الفشل. ولا سيما في سلاسل الأمل و OP Stack، يُستخدم مصطلح 'دليل الفشل'، في حين يتم استخدام مصطلح 'دليل على الاحتيال' في مشاريع مثل Arbitrum و Cartesi و L2Beat.

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

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

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

3. هجوم القراصنة! - الاستفادة من آلية دليل على الاحتيال

3.1. تصميم النزاعات الاقتصادية بروتوكول

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

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

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

换句话说，每个دليل على الاحتيال和质疑机制都需要考虑如何应对ناقل الهجوم。如果不了解每个ناقل الهجوم，就无法理解为什么بروتوكول必须以这种方式设计。

因此，在本节中，我们将首先研究以下ناقل الهجوم，并探索各بروتوكول如何应对这些攻击：

نتيجة لهجوم ناشئ عن ثغرات في لعبة مثيرة للجدل؛
وقت الإستجابة攻击，延长用户提现时间超过 7 天；
هجوم سايبيل الذي يستهلك أموال وموارد المشاركين الصادقين؛
هجوم محفوظ بواسطة L1 المدققون الذي تم إثارته؛
استغلال الثغرات في الآلة الافتراضية لشن هجمات دليل على الاحتيال.

ملاحظة: جميع نواقل الهجوم المُناقشة أدناه معروفة علناً ولا تؤثر على أمان الشبكة الرئيسية بأي شكل.

الفصل التالي سيحلل كل بروتوكول وخصائص كل منها على النحو التالي: 01928374656574839201

3.2. ناقل الهجوم #1: استغلال لعبة النزاع الاقتصادي

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

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

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

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

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

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

3.2.1. ناقل الهجوم #1-1：وقت الإستجابة攻击

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

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

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

然而，需要考虑一些因素。如果攻击者不怕资金被التقطيع，仍然试图进行وقت الإستجابة攻击，该怎么办？

هذا الناقل الهجومي صعب جدًا. وهذا هو السبب في أن نظام دليل الاحتيال الخاص بـ Arbitrum يعمل حاليًا في هيكل الإذن.

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

نموذج فروع Arbitrum

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

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

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

نظرًا لأن كل استفسار قد يستغرق وقتًا يصل إلى 7 أيام، يمكن للمهاجم تمديد وقت استجابة البروتوكول إلى 7 * (N-1) يومًا.

تأخر الهجوم على Arbitrum Classic | المصدر: [L2Beat Medium] (https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

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

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

3.2.2. ناقل الهجوم #1-2: هجوم Sybil (هجوم استنزاف الموارد)

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

عادة ما يمكن أن يحدث ناقل الهجوم المذكور أعلاه في الأنظمة غير المرخصة عبر طريقتين:

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

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

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

让我们看看每个بروتوكول如何通过各自的设计来应对这些وقت الإستجابة和 Sybil 攻击。

3.3. الحل #1: لعبة منازعات اقتصادية صحيحة

1) التحكيم BoLD

على أساس نموذج الفروع في Arbitrum Classic ، قام BoLD بإدخال ثلاثة عناصر التالية لمنع ثغرات هجمات وقت الاستجابة:

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

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

لذلك ، إذا كان المهاجم يرغب في تقسيم البيانات الصادقة في BoLD بشكل متكرر ، يجب عليه تقديم عدة بيانات.

ومع ذلك، يتطلب إنشاء هذا البرهان استخدام المدققين لموارد الحساب الكبيرة. داخلياً، يتطلب إنشاء هذا البرهان القيام بالتجزئة لجميع الحالات في النصفين، وهو يقدر عادة في Arbitrum بحوالي 270 تجزئة (حوالي 1.18 × 10²¹). لحل هذه المشكلة، يقوم BoLD بتقسيم التحقيق إلى ثلاثة مستويات، مما يقلل من عدد التجزئة التي يتعين حسابها إلى 226 (حوالي 6.71 × 10⁷).

(يفترض هذا الرسم البياني وجود 269 تعليمة إجمالية ، قد تختلف البيانات الفعلية قليلاً)

通过棋钟机制限制التكديس时间。

في Arbitrum Classic السابق، لم يكن هناك حد زمني لمدة الشكوك، مما يسمح للمشاركين الخبيثين بالاستمرار لفترة غير محدودة طالما توفرت الأموال. قام BoLD بإدخال آلية ساعة الشطرنج التي تحد بفعالية مدة الشكوك.

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

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

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

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

حسبما تم حسابه في ملف الاقتصاد الجريء من Arbitrum، فإن البروتوكول يعاني من وقت الإستجابة الطويل بسبب مراجعة المدققين L1. في حالة هجوم وقت الإستجابة، سيحدث السيناريو التالي:

يقوم المهاجم بتأكيد بيان N الحالي على Arbitrum قبل تقديم بيان N' المختلف عنه.
يحاول المدافع إرسال صفقة ثنائية، ولكن بسبب فحص المدققون L1 للمدافع على صفقته المشكوك فيها، فإن هذا الإجراء يفشل.
نظرًا لأن افتراضات مراجعة BoLD لا يمكن أن تستمر لأكثر من 7 أيام، فقد يؤدي هذا إلى تأكيد البيان N في نهاية المطاف بحد أقصى أسبوع وقت الإستجابة.

يتمثل ربح المهاجم في تكلفة الفرصة التي تنشأ عندما يقدم مستخدمون مشكوك فيهم طلبات سحب. في أسوأ الحالات، يتم طلب سحب جميع الأموال في Arbitrum في إجراء واحد، ويتم حساب تكلفة الفرصة التي يتحملها المستخدم كما يلي: نفترض أن إجمالي القيمة المقفلة في Arbitrum One هو 15.4 مليار دولار، ومعدل العائد السنوي (APY) هو 5٪.

تكلفة الفرصة = 15,400,000 × (1.051/52 - 1) = 14,722,400 دولار

نظرًا لأن تقديم إعلان غير صحيح قد يترتب عليه تكلفة فرصة عالية جدًا ، يُطلب من مقدمي الإعلانات في BoLD تقديم إيداع مشابه بالحجم. حاليًا ، تم تعيين الوديعة المطلوبة لتقديم الإعلانات في BoLD بمبلغ 3600 ETH ، ما يعادل حوالي 9.4 مليون دولار.

هذا ما يجعلها مقاومة لوقت الإستجابة السلوك الهجومي، حيث يمكن للمهاجم أن يتكبد خسائر كبيرة وقدرها 19،283،746،565،748،392،019،283،746،565،748،392،019 دولار أمريكي نتيجة لفقدان الوديعة خلال الشك، والتي قد تكلفهم فرصة تصل إلى 14،700،000 دولار أمريكي على أقصى تقدير، ولكنهم سيخسرون حوالي 9،400،000 دولار أمريكي من الأموال. وبالتالي، يقوم BoLD بكبح الهجمات ذات وقت الإستجابة من خلال المطالبة بوديعة مقدارها يعادل تكلفة الفرصة في أسوأ الظروف.

ومع ذلك، لم يتم تحديد مبلغ الوديعة البالغ 3600 ETH فقط بسبب هجوم وقت الإستجابة. من أجل الدفاع عن هجوم Sybil، يمكن لـ Arbitrum BoLD ضمان أن النظام يبقى آمنًا قبل أن يكون إجمالي أموال المهاجم 6.5 مرة أكبر من إجمالي أموال المدافع، وهذا هو أساس تحديد مبلغ الوديعة البالغ 3600 ETH.

من منظور هجوم Sybil ، من الممكن حدوث سيناريوهات الهجوم التالية في Arbitrum BoLD. يتألف نظام BoLD للشكوى من ثلاث مستويات ، حيث يجب على المستخدمين تأمين الأموال لتقديم بياناتهم الصحيحة.

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

في نموذج الفروع Arbitrum، يعني تأمين الأموال الموافقة على حالة السلسلة من Genesis إلى الإعلان. تتيح هذه الميزة للمشاركين نقل الأموال التي رهنوها من البيان A إلى فرعي A' و A''. لذلك، قامت Alice بتحويل X ETH التي رهنتها أصلاً إلى الطبقة السفلية وقفلت Y ETH لكل بيان شرير من Bob.

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

في النهاية، يتم تحويل هذه المشكلة إلى مدى التفوق الذي يجب أن يكون لدى المدافع على الهجوم في اللعبة.

تسمي أربيترم هذا المؤشر نسبة الموارد. وهو يعكس مدى تفوق المشاركين الأمناء على المشاركين الخبيثين. يتم تمثيل هذه النسبة عن طريق نسبة الرسوم غاز (G) التي يتعين على كل مشارك دفعها ومبلغ الرهن (S)، والتي تظهر كما يلي:

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

（تكلفة رهن النزاعات على مستوى القمة مقابل نسبة موارد Arbitrum BoLD | المصدر:Desmos)

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

لذلك، في BoLD، يتم تعيين نسبة الموارد إلى 6.5 مرة، مما يجعل الوديعة العليا تبلغ 3600 ETH، ويتم تعيين الوديعة من المستوى الأول والثاني على التوالي إلى 555 ETH و 79 ETH.

في النهاية، يضمن BoLD من خلال حساب نسبة الموارد وتحديد المبلغ المرهون أن للدفاع 6.5 مرة أكثر من مهاجم، لمنع هجمات سايبيل.

2) كارتيسي ديف

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

من خلال حساب الحالة الصحيحة للبرهان (التزام التاريخي) لمنع الانقسام الثنائي الخبيث.

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

يتم استخدام آلية الاستجواب الفردية في هيكل بطولة واحدة.

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

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

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

الدليل البحثي لـ Cartesi يثبت أن الدفاع دائمًا يحتفظ بالميزة العددية على المهاجم في أي حالة. وبعبارة أخرى ، يضمن ديف أنه يمكنه الدفاع عن هجوم سايبيل باستخدام موارد اللوغاريتم الخاصة بكمية المهاجم. هذا يجعل من الصعب جدًا تنفيذ هجوم سايبيل في ديف ، ولذلك تم تعيين مبلغ الرهن الخاص بديف على أدنى قيمة ممكنة وهي 1 ETH ، وهي أقل بكثير من BoLD.

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

Td = 7 × log2(1 + NA) (أيام)

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

Td = 7 x [log2(1 + NA)]L(الأيام)

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

تهدف Cartesi إلى حل هذه المشكلة باستخدام دليل بدون معرفة (ZK)، وسيتم مناقشة ذلك بالتفصيل في القسم 4 'تحسينات ممكنة'.

3) ضمان الأخطاء المتفائل (OPFP)

OPFP هو بروتوكول غير مرخص للشكوك، ويتم حاليًا تطبيقه في الشبكة الرئيسية OP، وله السمات التالية:

استخدام شجرة اللعبة لجميع آليات الشكوك المتزامنة

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

هيكل شجرة الألعاب OPFP وعملية التقسيم الثنائي | المصدر: Optimism الملف

يتم القيام بعملية التقسيم إلى نصفين بشكل متزامن على شجرة اللعبة كما هو موضح في الشكل أعلاه. يُمثل أوراق الشجرة حالة L2 ، ويُمثل كل عقدة في الشجرة حالة واحدة في L2 ، ويُمثل أوراق الجهة اليمنى الأحدث حالة L2. على سبيل المثال ، إن إرسال البيان في العقدة 1 مكافئ لإرسال الحالة في العقدة 31.

هذا النوع من الهيكل يسمح بتمثيل الانقسام. على سبيل المثال، إذا لم يوافق المدققون على البيان الجذري (العقدة 1) ، فسيقدمون بيانًا في العقدة 2 ، والتي تتوافق مع العقدة 23 في الشجرة لأنها الوسط بين العقدة 16 والعقدة 31. ثم يقوم مقدم العقدة 1 بفحص حالة L2 في العقدة 23 ، وإذا وافق ، فسيقدم العقدة 6 (العقدة 27) ، وإذا لم يوافق ، فسيقدم العقدة 4 (العقدة 19) ، ويستمر هذا العملية حتى يتم العثور على الانقسام.

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

OPFP البنية الكاملة لشجرة الألعاب | المصدر: ملف التفاؤل

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

مختلف عن BoLD أو Dave، OPFP لا يفرض الانقسام الصحيح من خلال الالتزامات التاريخية، لأن تكلفة إنشاء وتقديم مثل هذه الالتزامات في وخارج السلسلة/داخل السلسلة مرتفعة.

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

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

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

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

عملية سحب الأموال للمستخدم في "مسار السعادة" | المصدر: مدونة OP Labs

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

هذا يثير سؤالًا: هل يمكن أن يستغرق سحب المستخدم وقت الاستجابة أكثر من أسبوع، مثل حالة BoLD؟ الجواب هو "نعم". بالاختلاف عن BoLD أو Dave، يوفر Optimism خيارات للمستخدمين للتعامل مع حالات الشك، وذلك بناءً على خصائص بروتوكوله الفريدة.

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

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

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

بيان استفادة من نجاح الأمان في Optimism | المصدر: L2Beat

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

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

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

هذا قد يثير شكوكا. يمكن لبوب أن يستغرق أطول وقت استجابة 3.5 يوم + 3 ساعات × أكبر عدد ممكن من الانقسامات. MAX_GAME_DEPTH لـ OPFP هو 73، مما يعني أن بوب يمكنه في الحالات الأطول إجراء عملية تقسيم لمدة 8 أيام. إذا قامت أليس أيضًا باتخاذ إجراءات مماثلة للشك، فقد يستغرق الانقسام حوالي 16 يومًا.

هل يعني هذا أن المستخدمين لن يتمكنوا من سحب أموالهم في غضون 16 يومًا؟ في الواقع ، ليس هذا صحيحًا ، لأن منطق السحب في Optimism يجعل هذا السيناريو غير ممكن. على عكس Arbitrum ، الذي يتطلب ضمان أن السحب يكون مدرجًا في كتلة L2 محددة ، يستخدم OP Stack آلية تخزين الإثبات ، حيث يتم تسجيل طلبات السحب في عقد L2ToL1MessagePasser في L2. هذا يعني أنه حتى لو استغرقت فترة الشك بوقت طويل بالنسبة للإخراج المحدد ، يمكن للمستخدمين الانتظار لإكمال الإخراج التالي وسحب أموالهم وفقًا لجذر التخزين الذي يتضمنه الإخراج. وبالتالي ، فإن المستخدمين لا يحتاجون إلى تحمل وقت الاستجابة الطويل في حال تم استفسار الكتلة التي طلبوها ، لأنهم يمكنهم استخدام الإخراج التالي.

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

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

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

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

此外，OPFP 中还有一个额外的وقت الإستجابةناقل الهجوم，即每个输出都得到连续质疑。在这种情况下，用户无法通过在下一个输出上证明来绕过وقت الإستجابة，导致整个بروتوكول被وقت الإستجابة。OPFP 通过要求参与者在每个二分级别التكديسالهامش 来应对这一点，الهامش 金额呈指数级增加，如下图所示。

مبلغ الهامش OPFP | المصدر: [ملف التفاؤل] (https://specs.optimism.io/fault-proof/stage-one/bond-incentives.html)

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

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

قد يكون هناك ناقل الهجوم سايبيل التالي في OPFP، وجميعها يمكن أن تؤدي إلى سرقة أموال المستخدم:

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

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

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

ومع ذلك ، يجب على Optimism تعديل الآلية لضمان تمتع المدافعين بمزيد من الميزات مقارنة بالهجوميين من أجل نقل OPFP إلى المرحلة 2. Optimism يعد بإصدار لعبة النزاع V2 لحل هذه المشكلة ، وسيتم الكشف عن المزيد من التفاصيل في الجزء 4 "التحسينات العملية".

4) Kroma ZK شهادة العُطَب (Kroma ZKFP)

Kroma هو L2 مبني على OP Stack، تم إطلاقه في سبتمبر 2023 على الشبكة الرئيسية بدون ترخيص كنظام الإثبات المستندة للأخطاء ZK. يتميز Kroma ZKFP بميزات مشابهة لـ OPFP، ولكن الجوانب المميزة تكمن في استخدامه لإنشاء إثبات مستوى الكتل ZK واستخدام فصل بدلاً من التقسيم الثنائي، وهو ما يقلل بشكل كبير من عدد التفاعلات المطلوبة في عملية التحدي. يمكن تلخيص السمات الرئيسية لـ Kroma ZKFP على النحو التالي:

تقليل عدد التفاعلات من خلال ZK والتحليل

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

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

من خلال تحقيق اللامركزية من خلال آلية الحوافز01928374656574839201

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

لهذا الغرض ، قامت Kroma بتعديل مكدس OP لتوزيع نصف رسوم الغاز التي تنشأ داخل السلسلة على المدققين الذين يقدمون المخرجات المقدمة. بالإضافة إلى ذلك ، تخطط Kroma للانتقال إلى آلية المكافأة هذه بعد TGE إلى عملتها الأصلية KRO ، وتهدف إلى إدخال نظام المدققين المشابه لـ DPoS لجعل المستخدمين العاديين قادرين على المساهمة في أمان السلسلة ونشاطها دون تشغيل عميلهم الخاص.

يتم تعيين الهامش في Kroma حاليًا على 0.2 ETH لضمان تغطية تكلفة إنشاء إثبات ZK وتقسيمها. سيتحول هذا الهامش في النظام المستقبلي للمدققون إلى تكديس KRO.

نظام التحدي 1 ضد 1 المتزامن

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

نظرًا لهذا الآلية، يعمل Kroma ZKFP ونظام الشك 1:1 المتزامن. عندما يقوم المدققون العشوائيون بتقديم الناتج، يمكن لأي شخص أن يبدأ بالشك، ويتم النقاش فقط بين الشخص الذي قدم الناتج والمشكك. يمكن أن يحدث العديد من عمليات الشك في نفس الوقت، وسيفوز أول مشكك قدم دليل ZK صالح.

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

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

يستمر المهاجم في تساؤل النتائج الصالحة حتى ينفد أموال المقدمة للنتائج، وفي هذا الوقت يقدم المهاجم البرهان ZK للفوز في الاستفسار.

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

وبالإضافة إلى ذلك، يظل Kroma ZKFP في المرحلة 0، ونظام الإثبات لا يزال غير كامل، وذلك للأسباب التالية:

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

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

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

هل تمت المراجعة الصحيحة لكل المدققون بناءً على البيانات الدفعية؟ لم يتم التحقق من هذه النقطة.

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

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

ومع ذلك، يمكن لجنة الأمان التدخل لسحب نتائج الشكوك الخاطئة أو حذف الإخراج غير الصالح في الممارسة، لذا لن تؤثر ناقلات الهجوم هذه على أموال مستخدمي الشبكة الرئيسية Kroma. ومع ذلك، يجب تنفيذ آلية دفاعية موجهة نحو هذه الثغرات للوصول إلى المرحلة 2 من Kroma ZKFP. وقدمت Kroma مقترحات لتحسين هذه المشكلات، وسيتم تفصيلها بشكل محدد في القسم 4 "التحسينات الممكنة".

3.4 ناقل الهجوم #2: L1 المراجعة

ذكرنا سابقا أن Rollup يورث أمان Ethereum. هذا يعني أنه إذا تعرض أمان Ethereum للخطر، فإن Rollup سيتأثر أيضا.

هناك حالتان قد تؤثر حالة Ethereum على أمان Rollup:

مُدققو بلوك ETH يقومون بمراجعة تحقق Rollup لعمليات الاحتيال إذا اتحد كاذبون أو بناة ETH الخاصون بالتحقق في Optimistic Rollup وقدموا جذور إخراج ضارة، وفحصوا جميع المعاملات المتعلقة بدليل على الاحتيال، ماذا سيحدث؟ قد يواجه رصيد المستخدمين مخاطر بسبب عدم القدرة على حل الشكوك في الوقت المحدد وتأكيد الإخراج. يُشار إليها باسم المراجعة الضعيفة. في حالة Optimistic Rollup، إذا استمرت هذه المراجعة لأكثر من الوقت المحدد (عادة ما يكون 7 أيام)، قد تتعرض أموال المستخدم للخطر.
تعرضت إثيريوم لهجوم بنسبة 51٪، مما أدى إلى مراجعة جميع المعاملات المشبوهة **هذا الوضع يشمل نوعين محتملين من مسارات الهجوم:

أولاً، يمكن لكيان ما الحصول على أكثر من 2/3 من إجمالي الإثيريوم، مما يتيح لهم تأكيد الكتل بحرية. في مثل هذه الحالة، يمكن للمهاجم مراجعة صفقات دليل على الاحتيال، وحتى إنشاء هذه الصفقات بشكل تقليدي.
تتضمن الطريقة الثانية مشاركا يمتلك أكثر من 1/3 من المبلغ الإجمالي ل ETH لتنفيذ هجوم "خفي". تم وصف ذلك في الدراسة "[هجمات الرقابة غير المنسوبة ضد دليل على الاحتيال بناء على دليل L2 بروتوكول" (https://ethresear.ch/t/non-attributable-censorship-attack-on-fraud-proof-based-layer2-protocols/6492). في هذه الحالة ، يمكن للمهاجم الذي لديه مربع 1/3 ETH التكديس حظر أي تأكيدات كتلة لا يحبها. إذا استمر أحد المهاجمين في التصويت على كتلة عادية مع التزام الصمت على كتلة تحتوي على دليل على الاحتيال، فقد يؤكد وجود جذر إخراج ضار لسرقة الأموال من مجموعة التحديثات المتفائلة. يعرف هذا باسم هجوم الرقابة غير المنسوب ضد دليل على الاحتيال استنادا إلى L2. يصعب اكتشاف هذا الهجوم أكثر من مجرد الحصول على أكثر من 2/3 من التكديس والسيطرة على جميع ETH.

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

3.5 الحل رقم 2: 7 أيام للسحب ووقت الإستجابة واستعادة الهجوم بنسبة 51٪ شبه تلقائي

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

دعونا نحلل ما إذا كانت فترة الاستفسار لمدة 7 أيام في Optimistic Rollup كافية لصد هجوم التدقيق ، سننظر في نوعين من التدقيق: التدقيق الضعيف وهجوم التدقيق القوي.

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

هنا، يجب أن نأخذ في الاعتبار عاملين:

للقيام بتحدي النجاح في غضون 7 أيام ، يجب أن تكون هناك عمليات تداول متعددة ناجحة.

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

(مراجعة بناء الكتلة الرئيسية لـ ETH | المصدر: تغريدة Justin Drake)

بناءً على هاتين النقطتين، إذا فرضنا أن 99.5% من المدققون (وهو افتراض مفرط) شاركوا في المراجعة وحسبنا احتمال أن ينجح المشاركون الصادقون في إثارة تساؤلات حول البروتوكول المطلوب لتبادل 30 إلى 40، مثل BoLD أو OPFP، فإن احتمال النجاح يقترب من 100% في جميع الحالات. بالإضافة إلى ذلك، مع ظهور حلول مستقبلية مثل إدراج القائمة أو وجود عدة مقترحين متزامنين، مثل BRAID، APS + FOCIL، قد يتزايد قدرة مقاومة المراجعة، مما يُسقط مخاطر فقدان أموال المستخدمين بسبب الرقابة الضعيفة لـ Optimistic Rollup.

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

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

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

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

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

بمعنى آخر ، حتى في حالة حدوث هجوم بنسبة 51٪ ، يجب أن تبقى الأموال مقفلة حتى يتم القيام بالفورك الاجتماعي. في هذه الحالة ، يعمل فترة السحب لمدة 7 أيام في Optimistic Rollup كمنطقة انتقالية. إذا لم يتم القيام بالفورك الاجتماعي خلال هذا الأسبوع ، فقد تتعرض أموال المستخدمين في Optimistic Rollup للسرقة ، ويمكن سحبها إلى البورصة المركزية ، أو عبر Tornado Cash للخلط ، مما يجعل من الصعب تقريبا استعادة الأموال للمستخدمين بعد الفورك الاجتماعي.

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

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

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

3.6 ناقل الهجوم #3：利用دليل على الاحتيال系统中的漏洞

يتم تقديم معظم الشكوك حول البروتوكول من خلال جعل المشاركين يجدون نقطة معينة (تعليمة أو كتلة) حيث تختلف آراؤهم، ثم توليد دليل يظهر أن ادعاء المشارك الآخر خاطئ. الآلة الافتراضية المستخدمة لتوليد هذا الدليل على الاحتيال تسمى آلة الاحتيال الظاهر (Fraud Proof VM)، والبرنامج المستخدم على تلك الآلة الافتراضية لتوليد الدليل يسمى برنامج (program)، كما هو موضح في كل بروتوكول يستخدم آلة احتيالية افتراضية وبرنامج مختلفين، كما يلي:

كل نظام دليل على الاحتيال يهدف إلى إثبات صحة نتيجة تنفيذ معينة في EVM داخل السلسلة. ولكن ماذا يحدث إذا كان هناك ثغرات في هذا النظام (سواء كانت آلة افتراضية أو برنامج)؟

يمكن مناقشة هذه المسألة من خلال ناقل الهجوم [الذي وجد في OVM] (https://medium.com/infinitism/optimistic-time-travel-6680567f1864) من قبل Yoav Weiss. نظرًا لوجود ثغرات في وظيفة التراجع في OVM، يصبح الهجوم ممكنًا، لكن الشرط الأساسي لتنفيذ الهجوم هو إنشاء "صفقات الاحتيال". تعد صفقات الاحتيال صفقات تُنفَّذ بشكل طبيعي على Rollup، ولكنها تعطي نتائج مختلفة عند التشكيك في الآلة الافتراضية والبرنامج المستخدمين. نظرًا لأن النظام يجب أن يولد نتائج مماثلة لـ EVM، فإن القدرة على إنشاء صفقات الاحتيال تعني وجود ثغرات في النظام.

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

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

هذا هو أيضًا واحد من أسباب تحويل نظام إثبات الأخطاء والأعطال الخاص بـ OP Mainnet مؤخرًا من نمط غير مرخص إلى نمط يسمح فقط للمشاركين المعتمدين بالانضمام إليه. بعد تطبيق OPFP على الشبكة الرئيسية، كشفت التدقيقات الأمنية عن نظام دليل على الاحتيال (Cannon و op-program) وعدة ثغرات في بروتوكول تحدي الألعاب المثيرة للجدل. ومن أجل منع استغلال النظام، أعلن Optimism في 17 أغسطس أنه سيتحول إلى نظام بالأذونات.

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

(إطار تدقيق مختبرات OP | المصدر: [منتدى التفاؤل] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864))

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

ومع ذلك، بمجرد تحديد الثغرات، من الضروري حل هذه المشكلات. قامت الOptimism بإصلاح هذه المشكلات في ترقية شبكتها Granite، مما يمكن OP Mainnet من العودة إلى المرحلة 1.

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

3.7 الحل رقم 3: البرهان المتعدد

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

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

على سبيل المثال ، تخيل نظامًا متعدد الأدلة يستخدم Optimism Cannon و asterisc ZK الآلة الافتراضية (باستخدام Risc-V). في حالة الاستفسار ، ستحدث الحالات التالية:

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

لعبة فرعية لـ Cannon باستخدام طريقة OPFP التقليدية. استخدام asterisc لإنشاء لعبة فرعية لإثبات فشل ZK.

بعد الانتهاء من اللعبتين ، سيتم التحقق من دليل احتيال مختلفين.

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

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

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

4. التحسينات الممكنة

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

4.1 تحسين مساحة كل بروتوكول

1) التحكيم BoLD

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

نسبة الموارد 6.5 مرة أصبحت ميزة ضئيلة للمدافع.
الإيداع الذي تم تقديمه للبيان الأساسي هو 3،600 ETH ، وهو مبلغ كبير جدًا.

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

هذا المفهوم مشابه لاقتراح BoLD++ الذي قدمه Gabriel من Cartesi. عندما يتم تقسيم الشكوك إلى مستويات متعددة ، فإن زيادة نسبة الموارد ستؤدي إلى زيادة مقدار الوديعة في أعلى مستوى بشكل متسارع. ومع ذلك ، يمكن زيادة نسبة الموارد بشكل أسهل عند استخدام مستوى واحد ، مما يجعل البروتوكول أكثر قدرة على مقاومة هجمات Sybil.

المشكلة الثانية تتمثل في أن تأمين عربون بقيمة 3600 ETH أصبح أكثر صعوبة في الحل. حجم عربون BoLD ليس فقط لمواجهة هجمات Sybil، ولكن أيضًا كردع لهجمات وقت الإستجابة. حجم العربون هو دالة لقيمة القفل الإجمالية (TVL)، وحتى مع استخدام ZK، فإنه لا يمكن أن يتم إسقاطه بشكل كبير. لحل هذه المشكلة، يقوم BoLD حاليًا بتنفيذ آلية عربون متعددة المشاركين، تسمح لعدة مشاركين بتحمل العربون معًا.

2) كارتيسي ديف

دافي تعامل بشكل فعال مع هجمات سيبيل من خلال هيكلية البطولة الخاصة به، ولكن كما ذكر سابقًا، فإنه عرضة لهجمات وقت الاستجابة. وقت الاستجابة الأقصى هو دالة تشمل عدد البيانات الخبيثة NA وعدد مستويات التكديس L، ويتم حسابها بالصيغة: Td = 7 x [log2(1 + NA)]L(الأيام)

إذا كان NA = 7 و L = 3، فقد يواجه البروتوكول وقت الاستجابة المستمر لمدة أربعة أشهر، مما يسبب إزعاجًا وخسائر واضحة للمستخدمين، لأن سيتم تأخير سحب الأموال بسبب وقت الاستجابة.

ZK يمكن أن يساعد في تخفيف هذه المشكلة. من خلال تثبيت المستوى L على 1 (مثل السطر في BoLD++)، يمكن تقليل وقت الاستجابة الأقصى إلى: Td = 7 × log2(1 + NA) (أيام)

وفقًا للتقارير، يستخدم Cartesi تقنية ZK ل RISC Zero لتحسين هذا. ومع ذلك، لا تزال هناك مخاوف بشأن ما إذا كان هذا التحسين كافيًا لمنع هجمات وقت الاستجابة بشكل كامل. إذا كان NA = 7، فإن البروتوكول قد يواجه لا يزال وقت استجابة إضافي يصل إلى أسبوعين، بينما تكون تكلفة المهاجم فقط إيداع 7 ETH، بالإضافة إلى رسوم الغاز وتكلفة التزامات السلسلة خارج السلسلة. قد لا تكون هذه العقوبة كافية لردع هجمات وقت الاستجابة على السلاسل ذات القيمة العالية.

(ديف: آلية الشك الفرعية ذات النمط الجريء | المصدر: L2Beat Medium)

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

Td = 7 x log8(1 + NA)(الأيام)

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

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

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

3) تحسين العيب في الأمان (OPFP)

إن عيب OPFP هو أنه عرضة لهجمات سايبيل بسهولة نظرًا لأن تكاليف الهجوم والدفاع متساوية. قدمت OP Labs حلاً لهذه المشكلة في لعبة الخلاف V2.

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

(بيان الفرع |. في لعبة الجدل V2.) المصدر: [مواصفات التفاؤل جيثب] ( https://github.com/ethereum-optimism/specs/pull/266/files?short_path=a65092f#diff-a65092f49218576d09f64d51a5ca42a7897032aec1ca5a9528d8d98c4b50532d))

في OPFP السابقة ، كانت لدينا عدة نقاط لهجمات سايبيل:

إنشاء الكثير من الشكوك لاستنزاف الهامش ورسوم الغاز الخاصة بالمدافع.
الإبلاغ المستمر عن نتائج زائفة لإجبار المدافع على الاستجابة واستنفاد موارده.

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

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

لذا يمكن لـ OPFP مواجهة هجمات Sybil بشكل فعال من خلال إعلانات الفروع المقدمة في لعبة النزاع V2.

4) كروما ZK خطأ برهان (كروما ZKFP)

يواجه Kroma ZKFP تحديين هما ضعف النظام الإثباتي والعرضي Sybil Attack. للتقدم إلى المرحلة 1 ، يجب حل المشكلتين التاليتين:

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

Kroma تخطط للانتقال من Scroll's Halo2 zkEVM إلى Succinct SP1 zkVM لحل هذين المشكلتين والمضي قدمًا إلى المرحلة 1.

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

بالنسبة للسؤال الثاني، سيستخدم Kroma الاستنتاج غير الموثوق به القائم على ZK. يعمل بالطريقة التالية:

（استنتاج غير موثوق به للعبة النزاع بدون ثقة الكاملة لاستخدام ZK | المصدر: Lightscale Notion）

تخيل، نحن نريد أن نثبت أن الكتلة T L2 المحددة تم تنفيذها بشكل صحيح. قبل إنشاء دليل ZK، يجب علينا التحقق مما إذا كانت بيانات المعاملات في الكتلة T مبنية بشكل صحيح على بيانات الدفعة L1.

هنا، يعتزم Kroma التحقق من صحة البيانات الجماعية المستخرجة من L1 من خلال التحقق من ZK. إذا تم الحصول على البيانات فقط من خلال RPC الموثوق به خارج برنامج ZK، فإنه لا يمكن التأكد مما إذا كانت البيانات الجماعية قد تم تزويرها. يمكن التحقق من ما إذا كان البرنامج قد دخل إلى كتلة صحيحة واستخرج البيانات الجماعية من خلال إنشاء دليل ZK لاتصالية كتلةالتجزئة، حيث تتراوح هذه الكتل من كتلة O (مصدر L1 لكتلة T في L2) إلى كتلة C (L1 كتلة عند إنشاء الشك). إذا بنى المشكك كتلة L2 T استنادًا إلى البيانات الجماعية الخاطئة، فإن الكتلةالتجزئة المشار إليها التي استخرج منها المشكك البيانات الجماعية لن تكون متطابقة مع الكتلةالتجزئة الفعلية التي تحتوي على البيانات الجماعية (بما في ذلك T1)، ولن تكون متصلة بالكتلة C أيضًا. لذلك، طالما لا يوجد تضارب في التجزئة، يمكن أن يثبت التحقق من اتصالية كتلة L1 عن طريق ZK أن المشكك قام ببناء كتلة L2 بناءً على البيانات الجماعية الصحيحة.

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

من خلال هذه التحسينات، ستتمكن Kroma ZKFP من الدخول إلى المرحلة 1. ومع ذلك، لتحقيق المرحلة 2، يحتاج Kroma إلى حلول إضافية لمنع هجمات Sybil، بما في ذلك تحويل البروتوكول إلى جميع مقابل جميع وإعادة تصميم آلية الهامش.

4.2. الاستنتاج

5. دليل على الاحتيال في المستقبل

5.1. Rollup المرحلة 2 - أموالك آمنة

كما ذكر أعلاه، يتجه Optimistic Rollups نحو المرحلة 2. يعمل Arbitrum بجد على تحقيق المرحلة 2 بناءً على BoLD. تم نشر مقترح BoLD في منتدى الحكم وحصل على الكثير من الدعم، وتم نشره حاليًا على شبكة الاختبار. إذا لم يتم اكتشاف مشاكل أمان كبيرة، فمن المحتمل أن يتم تحقيق مرحلة 2 عبر BoLD من قبل Arbitrum قبل نهاية هذا العام.

Optimism أيضا تعمل بجد لتحقيق المرحلة 2. من أجل أن يصل OP الشبكة الرئيسية إلى المرحلة 2، يجب إكمال لعبة النزاع V2، ويجب أن يكون هناك دعم لأنواع متعددة من البراهين لدعم البراهين المتعددة. على الرغم من أن المعايير لا تزال قيد التحسين، إلا أن لعبة النزاع V2 حلت بشكل فعال نقاط الضعف الحالية في OPFP، وقدمت حماية قوية للدفاع عن هجمات Sybil، مما يجعلها أقرب إلى المرحلة 2. بالإضافة إلى ذلك، فإن مختلف الفرق، بما في ذلك OP Labs، Succinct، Kroma و Kakarot، يعملون بنشاط على تطوير البراهين المتعددة، ويستثمرون موارد البحث والتطوير بشكل كبير لخلق تنوع في طرق البراهين في OP Stack. لذا، ما لم يحدث مشكلة كبيرة، من المتوقع أيضًا أن تسير Optimism نحو المرحلة 2 في النصف الأول من العام المقبل.

قد يكون التحول من هاتين الطبقتين النمطيتين إلى المرحلة الثانية له تأثير كبير على نظام Rollup. تمتلك كل من Arbitrum و Optimism إطار Rollup خاص بها ، وهما Arbitrum Orbit و OP Stack على التوالي. يعني التحول إلى المرحلة 2 أن جميع Rollup التي تستخدم هذه الأطر يمكنها أيضًا التحول إلى المرحلة 2.

لذلك، من نهاية هذا العام حتى العام المقبل، من المتوقع أن تنتقل العديد من ال Rollup الرئيسية ذات القاعدة الكبيرة مثل Arbitrum و OP الشبكة الرئيسية و Base إلى المرحلة 2، مما يعني توريث الأمان الكامل من Ethereum. من المرجح أن يساهم ذلك في تهدئة الانتقادات مثل "Rollup هو فقط التوقيع المتعدد" أو "Rollup يمكن أن يستولي على أموالك في أي وقت".

5.2. دليل على الاحتيال ZK هو المستقبل

يمكن الاستفادة من معظم البروتوكولات المناقشة عن طريق تطبيق دليل على الاحتيال ZK. على سبيل المثال، يمكن استخدام ZK في Arbitrum BoLD لزيادة معدل الموارد وجعله أكثر قدرة على مقاومة هجمات Sybil، في حين يمكن لـ Cartesi Dave جعله أقل عرضة للهجمات وقت الإستجابة. يعمل OPFP أيضًا على تطوير ZK لدعم أنظمة الإثبات المتعددة، مما قد يقلل من الهامش ويزيد من أمان البروتوكول. 01928374656574839201

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

من خلال هذا الطريق، ZK دليل على الاحتيال يلعب دوراً حاسماً في أمان واللامركزية Optimistic Rollup.

5.3. كيف يتصرف ZK Rollup؟ هل ستتراجع دليل الاحتيال؟

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

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

مقدمة موجزة عن OP | المصدر: مدونة Succinct

ومع ذلك ، لا يزال هناك عدة عوامل يجب مراعاتها. أولاً هي التكلفة. في OP Succinct ، يكلف إنتاج كتلة برهان حوالي 0.005-0.01 دولار ، بينما يتم تقدير تكلفة تشغيل المثبت بين 6،480 و 12،960 دولارًا شهريًا. إذا كانت كمية معاملات السلسلة في الثانية (TPS) عالية ، فقد تزيد هذه التكاليف بشكل أكبر.

（تكلفة إثبات الشبكة المختلفة | المصدر: مدونة Succinct）

على سبيل المثال، على الشبكة الأساسية OP Succinct، يبلغ تكلفة إنتاج البرهان المتوسط لكل كتلة حوالي 0.62 دولار. بناءً على هذا الرقم، ستبلغ التكلفة الشهرية 803,520 دولار. هذه هي التكلفة الإضافية التي لا توجد في Optimistic Rollups، حيث أن تكلفة التشغيل لـ ZK Rollups ستظل دائمًا أعلى من Optimistic Rollups حتى إذا تم إسقاط تكلفة ZK.

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

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

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

على العموم، يبدو أن طريقة Optimistic Rollup فعالة حاليًا، في حين تستخدم ZK كحل مختلط. ومع استمرار تحسين تكلفة وسرعة إنتاج دليل ZK، قد يُنظر بجدية في المستقبل إلى المزيد من Optimistic Rollups التحول إلى ZK.

5.4. هل دليل الاحتيال ينطبق فقط على Rollup؟

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

再التكديسبروتوكول دليل على الاحتيال يمكن استخدامها بنشاط في التكديسبروتوكوول. لنأخذ Eigenlayer كمثال ، وهي خدمة إعادة تمثيلية في بورصة ETH.

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

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

** مثال على خفض AVS | المصدر: [Eigenlayer GitHub] (https://github.com/Layr-Labs/eigenlayer-contracts/blob/d3730b5dd1b94d5e676e0c7a00a031574263c2c3/docs/experimental/AVS-Guide.md)

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

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

طبقة توفر البيانات** **يمكن استخدام دليل الاحتيال أيضًا في طبقة القابلية للتوفر (DA). أحد الأمثلة البارزة هو دليل الاحتيال المقدم والمنفذ من قبل Celestia. لديه تقنية تتيح للعقدة الخفيفة التحقق من صحة تخزين البيانات عن طريق عينة قابلية التوفر. دعنا نتعرف بعناية على هذا المفهوم.

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

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

Celestia 中的دليل على الاحتيال有两种类型：

دليل على الاحتيال في تحويل الحالة

أولاً ، يعمل دليل الاحتيال على البيانات كما يلي: يُسمح لـ عقدة خفيفة بالتحقق مما إذا كان المدققون يحملون البيانات الصحيحة دون تنزيل جميع البيانات في الكتلة مباشرة. لتحقيق ذلك ، يستخدم Celestia تقنية تسمى أخذ عينات توافر البيانات (DAS).

عينة توافر البيانات في سيليستيا | المصدر: ملف سيليستيا

يقومالمدققون Celestia بتهيئة بيانات المعاملات إلى مصفوفة k × k ، ثم يوسعونها إلى مصفوفة 2k × 2k باستخدام تقنية تسمى الترميز الثنائي Reed-Solomon. ثم يحسبون 4k جذر ميركل لكل صف وعمود ، ويضمنون تضمين نتائج تجزئة هذه الجذور ميركل بشكل إضافي في ترويسة الكتلة ونشرها.

فقط باستخدام معلومات جذر ميركل في رأس الكتلة ، يمكن لعقدة خفيفة التحقق مما إذا كان المدققون لـ Celestia يحملون البيانات الصحيحة. تطلب العقدة الخفيفة البيانات من نقاط عشوائية في مصفوفة 2k × 2k ، وتحصل في الوقت نفسه على جذور ميركل المقابلة للصف والعمود من المدققين. إذا تم التحقق من أن هذه البيانات يمكن التحقق منها مع القيم في رأس الكتلة ، فيمكن الاعتماد على أن المدققين يحملون البيانات الصحيحة.

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

此外，Celestia 还提出了状态转换的دليل علىالاحتيال机制。

الهندسة المعمارية لكتلة سيليستيا | المصدر: [مساهمة DAO Blog] (https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

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

بشكل عام، يمكن أن يتم تصفية دليل الاحتيال في طبقة توافر البيانات دون الاعتماد على الإجماع لتصفية البيانات غير الصحيحة وتحويل الحالة.

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

السبب الرئيسي لتطبيق التعلم الآلي على التكنولوجيا العصف الذهني هو كالتالي:

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

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

دعونا نلقي نظرة أكثر تفصيلا على الطريقة التي قدمتها ORA، وهو مشروع يوفر بنية تحتية للذكاء الاصطناعي على سلسلة الكتل. يتكون تحدي opML من عملية تحدي rollup بشكل كبير، ويتكون من ثلاثة مكونات رئيسية التالية:

دليل على الاحتيالالآلة الافتراضية（Fraud Proof VM）：الآلة الافتراضية هي آلة تنفيذ الذكاء الاصطناعي، وتعمل بطريقة مشابهة لـ WAVM في Arbitrum وـ Cannon في Optimism.
opML العقد الذكي：该合约验证دليل على الاحتيال，作用类似于 Optimism 的 MIPS.sol 合约。
التحقق من اللعبة : يتفاعل المدققون الذين يطرحون شكوكًا بطريقة ثنائية مع الخادم لتحديد الخطوة الفردية الخاطئة في الآلة الافتراضية، ثم يولدون دليلاً على الاحتيال لهذه الخطوة ويقدمونه إلى عقد opML.

لعبة التحقق من الصحة على ORA opML | المصدر: [وثيقة ORA] (https://docs.ora.io/doc/technology/proving-frameworks-zkml-opml-opp-ai/opml)

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

6. استنتاج

يبذل Optimistic Rollup الكثير من الجهد لتحسين دليل على الاحتيال والتشكيك في بروتوكول لوراثة المزيد من أمان Ethereum وإنشاء سلسلة بثقة أقل. من المتوقع أن تصل Arbitrum إلى المرحلة الثانية عبر BoLD بحلول نهاية هذا العام ، وتعمل Optimism أيضا على المرحلة 2 ، بالاعتماد على لعبة V2 المثيرة للجدل وآليات متعددة الإثباتات. بحلول العام المقبل ، سيتمكن مستخدمو Optimistic Rollup من التفاعل مع الشبكة بأمان أكبر دون القلق من أن "Rollup قد تأخذ أموالهم". بالإضافة إلى ذلك ، يذكر فيتاليك في مدونته أنه من المتوقع أن يزداد عدد عمليات التجميع في المرحلة 1 وما فوقها أيضا.

ومع ذلك، لا يزال هناك مجال لتحسين كل بروتوكول، حيث يمكن تعزيز العديد من الجوانب من خلال دليل الاحتيال ZK. تقدم Kroma بروتوكولها على هذا الأساس، ويمكن للبروتوكولات الأخرى مثل Arbitrum و Optimism و Cartesi أيضًا الاستفادة من دليل الاحتيال ZK للحفاظ على أمان ولامركزية أكبر.

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

7. المراجع

(https://l2beat.com/scaling/summary)[L2Beat]

[الاحتيال يثبت الحرب |.] لوكا دونوه في L2Beat] (https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

[ملف التحكيم] (https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction)

[مقال التفاؤل] (https://docs.optimism.io/).

[مواصفات التفاؤل] (https://specs.optimism.io/fault-proof/index.html)

[لا يوجد ترجمة متاحة]

[مواصفات كروما] (https://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html)

BoLD: حل النزاعات بسرعة وبتكلفة منخفضة

[اقتصاديات مجلس الإدارة] (https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/Economics.pdf)

لماذا فترة التحدي في Rollup المتفائلة هي 7 أيام؟ | كيلفن فيكتر في مختبرات OP

[تحطمت دليل الاحتيال |.] غابرييل كوتينيو دي باولا في كارتيسي] (https://ethresear.ch/t/fraud-proofs-are-broken/19234)

رحلة زمنية متفائلة | Yoav Weiss

[مقدمة عن أول تحد ناجح لشبكة Kroma's Mainnet] (https://blog.kroma.network/about-the-first-successful-challenge-on-kroma-mainnet-aeca715b05d7)

[تفسير التقدم المحرز في اللامركزية الأساسية |.] مختبرات OP] (https://blog.oplabs.co/unpacking-progress-in-baseline-decentralization/)

[هجوم الرقابة غير المرتبطة على بروتوكولات الطبقة 2 القائمة على دليل الاحتيال غير المرتبط] (https://ethresear.ch/t/non-attributable-censorship-attack-on-fraud-proof-based-layer2-protocols/6492/1)

[إطار تدقيق مختبرات OP] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864)

[اشتقاق غير موثوق به |.] كروما](https://www.notion.so/Complete-Trust-less-Derivation-for-Zero-Knowledge-Dispute-Game-bfaebd36375d48169424064237986dea?pvs=4)

[تقديم OP موجز: إثبات كامل للصلاحية على مكدس OP |.] موجز] (https://blog.succinct.xyz/op-succinct/)

[إيجنلاير جيثب] (https://github.com/Layr-Labs/eigenlayer-contracts/blob/d3730b5dd1b94d5e676e0c7a00a031574263c2c3/docs/experimental/AVS-Guide.md)

[ملفات سيليستيا] (https://docs.celestia.org/)

[مساهمة DAO المدونة] (https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

[وثيقة أورا] (https://docs.ora.io/doc/technology/proving-frameworks-zkml-opml-opp-ai/opml)

إخلاء المسؤولية:

يتم نشر هذه المقالة بترخيص من [research.2077] ، جميع حقوق الطبع والنشر محفوظة للكاتب الأصلي [sm-stack و BTC Penguin]. إذا كان لديك أي اعتراض على إعادة النشر هذه ، يرجى الاتصال بفريق Gate Learn وسيتعاملون معه في الوقت المناسب.
تنصل: تعبر وجهات النظر والآراء التي تعبر عنها هذه المقالة فقط عن وجهة نظر الكاتب ولا تشكل أي نوع من التوصيات الاستثمارية.
فريق Gate Learn سيقوم بترجمة المقالات إلى لغات أخرى. ما لم يرد خلاف ذلك، يُمنع نسخ أو توزيع أو سرقة مقالات الترجمة.