نموذج CTO: تفسير هارد فورك براغ بعد ترقية Ethereum Cancun

** كلمات: جورجيوس كونستانتوبولوس ، CTO ، Paradigm **

** مترجم: لوفي ، أخبار الاستبصار **

الغرض من هذه المقالة هو تقديم نظرة عامة على آراء فريق Paradigm Reth حول ما يجب تضمينه في Prague Hard Fork (الترقية الرئيسية التالية إلى Consensus Ethereum بعد Cancun Hard Fork) وخطتنا الشاملة ل “EL Core Dev” في عام 2024. تتطور وجهات النظر التالية باستمرار وتمثل وجهات النظر الحالية لفريق Reth ولا تمثل بالضرورة فريق Paradigm بأكمله.

نعتقد أن هارد فورك براغ من المرجح أن يتحقق على EthereumTestnet في Q3 2024 وعلى Mainnet بحلول نهاية العام. يجب أن تشمل:

• EIPs المتعلقة بالتخزين ، مثل EIP-7002 الذي يدعم إعادة التخزين ومجمعات التخزين غير الموثوق بها.
• اختلافات EVM منفصلة.
• نحن على استعداد للعمل مع أي فريق يريد أن ينظر إلى أبعد من ذلك في براغ أو غيرها من EL Hard Fork في المستقبل ويسعدنا تقديم التوجيه والمساعدة حيث يمكن تعديل قاعدة بيانات Reth.

ما يجب القيام به:

• نعتقد أنه يجب إعطاء الأولوية ل EIPs التالية: 7002 ، 6110 ، 2537.
• نحن ندعم EOF الموضح في المواصفات ونأمل في وضع اللمسات الأخيرة على النطاق وإنشاء meta EIP في أقرب وقت ممكن.
• نحن على استعداد لإضافة EIP-4844 Max Blob Gas. ليس لدينا رأي حول أرقام محددة ، لكننا ندعو الأشخاص المعنيين بالبيانات للعمل معنا في هذا الموضوع.
• يسعدنا إصدار نسخة من EIP-7547: تحتوي على قائمة لمساعدة الطبقة الأساسية على مقاومة الرقابة.

ما لا يجب فعله:

• نحن لا ندعم إدراج Verkle Tries في براغ هارد فورك ، لكننا ندعم فريق العملاء لبدء العمل على هذا في الربع الثاني من عام 2024 مع الالتزام بالإصدار في ترقية أوساكا في عام 2025.
• لا نعتقد أنه يجب علينا زيادة حد غاز التنفيذ L1 أو حجم العقد ، لكننا ندعو أفراد البيانات للعمل معنا للتحقيق في تأثيره على الشبكة. نحن على استعداد لتغيير تصورنا لأن الاختبارات السابقة أظهرت أن Reth Node يمكنها التعامل مع الحمل المتزايد دون أي مشاكل.
• نعتقد أن EIPs لتجريد المحفظة / الحساب تحتاج إلى اختبار أكثر عدائية ضد بعضها البعض لفهم مساحة المقايضة بشكل أفضل. إذا لم تكن حصرية بشكل متبادل ، فسنكون على استعداد لنشر العديد من EIPs المتعلقة ب AA في المستقبل.
• إذا وافق المجتمع على الباب الخلفي لوكالة الأمن القومي المشاع ، فيمكننا عبور الخط على EIP-7212 (secp256r1).
• موضوعات خارطة الطريق الأخرى: ليس لدينا فهم فعلي لاقتران شوكات CL EIP أو CL / EL ، لكن EIPs 7549 و 7251 تبدو واعدة. نريد أيضا المساهمة في عمل PeerDAS من جانب EL قدر الإمكان. في الوقت الحالي ، نريد تجنب إدخال جذور SSZ (EIPs 6404 ، 6465 ، 6466). أخيرا ، نرى فرصة لتوفير حل أرشفة بيانات طويل الأجل للنقاط منتهية الصلاحية والتاريخ والحالة ، حيث يوضح كل من EIP-4844 و EIP-4444 ذلك ، ولا يزال يتعين تحديد ما إذا كانت Ethereum على استعداد لتقديم مثل هذا الحل.

توسع في ذلك بالتفصيل أدناه.

أشياء يمكن القيام بها

في الملخص ، نحن ندعم 1) زيادة سد الفجوة بين CL و EL ، و 2) يمكن إجراء تعديلات EVM كعمل فردي ، ويمكن اختبارها بشكل منفصل وبالتوازي.

EIP-7002

يفتح برنامج EIP هذا تجمعات إعادة التخزين والتخزين غير الموثوق بها من خلال تمكين Smart Contract على جانب EL من التحكم في 1 أو أكثر من المدققين على جانب CL. من وجهة نظرنا ، سيمكن على الأقل مجمعات Staking الحالية من إزالة طبقة من المركزية من العقد الذكي الذي يتيح عمليات السحب.

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

EIP-6110

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

EIP-2537

يوجد حاليا العديد من تطبيقات BLS12-381 ، وهو منحنى يستخدم بشكل متكرر في العديد من SNARKs وخوارزميات توقيع BLS و EIP-4844. نحن نعتبرها ذات تعقيد تنفيذ منخفض لأنها تكشف فقط خوارزمية التحقق من صحة المنحنى من خلال واجهة مترجمة مسبقا. قد نحتاج أيضا إلى تجزئة منحنى BLS12-381 الذي تم تجميعه مسبقا.

EOF

• ملاحظة المترجم: EOF تعني تنسيق كائن EVM ، والذي يترجم إلى تنسيق كائن Ethereum ، ويحتوي على سلسلة من EIPs التي تعد بجعل تنفيذ Ethereum أكثر كفاءة واتساقا وقابلية للترقية. تم تنفيذ الخطط المبكرة في ترقية شنغهاي ، والتي تمت إزالتها لاحقا. *

سوف EOF دعم كل من الصلابة و Vyper. ليس هناك شك في أن تنسيق التعليمات البرمجية وتعديلات التحقق ستجعل تحليل الرمز الثانوي أبسط بكثير ، ونوصي بالتفكير بعناية في أي شيء آخر. لقد أوصينا ببعض EIPs أدناه ، لكننا على استعداد لمزيد من التعديل عليها.

على الجانب الإيجابي:

• تغييرات EVM فقط التي يمكن اختبارها باستخدام Ethereum / Testnet وتنفيذها من قبل شخص واحد.
• تغييرات EVM التي يريدها Vyper والصلابة
• يساعد على تحسين الأداء وزيادة حدود حجم العقد.
• يلغي الحاجة إلى تحليل الرمز الثانوي في وقت التشغيل ل EVM. مع عدم وجود تخزين مؤقت ، يمكن أن يصل وقت التحليل إلى 50٪ ويزداد مع زيادة حجم العقد.
• تمكين تحميل التعليمات البرمجية الجزئية للمساعدة في تنفيذ العقود الذكية الكبيرة.
• Devex: سيسمح بإصلاح مشكلة “المكدس العميق جدا” من خلال dupN / swapN وتحسينات الأدوات الأخرى.
• دليل على المستقبل: يمكن تقديم ميزات جديدة بأمان عبر L2 ، وستعرف الأداة ما هو متوافق.

الجوانب السيئة:

• المدى والأهداف الديناميكية.
• لا يوجد ضغط قوي من قبل المؤيدين لإدراجه.
• لا يزال دعم التعليمات البرمجية القديمة مطلوبا
• قبل التبني ، كان هناك خلاف مؤقت بين EthereumMainnet وسلاسل EVM الأخرى.

نعتقد أنه يجب نشر ميزات EOF التالية في عام 2024. نوصي بتحديد النطاق والالتزام بالتنفيذ في أقرب وقت ممكن. يجب النظر في أي شيء آخر لعمليات النشر اللاحقة. توصياتنا هي:

• EIP-3540 (EOF - EVM Object Format v1): يقدم حاويات التعليمات البرمجية والبيانات ، ويضيف بنية وإصدارا إلى Ethereum bytecode.
• EIP-3670 (EOF - التحقق من صحة الكود): يرفض أي عقد لا يتبع تنسيق EOF عند نشره. تنفيذ تعليمات برمجية أكثر تنظيما وتعطيل التوجيهات غير الصالحة وغير المحددة.
• EIP-663 (تعليمات SWAP و DUP اللانهائية): هذا يحل مشكلة “المكدس العميق جدا” في الصلابة وله آثار جانبية كقيمة فورية عبر تحليل JUMPDEST. ميزة مرغوبة للغاية للغة EVM.
• EIP-4200 (EOF - القفزات النسبية الثابتة): تحليل ثابت أفضل مع عدم وجود قفزات غير مؤكدة. تجميع أفضل AOT. القفزات هي أكثر ملاءمة لإعادة استخدام التعليمات البرمجية.
• EIP-4750 (EOF - وظيفة): يتطلب دقة الروتينات الفرعية التي يمكن أن تستخدم القفزات الديناميكية ولكن ليس القفزات الثابتة. كما يسمح بتحميل التعليمات البرمجية الجزئية ، والتي تعمل بشكل مثالي مع Verkle لزيادة حد حجم العقد.
• EIP-5450 (EOF - التحقق من صحة المكدس): تحقق من متطلبات التعليمات البرمجية والمكدس. إزالة عمليات التحقق من التدفق السفلي لمكدس وقت التشغيل والتجاوز لجميع الإرشادات باستثناء CALLF (EIP-4750)
• EIP-7480 (EOF - تعليمات الوصول إلى قسم البيانات): يسمح بالوصول إلى جزء البيانات من الرمز الثانوي.
• EIP-7069 (توجيه CALL المحسن): القدرة على إزالة إمكانية ملاحظة الغاز من CALL ، مما يسهل إعادة تسعير الغاز في المستقبل. على الرغم من أنه مستقل عن EOF ، إلا أننا نرى أن هذه فرصة جيدة لتقديمه.

لسنا متأكدين من EIP-6206 (EOF - JUMPF ووظيفة عدم الإرجاع). على الرغم من أنه يسمح بتحسين مكالمة الذيل في وظائف EOF ، إلا أننا ما زلنا بحاجة إلى معرفة ما يفعله التنميط اللغوي لذلك. إذا لم نفعل ذلك ، نعتقد أنه يمكننا إزالته من النطاق وتضمينه في تحديث EOF لاحق.

نحن نقدر عبء العمل أعلاه ليكون شخص واحد يعمل بدوام كامل لمدة 1-2 أشهر. ونحن على استعداد لتضييق نطاقه أكثر من ذلك.

ملاحظة حول الرمز الثانوي القديم:

• بينما يمكننا حظر رمز بايت قديم / غير EOF جديد ، لا يمكننا إهمال الرمز الثانوي القديم الحالي ، والذي يعمل بشكل فعال ك EOF “v0”. لا يزال الرمز الثانوي القديم يتطلب تحليل JUMPDEST بعد EOF ولا يزال يتطلب معالجة تعليمات برمجية خاصة لتجزئته إلى أجزاء في Verkle Trys.
• على حد علمنا ، لا يمكن التحقق من التحويل من رمز ثانوي غير EOF إلى EOF دون الوصول إلى شفرة المصدر ، لكننا على استعداد للنظر في آليات لتسهيل هذا التحويل.
• بدلا من ذلك ، سنكون على استعداد لاستكشاف طرق لإجبار الدولة على الهجرة إلى EOF.

** زيادة عدد نقاط EIP-4844 **

نحن منفتحون على هذا التغيير ، والذي سيتوافق مع زيادة في MAX_BLOB_GAS_PER_BLOCK و TARGET_BLOB_GAS_PER_BLOCK. يقرأ EIP-4844:

حدد قيم TARGET_BLOB_GAS_PER_BLOCK وMAX_BLOB_GAS_PER_BLOCK لتتوافق مع هدف 3 نقاط (0.375 ميجابايت) لكل كتلة (حتى 6 نقاط). تم تصميم هذه الحدود الأولية الصغيرة لتقليل الضغط على الشبكة الناجم عن EIP ، ومن المتوقع أن يزداد عدد النقط في الترقيات المستقبلية حيث تظهر الشبكة الموثوقية في الكتل الأكبر.

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

لا تفعل

فيركل يحاول

Tl; TL ؛ DR: لا نرى محاولة لنشر Verkle في أواخر عام 2024 / أوائل عام 2025. نوصي بأن يقوم الفريق بتخصيص الموارد لهذا في الربع الثاني من عام 2024 والالتزام بالنشر في هارد فورك في أوساكا في الربع الثاني من عام 2025.

على الجانب الإيجابي:

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

عيوب:

• أثر التغييرات والجهود المبذولة لتنفيذها واختبارها.
• تغييرات حساب الغاز: يحاول Verkle إدخال حجم الشاهد في ميزة حساب الغاز. نحن قلقون من أن التغييرات في أسعار التخزين لم يتم استكشافها بعد (على سبيل المثال ، ما هي تكلفة كبار مستهلكي الغاز بعد Verkle)؟
• تكامل التطبيق: ما الذي يجب أن يفعله التطبيق الذي يحتوي على مدقق Merkle Patricia Trie عند تشغيل انتقال التراكب؟ كيف يجب أن يتصرف eth \ _getProof؟

بينما نتفهم فوائد Verkle Try ، نعتقد أنه يجب إيلاء المزيد من الاهتمام لكيفية ملاءمة أدوات / عقود الجهات الخارجية ، وما هو تأثير ذلك على الطبقة 2 وما شابه ذلك خلال الفترة الانتقالية. في البداية كانت لدينا شكوك حول استراتيجية الهجرة لأنها ذكرت أنه يجب تحديث محاولة Verkle عندما تمت قراءة الدولة من MPT موجود مسبقا ، ولكن يبدو أن هذا لم يعد هو الحال. لذلك ، نحن نؤيد نهج التراكب كمسار ترحيل قابل للتطبيق.

تبدو وثائق استراتيجية ترحيل Verkle قديمة ، حيث لا تزال معظم الموارد تنص على أنه يجب تحديث محاولة Verkle عند قراءة الحالة من MPT. نود أن نرى وثائق الانتقال بأحدث الأساليب ، مثل هذا النهج الممتاز. نود أيضا أن نرى مسودة EIP حول استراتيجية الانتقال.

لذلك ، ما زلنا ندعم طرحه في عام 2025 بدلا من نشره في براغ هارد فورك.

** حد الغاز L1 **

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

ندعو الآخرين للعمل معنا في البحث في هذا الاتجاه ، غالبا حول كسر قياس الموارد في EVM. أطروحة متر مكسور هي نقطة انطلاق جيدة للبحث في هذا المجال.

تجريد الحساب

نود تضمين 1 أو أكثر من EIPs ، لكننا نود أن نرى المزيد من المقارنة بين تجربة المستخدم وتجربة المطور بين كل اقتراح لفهم المقايضات والجهد المبذول لتكامل الأداة بشكل أفضل. نحن نبحث في EIPs / ERCs التالية ، ولكن لا تتردد في تقديم المشورة لنا:

• EIP-3074: رمز تشغيل AUTH و AUTHCALL
• ERC-4337: استخدام Alt Mempool لتجريد الحساب
• EIP-5806: معاملة مفوضة
• EIP-5920: رمز عملية الدفع
• EIP-6913: توجيه SETCODE
• EIP-7377: معاملات الترحيل
• RIP-7560: تجريد الحساب الأصلي - Core EIP - زمالة سحرة Ethereum

ما نحتاج إلى ملاحظته أعلاه هو أن “تجريد الحساب” يشبه “وظيفة التحقق المجردة ، والهدف الرئيسي هو تنفيذ دوران المفتاح السري ، وإنشاء مفتاح multisig ، وتزويدنا بمسار لتحقيق المقاومة الكمومية تلقائيا”.