*أرسل العنوان الأصلي ：استكشاف جسر Ethereum الكنسي ونظام إثباته

نظرة عامة على جسرنا الكنسي

يتكون الكسوف من ثلاث طبقات:

1. التنفيذ: شوكة لعميل Solana Labs (الإصدار 1.17) لتنفيذ معاملات SVM
2. التسوية: جسرنا الأساسي الذي يحدد قاعدة اختيار شوكة Eclipse موجود على Ethereum، حيث سيتم أيضًا تقديم أدلة الاحتيال
3. توفر البيانات: ينشر Eclipse البيانات اللازمة لإنتاج أدلة الاحتيال على شكل نقاط بيانات على Celestia

يوضح الرسم البياني أدناه كيفية تفاعل هذه الوحدات:

ستركز بقية هذه المقالة على جسر Eclipse's Ethereum، كما هو موضح في الرسم البياني. سوف تقوم Blobstream بترحيل الشهادات الموقعة من قبل أداة التحقق من صحة Celestia التي تم تعيينها لتأكيد Ethereum بأن البيانات الخاصة بمجموعة فتحات Eclipse قد تم نشرها بشكل صحيح. يسمح هذا لجسر Eclipse بالتحقق من البيانات المقدمة لإثباتات الاحتيال ضد جذور البيانات الموقعة من Celestia. وفي بقية هذا القسم، سنوضح العمليات التي يتم من خلالها:

1. يتم إيداع الأموال عبر جسرنا،
2. يتم نشر نقاط البيانات من مجموعات كتل Eclipse على Celestia،
3. تتم معالجة عمليات السحب عبر الجسر، و
4. يتم إنشاء أدلة الاحتيال في أسوأ السيناريوهات.

الإيداع عبر Eclipse's Native Ethereum Bridge

يتم تلخيص التدفق عندما يقوم المستخدم بالإيداع في Eclipse عبر جسر Ethereum الأصلي على النحو التالي:

1. يقوم المستخدم باستدعاء عقد Deposit Bridge الخاص بـ Eclipse على Ethereum
2. من داخل منفذ SVM الخاص بـ Eclipse [1]، يراقب المرحل [2] إيداع المستخدم وعنوان الوجهة
3. بعد ذلك، يقوم جهاز الترحيل باستدعاء برنامج جسر SVM، وهو المسؤول عن تحويل إيداع المستخدم إلى عنوان الوجهة المناسب
4. يتحقق المرحل من معاملة الإيداع عبر عميل zk-light (سيتم تنفيذه)
5. أخيرًا، يتم الانتهاء من الكتلة التي تحتوي على معاملة تحويل ما بعد الإيداع اللاحقة ونشرها عبر البرنامج الإضافي Solana Geyser

يوضح الرسم البياني أدناه التفاعلات بين Ethereum وCelestia ومنفذ SVM أثناء تدفق الإيداع الموصوف أعلاه:

نشر فتحات Eclipse على Celestia على هيئة نقاط بيانات

يتم تلخيص تدفق نشر دفعات من فتحات Eclipse إلى Celestia كنقاط بيانات أدناه:

1. ينشر منفذ SVM كل فتحة Eclipse في قائمة انتظار الرسائل عبر Geyser
2. ينشر منفذ SVM دفعات من فتحات Eclipse إلى Celestia على شكل نقاط بيانات
3. تنتج مجموعة أدوات التحقق من صحة Celestia التزامات تجاه نقاط البيانات المقدمة، والتي يمكن استخدامها لإثبات إدراج معاملة في سلسلة Eclipse مقابل جذر البيانات
4. يتم ترحيل جذور البيانات الموجودة في كل رأس كتلة Celestia إلى عقد جسر Eclipse على Ethereum عبر Blobstream

يشرح الرسم البياني أدناه من Celestia كيفية تخزين التزام البيانات داخل كتلة Celestia معينة في رأس الكتلة:

سحب وتقديم أدلة الاحتيال إلى Eclipse's Ethereum Bridge

على غرار لغات L2 الأخرى التي تستخدم أدلة الاحتيال (Arbitrum، وFuel، وغيرها الكثير)، تتطلب عمليات السحب من Eclipse فترة تحدي يمكن خلالها للمحققين تقديم أدلة الاحتيال في حالة انتقال حالة غير صالحة:

1. بإيقاع منتظم، ينشر منفذ SVM التزامًا بفترة (عدد محدد مسبقًا من الدُفعات) من فتحات Eclipse إلى Ethereum، إلى جانب الضمانات
2. يُجري عقد الجسر الخاص بـ Eclipse بعض الفحوصات الأساسية للتأكد من أن البيانات المنشورة جيدة الصياغة (موضحة في قسم تصميم إثبات الاحتيال)
3. إذا اجتازت الدفعة المقدمة عمليات الفحص الأساسية هذه، فستكون هناك نافذة محددة مسبقًا يستطيع خلالها القائمون على التحقق نشر إثباتات الاحتيال في حالة أن التزام الدفعة يعني انتقال حالة غير صالح
4. إذا قام أحد المدققين بنشر دليل احتيال ناجح، فإنه يفوز بضمان المنفذ، ويتم رفض الدفعة المنشورة، ويتم إرجاع الحالة الأساسية لـ Eclipse L2 إلى آخر التزام دفعة صالح. وهنا، سيكون لدى إدارة Eclipse القدرة على انتخاب منفذ جديد
5. إذا انقضت فترة التحدي دون نجاح إثبات الاحتيال، يسترد المنفذ ضماناته مع المكافأة
6. وبالتالي، سيكمل عقد Eclipse Bridge الآن أي معاملات سحب تم تضمينها في الدفعة النهائية

تصميم مقاوم للاحتيال

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

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

في حالة Eclipse، (1) تقوم Celestia بدمج النقط من مجموعات الكتل التي ينشرها منفذ SVM الخاص بـ Eclipse، مما يسمح بإثباتات إدراج المعاملة عبر شهود Merkle. بالنسبة إلى (2)، على عكس L2s المستندة إلى EVM، والتي تنشر جذر Merkle لشجرة الحالة العالمية، لأسباب تتعلق بالأداء، لا يقوم Eclipse بتحديث شجرة حالة عالمية على أساس كل معاملة على حدة، ولكننا سنشرح كيف نضمن صحة المدخلات بمزيد من التفاصيل أدناه. أخيرًا، في الحالة (3)، يقوم برنامج التحقق الخاص بـ Eclipse بإنشاء دليل zk للمخرجات (المخرجات) لمعاملة معينة، على عكس نهج لعبة التحقق التفاعلية الشائع عبر L2s المستندة إلى EVM.

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

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

تم إرسال مدخلات المعاملات إلى سيليستيا

1. بيانات المعاملة (المرسلة بواسطة جهاز التسلسل)
2. بيانات المعاملة (المرسلة بواسطة منفذ SVM) والتي تحتوي على ما يلي:
   1. عدد المعاملات [3]
   2. موقع مساحة الاسم Celestia لبيانات المعاملة
   3. تجزئة الحساب [4] لكل إدخال، مع عدد المعاملات الناتج عن كل إدخال
   4. قائمة بمحركات النظام المستخدمة وقيمة كل منها، مع عدد المعاملات الناتج عن كل منها (إن أمكن) [5]
   5. مخرجات المعاملة، إذا كانت المعاملة ناجحة؛ بخلاف ذلك، مؤشر على فشل المعاملة (إما بسبب فشل التحليل أو عدم القدرة على التنفيذ)

الالتزامات المجمعة المرسلة إلى جسر Ethereum

بالإضافة إلى ذلك، فإن دفعات بيانات المعاملات المرسلة إلى Celestia قد تم ترحيل التزاماتها إلى عقد Ethereum. وتتكون الالتزامات من:

1. موقع مساحة الاسم Celestia لبيانات المعاملة لآخر معاملة مضمنة في الدُفعة
2. موقع مساحة الاسم Celestia لبيانات التنفيذ [6] لجميع المعاملات المضمنة
3. قائمة بالإيداعات والسحوبات والتجاوزات، كل منها يأتي مع عدد المعاملات الخاصة بمعاملة Eclipse المرتبطة

معايير الدفعة غير الصالحة

كما هو موضح أعلاه، هناك عدة طرق يمكن من خلالها اكتشاف أن الدُفعة غير صحيحة:

1. أحد مواقع مساحة اسم Celestia المرتبطة مشوه أو لا يشير إلى بيانات من النوع المطلوب
2. توجد معاملة على Celestia دون وجود بيانات تنفيذ مرتبطة بها، وقد يرجع ذلك إلى سببين:
   1. لا تحتوي المعاملة، التي كان من المفترض أن تكون الأحدث في الدفعة، على أي بيانات تنفيذ مرتبطة بها.
      1. في مثل هذه الحالة، يتحقق المدقق من أن هذا هو الحال ويتحقق عقد جسر Ethereum من أن الإدخال الأخير في قائمة بيانات التنفيذ لا يتوافق مع بيانات المعاملة الصحيحة
   2. بيانات التنفيذ لمعاملة مختلفة مفقودة
      1. يقوم المدقق بنشر موقع مساحة اسم Celestia لبيانات المعاملة الخاصة بالمعاملة المخالفة والمعاملات السابقة واللاحقة بالترتيب الذي تم تنفيذه بنجاح. بعد ذلك، يتحقق عقد الجسر من تخطي هذه المعاملة
3. هناك معاملة بيانات تنفيذها غير صحيحة، وقد يكون السبب ما يلي:
   1. لا ينتج عن عدد المعاملات المرتبط بتجزئة الحساب أو sysvar المخرجات المطلوبة.
      1. في هذه الحالة، يقوم المدقق بنشر موقع مساحة اسم Celestia لبيانات التنفيذ للمعاملة المحددة مع العدد المقابل، ويتحقق عقد الجسر من أن القيمة المحددة غير صحيحة.
   2. عدد المعاملات المرتبط بتجزئة الحساب أو sysvar قديم
      1. يقوم المدقق بنشر موقع مساحة اسم Celestia لبيانات التنفيذ لمعاملة أحدث، وتعديل القيمة المعنية، ويتحقق عقد الجسر من أن هذه أحدث بالفعل.
   3. مخرجات المعاملة غير صحيحة، أو أن المعاملة تستخدم مدخلاً غير مدرج:
      1. في هذه الحالة، هناك حاجة إلى إثبات zk للتنفيذ الصحيح للمعاملة أو إثبات zk بأن المعاملة تستخدم مدخلاً غير مدرج. ويمكن الحصول على ذلك بطريقتين:
         1. يقوم المدقق بنشر الدليل، أو
         2. يقوم المدقق بنشر فهرس المعاملة المزعوم أنها احتيالية، ويستخدم عقد Eclipse Bridge هذا للحصول على دليل ZK من Bonsai التابع لـ RISC Zero
   4. كان هناك إيداع من Ethereum منذ أكثر من N دفعة، ولكن لا يوجد إيداع مقابل في قائمة المعاملات (مضمن في التزام الدُفعة المنشور في عقد الجسر) للدفعات N السابقة. وبدلاً من ذلك، هناك إيداع في قائمة المعاملات دون أي معاملة إيداع ذات صلة بـ Ethereum، أو أن المعاملة موجودة ولكن تم تضمينها بالفعل في دفعة Eclipse أخرى
      1. يمكن لعقد الجسر في جميع هذه الحالات أن يحدد حدوث ذلك ويعتبر هذه الدفعة غير صالحة
   5. يتم تنفيذ عملية إيداع أو سحب بدون إدخال مقابل في قائمة المعاملات
      1. في مثل هذه الحالة، يقوم المدقق بنشر موقع مساحة اسم Celestia لبيانات التنفيذ المحددة، ويتحقق عقد الجسر من هذه الحقيقة ليحكم على المعاملة بأنها غير صالحة
   6. يوجد إيداع أو سحب في قائمة المعاملات التي لا تقوم معاملة Eclipse المرتبطة بها بتنفيذ الإجراء المتوقع أو التي لا يقع عدد معاملاتها ضمن نطاق عدد المعاملات المتوقع. وفي مثل هذه الحالة سيحدث أحد الأمرين التاليين:
      1. سيحدد الجسر تلقائيًا أن هذه هي الحالة ويرفض الدفعة المقابلة
      2. يلاحظ المدقق انتقال الحالة غير الصالح وينشر دليلاً على المعاملة المخالفة، والذي يتم التحقق منه بعد ذلك من خلال عقد الجسر

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

أفكار فراق

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

للمشاركة في Eclipse Testnet، يرجى اتباع تعليماتنا هنا. يمكنك الاتصال بنا على Twitter أو Discord لطرح استفسارات محددة حول Testnet أو الجسر أو الأسئلة الفنية.

الحواشي

[1]: العقدة التي تحسب نتائج معاملات SVM وتطبق الإخراج النهائي على حالة Eclipse الجديدة

[2]: عامل يقوم بتمرير الأحداث على السلسلة بين Ethereum وEclipse

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

[4]: يمكن تمثيل حسابات SVM بتجزئة فريدة. الطريقة الوحيدة لتعديل هذا التجزئة هي من خلال المعاملة.

[5]: للقيام بذلك بدون كمية زائدة من التجزئة، سنقوم بإجراء تتبع على كل برنامج تم تنفيذه لمعرفة الأجزاء التي تم الوصول إليها بالفعل من كل نظام مستخدم. هذا ممكن، لكنه سيتطلب تعديل مترجم BPF الخاص بـ Solana.

[6]: يتضمن ذلك بيانات المعاملات التي فشل تنفيذها.

تنصل:

1. تمت إعادة طبع هذه المقالة من [[مرآة]، جميع حقوق النشر مملوكة للمؤلف الأصلي [إكليبس]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.