الهدف النهائي: كيف نؤمّن MegaETH باستخدام ZK

المؤلف: MegaETH المصدر: @megaeth_labs الترجمة: شان أوبا، جولدن فاينانس

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

عبء إثباتات الاحتيال

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

1. يمكن تحديد جميع مقترحات الولايات غير الصحيحة،

2. لن تنجح الطعون غير الصحيحة أبدًا.

من منظور فني، تتكون هذه الآلية من عنصرين أساسيين:

• بروتوكول التحدي الفرعي: يتعامل مع النزاعات حول اقتراح حالة واحدة.

• آلية البطولة: عندما تظهر مقترحات حالة متنافسة متعددة لنفس الكتلة، يتم استخدامها لتصفية الاقتراح الصحيح الوحيد.

كل اقتراح حالة هو بيان لنتائج مجموعة من تنفيذات المعاملات، وعادة ما تتكون من ثلاثة أجزاء:

• الحالة الأولية: أحدث حالة L2 مؤكدة على Ethereum؛

• حمولة المعاملة: سلسلة من معاملات L2 التي حدثت منذ تلك الحالة؛

• الحالة النهائية: النتيجة التي يدعي المقترح أنه حصل عليها بعد تنفيذ هذه المعاملات.

إذن، ينص الاقتراح الكامل بشكل أساسي على ما يلي:

"بافتراض أن الحالة الأولية الحالية هي A، قم بتنفيذ قائمة المعاملات (الحمولة) التالية، أعتقد أن الحالة النهائية يجب أن تكون X."

يمكننا تصور هذا الهيكل في شكل الشكل التالي:

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

إثبات الخطأ التفاعلي (لعبة التحدي الثنائية)

في معظم أنظمة التجميع المتفائلة السائدة حاليًا، يُعتمد بروتوكول تفاعلي: ينخرط المتحدي والمقترح في مواجهة متبادلة.

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

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

ومع ذلك، فإن هذه الآلية بها مشاكل متعددة:

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

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

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

في الواقع، تكون أدلة الاحتيال التفاعلية مكلفة وهشة تحت الحمل العالي وسهلة الإساءة.

إثباتات الاحتيال غير التفاعلية (نموذج تحدي ZK)

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

على وجه التحديد، يوضح دليل ZK هذا أن تنفيذ سلسلة من المعاملات من الحالة الأولية لن يؤدي إلى الحالة النهائية التي يطالب بها المقترح. سيتم بناء الآلية على منصة zkVM من RISC Zero، وسيتم تنفيذها باستخدام بنية OP Kailua الهجينة غير التفاعلية المقاومة للاحتيال. يُرسَل الدليل إلى إيثريوم عبر معاملة واحدة، وسيؤكد عقد التحقق على السلسلة صحته. لا يحتاج مُقترح الدليل إلى المشاركة في أي عمل، ولا يمكنه التدخل في العملية بأكملها، ولا يُشارك في النزاعات.

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

يُستخدَم ZK لإثبات الاحتيال، وليس لإثبات صحة الحالة

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

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

نطلق على هذا النهج الهجين ZK scam proofs، وهو يجلب نموذج ثقة مختلفًا تمامًا.

نافذة الكشف دون تغيير، وانخفاض كبير في النهاية

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

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

توفر البيانات مضمون بواسطة EigenDA

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

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

من خلال هذا الهيكل، يتم تبسيط العملية بأكملها إلى الشكل الأكثر أمانًا وكفاءة:

• ينشر المُفرز بيانات الكتلة إلى EigenDA، ولا يرسل سوى ملخص بيانات صغير إلى Ethereum. يضمن ضمان التشفير الذي توفره EigenDA إمكانية إنشاء أدلة الاحتيال في أي وقت، ولا يمكن للمصنف "إخفاء" البيانات للتهرب من المراجعة؛

• يمكن لأي مراقب استرداد بيانات الكتلة من EigenDA، وإعادة بناء الكتلة الكاملة وتنفيذها في zkVM؛

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

نموذج ثقة آمن تشفيريًا وقابل للتطوير

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

مع توفير RiscZero لقدرة حسابية قابلة للتحقق، وضمان @eigen_da للوصول إلى البيانات الخام، فإن كل مقترح حالة يكون:

قابلًا لإعادة البناء والتحقق والطعن من قبل أي شخص - على أي نطاق.