نموذج CTO: الفصل التالي بعد ترقية Ethereum Cancun

قد يتم تنفيذ ترقية براغ بعد ترقية كانكون بحلول نهاية عام 2024.

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

** تم إعداده بواسطة: لوفي، فورسايت نيوز**

الغرض من هذه المقالة هو توضيح وجهة نظر فريق Paradigm Reth حول ما يجب تضمينه في EIP في شوكة براغ الصلبة (الترقية الرئيسية التالية إلى Ethereum بعد شوكة كانكون الصلبة)، وخطتنا الشاملة لـ “EL Core Dev” في عام 2024 ملاحظة: تشير EL إلى طبقة التنفيذ، وتشير CL إلى طبقة الإجماع). تتطور وجهات النظر التالية باستمرار وتمثل فقط وجهات النظر الحالية لفريق Reth ولا تمثل بالضرورة فريق Paradigm بأكمله.

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

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

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

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

ما الذي عليك عدم فعله:

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

قم بالتوسيع بالتفصيل أدناه.

الأشياء الذي ينبغي فعلها

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

إي آي بي-7002

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

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

إي آي بي-6110

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

إي آي بي-2537

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

إي أو إف

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

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

الجانب الجيد:

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

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

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

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

• EIP-3540 (EOF - EVM Object Format v1): يقدم حاويات التعليمات البرمجية والبيانات ويضيف البنية والإصدار إلى كود Ethereum الثانوي.
• 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 (تعليمات الاتصال المحسنة): القدرة على إزالة إمكانية ملاحظة الغاز من الاتصال، مما يسهل إعادة تسعير الغاز في المستقبل. على الرغم من استقلالنا عن EOF، إلا أننا نعتقد أن هذه فرصة جيدة لتقديمه.

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

نحن نقدر أن عبء العمل المذكور أعلاه يتطلب أن يعمل شخص واحد بدوام كامل لمدة شهر إلى شهرين. ونود أن نزيد من تضييق النطاق المذكور أعلاه.

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

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

زيادة عدد EIP-4844 Blobs

نحن منفتحون على هذا التغيير، والذي سيتوافق مع زيادة في 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;DR: لا نرى محاولة في أواخر عام 2024 وأوائل عام 2025 لنشر Verkle. نوصي الفريق بتخصيص الموارد لذلك في الربع الثاني من عام 2024 والالتزام بالنشر في الانقسام الصلب في أوساكا في الربع الثاني والربع الثالث من عام 2025.

الجانب الجيد:

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

مكانا سيئا:

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

على الرغم من أننا نفهم فوائد Verkle Tries، إلا أننا نعتقد أنه يجب إيلاء المزيد من الاهتمام لكيفية تكيف أدوات/عقود الطرف الثالث، وما هو التأثير الذي ستحدثه هذه الفترة الانتقالية على الطبقة الثانية وما إلى ذلك. في البداية كانت لدينا مشكلات تتعلق بسياسة الترحيل حيث نصت على أنه يجب تحديث محاولة Verkle عند قراءة الحالة من MPT الموجود مسبقًا، ولكن لا يبدو أن هذا هو الحال بعد الآن. لذلك، نحن ندعم نهج التراكب كمسار ترحيل قابل للتطبيق.

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

لذلك، ما زلنا نؤيد إطلاقه في عام 2025 بدلاً من نشره في شوكة براغ الصلبة.

حد الغاز L1

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

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

تجريد الحساب

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

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

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