ما هي الترقية التالية بعد الانقسام الصلب لإيثريوم في كانكون؟

الهدف من هذه المقالة هو تحديد وجهات نظر فريق Paradigm Reth ^[4] حول شوكة براغ الصلبة، التالية بعد كانكون EL الصعبة شوكة، ونظرة عامة على خطط "EL Core Development" لعام 2024. الآراء الواردة أدناه قيد التطوير وتمثل وجهات النظر الحالية لفريق Reth ولا تمثل بالضرورة فريق Paradigm الأوسع.

يجب أن يتضمن:

أي EIP يتعلق بالتعهد، مثل EIP-7002 ، فهو يتيح إعادة التوقيع المساحي ومجموعات التوقيع المساحي غير الموثوق بها.

تغييرات EVM المستقلة.

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

الدعم:

نعتقد أنه يجب إعطاء الأولوية لبرنامج EIP التالي: 7002^{[5 ]}, 6110^<[6], 2537^<[7].

نحن ندعم EOF كما هو موضح في المواصفات ^[8]، ولكننا نرغب في توسيع نطاقه قريبًا وإنشاء Meta-EIP الذي يلتزم بالالتزام بهذا النطاق.

نحن على استعداد لزيادة إصدار EIP-4844 الحد الأقصى لغاز Blob Gas^[9]. ليس لدينا رأي في الرقم الصحيح، ولكننا ندعو مسؤولي البيانات للعمل معنا للتحقيق في هذه المشكلة.

نود إصدار EIP-7547: إصدار يحتوي على القائمة ^[10] للمساعدة في جعل الطبقة الأساسية مقاومة للرقابة.

غير مدعوم:

نحن لا ندعم محاولات Verkle في براغ^{[ 11 ]}، ولكننا ندعم فريق العميل الذي يعمل على تحقيق ذلك بدءًا من الربع الثاني من عام 2024، مع الوعد بإصداره في منتصف وأواخر عام 2025 في أوساكا.

لا نعتقد أنه يجب زيادة حدود غاز التنفيذ L1 أو أحجام العقود، ولكننا ندعو مسؤولي البيانات للعمل معنا للتحقيق في التأثير على الشبكة. نحن على استعداد لمراجعة رأينا لأن الاختبارات السابقة أظهرت أن عقد Reth يمكنها التعامل مع الحمل المتزايد دون مشكلة.

نعتقد أن EIP الخاص بالمحفظة/الحساب يحتاج إلى مزيد من الاختبارات ضد بعضها البعض لفهم مساحة المقايضة بشكل أفضل. نحن على استعداد لنشر العديد من خطط EIP ذات الصلة بـ AA في المستقبل إذا لم تكن متنافية.

إذا كان المجتمع قلقًا بشأن ^[12] المشاع عن وكالة الأمن القومي ^[13] الباب الخلفي ^{[14 ]} حسنًا، يمكننا قبول EIP-7212 (secp256r1).

موضوعات خارطة الطريق الأخرى: ليس لدينا وجهات نظر محددة حول CL EIP أو اقتران شوكات CL/EL، ولكن EIP 7549^[15] و7251^<[16] تبدو واعدة. نأمل أيضًا أن نساهم قدر الإمكان في عمل PeerDAS من جانب EL. نريد تجنب تقديم جذور SSZ (EIP 6404، 6465، 6466) في الوقت الحالي. أخيرًا، نلاحظ الفرصة لتوفير حل طويل الأمد لأرشفة البيانات للكائنات الثنائية الكبيرة والتاريخ والحالة منتهية الصلاحية، مثل EIP-4844^[17] وEIP-4444^[18] لم يحدد أي منهما ذلك، ولا ما إذا كانت إيثريوم على استعداد لتقديم مثل هذا الحل.

وفيما يلي المنطق.

الدعم

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

EIP-7002^<[19]

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

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

EIP-6110^<[20]

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

EIP-2537^<[21]

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

EOF^[22] تنسيق كائن الإيثريوم

TL ; DR: دعم الإصدار واسع النطاق الذي ستتبناه Solidity وVyper. إن تنسيق التعليمات البرمجية وتعديلات التحقق التي تجعل التحليل أسهل هي أمر لا يحتاج إلى تفكير، ونحن نوصي بمزيد من التحسين.

الفوائد:

يمكن إجراء تغييرات EVM فقط من خلال Ethereum/اختبارات للاختبار والتنفيذ من قبل شخص واحد.

قم بإجراء تغييرات EVM التي يريدها Vyper وSolidity!

يساعد في الأداء ويحسن حجم حدود العقد.

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

يمكن تحميل التعليمات البرمجية جزئيًا، مما يساعد على تنفيذ العقود الكبيرة.

Devex: سيسمح بإصلاح "Stack Too Deep" باستخدام dupN/swapN في Solidity، من بين تحسينات الأدوات الأخرى.

مقاومة للمستقبل: يمكن تقديم الميزات الجديدة بأمان إلى اللغة الثانية وستعرف الأدوات ما هو المتوافق.

نقاط الضعف:

الأهداف المتغيرة.

لم يضغط أي مؤيد بشدة من أجل إدراجه.

لا تزال التعليمات البرمجية القديمة بحاجة إلى الدعم

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

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

EIP-3540: EOF - تنسيق كائن EVM v1^[23]: تقديم حاويات التعليمات البرمجية والبيانات، وتوفير Ethereum يضيف bytecode البنية والإصدار.

EIP-3670: EOF - التحقق من الرمز ^[24]: رفض أي عقد لا يتبع تنسيق EOF عند النشر. يفرض تعليمات برمجية أكثر تنظيماً ويعطل التوجيهات غير الصالحة وغير المحددة.

EIP-663: تعليمات SWAP وDUP غير محدودة ^[25]: يؤدي هذا إلى حل مشكلة "Stack Too Deep" في Solidity، والتحليل عبر JUMPDEST كقيمة فورية قد يكون لها آثار جانبية. تأمل لغة EVM كثيرًا في الحصول على مثل هذه الميزة.

EIP-4200: EOF - القفزات النسبية الثابتة^[26]: تحليل ثابت أفضل، لا توجد قفزات غير مؤكدة . أفضل تجميع AOT. تعد القفزات النسبية أفضل لإعادة استخدام التعليمات البرمجية.

EIP-4750: EOF - الوظيفة ^[27]: تحتاج إلى التعامل مع الفئات الفرعية التي قد تحتوي على قفزات ديناميكية ولكن ليس روتين القفزات الثابتة. كما يسمح أيضًا بالتحميل الجزئي للكود، والذي يعمل بشكل جيد مع Verkle ويزيد من حد حجم العقد.

EIP-5450: EOF - التحقق من المكدس^[28]: التحقق من الكود ومتطلبات المكدس. تمت إزالة عمليات التحقق من تجاوز السعة والتجاوز لمكدس وقت التشغيل لجميع التعليمات باستثناء CALLF (EIP-4750).

EIP-7480: EOF - تعليمات الوصول إلى مقطع البيانات ^[29]: تسمح بالوصول إلى مقطع البيانات الخاص بالرمز الثانوي.

EIP-7069: تعليمات الاتصال المحسنة ^[30]: اختفاء إمكانية ملاحظة الغاز في المكالمات، مما يسهل إجراء الغاز في المستقبل إعادة التسعير. على الرغم من استقلالنا عن EOF، فقد اعتقدنا أن هذه كانت فرصة جيدة لتقديمه.

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

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

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

على الرغم من أنه يمكننا حظر التقليدي الجديد/غير EOF bytecode، ولكن لا يمكن إهمال الكود الثانوي القديم الحالي، فهو يعمل بشكل فعال كـ EOF "v0". لا يزال الرمز الثانوي التقليدي يتطلب تحليل JUMPDEST بعد EOF، ولا تزال هناك حاجة إلى معالجة خاصة للتعليمات البرمجية لتقسيمه إلى محاولات Verkle.

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

بدلاً من ذلك، نحن على استعداد لاستكشاف طرق انتهاء الصلاحية التي تفرض ترحيل الحالة إلى EOF.

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

نحن على استعداد لقبول هذا التغيير، والتي سيتم زيادتها MAX_BLOB_GAS_PER_BLOCK وTARGET_BLOB_GAS_PER_BLOCK، لمعرفة السياق، راجع EIP-4844^[32]:

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

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

غير مدعوم

محاولات Verkle^<[33]

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

الفوائد:

يتم تحقيقها من خلال أدلة تخزين أصغر وضوء أرخص عميل.

تمكين التنفيذ عديم الحالة من خلال تضمين الحالة المسبقة للقراءة في رأس الكتلة، مما قد يؤدي أيضًا إلى تحسينات في الأداء بسبب الوصول إلى الحالة الثابتة.

قم بزيادة الحد الأقصى لحجم العقد عن طريق تقسيم الكود الثانوي وتمكين التحميل الجزئي للكود.

نظرًا لانخفاض تكلفة "إحياء" الحالة، يصبح انتهاء صلاحية الحالة أكثر جاذبية.

نقاط الضعف:

عبء العمل الكبير: تأثير التغييرات، تنفيذ واختبار العمل التكاملي.

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

تكامل التطبيق: ما الذي يجب أن يفعله التطبيق المزود بمدقق Merkle Patricia Trie عند تشغيل انتقال التراكب؟ كيف يجب أن يتصرف eth_getProof؟

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

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

لذلك، ما زلنا ندعم إطلاق Verkle في عام 2025، لكننا لا نرى مسار نشر لترقية براغ.

حد الغاز L1

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

ندعو الجميع للتعاون معنا في أي بحث في هذا الاتجاه وحول التخلص من قياس الموارد في EVM. تُعد ورقة "العداد المكسور"^[35] نقطة انطلاق جيدة لهذا الاتجاه البحثي.

تجريد الحساب

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

EIP-3074: أكواد تشغيل AUTH وAUTHCALL^[36]

ERC-4337: تجريد الحساب باستخدام Alt Mempool^[37]

EIP-5806: تفويض المعاملة^[38]

EIP-5920: رمز تشغيل الدفع^[39]

EIP-6913: تعليمات SETCODE^[40]

EIP-7377: معاملة الترحيل^[41]

RIP-7560: تجريد الحساب الأصلي - الأساسي EIPs - زمالة سحرة الإيثريوم^[42]

نود توضيح أنه في المحتوى أعلاه، يشير "تجريد الحساب" إلى "وظيفة التحقق المجردة، الهدف الرئيسي هو تمكين تدوير المفاتيح، وجعل التوقيع المتعدد ميزة من الدرجة الأولى، ومنحنا مسارًا آليًا للمقاومة الكمية" (h/t VB)، ينطبق فقط على 4337 و7560، في حين أن البعض الآخر وتنقسم المقترحات إلى فئتين، أي رعاية الغاز وتشغيل الخلط.

المؤلف:

جورجيوس كونستانتوبولوس^<[43]

جورجيوس كونستانتوبولوس هو الرئيس التنفيذي للتكنولوجيا والشريك البحثي في ​​Paradigm، مع التركيز على شركات محفظة Paradigm والبروتوكولات مفتوحة المصدر. في السابق، عمل جورجيوس كمستشار وباحث مستقل.