باحث إيثريوم: مجموعات القيمة الأصلية – قوى خارقة من تنفيذ L1

المؤلف: جاستن دريك، الباحث في إيثريوم، والمترجم: تاو تشو، جولدن فاينانس

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

الملخص

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

نظرًا لأن تنفيذ التنفيذ المسبق يتم تنفيذه مباشرة بواسطة أداة التحقق، فإنه يتمتع بتنوع عملاء (zk)EL ويوفر معادلة EVM خالية من الأخطاء في البناء ومتوافقة مع ترقيات Forked EVM المتوافقة مع الأمام. بالنسبة لمجموعات EVM المكافئة التي ترغب في وراثة أمان Ethereum بالكامل، يعد شكل من أشكال استبطان EVM مثل الترجمة المسبقة EXECUTE ضروريًا. نطلق على المجموعات المجمعة التي ترث أمان Ethereum بالكامل اسم "المجموعات غير الموثوق بها".

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

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

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

الجزء الأول - تنفيذ الترجمة المسبقة

البنية

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

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

• يبدأ تنفيذ التتبع بدون حالة عند pre_state_root وينتهي عند post_state_root النهاية

• يستهلك تنفيذ التتبع عديم الحالة الغاز المستخدم تمامًا

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

يكلف استدعاء التجميع المسبق كمية ثابتة من غاز L1، EXECUTE_GAS_COST، بالإضافة إلى Gas_used *gas_price، حيث يتم تحديد سعر الغاز (المسعر بـ ETH/gas) بواسطة آلية على طراز EIP-1559. حتى لو كانت نتائج الترجمة المسبقة خاطئة، فسيتم أخذ التقدمة الكاملة.

يجب أن تشير الآثار إلى بيانات Ethereum المتوفرة من بيانات الاتصال أو البيانات الثنائية الكبيرة أو الحالة أو الذاكرة.

إعادة التنفيذ

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

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

لملاحظة تاريخية، اقترح Vitalik في عام 2017 تجميعًا مسبقًا مشابهًا لـ "EVM داخل EVM" يسمى EXECTX.

التنفيذ من خلال SNARK

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

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

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

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

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

إثبات خارج السلسلة

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

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

• الحياد: إن وجود سوق عملاء أداة التحقق من صحة zkEL يسمح لطبقة الإجماع بعدم اختيار الفائز التكنولوجي. على سبيل المثال، يتميز سوق zkVM بقدرة تنافسية عالية، وقد لا يعتبر اختيار البائع الفائز (مثل Risc0 أو Succinct أو العديد من المنتجات الأخرى) محايدًا.

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

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

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

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

• عدد قليل من zkELs: من الصعب تحفيز عدد صغير من zkELs لإنشاء البراهين. قد يقوم مقدمو الاقتراحات المنفذون بعقلانية فقط بإنشاء ما يكفي من الأدلة للوصول إلى الأغلبية العظمى من المُثبتين دون فقدان مكانهم. لحل هذه المشكلة، يمكن تشجيع مشغلي التوقيع المساحي اجتماعيًا على تشغيل عملاء zkEL متعددين بالتوازي، على غرار مشغلي Vouch الحاليين. إن تشغيل إعداد k-of-n له فائدة إضافية تتمثل في تحسين الأمان، وتحديدًا منع الثغرات الأمنية التي من شأنها أن تسمح للمهاجم بصياغة إثباتات لمكالمات التنفيذ التعسفية (وهو موقف غير ممكن مع عملاء EL التقليديين).

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

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

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

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

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

نظرًا للتقارب الفعلي اليوم مع RISC-V zkVM، قد تكون هناك فرصة لكشف تحولات حالة RISC-V قم بإعطاء EVM أصلاً (على غرار WASM في بيئة Arbitrum Stylus) واجعله صديقًا لـ SNARK.

الجزء الثاني - مجموعة التحديثات الأصلية

التسمية

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

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

• المستند إلى التجميع: التجميع القائم على التجميع والتجميع الأصلي هما مفاهيم متعامدة: يرتبط "مستند" بترتيب L1، بينما يرتبط "أصلي" لتنفيذ L1. يُطلق على كل من المجموعات الأصلية والأصلية اسم "مجموعات الأسرع من الصوت".

• تقسيم التنفيذ: يعد تقسيم التنفيذ (أي النسخ المضمنة من سلسلة L1 EVM) مفهومًا مختلفًا ولكنه مرتبط بالتراكم الأصلي، والتجميع الأصلي المسبق بواسطة عدة سنوات. (كانت تقسيم التنفيذ سابقًا "المرحلة الثانية" من خريطة طريق Ethereum 2.0.) على عكس المجموعات الأصلية، فإن تقسيم التنفيذ غير قابل للبرمجة، أي لا توجد خيارات للحوكمة المخصصة، والترتيب المخصص، ورموز الغاز المخصصة، وما إلى ذلك. عادةً ما يتم أيضًا إنشاء مثيل لأجزاء التنفيذ برقم ثابت (مثل 64 أو 1024 قطعة). لسوء الحظ، استخدم مارتن كوبلمان مصطلح "L2 الأصلي" في حديثه عن تنفيذ التقسيم في Devcon 2024 7 .

الفوائد

للمجموعات الأصلية العديد من الفوائد، والتي سنشرحها بالتفصيل أدناه:

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

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

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

• تكلفة غاز SNARK: يعد التحقق من SNARK على السلسلة أمرًا مكلفًا. لذلك، نادرًا ما يتم تسوية العديد من عمليات zk-rollups لتقليل التكاليف. نظرًا لعدم التحقق من SNARKs على السلسلة، يمكن استخدام التنفيذ المسبق لتقليل تكاليف التحقق. إذا كنت تستخدم SNARK العودية لدفع بروفات EXECUTE لاستدعاءات متعددة في كتلة، فيمكن تعيين EXECUTE_GAS_COST على مستوى منخفض نسبيًا.

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