المؤلف: MegaETH المصدر: @megaeth_labs الترجمة: شان أوبا، الاقتصاد الذهبي
في قلب جميع Optimistic Rollups، توجد فرضية رئيسية: الاقتراحات الحالة المقدمة تعتبر صالحة بشكل افتراضي حتى يتم إثبات خطأها. ومع ذلك، فإن هذه الفرضية صحيحة فقط عندما تمتلك Rollup آلية قوية لإثبات الاحتيال. في حالة عدم وجود هذه الآلية، تصبح السلسلة غير آمنة على الفور إذا لم يتم التشكيك في حالة غير صالحة، أو إذا تم تعطيل عملية التسوية بسبب تحديات خبيثة.
عبء إثبات الاحتيال
لدعم الافتراضات المذكورة أعلاه، يجب أن يدعم L2 الخاص بـ Optimistic آلية إثبات الاحتيال (المعروفة أيضًا باسم بروتوكول حل النزاعات) التي تسمح للمدققين (المتحدين) بتحدي اقتراح الحالة المحتمل الخاطئ المقدم من المنظمين (المقترحين). يجب أن تضمن هذه الآلية خاصيتين رئيسيتين:
جميع حالات الاقتراحات الخاطئة يمكن التعرف عليها،
التحديات الخاطئة لن تنجح أبداً.
من الناحية الفنية، تتضمن هذه الآلية عنصرين أساسيين.
بروتوكول التحدي: معالجة النزاعات المتعلقة باقتراح حالة واحدة.
آلية البطولة: عندما تظهر اقتراحات حالة تنافسية متعددة في نفس الكتلة، تُستخدم لتصفية الاقتراح الصحيح الوحيد.
كل اقتراح حالة هو بيان لنتائج تنفيذ مجموعة من المعاملات، وعادة ما يتضمن ثلاثة أجزاء:
الحالة الأولية: أحدث حالة L2 التي تم تأكيدها نهائيًا على Ethereum؛
حمولة المعاملات: سلسلة من معاملات L2 التي حدثت منذ تلك الحالة؛
الحالة النهائية: يدعي المقترح أن النتائج التي تم الحصول عليها بعد تنفيذ هذه المعاملات.
لذلك، فإن الاقتراح الكامل بشكل أساسي يقول:
"افترض أن الحالة الأولية الحالية هي A، تنفيذ قائمة المعاملات التالية (payload)، أعتقد أن الحالة النهائية يجب أن تكون X."
في هذه الحالة، تكون وظيفة بروتوكول التحدي هي التحقق مما إذا كان هذا الادعاء صحيحًا. إذا كان خاطئًا، يجب أن ينجح التحدي ويجب رفض الاقتراح.
إثبات العطل التفاعلي (لعبة التحدي الثنائية)
في معظم أنظمة Optimistic Rollup السائدة حاليًا، يتم استخدام نوع من البروتوكول التفاعلي: حيث يتبادل المتحدي والمقترح الهجمات.
بمجرد تقديم نزاع، سيقوم الطرفان بإجراء تقسيم ثنائي للنتائج الوسيطة للعملية الحسابية (النتائج التي يدعيها المقترح لكل خطوة تنفيذية) لتقليل نطاق الخطأ المحتمل تدريجياً. ستستمر هذه العملية في التكرار حتى يتمكن الطرفان من تحديد خطوة الحساب الخاطئة الفردية (مثل تنفيذ صفقة بشكل خاطئ).
بعد تحديد الخطأ المحدد، ستتم إعادة تنفيذ هذه الخطوة على شبكة Ethereum الرئيسية لتحديد ما إذا كانت هناك فعلاً عملية احتيال.
التأخير العالي: كل تفاعل يتطلب بدء معاملة على سلسلة الإيثريوم. قد تستغرق عملية معالجة النزاع الكاملة عدة ساعات أو حتى أيام، خاصةً في حالة ازدحام الشبكة أو التعرض للرقابة؛
مطلب عالٍ من المقترح: حتى لو كان المقترح صادقًا، وكانت التحديات لا أساس لها، لا يزال يتعين عليه المشاركة في عملية النزاع بأكملها، مما يتطلب تكاليف حسابية وتفاعلات على السلسلة ليست بالقليلة؛
سهل الاستغلال بشكل ضار: يمكن للمنافسين الضارين تقديم تحديات لا أساس لها بشكل مستمر، مما يجبر المقترحين المخلصين على إضاعة الوقت وتكاليف الغاز بشكل متكرر للدفاع عن الحالة الصحيحة.
في الواقع، فإن إثبات الاحتيال التفاعلي مكلف للغاية، وهش في أوقات التحميل العالية، وسهل الاستغلال.
إثبات احتيال غير تفاعلي (نموذج تحدي ZK)
ميغا إيث اتبعت مسارًا مختلفًا تمامًا: فهي تتطلب من المتحدي فقط إنشاء دليل معرفة صفرية (ZKP) بسيط، لإثبات أن الحالة النهائية التي أعلن عنها المقترح غير صالحة.
على وجه التحديد، فإن هذه الشهادة ZK تشير إلى أن تنفيذ تسلسل المعاملات من الحالة الأولية لن ينتج عنه الحالة النهائية التي يدعيها المقترح. ستبنى هذه الآلية على zkVM الخاص بـ RISC Zero، وستستند إلى الهيكل المختلط لإثبات الاحتيال غير التفاعلي لـ OP Kailua لتحقيق ذلك.
يتم تقديم هذا الإثبات إلى شبكة الإيثريوم من خلال معاملة واحدة، وسيؤكد عقد المتحققين على السلسلة صحته. لا يحتاج مقدم الإثبات إلى المشاركة في أي عمل، ولا يمكنه التدخل في العملية بأكملها، ولا يشارك في أي نزاع.
بالطبع، ليس من السهل إنشاء مثل هذا الإثبات ZK** - يتطلب تشغيل عملية الحساب المتنازع عليها بالكامل في آلة zk الافتراضية، ومن المتوقع أن يستهلك حوالي 100 مليار دورة حسابية، في أسوأ الحالات، التكلفة حوالي 100 دولار. لكن هذه التكلفة** تحدث فقط عندما يتم إثبات الاحتيال**، ووفقًا للتصميم، يتحملها الطرف غير الأمين. هذا النموذج يقلل بشكل كبير من الضغط الرأسمالي على المتحدي الأمين، ويقضي تمامًا على مخاطر التخريب الخبيث في آلية الانقسام.
ZK تستخدم لإثبات الاحتيال، وليس لفعالية الحالة
في مجال التشفير، غالبًا ما يتم فهم "المعرفة الصفرية (ZK)" بشكل مبسط على أنه مرادف لـ ZK Rollup - أي استخدام إثباتات ZK للتحقق من تحويل الحالة خارج السلسلة ثم نشرها على النظام الموجود على السلسلة. لكن هذا الفهم يغطي في الواقع نصف إمكانيات ZK فقط.
يهدف MegaETH من استخدام إثباتات المعرفة الصفرية ليس للتحقق من صحة الحالة، ولكن لإثبات السلوك الاحتيالي. هذا يسمح لنا بالحفاظ على كفاءة وتوسع Optimistic Rollup بينما نضيف آلية غير موثوقة وغير تفاعلية للكشف عن التحولات غير الصالحة للحالة والتحدي لها.
نحن نسمي هذه الطريقة المختلطة إثبات احتيال ZK، حيث تقدم نموذج ثقة مختلف تمامًا.
نافذة الفحص ثابتة، ووقت النهاية تقلص بشكل كبير
نظرًا للاعتبارات الأمنية والحذر، ستحتفظ MegaETH بـنافذة التحدي التي تدوم 7 أيام، مما يعني أن أي مشارك لديه أسبوع كامل للاعتراض على جذر حالة معينة. لكن الفرق الحقيقي يحدث بعد تقديم الاعتراض، في النموذج التفاعلي، إذا تم تقديم التحدي في اليوم السابع، قد يتطلب الأمر بضعة أيام إضافية لإكمال حل الاعتراض. خلال هذه الفترة، ستتجمد نهائية السلسلة على الشبكة الرئيسية لـ Ethereum، وسيتم تعطيل تقدم البروتوكول، وسيؤثر ذلك أيضًا على نشاط السلسلة.
في حالة استخدام إثبات الاحتيال ZK، ستكتمل عملية النزاع بأكملها في حوالي ساعة واحدة. يقوم المتحدي بإنشاء إثبات ZK، وتقديمه إلى الشبكة الرئيسية للإيثيريوم، ويصبح ساري المفعول فور التحقق، وتكتسب حالة السلسلة الفورية النهائية. وهذا فعال في صد أحد الأساليب الهجومية الرئيسية: المتحدي الخبيث الذي يطلق نزاعات زائفة مرارًا وتكرارًا لتعطيل النهائية في السلسلة.
توفير ضمان توافر البيانات من قبل EigenDA
لضمان نزاهة عملية إثبات الاحتيال، يجب أن يكون للتحدي إمكانية الوصول بسهولة وموثوقية إلى بيانات الكتلة الأصلية لإعادة إنتاج العملية الحسابية المتنازع عليها.
هذا هو السبب في أننا نستخدم نموذج احتيال ZK مع EigenDA (طبقة توفر بيانات مركزية عالية الإنتاجية).
من خلال هذه البنية، تم تبسيط العملية بأكملها إلى الشكل الأكثر أمانًا وكفاءة:
يقوم المنظم بنشر بيانات الكتلة إلى EigenDA، بينما يتم تقديم ملخص صغير من البيانات فقط إلى Ethereum، وتضمن الضمانات التشفيرية التي تقدمها EigenDA إمكانية توليد إثبات الاحتيال في أي وقت، ولا يمكن للمنظم "إخفاء" البيانات لتجنب الرقابة؛
يمكن لأي مراقب استرداد بيانات الكتلة من EigenDA وإعادة بناء الكتلة الكاملة وتنفيذها في zkVM؛
بمجرد اكتشاف الاحتيال، سيتمكن هذا المراقب من إنشاء إثبات احتيال ZK المختصر، وتقديمه إلى عقد التحقق على الإيثريوم؛ وسيتم معاقبة المنظم، وسيتم رفض اقتراحه غير الصالح.
نموذج ثقة قابل للتوسع مع ضمانات تشفير
استبدل MegaETH إثبات الاحتيال غير التفاعلي البسيط ZK باللعب المزعج المعقد لإثبات الاحتيال التفاعلي. هذه الطريقة تقضي على مخاطر الهجمات المزعجة، وتختصر بشكل كبير وقت التأكيد النهائي، وتضمن أن يتم حل النزاعات بطريقة فعالة وقابلة للتوسع.
مع قدرة RiscZero على توفير حسابات يمكن التحقق منها، ودعم @eigen_da للوصول إلى البيانات الأصلية، فإن كل اقتراح حالة يتمتع بـ:
قابلية إعادة البناء، قابلية التحقق، إمكانية تحدي أي شخص - بغض النظر عن أي حجم.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
الحرب النهائية: كيف نحمي أمان MegaETH باستخدام تقنية ZK
المؤلف: MegaETH المصدر: @megaeth_labs الترجمة: شان أوبا، الاقتصاد الذهبي
في قلب جميع Optimistic Rollups، توجد فرضية رئيسية: الاقتراحات الحالة المقدمة تعتبر صالحة بشكل افتراضي حتى يتم إثبات خطأها. ومع ذلك، فإن هذه الفرضية صحيحة فقط عندما تمتلك Rollup آلية قوية لإثبات الاحتيال. في حالة عدم وجود هذه الآلية، تصبح السلسلة غير آمنة على الفور إذا لم يتم التشكيك في حالة غير صالحة، أو إذا تم تعطيل عملية التسوية بسبب تحديات خبيثة.
عبء إثبات الاحتيال
لدعم الافتراضات المذكورة أعلاه، يجب أن يدعم L2 الخاص بـ Optimistic آلية إثبات الاحتيال (المعروفة أيضًا باسم بروتوكول حل النزاعات) التي تسمح للمدققين (المتحدين) بتحدي اقتراح الحالة المحتمل الخاطئ المقدم من المنظمين (المقترحين). يجب أن تضمن هذه الآلية خاصيتين رئيسيتين:
من الناحية الفنية، تتضمن هذه الآلية عنصرين أساسيين.
كل اقتراح حالة هو بيان لنتائج تنفيذ مجموعة من المعاملات، وعادة ما يتضمن ثلاثة أجزاء:
لذلك، فإن الاقتراح الكامل بشكل أساسي يقول:
"افترض أن الحالة الأولية الحالية هي A، تنفيذ قائمة المعاملات التالية (payload)، أعتقد أن الحالة النهائية يجب أن تكون X."
يمكننا استخدام الشكل أدناه لتصور هذه البنية:
! 8i2x0qwTXcDdLYX1x0fWm3PjE8BoCmLwC2YXpOqK.png
في هذه الحالة، تكون وظيفة بروتوكول التحدي هي التحقق مما إذا كان هذا الادعاء صحيحًا. إذا كان خاطئًا، يجب أن ينجح التحدي ويجب رفض الاقتراح.
إثبات العطل التفاعلي (لعبة التحدي الثنائية)
في معظم أنظمة Optimistic Rollup السائدة حاليًا، يتم استخدام نوع من البروتوكول التفاعلي: حيث يتبادل المتحدي والمقترح الهجمات.
بمجرد تقديم نزاع، سيقوم الطرفان بإجراء تقسيم ثنائي للنتائج الوسيطة للعملية الحسابية (النتائج التي يدعيها المقترح لكل خطوة تنفيذية) لتقليل نطاق الخطأ المحتمل تدريجياً. ستستمر هذه العملية في التكرار حتى يتمكن الطرفان من تحديد خطوة الحساب الخاطئة الفردية (مثل تنفيذ صفقة بشكل خاطئ).
بعد تحديد الخطأ المحدد، ستتم إعادة تنفيذ هذه الخطوة على شبكة Ethereum الرئيسية لتحديد ما إذا كانت هناك فعلاً عملية احتيال.
! 6WF4yCanaXLDVqAMrwqPHcehkLUpcsFo2PueK0tQ.png
لكن هذه الآلية تواجه عدة مشكلات:
في الواقع، فإن إثبات الاحتيال التفاعلي مكلف للغاية، وهش في أوقات التحميل العالية، وسهل الاستغلال.
إثبات احتيال غير تفاعلي (نموذج تحدي ZK)
ميغا إيث اتبعت مسارًا مختلفًا تمامًا: فهي تتطلب من المتحدي فقط إنشاء دليل معرفة صفرية (ZKP) بسيط، لإثبات أن الحالة النهائية التي أعلن عنها المقترح غير صالحة.
على وجه التحديد، فإن هذه الشهادة ZK تشير إلى أن تنفيذ تسلسل المعاملات من الحالة الأولية لن ينتج عنه الحالة النهائية التي يدعيها المقترح. ستبنى هذه الآلية على zkVM الخاص بـ RISC Zero، وستستند إلى الهيكل المختلط لإثبات الاحتيال غير التفاعلي لـ OP Kailua لتحقيق ذلك.
يتم تقديم هذا الإثبات إلى شبكة الإيثريوم من خلال معاملة واحدة، وسيؤكد عقد المتحققين على السلسلة صحته. لا يحتاج مقدم الإثبات إلى المشاركة في أي عمل، ولا يمكنه التدخل في العملية بأكملها، ولا يشارك في أي نزاع.
! 8O20iC5M2rQK5t0Psa3Hsqon0YB5G8zXCFG2gNVH.png
بالطبع، ليس من السهل إنشاء مثل هذا الإثبات ZK** - يتطلب تشغيل عملية الحساب المتنازع عليها بالكامل في آلة zk الافتراضية، ومن المتوقع أن يستهلك حوالي 100 مليار دورة حسابية، في أسوأ الحالات، التكلفة حوالي 100 دولار. لكن هذه التكلفة** تحدث فقط عندما يتم إثبات الاحتيال**، ووفقًا للتصميم، يتحملها الطرف غير الأمين. هذا النموذج يقلل بشكل كبير من الضغط الرأسمالي على المتحدي الأمين، ويقضي تمامًا على مخاطر التخريب الخبيث في آلية الانقسام.
ZK تستخدم لإثبات الاحتيال، وليس لفعالية الحالة
في مجال التشفير، غالبًا ما يتم فهم "المعرفة الصفرية (ZK)" بشكل مبسط على أنه مرادف لـ ZK Rollup - أي استخدام إثباتات ZK للتحقق من تحويل الحالة خارج السلسلة ثم نشرها على النظام الموجود على السلسلة. لكن هذا الفهم يغطي في الواقع نصف إمكانيات ZK فقط.
يهدف MegaETH من استخدام إثباتات المعرفة الصفرية ليس للتحقق من صحة الحالة، ولكن لإثبات السلوك الاحتيالي. هذا يسمح لنا بالحفاظ على كفاءة وتوسع Optimistic Rollup بينما نضيف آلية غير موثوقة وغير تفاعلية للكشف عن التحولات غير الصالحة للحالة والتحدي لها.
نحن نسمي هذه الطريقة المختلطة إثبات احتيال ZK، حيث تقدم نموذج ثقة مختلف تمامًا.
نافذة الفحص ثابتة، ووقت النهاية تقلص بشكل كبير
نظرًا للاعتبارات الأمنية والحذر، ستحتفظ MegaETH بـنافذة التحدي التي تدوم 7 أيام، مما يعني أن أي مشارك لديه أسبوع كامل للاعتراض على جذر حالة معينة. لكن الفرق الحقيقي يحدث بعد تقديم الاعتراض، في النموذج التفاعلي، إذا تم تقديم التحدي في اليوم السابع، قد يتطلب الأمر بضعة أيام إضافية لإكمال حل الاعتراض. خلال هذه الفترة، ستتجمد نهائية السلسلة على الشبكة الرئيسية لـ Ethereum، وسيتم تعطيل تقدم البروتوكول، وسيؤثر ذلك أيضًا على نشاط السلسلة.
في حالة استخدام إثبات الاحتيال ZK، ستكتمل عملية النزاع بأكملها في حوالي ساعة واحدة. يقوم المتحدي بإنشاء إثبات ZK، وتقديمه إلى الشبكة الرئيسية للإيثيريوم، ويصبح ساري المفعول فور التحقق، وتكتسب حالة السلسلة الفورية النهائية. وهذا فعال في صد أحد الأساليب الهجومية الرئيسية: المتحدي الخبيث الذي يطلق نزاعات زائفة مرارًا وتكرارًا لتعطيل النهائية في السلسلة.
توفير ضمان توافر البيانات من قبل EigenDA
لضمان نزاهة عملية إثبات الاحتيال، يجب أن يكون للتحدي إمكانية الوصول بسهولة وموثوقية إلى بيانات الكتلة الأصلية لإعادة إنتاج العملية الحسابية المتنازع عليها.
هذا هو السبب في أننا نستخدم نموذج احتيال ZK مع EigenDA (طبقة توفر بيانات مركزية عالية الإنتاجية).
من خلال هذه البنية، تم تبسيط العملية بأكملها إلى الشكل الأكثر أمانًا وكفاءة:
نموذج ثقة قابل للتوسع مع ضمانات تشفير
استبدل MegaETH إثبات الاحتيال غير التفاعلي البسيط ZK باللعب المزعج المعقد لإثبات الاحتيال التفاعلي. هذه الطريقة تقضي على مخاطر الهجمات المزعجة، وتختصر بشكل كبير وقت التأكيد النهائي، وتضمن أن يتم حل النزاعات بطريقة فعالة وقابلة للتوسع.
مع قدرة RiscZero على توفير حسابات يمكن التحقق منها، ودعم @eigen_da للوصول إلى البيانات الأصلية، فإن كل اقتراح حالة يتمتع بـ:
قابلية إعادة البناء، قابلية التحقق، إمكانية تحدي أي شخص - بغض النظر عن أي حجم.