jakiro
الهدف من هذا المقال هو تحديد النموذج Reth Team[4]بالنسبة لشوكة براغ الصعبة ، فإن براغ هو الشوكة الصلبة التالية بعد كانكون ، ونظرة عامة على خطة “EL Core Development” لعام 2024.وجهات النظر التالية قيد التطوير ، ولا تمثل النظرة الحالية لفريق RETH سوى فريق نموذج أوسع.
نعتقد أنه قد يتم تحقيق شوكة براغ الصعبة على شبكة اختبار Ethereum في الربع الثالث من عام 2024 ، وسيتم تحقيقها على الشبكة الرئيسية في نهاية العام.
يجب أن تشمل:
أي EIP المتعلق بالتعهد ، مثل EIP-7002 ، يجعل من الممكن إعادة الظهر والبركة غير الموثوقة.
تغييرات EVM المستقلة.
نحن على استعداد للتعاون مع أي فريق نريد مزيد من دراسة براغ أو غيرها من الانقسامات الصعبة في المستقبل ، ونكون على استعداد لتوجيه أو تقديم إرشادات لتعديل موقع مكتبة RETH Code.
يدعم:
نعتقد أنه يجب إعطاء EIP التالي الأولوية: 7002[5]، 6110[6]، 2537[7]جوهر
نحن ندعم EOF ، مثل المواصفات[8]في هذا ، آمل أن أحدد النطاق في أسرع وقت ممكن وأنشئ meta -eip لوعد بالامتثال للنطاق.
نحن على استعداد[9]إصدار.ليس لدينا أي رأي بشأن الأرقام الصحيحة ، لكننا ندعو موظفي البيانات إلى التعاون معنا للتحقيق في هذه المشكلة.
نحن على استعداد لنشر EIP-7547: تضمين القوائم[10]الإصدار لمساعدة الطبقة الأساسية لمكافحة المراجعة.
غير مدعوم:
نحن لا ندعم استخدام محاولات Verkle في براغ[11]ومع ذلك ، فإننا ندعم فريق العميل لتحقيق ذلك منذ الربع الثاني من عام 2024 ، ووعد بالإفراج عنه في أوساكا في منتصف -2025 منتصف -2025.
لا نعتقد أنه ينبغي زيادة حد غاز تنفيذ L1 أو حجم العقد ، لكننا ندعو موظفي البيانات إلى التعاون معنا للتحقيق في التأثير على الشبكة.نحن على استعداد لتعديل وجهات نظرنا ، لأن الاختبارات السابقة تظهر أن عقدة RETH يمكنها التعامل مع الحمل المتزايد دون مشاكل.
نعتقد أن تجريد المحفظة/الحساب يتطلب EIP المزيد من اختبارات المواجهة المتبادلة لفهم مساحة التوازن بشكل أفضل.إذا لم تكن حصرية بشكل متبادل ، فنحن على استعداد لنشر EIPs متعددة المرتبطة AA في المستقبل.
إذا كان المجتمع في الشائعات[12]NSA[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]لم يتم تحديد شيء ، وما إذا كان Ethereum على استعداد لتقديم مثل هذا الحل.
ما يلي هو المنطق.
يدعم
الخلاصة ، نحن ندعم 1) الفجوة بين CL و EL ، 2) يمكن إجراء تعديل EVM كعمل شخص واحد ، ويمكن أن يكون في عزلة واختبار موازي.
EIP-7002[19]
فتح هذا eip تجمع إعادة تمجيده والتعهد عن طريق التحكم في جانب CL عن طريق التحكم في جانب CL من جانب CL.من وجهة نظرنا ، هذا هو eip لا يحتاج إلى التفكير فيه ، لأنه على الأقل سيمكن تجمع المعهد الحالي من إزالة طبقة واحدة من المركزية من العقد الذكي الذي يبرز انسحابه.
إن تقديم الدولة قبل التنفيذ في تنفيذ EVM هو تجريد جديد نحتاج إلى التقاطه في تنفيذ EVM ، ولكن بالإضافة إلى ذلك ، نعتقد أن هذا eip يمكن تنفيذه مباشرة.
EIP-6110[20]
يقدم هذا EIP الودائع في الدولة EL ، مما يؤدي إلى تبسيط إدارة الدولة اللازمة على CL.فيما يتعلق بالتنفيذ ، يشبه هذا تتبع انسحاب CL ، لذلك بشكل عام ، نعتقد أن هذا أيضًا EIP يسهل تحقيقه واستقلاله.
EIP-2537[واحد وعشرون]
يوجد الآن تطبيق BLS12-381 في الخارج.نعتقد أن التعقيد منخفض ، لأنه يكشف فقط عن خوارزمية التحقق من المنحنى من خلال واجهة ما قبل التجميع.ربما نريد أيضًا مجموعة من التجزئة إلى منحنى BLS12-381.
eof[إثنان وعشرون]تنسيق كائن Ethereum
TL ؛إنه شيء يجعل من السهل تحليل تنسيق الكود وتعديل التحقق.
فائدة:
يمكن اختبار تغييرات EVM فقط بواسطة Ethereum/الاختبارات وتنفيذها من قبل شخص واحد.
اجعل تغييرات EVM التي تريد Vyper و Slidity!
يساعد في الأداء وتحسين حجم العقد.
EVM يلغي احتياجات Bytecode أثناء التشغيل.
يمكن تحميله جزئيًا للمساعدة في تنفيذ العقود الكبيرة.
DeVex: سيتم السماح باستخدام DuPn/Swapn لإصلاح “Stack Deep” وأدوات أخرى في صلابة.
التحقق المستقبلي: يمكن أن يقدم بأمان ميزات جديدة لـ L2 ، وستتعرف الأدوات ما هو التوافق.
غير كافٍ:
تغيير الهدف.
لم يحاول أي مؤيدين الترويج لإضافته.
لا تزال بحاجة إلى دعم الرمز القديم
حتى التبني ، ستكون هناك اختلافات مؤقتة بين الشبكة الرئيسية Ethereum وسلاسل EVM الأخرى.
نعتقد أنه ينبغي نشر ميزات EOF التالية في عام 2024.نوصي بتحديد النطاق في أقرب وقت ممكن ونعد بمراقبة.أي شيء آخر يجب أن ينظر في النشر اللاحق.اقتراحاتنا:
EIP -3540: EOF -EVM Object Format v1[ثلاثة وعشرين]: تقديم الكود وحاويات البيانات ، وإضافة الهياكل والإصدارات إلى بايت Ethereum.
EIP -3670: التحقق من الرمز EOF[أربعة وعشرون]: رفض أي عقود لا تتبع تنسيق EOF أثناء النشر.رمز إلزامي وأكثر تنظيماً وتعطيل التعليمات غير الصالحة وغير المتوقعة.
EIP-663: تعليمات مبادلة غير محدودة و DUP[25]: هذا يحل المشكلة “المكدس عميقًا جدًا” في صلابة ، وقد يكون لها آثار جانبية من خلال تحليل القفز كقيمة مؤقتة.وتأمل لغة EVM أن يكون لها مثل هذه الوظيفة كثيرًا.
EIP -4200: قفزة نسبية eof -static[26]: تحليل ثابت أفضل ، لا يوجد قفزة غير مؤكدة.تجميع أفضل AOT.الاسترخاء إلى الرمز للرمز أفضل.
eip -4750: eof -function[27]: أنت بحاجة إلى التعامل مع روتين فرعي قد يكون لها قفزة ديناميكية ولكن ليس لديك قفزة ثابتة.كما يتيح تحميل بعض التعليمات البرمجية ، والتي يتم استخدامها بشكل جيد مع Verkle وتضيف قيود حجم العقد.
EIP -5450: التحقق من eof -stack[28]: تحقق من متطلبات الكود والمكدس.جميع الإرشادات باستثناء Callf (EIP-4750) قد حذفت فحص الفائض والفتح في الفائقة أثناء التشغيل.
EIP -7480: تعليمات الوصول إلى مقطع EOF -DATA[29]: السماح لقطاع البيانات من رمز البايت.
EIP-7069: تعليمات المكالمة المحسنة[30]: اجعل الغاز في المكالمات يختفي ، بحيث يتم إعادة سعر الغاز في المستقبل.على الرغم من أنه مستقل عن EOF ، فإننا نعتقد أن هذه فرصة جيدة لتقديمها.
نحن TIP-6206: وظائف eof-jumpf وغير إعادة إرجاع[31]إنه بالفعل منخفض.على الرغم من أنه يسمح بتحسين استدعاء الذيل في وظيفة EOF ، إلا أننا ما زلنا بحاجة إلى رؤية تحليل اللغة لفائدته.إذا لم يكن لدينا هذا ، فإننا نعتقد أنه يمكننا إزالته من النطاق وتضمين تحديثات EOF اللاحقة.
سيكون لدينا ميزانية العمل أعلاه لمدة 1-2 أشهر ، والتي يتم الانتهاء منها من قبل شخص واحد.إذا كان هذا يعني الحفاظ على الدافع ، فنحن على استعداد لزيادة الحد من النطاق المذكور أعلاه.
شرح البايتات التقليدية:
على الرغم من أننا يمكن أن نحظر الرموز التقليدية/غير المقيدة الجديدة ، إلا أنه لا يمكن أن يتخلى عن الرمز الباقري التقليدي الحالي.لا يزال رمز Bytecode التقليدي يحتاج إلى إجراء تحليل Jumpdest بعد EOF ، ولا يزال يحتاج إلى معالجة رمز خاصة لتجزئته في محاولات Verkle.
بقدر ما نعلم ، لا يوجد تحويل التحقق من رمز bytecode غير المقصود إلى EOF دون الوصول إلى قطع العمل المصدر ، لكننا على استعداد للتحقيق في آلية تعزيز هذا التحويل.
بدلاً من ذلك ، نحن على استعداد لاستكشاف طريقة انتهاء الصلاحية لترحيل الدولة إلى EOF.
قم بزيادة عدد Blob EIP-4844
نحن على استعداد لقبول هذا التغيير ، الذي سيكون على حقmax_blob_gas_per_blockوTarget_blob_gas_per_blockزيادة ، يرجى الرجوع إلى EIP-4844[32]ال
يتم اختيار Target_blob_gas_per_block و max_blob_gas_per_block كـ 3 blob (0.375 mb) لكل كتلة ، بحد أقصى 6 نقطة (0.75 ميجابايت).تم تصميم هذه القيود الأولية الأصغر لزيادة الضغط الناجم عن EIP إلى الشبكة ، ومن المتوقع أن تزيد من الترقية المستقبلية حتى يمكن للشبكة إظهار الموثوقية تحت كتل أكبر.*
في الواقع ، هذا تغيير رمز صغير.قد تواجه طبقة الإجماع صعوبات عند نشر المزيد من النقطة ؛
لا الدعم
يحاول فيركل[33]
TL ؛نوصي الفريق بتعيين الموارد في الربع الثاني من عام 2024 ووعد بالنشر في الربع الثاني من عام 2025 إلى الربع الثالث من أوساكا.
فائدة:
يتم تحقيق عميل الضوء أرخص من خلال دليل تخزين أصغر.
إدراك التنفيذ عديمة الجنسية من قبل الحالة السابقة للدولة في كتلة الكتلة ، والتي قد تكون أيضًا بسبب وصول الحالة الثابتة.
قم بزيادة حد حجم العقد عن طريق تحميل رمز bytecode وتمكين جزء من الرمز.
بسبب انخفاض تكلفة حالة “القيامة” ، تصبح الدولة أكثر جاذبية.
غير كافٍ:
عبء العمل الكبير: التأثير وتنفيذ التكامل واختبار التغييرات.
تغيير فواتير الغاز: قام Verkle بتقديم الشاهد إلى وظيفة حساب الغاز.نحن قلقون من عدم استكشاف التغييرات في أسعار التخزين (على سبيل المثال ، ما هي تكلفة كبار مستهلكي الغاز بعد Verkle)؟
تكامل التطبيق: عندما يكون انتقال التراكب قيد التشغيل ، ماذا يجب أن يفعل التطبيق مع جهاز التحقق من Merkle Patricia Trie؟eth_getproofكيف ينبغي أن يكون؟
على الرغم من أننا نفهم فوائد محاولات Verkle ، فإننا نعتقد أننا بحاجة إلى مزيد من التفكير لفهم كيف يجب أن تكون أدوات/عقود الحمل الثالثة للتكيف معها ، وتأثير الانتقال على مثل حل الطبقة الثانية.في البداية ، كنا متشككين في استراتيجية الترحيل لأنها تنص على أنه ينبغي تحديث Verkle Trie عند قراءة حالة MPT الحالية ، ولكن يبدو أن هذا ليس هو الحال الآن.لذلك ، نحن ندعم طريقة شجرة التراكب كمسار ترحيل ممكن.
يبدو أن وثيقة استراتيجية ترحيل Verkle عفا عليها الزمن بشكل عام ، لأن معظم الموارد لا تزال تشير إلى أنه يجب تحديث Verkle Trie عند قراءة الدولة من MPT ، على الرغم من أن الموقف ليس هو الحال.نأمل أن نرى تحديث مستند الانتقال الرئيسي إلى أحدث طريقة ، مثل هذا المستند الممتاز[34]جوهرنأمل أيضًا أن نرى مسودة استراتيجية الانتقال EIP.
لذلك ، ما زلنا ندعم إطلاق Verkle في عام 2025 ، لكننا لم نر مسار النشر في ترقية Prague.
L1 الحد من الغاز
نحن نعتقد أن رفع قيود غاز L1 من منظور الطلب لن يكون له تأثير كبير في الممارسة.نعتقد أيضًا أن معظم العملاء يمكنهم التعامل مع الزيادة في متوسط الحمل ، لكننا نأمل أن نكون متيقظين بشأن أسوأ موقف ، لذلك لا نوصي بزيادة حد غاز L1 في الوقت الحالي.نعتقد أن إضافة حد غاز النقطة على المدى القصير هو حل أكثر واعدة.
ندعو الجميع للتعاون معنا لإجراء أي بحث حول هذا الاتجاه وطريقة قياس الموارد حول EVM.ورقة عداد مكسورة[35]إنها نقطة انطلاق جيدة في هذا الاتجاه البحثي.
تجريد الحساب
نحن على استعداد لتضمين 1 أو أكثر من ERCs) ، لكننا نأمل أن نرى المزيد من تجربة المستخدم وتجربة التطوير بشكل أفضل لفهم أعمال تكامل الأدوات بشكل أفضل.نحن نولي اهتماما ل EIP/ERCS التالية ، ولكن يرجى اقتراح لنا في أي وقت:
EIP-3074: أدوات التصوير والتواطؤ[36]
ERC-4337: تجريد الحساب باستخدام Alt Mempool[37]
EIP-5806: معاملة تفويض[38]
EIP-5920: دفع الرمز[39]
EIP-6913: تعليمات setCode[40]
EIP-7377: معاملة الهجرة[41]
RIP -7560: تجريد الحساب الأصلي -eips -fellowship of Ethereum Magicians[42]
نريد أن نوضح أنه في المحتوى أعلاه ، يشير “تجريد الحساب” إلى “وظيفة التحقق التجريدية” ، والهدف الرئيسي هو تمكين الدوران الرئيسي ، وجعل التوقيعات المتعددة وظيفة الطبقة الأولى ، وتزويدنا بمسار مقاومة الكم التلقائي “(H” /T VB) ، مناسبة فقط لـ 4337 و 7560 ، في حين تنقسم المقترحات الأخرى إلى فئتين ، وهما رعاية الغاز ومعالجة الدُفعات العملية.
مؤلف:
>
جورجيوس كونستانتوبولوس[43]
Georgios Konstantopoulos هو كبير مسؤولي التكنولوجيا والشريك الأبحاث لـ Paradigm ، مع التركيز على بحث محفظة الاستثمار في Paradigm وبروتوكول المصدر المفتوح.في وقت سابق ، كان جورجيوس مستشارًا مستقلًا وباحثًا.
