باحث Ethereum: Rollups الأصلية – القوى العظمى من تنفيذ L1

المؤلف: باحث Ethereum جوستين دريك ، Ethresearch ؛

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

ملخص

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

نظرًا لأن Execute Prefompilation يتم تنفيذه مباشرة بواسطة المدقق ، فإنه يتمتع بتنوع عميل EL (ZK) ويوفر معادلات EVM خالية من الأخطاء ويتم ترقيتها إلى EVM عبر التوافق السابق في الشوكة L1.للحصول على ملخص مكافئ EVM الذي يرغب في أن يرث أمن Ethereum بالكامل ، من الضروري أن تكون أشكال التأمل EVM مثل التنفيذ ضرورية.نحن نسمي ملخص ورث الأمن Ethereum بالكامل “ملخص غير موثوق به”.

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

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

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

الجزء 1 – تنفيذ مسبق

بناء

يقبل تنفيذ Precompilation المدخلات pre_state_root ، post_state_root ، trace ، و gas_used.يعود صحيحًا إذا وفقط إذا تم استيفاء الشروط التالية:

• تتبع هو تتبع تنفيذ جيد الشكل (على سبيل المثال ، قائمة المعاملات L2 وإثبات الوصول إلى الحالة المقابلة)

• يبدأ التنفيذ عديمة الجنسية للتتبع بـ pre_state_root وينتهي بـ post_state_root

• إن التنفيذ عديمي الجنسية للتتبع يستهلك الغازات الغازية فقط

هناك آلية على غرار EIP-1559 لقياس وتسعير الغاز المتراكم الذي تستهلكه جميع المكالمات التنفيذ في كتلة L1.على وجه التحديد ، هناك حد غاز مترابط execute_cumulative_gas_limit ، وهدف الغاز المتراكم execute_cumulative_gas_target.(عندما يمكن تنفيذ L1 EVM بلا أساس من قبل المحقرة ، يمكن دمج الحدود التراكمية والأهداف مع آلية L1 EIP-1559.)

يتطلب استدعاء المكالمات المسبقة عددًا ثابتًا من غاز L1 ، Execute_GAS_COST ، بالإضافة إلى gas_used * gas_price ، حيث يتم تعيين GAS_PRICE (السعر في ETH/GAS) بواسطة آلية على غرار EIP-1559.سيتم سحب الدفع المسبق الكامل حتى لو عادت Precompilation False.

يجب أن يشير التتبع إلى بيانات Ethereum المتاحة من بيانات المكالمات أو النقطة أو الحالة أو الذاكرة.

إعادة تنفيذ

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

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

كسجل تاريخي ، في عام 2017 ، اقترح Vitalik “EVM Inside EVM” مماثل يسمى exectx.

تنفيذ عبر Snark

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

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

من الآن فصاعدًا ، نفترض أن مقترح التنفيذ ينضج في سياق فصل Prove-Proposer (APS) مع فتحات التنفيذ والتوافق في الآراء.لتحفيز مقترح التنفيذ العقلاني على إنشاء أدلة في الوقت المناسب (خلال فترة زمنية واحدة) ، نطلب أن تثبت البراهين كتلة التنفيذ N+1 فقط عندما يتوفر دليل التنفيذ N.(نوصي بتجميع الكتلة N+1 باستخدام دليل تنفيذ الكتلة N على طبقة P2P.) قد يفوت مقترحو التنفيذ الذين يخطون البراهين فتحاتهم ، مما يؤدي إلى رسوم ضائعة و MEVs.نفرض أيضًا عقوبة ثابتة على فتحات التنفيذ الفائتة ، ونضعها عالية بدرجة كافية (على سبيل المثال 1 ETH) لتجاوز دائمًا تكلفة الدليل.

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

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

دليل خارج السلسلة

للتكرار ، نوصي بعدم وضع دليل Zkel على السلسلة ، ولكن مشاركته خارج السلسلة.عدم توفير الدليل هو فكرة جيدة ، اقترحها فيتاليك أولاً ، ولديها العديد من المزايا:

• تنوع:التحديثات حرة في تحديد صحة إثبات (بما في ذلك أنظمة الإثبات والدوائر) من فريق التطوير الذي يثقون به ، على غرار كيفية اختيار المدققين لعملاء EL الذين يثقون به.وهذا يوفر المتانة من خلال التنوع.يعد عميل Valitator Zkel (وبعض ZKVMs الأساسية للعملاء) برنامج تشفير معقد.يجب ألا تتسبب الأخطاء في أي من العميل في تعطل Ethereum.

• الحياد:يتيح وجود سوق عميل Zkel Validator لطبقة الإجماع عدم تحديد الفائز بالتكنولوجيا.على سبيل المثال ، فإن سوق ZKVM تنافسية للغاية وقد لا يعتبر مورد رابح (مثل RISC0 ، أو مقتضبة ، أو العديد من الموردين الآخرين) محايدًا.

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

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

إن وجود دليل خارج السلسلة يؤدي إلى بعض المضاعفات التي يمكن التحكم فيها:

• إثبات الحمل وتفتت P2P:نظرًا لعدم وجود دليل واحد على المواصفات ، يجب إنشاء أدلة متعددة (على الأقل واحد لكل عميل Zkel).يتطلب كل تخصيص عميل ZKEL (على سبيل المثال ، تبديل واحد ZKVM RISC-V لآخر) دليلًا مختلفًا.وبالمثل ، تتطلب كل ترقية إصدار Zkel دليلًا مختلفًا.هذا سيؤدي إلى زيادة تحميل دليل.إذا كان لكل نوع من أنواع الإثبات قناة ثرثرة منفصلة ، فسيؤدي ذلك إلى زيادة جزء شبكة P2P.

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

سيؤدي الإثبات خارج السلسلة أيضًا إلى تقليل كفاءة التسوية في الوقت الفعلي L2:

• لا يوجد بديل دا:نظرًا لأن إدخال تتبع التنفيذ يجب توفيره لمقحة L1 ، فإن L2 الذي يستقر في الوقت الحقيقي (L2 الذي يقوم بتحديث جذر حالة المواصفات الخاص به على الفور) يجب أن يستهلك L1 DA ، أي الملخص.لاحظ أنه لا يوجد حد من هذا القبيل على L2 المتفائل لتسوية اللعبة المتأخرة عن طريق الاحتيال ، أي أنه يمكن أن يكون قيمة صالحة.

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

• لا يوجد فرق في الدولة:نظرًا لأن الدليل يجب أن يكون بدون إذن ، فلا يمكن إجراء اختلاف حالة الملخص بسبب تتبع معين.ومع ذلك ، إذا تم دمج الدليل المتخصص المقابل في الإجماع ، فيمكن ضغط دليل الوصول أو توقيع معاملة EVM.

التنفيذ الأصلي RISC-V

بالنظر إلى التقارب الفعلي اليوم مع RISC-V ZKVM ، قد تكون هناك فرصة لفضح انتقالات حالة RISC-V محليًا إلى EVMs (على غرار WASMs في بيئات القلم التعريفي) والحفاظ على الصديقة.

الجزء 2 – Rollup الأصلي

اسم

دعنا نناقش أولاً تسمية Rollup الأصلي لحل العديد من المشكلات المربكة:

• الاسم البديل:كان ملخص الأصلي معروفًا سابقًا باسم الملخص المكرس.(تم استخدام مصطلح “الملخص الكنسي” أيضًا لفترة وجيزة في Polynya 12.) تم التخلي عن مصطلح “مكرس” لاحقًا واستبداله بـ “الأصلي” للإشارة إلى أن الملخص المكافئ EVM الحالي يمكن ترقيته اختياريًا إلى الأم.تم اقتراح اسم “مواطن” بشكل مستقل من قبل دان روبنسون ومساهم في Lido الذي أراد عدم الكشف عن هويته في نوفمبر 2022.

• بناءً على الملخص:استنادًا إلى الملخص والملخصات الأصلية ، تكون المفاهيم المتعامدة دائمًا: “بناء” مرتبط بفرز L1 ، في حين يرتبط “الأصلي” بتنفيذ L1.في الوقت نفسه ، بناءً على الملخص الأصلي هو غريب الأطوار يسمى “ملخص فائق”.

• تنفيذ Sharding:يعد Syngution Swarding (أي النسخة المكرسة من سلسلة L1 EVM) مفهومًا مختلفًا ولكنه مرتبط بالملخصات الأصلية ، قبل عدة سنوات من الملخصات الأصلية.(كان تنفيذ Sharding قبل “المرحلة 2” من خريطة الطريق Ethereum 2.0.) على عكس Rollup الأصلي ، فإن Sharding غير قابل للبرمجة ، أي أنه لا توجد خيارات مثل الحوكمة المخصصة والفرز المخصص ورموز الغاز المخصصة.عادةً ما يتم إنشاء مثيل لأش0 التنفيذ في رقم ثابت (على سبيل المثال 64 أو 1024 شظايا).لسوء الحظ ، استخدم Martin Köppelmann مصطلح “Native L2” 7 في خطاب Devcon لعام 2024 بشأن تنفيذ الشظايا.

فائدة

تتميز Rollups الأصلية بعدة فوائد ، والتي سنقدمها بالتفصيل أدناه:

• بساطة:يمكن تغليف معظم تعقيد Rollup VM الأصلي عن طريق precompilation.اليوم ، يمتلك التفاؤل و ZK-Rollup ، مماثل لـ EVM ، آلاف خطوط التعليمات البرمجية لألعاب إثبات الاحتيال الخاصة بهم أو صحة Snark التي يمكن ضغطها في سطر واحد من التعليمات البرمجية.لا تتطلب Rollups الأصلية أيضًا بنية تحتية مساعدة مثل شبكات الإثبات وأعمال المراقبة ولجان الأمن.

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

• معادلة EVM:اليوم ، فإن الطريقة الوحيدة التي تتمثل فيها Rollup متزامنة مع قواعد L1 EVM هي أن يكون لها حوكمة (عادةً لجان أمنية و/أو رموز الحوكمة) ترقيات L1 EVM.(لا تزال تحديثات EVM يتم تنفيذها بانتظام مع شوكات صلبة تقريبًا مرة واحدة في السنة.) الحوكمة ليست فقط متجه الهجوم ، بل تنحرف بشكل صارم عن L1 EVM وتمنع أي رولوب من تحقيق معادلة EVM ذات الأجل الحقيقية.另一方面，原生 rollup 可以与 L1 同步升级，无需治理。

• تكلفة غاز Snark:التحقق من Snark على السلسلة مكلفة.لذلك ، نادراً ما يستقر العديد من ZK-Rollups لتقليل التكاليف.نظرًا لعدم التحقق من صحة Snark على السلسلة ، يمكن استخدام تنفيذ التنفيذ لتقليل تكاليف التحقق.إذا كنت تستخدم Snark لتنفيذ الدُفعات بشكل متكرر لمكالمات متعددة في كتلة ، فيمكن تعيين Execute_GAS_COST منخفضًا نسبيًا.

• التزامن المتزامن:اليوم ، يتطلب الإمكانية المتزامنة مع L1 دليلًا في الوقت الفعلي على نفس الفتحة.يعد تنفيذ أدلة الكمون الفائقة (على سبيل المثال ، حوالي 100 ميلي ثانية) مهمة هندسية صعبة بشكل خاص لـ ZK Rollups.باستخدام جذر حالة تأخير فتحة واحدة ، يمكنك استرخاء تأخير دليل الأداء الأصلي الذي تم تجميعه إلى فتحة كاملة.