تقترب ترقية Ethereum Cancun ، حيث تقوم بمراجعة الماضي والحاضر والمستقبل لترقية Cancun

المؤلف: فات بيرد فاينانس

حياة الماضي

لماذا يلزم ترقية كانكون؟

تتمثل رؤية Ethereum في أن تصبح أكثر قابلية للتطوير وأكثر أمانًا في ظل فرضية اللامركزية. تلتزم الترقية الحالية لـ Ethereum أيضًا بحل هذه المشكلة الثلاثية ، لكنها واجهت تحديات كبيرة.

مشاكل مع Ethereum:

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

لذلك ، في ظل فرضية اللامركزية ، فإن كيفية نقل المزيد من البيانات وتقليل الغاز لتعزيز قابلية التوسع ، وكيفية تحسين خوارزمية الإجماع لضمان الأمان هي جميع الجهود التي تبذلها Ethereum حاليًا.

من أجل حل ثلاثية الأمان واللامركزية وقابلية التوسع ، استخدمت Ethereum آلية PoW-to-PoS لزيادة تقليل عتبة العقدة ، وتخطط أيضًا لاستخدام سلسلة المنارات لتعيين محققين عشوائيًا لتحسين الأمان. من قابلية التوسع ، تنظر Ethereum في استخدام التجزئة لتقليل عبء العمل على العقد ، مما يمكّن Ethereum أيضًا من إنشاء كتل متعددة في نفس الوقت وتعزيز قابلية التوسع.

في الوقت الحالي ، تبلغ مساحة كل كتلة من Ethereum حوالي 200 ~ 300 كيلو بايت ، والحد الأدنى لحجم كل معاملة حوالي 100 بايت ، حوالي 2000 معاملة ، مقسومًا على وقت الكتلة البالغ 12 ثانية ، والحد الأعلى لـ TPS من Ethereum يقتصر على حوالي 100. من الواضح أن هذه البيانات لا يمكن أن تلبي احتياجات Ethereum.

لذلك ، يركز Ethereum Layer 2 على كيفية وضع كمية كبيرة من البيانات في blockspace ، وضمان الأمان من خلال إثباتات الاحتيال وإثباتات الصلاحية. وهذا هو السبب في أن طبقة DA تحدد الحد الأعلى للأمان ، وهو أيضًا المحتوى الأساسي لـ ترقية كانكون.

لا يمكن للمسار التكراري لبيئة Ethereum بناء أداء معيار Solana (من حيث التأخير والإنتاجية) ، ولن يتم رؤية أداء التجزئة لـ Near على المدى القصير ، ولا أداء التنفيذ الموازي لـ Sui و Aptos. على المدى القصير ، يمكن لـ Ethereum فقط بناء هيكل متعدد الطبقات مع Rollup باعتباره جوهرًا ، لذا فإن ترقية Cancun لحل TPS و gasfee وتجربة المطور أمر بالغ الأهمية لخريطة طريق Ethereum.

كيف يتم تخطيط خارطة طريق Ethereum؟

الترقيات المهمة الأخيرة وأهدافها

في 1 ديسمبر 2020 ، تم إطلاق سلسلة المنارات رسميًا ، مما يمهد الطريق لتحديثات نقاط البيع

ترقية لندن في 5 أغسطس 2021 ، غيرت EIP1559 النموذج الاقتصادي لإيثريوم ؛

في 15 سبتمبر 2022 ، أكملت ترقية باريس (TheMerge) تبديل POW إلى POS ؛

في 12 أبريل 2023 ، تمت ترقية شنغهاي لحل مشكلة سحب التعهدات ؛

تم الانتهاء من النموذج الاقتصادي والترقيات المتعلقة بنقاط البيع ، وحلت الترقيات القليلة التالية مشاكل أداء Ethereum و TPS وتجربة المطور ؛

تركز الخطوة التالية على TheSurge في خارطة طريق Ethereum.

الهدف: تحقيق 100،000+ TPS في Rollup.

يوجد حلان أساسيان ، على السلسلة وخارج السلسلة:

الحل خارج السلسلة: يشير إلى الطبقة 2 ، بما في ذلك التجميع ، إلخ.

مخطط على السلسلة: يشير إلى إجراء تغييرات مباشرة في L1 ، وهو مخطط تجزئة شائع.إن الفهم البسيط للتجزئة هو تقسيم جميع العقد إلى مناطق مختلفة وإكمال مهام كل منطقة ، مما يؤدي إلى زيادة السرعة بشكل فعال ؛

تحليل مخطط التجزئة:

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

Danksharding هو تصميم تجزئة جديد مقترح لـ Ethereum. تتمثل فكرته الأساسية في إنشاء كتلة مركزية + التحقق اللامركزي + مقاومة الرقابة. يرتبط هذا أيضًا بأخذ عينات توفر البيانات (DAS) ومنتجي الكتل المذكورة أدناه. - فصل الحزم (PBS) والرقابة القوائم المقاومة (Crlist) ذات الصلة. تتمثل الأهمية الأكبر لفكرة Danksharding الأساسية في تحويل Ethereum L1 إلى طبقة تسوية موحدة وتوافر البيانات (DataAvailability).

ينقسم مخطط التجزئة إلى خطوتين: في الوقت الحالي ، يتم تقسيمه إلى Proto-danksharding و Fully-Rollup.

Proto-danksharding ：

مقدمة: من خلال تقديم blobs لمساعدة L2 على خفض الرسوم وزيادة الإنتاجية ، فإنه يمهد أيضًا الطريق للتجزئة الكاملة كمخطط مسبق للتجزئة. من المتوقع أنه بعد التقاسم الضخم الأولي ، سيستغرق تنفيذ المشاركة الرطبة من 2 إلى 5 سنوات.

المحتوى: الميزة الرئيسية لـ proto-danksharding هي تقديم نوع جديد من معاملات blob. تتميز Blob بخصائص السعة الكبيرة والتكلفة المنخفضة. يمكن أن تسمح إضافة حزم البيانات هذه إلى Ethereum بتخزين جميع البيانات المجمعة في blob ، مما يقلل بشكل كبير من تخزين ضغط السلسلة الرئيسية ، ولكن أيضًا تقليل تكلفة التجميع.

تراكمي بالكامل

مقدمة: يعمل التراكم على توسيع السعة بشكل كامل ، مع التركيز على الاستفادة من توافر البيانات.

محتوى:

تصميم P2P لـ DAS: بعض الأعمال والأبحاث المتعلقة بمشكلة اتصال شبكة تجزئة البيانات ؛

عميل أخذ عينات توفر البيانات: تطوير عميل خفيف الوزن يمكنه تحديد ما إذا كانت البيانات متاحة بسرعة عن طريق أخذ عينات عشوائية من بضعة كيلوبايت ؛

الإصلاح الذاتي الفعال لـ DA: قادر على إعادة بناء جميع البيانات بكفاءة في ظل ظروف الشبكة الأسوأ (مثل هجوم المدقق الضار ، أو التوقف الطويل لعقد الكتلة الكبيرة).

اجتماع مطوري Ethereum الأساسية

تعتمد كل ترقية لـ Ethereum على اجتماع المطور الأساسي ، من خلال المناقشة المشتركة للمساهمين الأساسيين ، ووفقًا لسلسلة من المقترحات من المطورين ، يتم تحديد اتجاه التطوير المستقبلي

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

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

هناك نوعان من الاجتماعات ، وهما اجتماع طبقة الإجماع واجتماع الطبقة التنفيذية ، والتي تُعقد بالتناوب كل أسبوعين:

مؤتمر طبقة الإجماع (إجماع مطوري AllCore - ACDC) ، مع التركيز على طبقة الإجماع من Ethereum (إثبات الحصة ، سلسلة منارة ، إلخ) ؛

مؤتمر الطبقة التنفيذية (حل AllCore Developers - ACDE) ، والذي يركز على طبقة تنفيذ Ethereum (EVM ، جدول الغاز ، إلخ).

هناك ثلاثة أنواع من المشرفين الأساسيين على Ethereum ، وهي منظمات رسمية أو منتديات تطوعية تناقش المقترحات:

AllCoreDevs: مشرفو الكود ، المسؤولون عن عميل شبكة ETH1 ، ترقية ، صيانة كود Ethereum والبنية الأساسية ؛

قسم "إدارة المشروع": دعم مطوري Ethereum ، وتنسيق الهارد فورك ، ومراقبة EIP ، وما إلى ذلك ، ومساعدة AllCoreDevs بشكل مباشر في الاتصالات والعمليات ؛

EthereumMagicians: "منتدى" للرغبة في إجراء مناقشات حول EIP والمواضيع التقنية الأخرى.

الجدول الزمني للاجتماعات ذات الصلة بالتصعيد في كانكون

وفقًا لمحتوى المناقشة ، يمكن تقسيم ترقية كانكون تقريبًا إلى خمس مراحل.

المرحلة الأولى - تقديم موضوع الترقية

قدم مهامًا جديدة ، شاردينج أولي ، EOF ورموز عمليات "التدمير الذاتي" ، ناقش بإيجاز محتوى ترقية شنغهاي

بعد اكتمال دمج Ethereum في 15 سبتمبر 22 ، تم تعليق اجتماع المطورين لمدة 4 أسابيع ، مما سمح للمطورين بالتحقق من EIP الذي تمت مناقشته في الترقية اللاحقة لمدة شهر واحد ؛

في 28 ، 22 أكتوبر ، اقترح أول اجتماع للمطورين بعد الاندماج تنفيذ التقاسم الأولي ، و EOF وكود التشغيل "التدمير الذاتي" لأول مرة. في هذا الوقت ، لم يتم تحديد النطاق المحدد للتجزئة الأولية ، و يعتقد بعض المطورين في البداية أنه يمكن تقسيم ترقية شنغهاي إلى عدة ترقيات صغيرة ، مثل تمكين عمليات سحب ETH المتعهد بها أولاً ، ثم ترقية EIP4844 ، لكن بعض المطورين يعتقدون أنه من المفيد تنفيذ ترقية أكبر في خطوة واحدة.

المرحلة الثانية - تحديد الإطار الزمني والتحضير لحفل KZG

في نهاية عام 2022 ، سيركز مؤتمر Ethereum بشكل أساسي على EOF و EIP4844. وفي الوقت نفسه ، سنواصل الترويج لحفل الإعداد الموثوق مسبقًا المطلوب بواسطة EIP4844 - حفل KZG. سيحدد المطورون رسميًا الترقية 4844 تظهر في 23 يناير

في 22 نوفمبر ، تم ذكر EOF أو proto-danksharding في المكالمة الجماعية رقم 149 لجميع مطوري Ethereum الأساسيين في هذا الوقت ، لا يزال المطورون يفكرون في وضعها في ترقية Shanghai ؛

في اجتماع طبقة الإجماع بتاريخ 12/02/22 ، قام Trent Van Epps ، رئيس النظام البيئي Ethereum ، بإطلاع على التقدم المحرز في حفل الإعداد الموثوق به المطلوب لتنفيذ EIP4844 ، والذي يهدف إلى إنشاء جزء من التعليمات البرمجية الآمنة التي ستكون المستخدمة في EIP4844. تأمل VanEpps أن يكون الحفل واحدًا من أكبر الحفل على الإطلاق في مجال العملات المشفرة ، حيث سيجمع ما بين 8000 إلى 10000 مساهمة ، وستستمر فترة المساهمة العامة للحفل حوالي شهرين وستبدأ في وقت ما في شهر ديسمبر ؛

في اجتماع المطورين الأساسيين في نفس اليوم ، كان هناك بعض النقاش حول EOF وإلغاء تنشيط كود التشغيل الذاتي. اعترض مطور معين لمؤسسة Ethereum على تأجيل EOF إلى كانكون ، بحجة أنه إذا لم يتم تضمين تغييرات الكود في شنغهاي ، ستدخل إمكانية كانكون صغيرة جدًا. فيما يتعلق برمز التدمير الذاتي ، دعا بعض المطورين إلى تطوير EIP4758 في ذلك الوقت ، ولكن تعطيل رمز التشغيل هذا بشكل مباشر سيؤدي إلى تعطيل بعض التطبيقات. ويعتقد المطورون أنه قبل إنشاء حالة طرفية لحماية هذا النوع من العقود ، يجب وزن هذا EIP مرة أخرى لفترة من الوقت ؛

في اجتماع المطورين الأساسيين في 9 ، 22 ديسمبر ، تم الترويج لتنفيذ حفل KZG فيما يتعلق بترقية كانكون.

في اجتماع طبقة الإجماع بتاريخ 12/16/22 ، حول موضوع EIP4844 ، ناقش المطورون دمج طلبين مختلفين للسحب (PRs) في المواصفات الخاصة بـ proto-danksharding ، أحدهما يتعلق بكيفية تعامل العقد مع البيانات التي تم قصها من واحد. عندما تكون المعلومات حول blobs مفقودة في كتلة معينة ، سيتم تقديم رمز خطأ جديد لتنبيه العقد ؛

في اجتماع المطورين الأساسي في 5 ، 23 يناير ، توصل المطورون إلى توافق في الآراء بشأن إزالة تعديلات التعليمات البرمجية المتعلقة بتنفيذ EOF من ترقية شنغهاي.في هذا الوقت ، اقترحت Beiko تحديد ما إذا كان يجب تضمين EOF في العقبة بعد أسبوعين. يجري ترقية كون ؛

المرحلة 3 - مناقشة أولية لنطاق الاقتراح

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

في اجتماع المطورين الأساسيين في 20 ، 23 يناير ، تم نقل EOF إلى كانكون للترقية ؛

في اجتماع المطورين الأساسي في 6 و 23 مارس ، كانت المقترحات الأولية لترقية كانكون هي: EIP4788 (جذر حالة سلسلة المنارة العامة) ، EIP2537 (أداء العمليات بكفاءة مثل التحقق من توقيع BLS والتحقق من SNARKs) ، EIP-5920 (مقدمة جديدة) opcode PAY) ، وتنفيذ مشترك لـ EIP6189 (لجعل SELFDESTRUCT متوافقًا مع أشجار Verkle) و EIP-6190 (تغيير وظيفة SELFDESTRUCT لإحداث عدد محدود فقط من تغييرات الحالة) ؛

في اجتماع المطورين الأساسي في 16 و 23 مارس ، بالإضافة إلى EOF و EIP4844 ، تم النظر في المقترحات التالية لإدراجها في كانكون: تنسيق SSZ ، وحذف SELFDESTRUCT ، و EIP2537 ، و EVMMAX ، و EIP1153 ، وتعليمات SWAP و DUP غير المحدودة ، وإدخال PAY Beacon جذر الدولة في الكود و EVM ؛

في اجتماع المطورين الأساسي في 30 مارس 23 ، تم طرح اقتراح EIP-6780 بشأن تعطيل SELFDESTRUCT لأول مرة ، وهو أيضًا اقتراح لتعطيل SELFDESTRUCT الذي قررت كانكون أخيرًا استخدامه. ولكن فيما يتعلق بتنفيذ EOF ، صرح مطور من فريق عملاء Erigon (EL) أن EOF "تغير كثيرًا" ليتم دمجه مع اقتراح تحسين Ethereum EIP4844 في ترقية Cancun القادمة ، والتي تم اقتراح ترقيتها في Cancun تنفيذ EOF في الشوكة الصلبة بعد فترة وجيزة ؛

المرحلة الرابعة - تحديد الاتجاه الواضح لترقية الاقتراح وحذف المقترحات غير ذات الصلة

في 23 أبريل ، كان هناك اتجاه واضح للمقترحات التي ينبغي تغطيتها من خلال ترقية كانكون. وكانت العقدة الرئيسية هي اجتماع المطورين في 13 أبريل. اقترح هذا الاجتماع 9 خطط تنفيذية ، وكان لدى تيم نفسه أيضًا فهم أكثر تعمقًا لـ المقترحات البديلة. المناقشة ، في الاجتماع الذي عقد في 27 أبريل ، تم تحديد EIP6780 و EIP6475 و EIP1153 ليتم تضمينها في كانكون ، بينما تمت إزالة EOF و EVMMAX (مجموعات EIP المتعلقة بتنفيذ EOF) من ترقية كانكون ، يمكن أن تساعد ترقية EOF بشكل أساسي يمكن تشغيل التحكم في إصدار EVM ومجموعات متعددة من قواعد العقد في نفس الوقت ، مما يؤدي إلى التوسع اللاحق في Ethereum. ومع ذلك ، مع مراعاة جدوى الترقية بأكملها ، يمكن ترقية ترقية EOF مع ترقيات يومية في ما يلي- أعلى

في 12 أبريل ، 23 ، تم الانتهاء من ترقية Ethereum Shanghai ؛

بالإضافة إلى اجتماع التطوير الأساسي في 13.04.23 حيث ناقش المطورون EIP4844 (لفضح البيانات حول جذر حالة CL في EL) ، هناك ما لا يقل عن تسعة برامج EIP أخرى قيد النظر للترقية ، وهي EIP4844 ، إزالة SELFDESTRUCT ( EIP-6780 و EIP4758 و EIP6046 و EIP6190) و EIP5920 و EIP1153 و EIP2537 و EIP4788 و EVMMAXEIPs (EIP6601 و EIP6690) و SSZchanges (EIP6475 و EIP6493 و EIP 6465 و EIP6656 و EIP646346)

في اجتماع المطورين الأساسيين في 27 ، 23 أبريل ، تم التركيز على العديد من التقدم والمفاضلات. أولاً ، يستمر تحديد EIP4844 لتضمينه في ترقية Cancun ، بينما تمت إضافة EIPs التالية: EIP6780 (يغير وظيفة رمز التشغيل SELFDESTRUCT) ، EIP6475 (نوع تسلسل بسيط جديد (SSZ) لتمثيل القيم الاختيارية) ، EIP1153 ( يضيف جديدًا ثانيًا ، EIPs التي يتم النظر فيها ولكن لم يتم تضمينها رسميًا في الترقية هي EIP6913 (تقديم تعليمات SETCODE) ، EIP6493 (تحديد مخطط التوقيع للمعاملات المشفرة بـ SSZ) ، EIP4788 (الكشف عن جذر سلسلة المنارة في كتلة EL header) ، EIP2537 (يضيف منحنى BLS12-381 كمجمع مسبق) و EIP5656 (يقدم تعليمات EVM جديدة لنسخ مناطق الذاكرة) ؛ أخيرًا ، تمت إزالة EOF و EVMMAX (مجموعة فرعية من EIP المتعلقة بتنفيذ EOF) من ترقية كانكون. تمت إزالة ترقية EOF من ترقية شنغهاي في مؤتمر مطوري Ethereum في أوائل يناير 2023 ، وتم إخفاقها في الظهور في ترقية كانكون من نهاية يناير 2023 إلى بداية أبريل 2023 ، ولكن تم التطوير في 29 أبريل ، 23 تتم إزالة EOF مرة أخرى أثناء اجتماع المؤلفين.

المرحلة الخامسة - تحديد الاقتراح النهائي وتحسين التفاصيل

في 23 مايو ، تم تبسيط وتحسين تفاصيل الاقتراح النهائي بشكل أساسي.يعني تغيير SSZ-> RLP أنه لن تكون هناك حاجة إلى اثنين من SSZEIPs في كانكون ، لذلك سيتم نقل EIPs6475 و 6493 من كانكون للترقية. أيضًا في المؤتمر الحزبي يوم 26 ، اقترح تيم بيكو أن تقتصر المحادثات المستقبلية حول توسيع نطاق كانكون على خمسة برامج EIP التالية: EIP-5920 و 5656 و 7069 و 4788 و 2530. لقد حدد المطورون الآن النطاق الكامل لترقية كانكون.

ناقش اجتماع توافق Ethereum الأساسي في 5 و 23 مايو EIP4788 ، والذي تم ذكره في المرة السابقة ، وأضاف مناقشات حول EIP6987 و EIP6475 ، والتي تتعلق بالمصدقين ومعاملات SSZ على التوالي ؛

في اجتماع الطبقة التنفيذية رقم 161 من Ethereum في 11 ، 23 مايو ، قال TimBeiko إنه لا يزال من الممكن تعديل نطاق ترقية كانكون في الأسابيع القليلة المقبلة ، ولكن إذا لم يكن هناك اقتراح واضح من المطور ، فإن نطاق ترقية كانكون سوف احتفظ بالحالة "الافتراضية" ، وتوضح المناقشة حول EIP-4844 أن المطورين يوافقون على إزالة SSZ من تطبيق EL لـ EIP-4844 ، لكنه لم يؤثر على التقدم المستمر لـ 6475. بالإضافة إلى ذلك ، ناقش المطورون أيضًا بإيجاز اثنين من EIPs للنظر فيها في كانكون ، وهما EIP6969 (نسخة معدلة من EIP1559) و EIP5656 (تعليمات EVM فعالة لنسخ مناطق الذاكرة) ؛

تمت مناقشة تطوير 4844 بإيجاز في اجتماع توافق المطورين بتاريخ 18.05.23 ، مثل السماح لتطبيقات العقود الذكية على EL للتحقق من إثبات حالة CL ؛

تمت مناقشة إلغاء تنشيط SELFDESTRUCT ، وتغييرات مواصفات EIP-4844 ، وإدارة كود التشغيل ، وإضافات كانكون المحتملة في الاجتماع 162 Ethereum Core في 25 مايو 2023. اقترح Tim Beiko أن تقتصر المحادثات المستقبلية حول توسيع نطاق كانكون على خمسة برامج EIP التالية: EIP-5920 و 5656 و 7069 و 4788 و 2530. سيحدد المطور النطاق الكامل لـ Dencun (Deneb + Cancun) في الأسابيع القليلة القادمة ؛

في الاجتماع رقم 110 لإجماع الإيثريوم في 1 يونيو 2023 ، قدم باحث من مؤسسة Ethereum نتائج تجربة بيانات حول قدرة عقد Ethereum mainnet على نشر كميات كبيرة من البيانات.من هذه النتيجة ، اقترح الباحث أن EIP4844 تمت زيادة المواصفات من 4 نقاط كحد أقصى إلى 6 نقاط لكل كتلة. في الوقت نفسه ، يفكر المطورون في دمج EIP4788 في ترقية كانكون ؛

في اجتماع المطورين الأساسي في 13 يونيو 2023 ، أكد المطورون رسميًا نطاق الترقية ، بما في ذلك EIP4844 و EIP1153 و EIP5656 و EIP6780 و EIP4788 ؛

في الاجتماع الإجماعي في 15 يونيو 2023 ، تمت مناقشة أي خطط EIP مركزة على CL لتضمينها في Deneb ، ومن بينها EIP-6988 و EIP-7044 و EIP-7045 التي تم اقتراح إضافتها ، واتفق فريق CL العميل على الاختبار التالي للعدد المتزايد من النقاط على شبكة اختبار EIP-4844 Devnet6 ، واتخاذ قرار نهائي بشأن هذه المسألة في غضون أسبوعين. وفي الوقت نفسه ، اقترح مايكل نودر ، الباحث في مؤسسة Ethereum ، إلغاء 32 ETH حد التعهد للمساعدة في تقليل نمو مجموعة المدقق النشطة ؛

في الاجتماع الذي عقد في 22 يونيو 2023 ، اقترح تيم نقل العنوان المترجم مسبقًا 4844 إلى 0xA ، وتعبئتها ونقل BLS إلى عنوان آخر ، على الرغم من تقديم هذا المترجم مسبقًا من خلال EIP2537 ، فلن يتم النظر فيه في خطة كانكون ؛

في اجتماع الإجماع في 29 يونيو 2023 ، واصل المطورون مناقشة عدد النقاط ، ورفعوا حد النقطة المستهدفة من 2 إلى 3 ، ورفعوا حد النقطة الأقصى من 4 إلى 6. وفي الوقت نفسه ، 4844 testnet Devnet # 7 سيتم إطلاقه قريبًا.

هذه الحياة

المحتوى الأساسي هو EIP4844 ، Proto-Danksharding

نطاقات EIP النهائية لترقية كانكون هي: EIP4844 و EIP1153 و EIP5656 و EIP6780 و EIP4788. في الوقت نفسه ، في الاجتماع 111 لشركة Ethereum ACDC في 19 يونيو ، واصل المطورون مناقشة EIP6988 و EIP7044 و EIP7045 لإدراجها في Deneb. قال المطورون إنهم يخططون لدمج EIPs الثلاثة المذكورة أعلاه في مواصفات Deneb في الأسابيع المقبلة.

تحليل EIPs الرئيسية

EIP4844

مقدمة:

اسم اقتراح EIP4844 هو Proto-Danksharding ، وهو حل ما قبل التجزئة للنسخة الكاملة من Danksharding. تدور المجموعة الكاملة من مخططات التجزئة في الواقع حول Rollup للتوسع على السلسلة. الغرض من الحل هو توسيع طبقة 2 Rollup - من خلال مساعدة L2 على خفض الرسوم وزيادة الإنتاجية ، مع تمهيد الطريق للتجزئة الكاملة.

في المكالمة الجماعية في 23 فبراير ، قام مطورو Ethereum بترقية EIP4844 وأطلقوا عليها اسم Deneb ، وهو اسم نجمة من الدرجة الأولى في Cygnus. أي ، سيتم تحديث اسم EIP4844 على إصدار GitHub ذي الصلة إلى Deneb في المستقبل ؛ في الاجتماع الذي عقد في 1 مارس ، كانت هناك بعض التغييرات في مواصفات الترقية التالية لـ Ethereum ، والتي تسمى Deneb على جانب CL وكانكون على جانب EL ؛

في اجتماع المطورين في 23 يونيو ، 23 ، كان المطورون سيقومون بتحديث عنوان EIP4844 المترجم مسبقًا. حاليًا ، أضاف المطورون الأساسيون 9 مجموعات مسبقة إلى EVM ، وسيقومون بإنشاء اثنين من التجميعات المسبقة تحت عناوين "0xA" و "0xB" عن طريق تنشيط EIP4844 و 4788 على التوالي. في اجتماع الإجماع في 29 يونيو ، تم إعداد Devnet # 7 ، وهي شبكة اختبار مخصصة قصيرة المدى لـ EIP4844.

يقدم EIP-4844 نوع معاملة جديد تمامًا - BlobTranscation.

مقدمة عن النقط:

Blob ، على غرار حزمة بيانات المكون الإضافي ، يحتوي على مساحة تخزين تبلغ 128 كيلوبايت فقط في البداية. في بداية مناقشة الاقتراح ، كان الهدف والحد الأقصى لـ Blob 2/4. في اجتماع المطورين في 9 حزيران (يونيو) ، 23 ، تم تعديله إلى 3/6. أي ، في الوقت الحالي ، يمكن لكل معاملة في Ethereum أن تحمل ما يصل إلى ثلاث معاملات Blob ، أي 384 كيلوبايت ، وسعة targetBlob لكل كتلة هي 6 ، أي 768 كيلوبايت ، ويمكن أن تحمل 16 معاملة Blob بحد أقصى ، أي 2 ميغابايت ؛

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

يستخدم Blob KZGcommit Hash كتجزئة للتحقق من البيانات ، على غرار Merkle ؛

بعد أن تقوم العقدة بمزامنة BlobTransaction على السلسلة ، ستنتهي صلاحية جزء Blob ويتم حذفه بعد فترة زمنية ، ويكون وقت التخزين ثلاثة أسابيع.

دور Blob - تحسين TPS في Ethereum مع تقليل التكاليف

في الوقت الحالي ، يبلغ إجمالي حجم البيانات لـ Ethereum بالكامل حوالي 1 تيرابايت فقط ، ويمكن لـ Blob جلب 2.5-5 تيرابايت من حجم البيانات الإضافي إلى Ethereum كل عام ، والذي يتجاوز مباشرة دفتر الأستاذ نفسه بعدة مرات ؛

بالنسبة للعقد ، لن يؤدي تنزيل بيانات blob من 1 ميجابايت إلى 2 ميجابايت لكل كتلة إلى عبء عرض النطاق الترددي ، وستزيد مساحة التخزين فقط من الكمية الثابتة لبيانات blob التي تبلغ حوالي 200 ~ 400 جيجابايت شهريًا ، وهو ما لن يؤثر على لامركزية الكل عقدة Ethereum ، ولكن تم تحسين التوسع حول Rollup بشكل كبير ؛

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

دور EIP-4844 - فتح الفصل الأول من سرد Danksharding

توسع كبير: في الوقت الحالي ، يمكن لـ EIP-4844 توسيع سعة L2 مبدئيًا.يمكن للنسخة الكاملة من Danksharding توسيع حجم بيانات Blob في EIP-4844 من 1 ميجابايت إلى 2 ميجابايت إلى 16 ميجابايت إلى 32 ميجابايت.

رسوم منخفضة: وفقًا لمحللي bernstein ، يمكن لـ Proto-dank-sharding أن تقلل رسوم شبكة الطبقة 2 إلى 10-100 ضعف المستوى الحالي ؛

البيانات الفعلية:

نشرت شبكة اختبار Opside 4844 ، ويمكن أن تقلل الملاحظة الحالية من تكلفة التجميع بنسبة 50 ٪ ؛

لا يكشف الحل التقني DA الخاص بـ EigenLayer عن الكثير لتقييم بياناته ؛

بالمعنى الدقيق للكلمة ، ليس لدى Celestia علاقة تذكر بـ Ethereum ، ولا يمكن تقييم تكلفة DA الخاصة بها الآن ، اعتمادًا على حلولها التقنية المحددة ؛

يتمثل حل Ethstorage في تحميل شهادة تخزين Layer2 الخاصة بها ، وقد يتم تخفيض تكلفة DA الخاصة بها إلى 5٪ من الأصل ؛

تتوقع Topia خفض التكاليف بنسبة 100 إلى 1000 مرة ، لأن الشبكة الرئيسية Danksharding تحتاج أيضًا إلى مراعاة الأمان والتوافق مع بث شبكة الطبقة 1 P2P.

حل DA: قد يتسبب Danksharding (حل تجزئة لتوسيع Ethereum) حاليًا في حدوث مشكلات مثل عبء العقدة المفرط (فوق 16 ميجابايت) وعدم توفر البيانات غير الكافي (فترة الصلاحية لمدة 30 يومًا). حل:

أخذ عينات توفر البيانات - يقلل من عبء العقدة

قم بقص البيانات الموجودة في Blob إلى أجزاء بيانات ، واترك العقد تتغير من تنزيل بيانات Blob إلى التحقق العشوائي من أجزاء بيانات Blob ، بحيث تنتشر أجزاء بيانات Blob في كل عقدة من Ethereum ، ولكن يتم تخزين بيانات Blob الكاملة في دفتر الأستاذ Ethereum In Fang بأكمله ، فإن الفرضية هي أن العقد يجب أن تكون كافية ولا مركزية ؛

يستخدم DAS تقنيتين: تشفير المحو (ErasureCoding) والالتزام متعدد الحدود KZG (KZGCommitment) ؛

فصل Proposer-Bundler (PBS) - يحل مشكلة تقسيم عمل العقدة ، مما يسمح للعقد ذات التكوين عالي الأداء بتنزيل جميع البيانات للتشفير والتوزيع ، والسماح للعقد ذات التكوين المنخفض الأداء أن تكون مسؤولة عن التحقق من الفحص الفوري.

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

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

قائمة مكافحة الرقابة (crList) - تحل المشكلة المتمثلة في أن الحزم يمكن أن يتجاهل عمدًا معاملات معينة ويدخل المعاملات التي يريدونها للحصول على MEV بسبب قدرتهم المفرطة على المراجعة.

قبل أن يقوم المنشئ (Builder) بحظر المعاملات ، سينشر مقدم العرض (Proposer) أولاً قائمة مقاومة للمراجعة (crList) ، والتي تحتوي على جميع المعاملات في mempool ؛

يمكن للمُنشئ (Builder) فقط اختيار حزم المعاملات وفرزها في crList ، مما يعني أنه لا يمكن للمُنشئ إدخال معاملته الخاصة للحصول على MEV ، ولا يمكنه رفض معاملة عمدًا (ما لم يكن Gaslimit ممتلئًا) ؛

بعد التعبئة ، يبث المنشئ الإصدار النهائي من قائمة المعاملات Hash إلى مقدم العرض ، ويختار مقدم العرض إحدى قوائم المعاملات لإنشاء رأس كتلة (BlockHeader) وبثها ؛

عندما تزامن العقدة البيانات ، ستحصل على رأس الكتلة من مقدم الاقتراح (مقدم الاقتراح) ، ثم تحصل على جسم الكتلة من أداة التجميع (Builder) ، للتأكد من أن جسم الكتلة هو الإصدار النهائي المحدد.

PBS مزدوج الفتحة - يحل مشكلة الحزم المركزية التي أصبحت أكثر مركزية من خلال الحصول على MEV

استخدم وضع التسعير لتحديد الكتلة:

ينشئ المنشئ (Builder) رأس الكتلة لقائمة المعاملات بعد الحصول على crList والعطاءات ؛

يختار مقدم العرض (مقدم العرض) رأس الكتلة والمُنشئ (المنشئ) الذي قدم عرضًا أخيرًا بنجاح ، ويتلقى مقدم العرض دون قيد أو شرط رسوم العطاء الفائز (بغض النظر عما إذا تم إنشاء كتلة صالحة) ؛

تؤكد لجنة التحقق (اللجان) رأس الكتلة الفائزة ؛

يكشف المنشئ عن جسم الكتلة الفائزة ؛

تؤكد لجنة التحقق (اللجان) جسم الكتلة الفائزة وتجري تصويتًا للتحقق (إذا تم تمرير الكتلة ، يتم إنتاج الكتلة ، وإذا لم يقم المعبئ عن عمد بإعطاء كتلة الكتلة ، فيُعتبر أن الكتلة لا يخرج).

دلالة:

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

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

هذا له آثار على بعض حلول MEV التي تستخدم مزادات MEV.

دلالة:

EIP4844 هو في الواقع نسخة مبسطة للغاية من Danksharding: فهو يوفر نفس واجهة التطبيق مثل Danksharding ، بما في ذلك كود تشغيل جديد يسمى DataHash ؛ وكائن بيانات جديد يسمى BinaryLarge Objects ، وهو Blob ؛

يُعد proto-danksharding اقتراحًا "قوسًا" (أي تنسيق المعاملة وقواعد التحقق) لتنفيذ مواصفات Danksharding الكاملة: ومع ذلك ، لم يتم تنفيذ أي تجزئة حتى الآن ، ولا يزال يتعين على جميع المدققين والمستخدمين التحقق مباشرة من توفر البيانات الكاملة ؛

لماذا تختار proto-danksharding بدلاً من EIP4488 لتخفيض رسوم layer2 مباشرة على المدى الطويل ، لأنه لا يلزم سوى تعديل بسيط عند الترقية إلى جزء كامل في المستقبل:

يتمثل الاختلاف العملي الرئيسي بين EIP4488 و proto-danksharding في أن EIP-4488 يحاول تقليل التغييرات التي يحتاجها Ethereum اليوم ، بينما يقوم proto-danksharding بإجراء المزيد من التغييرات على Ethereum اليوم من أجل الترقية إلى Ethereum في المستقبل. مطلوب لتقسيم النسخة الكاملة ؛

على الرغم من أن تنفيذ التجزئة الكاملة (مع أخذ عينات توفر البيانات ، وما إلى ذلك) يعد مهمة معقدة ، ولا يزال هناك عمل معقد يتعين القيام به بعد تنفيذ التقسيم الأولي ، سيتم التحكم في هذه التعقيدات في طبقة الإجماع. بمجرد نشر proto-danksharding ، لن يحتاج فريق العميل من الطبقة التنفيذية ، ومطورو التحديثات ، والمستخدمون إلى القيام بأي عمل إضافي عند الانتقال إلى التجزئة الكاملة.

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

بعد إزالة SELFDESTRUCT ، تم تحديد EIP-6780 أخيرًا ليكون الحل الأنسب ، ولكن في اجتماع المطورين في السادس والعشرين ، اقترح Tim إضافة رمز تشغيل آخر SETCODE إلى هذا الاقتراح للسماح بالحسابات الآلية ليتم تحديثها.

إزالة النفس EIP-6780 ： X

خلفية:

في 21 مارس ، اقترح فيتاليك أن ضرر SELFDESTRUCT أكثر من نفعه لبيئة Ethereum. والسبب الرئيسي هو أنه الوحيد الذي يمكنه تغيير عدد لا حصر له من كائنات الحالة في كتلة واحدة ، مما يؤدي إلى تغييرات رمز العقد ، ويمكن يتم تعديلها دون موافقة الحساب. كود التشغيل الخاص برصيد الحساب لديه خطر خفي كبير على أمان Ethereum ؛

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

في اجتماع المطورين الأساسي في 13 و 23 أبريل ، تم تقديم أربعة مقترحات حول SELFDESTRUCT للمشاركة في المناقشة ، وهي 6780 و 4758 و 6046 و 6190 ، وتم تحديد EIP6780 للمتابعة باعتباره الاقتراح النهائي.

مقدمة: التدمير الذاتي هو زر الطوارئ للعقد الذكي ، والذي يؤدي إلى إتلاف العقد ونقل ETH المتبقي إلى الحساب المخصص.

EIP6780: تعطيل SELFDESTRUCT ما لم تكن في نفس المعاملة في العقد.

تحديث: في 26 مايو ، اقترح تيم إضافة رمز تشغيل آخر - SETCODE ، بالإضافة إلى إزالة SELFDESTRUCT ، للسماح بتحديث الحسابات الآلية. (أي ، يتم إضافة وظيفة التحديث ، ويتم تحديث الخاصية في العقد الذكي عن طريق التحديث / الترقية). هنا ، يتم استيعاب مزايا EIP4758 ، مما يسمح لـ dapp بالحصول على مساحة للترقية.

! [ترقية Ethereum Cancun تقترب ، راجع ترقية كانكون في الماضي والحاضر والمستقبل] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-2097d6bce8-dd1a6f-1c6801)

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

تم التغيير: يقوم برنامج EIP هذا بتنفيذ تغيير يزيل SELFDESTRUCT ، مع الاستثناءين التاليين

ستظل التطبيقات التي تُستخدم فقط لسحب الأموال من SELFDESTRUCT تعمل ؛

لا يلزم تغيير SELFDESTRUCT المستخدم في نفس المعاملة في العقد أيضًا.

الأهمية: تحسين السلامة

في السابق ، كان هناك عقد على الشبكة الرئيسية يستخدم SELFDESTRUCT لتقييد من يمكنه بدء المعاملات من خلال العقد ؛

لمنع المستخدمين من الاستمرار في إيداع الأموال والتداول في الخزنة بعد SELFDESTRUCT ، قد يتسبب هذا الخزانة في قيام أي شخص بسرقة الرموز المميزة في الخزنة أثناء الاستخدام المتكرر.

المقترحات الثلاثة أدناه هي مقترحات متعلقة بـ SELFDESTRUCT والتي تم حذفها لاحقًا. تم اختيار 6780 رسميًا في اجتماع المطور الأساسي في 28 أبريل 23 ، وتم التخلي عن الاقتراحات الثلاثة المتبقية لأن فريق تطوير Ethereum أراد في النهاية حذف رمز التشغيل SELFDESTRUCT بالكامل ، ويتم تعديل المقترحات الثلاثة التالية عن طريق الاستبدال.

EIP-4758 (تم الإلغاء): قم بتعطيل SELFDESTRUCT عن طريق تغيير SELFDESTRUCT إلى SENDALL ، والذي يعيد جميع الأموال إلى المتصل (يرسل كل الأثير الموجود في الحساب إلى المتصل) ، لكنه لا يحذف أي رمز أو مساحة تخزين.

السبب: كما هو مذكور أعلاه ، تطلبت معالجة أكواد SELFDESTRUCT سابقًا تغييرات واسعة في حالة الحساب ، مثل حذف جميع الرموز والتخزين. هذا يخلق صعوبات في استخدام أشجار Verkle في المستقبل: سيتم تخزين كل حساب في العديد من مفاتيح الحساب المختلفة التي لن تكون مرتبطة بشكل صريح بحساب الجذر.

يتغير:

تمت إعادة تسمية رمز التشغيل SELFDESTRUCT إلى SENDALL ، والآن يقوم فقط بنقل جميع ETH في الحساب إلى المتصل ، ولم يعد النظام يكسر الكود والتخزين ، أو يغير nonces ؛

تم حذف جميع عمليات رد الأموال ذات الصلة SELFDESTRUCT

دلالة:

يتم الاحتفاظ بالوظيفة الأصلية مقارنةً بـ EIP-6780 ، لأن بعض التطبيقات لا تزال / تحتاج إلى استخدام رمز SELFDESTRUCT.

EIP-6046 (مهمل): استبدل SELFDESTRUCT بـ DEACTIVATE. غيّر SELFDESTRUCT لعدم حذف مفتاح التخزين واستخدم قيمة خاصة في حساب nonce للإشارة إلى التعطيل

السبب: كما هو مذكور أعلاه ، مع أشجار Verkle ، سيتم تنظيم الحسابات بشكل مختلف: سيكون لخصائص الحساب (بما في ذلك التخزين) مفاتيح منفصلة ، ولكن سيكون من المستحيل اجتياز جميع المفاتيح المستخدمة والعثور عليها. ومع ذلك ، تتطلب معالجة أكواد SELFDESTRUCT عددًا كبيرًا من التغييرات في حالة الحساب ، مما جعل من الصعب جدًا الاستمرار في استخدام SELFDESTRUCT في أشجار Verkle.

يتغير:

قم بتغيير القواعد التي قدمها EIP-2681 بحيث يتم تقييد الزيادات غير المتكررة العادية بـ 2 ^ 64-2 بدلاً من 2 ^ 64-1 ؛

تم تغيير SELFDESTRUCT إلى:

لا تحذف أي مفاتيح تخزين وتترك الحساب في مكانه ؛

قم بتحويل رصيد الحساب إلى الهدف ، واضبط رصيد الحساب على 0.

اضبط الحساب nonce على 2 ^ 64-1.

لا توجد مبالغ مستردة منذ EIP-3529 ؛

تظل القاعدة ذات الصلة SELFDESTRUCT لـ EIP-2929 دون تغيير.

دلالة:

يتمتع هذا الاقتراح بمرونة أكثر من السلوكيات الأخرى التي تحذف SELFDESTRUCT مباشرة.

EIP-6190 (مهمل): تغيير SELFDESTRUCT ، متوافق مع Verkle ، بحيث يتسبب فقط في عدد محدود من تغييرات الحالة

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

التغيير: بدلاً من إتلاف العقد في نهاية المعاملة ، يحدث ما يلي في نهاية المعاملة التي يطلق عليها:

يتم تعيين رمز العقد على 0x1 ، ويتم تعيين الرقم العشوائي على 2 ^ 64-1.

يتم تعيين الفتحة 0 من العقد على العنوان الذي سيتم نشره عندما يستخدم العقد رمز التشغيل CREATE (keccak256 (contractAddress، nonce)). الرقم العشوائي دائمًا هو 2 ^ 64-1.

إذا تم إتلاف العقد ذاتيًا بعد إعادة توجيه الاستدعاء من خلال عقد اسم مستعار واحد أو أكثر ، فقم بتعيين فتحة التخزين 0 لعقد الاسم المستعار على العنوان المحسوب في الخطوة 2 ؛

سيتم تحويل رصيد العقد إلى العنوان الموجود أعلى المكدس ؛

ظهر الجزء العلوي من المكدس.

دلالة:

مصمم للسماح لـ SELFDESTRUCT بتشكيل أشجار Verkle لاحقًا مع الحد الأدنى من التغييرات ؛

زادت تكلفة الغاز مع تطبيق EIP-2929.

ثم هناك EIP1153 ، الذي يوفر الغاز ويمهد الطريق لتصميم التخزين في المستقبل

EIP1153X

ملخص: أكواد تشغيل المتجر العابر ، أضف أكواد التشغيل لمعالجة الحالة التي تتصرف مثل المتاجر ولكنها تتجاهل بعد كل معاملة.

سبب:

يمكن أن يؤدي تشغيل معاملة في Ethereum إلى إنشاء عدة إطارات تنفيذ متداخلة ، كل إطار تم إنشاؤه بواسطة تعليمات CALL (أو ما شابه ذلك). يمكن إعادة إدخال العقود في نفس المعاملة ، وفي هذه الحالة ينتمي أكثر من إطار واحد إلى عقد واحد.

حاليًا ، يمكن لهذه الأطر التواصل بطريقتين: الإدخال / الإخراج عبر تعليمات CALL وعبر تحديثات المتجر. يعتبر الاتصال عبر I / O غير آمن إذا كان هناك إطار عمل وسيط ينتمي إلى عقد آخر غير موثوق به.

بأخذ reentrancylock كمثال ، لا يمكن الاعتماد على الإطارات الوسيطة لنقل حالة القفل: SSTORE Communication SLOAD من خلال التخزين باهظة الثمن ، والتخزين المؤقت هو حل مخصص وفعال للغاز لمشكلة الاتصال بين الإطارات.

تم التغيير: تمت إضافة رمزين تشغيل جديدين إلى EVM و TLOAD (0xb3) و TSTORE (0xb4).

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

حالات الاستخدام المحتملة:

reentrancylock ；

عناوين CREATE2 القابلة للحساب على السلسلة: تتم قراءة معلمات المُنشئ من عقد المصنع ، بدلاً من تمريرها كجزء من تجزئة كود التهيئة ؛

موافقة EIP-20 على المعاملة الواحدة ، على سبيل المثال #tporaryApprove (addressspender، uint256 amount) ؛

عقد رسوم التحويل: ادفع رسومًا لعقد الرمز المميز لفتح التحويلات أثناء المعاملات ؛

وضع "حتى": يسمح للمستخدم بإجراء جميع العمليات كجزء من رد الاتصال ، والتحقق مما إذا كانت "حتى" متوازنة في النهاية ؛

البيانات الوصفية لاستدعاء الوكيل: قم بتمرير بيانات وصفية إضافية لتنفيذ العقود دون استخدام بيانات الاتصال ، مثل قيم معلمات مُنشئ الوكيل الثابت.

دلالة:

وفر الغاز واتبع قواعد أبسط لفواتير الغاز ؛

حل مشكلة الاتصال بين الإطارات ؛

لا يغير دلالات العمليات الحالية ؛

لا حاجة لمسح فتحة التخزين بعد الاستخدام ؛

لا تحتاج تصميمات التخزين المستقبلية (مثل أشجار Verkle) إلى النظر في مسألة عمليات رد المبالغ المدفوعة للتخزين الفوري.

ثم هناك 4788 ، والتي يمكن أن تقلل افتراض الثقة لمجمع التعهدات

EIP4788 ： X

موجز: منارة تحجب الجذور في EVM.

تحديث: في اجتماع المطورين بتاريخ 15.06.23 ، اقترح المطورون إجراء تغييرات في التعليمات البرمجية لتحسين تجربة المُصنِّف ، وسوف يكشف برنامج EIP هذا عن جذر كتلة سلسلة المنارة ، التي تحتوي على معلومات حالة سلسلة EVM الداخلية ، لثقة مطوري DApp- الوصول المصغر.

تم التغيير: إرسال جذور التجزئة لكل كتلة سلسلة إشارات في رأس حمولة التنفيذ المقابل ، وتخزين هذه الجذور في عقد في حالة التنفيذ ، وإضافة كود تشغيل جديد لقراءة هذا العقد.

الأهمية: هذا اقتراح لتعديل الكود ، والذي يقترح تعديل جهاز Ethereum Virtual Machine (EVM) بحيث يمكنه الكشف عن بيانات جذر حالة طبقة العقد (CL) في طبقة التنفيذ (EL) ، والتي يمكنها عمل بروتوكولات مختلفة و التطبيقات في شبكة Ethereum ، يعتبر الاتصال بين البرامج أكثر كفاءة وأمانًا. اسمح بمزيد من التصاميم غير الموثوقة لتركيب تجمعات التجمعات والجسور وإعادة وضع البروتوكولات.

أخيرًا ، هناك 5656 ، الذي يوفر شفرة تشغيل جديدة فعالة لنسخ الذاكرة ، ولكنه حاليًا في حالة تضمينه مؤقتًا في الترقية بسبب عرض النطاق الترددي للاختبار.

EIP5656X

مقدمة: MCOPY- تعليمات نسخ الذاكرة.

تحديث: في 09.06.23 ، ذكر فريق التطوير أنه تم تقسيمهم في البداية على MCOPY لأنه أثناء حل المشكلة الأمنية ، كانوا قلقين بشأن النطاق الترددي للتنفيذ والاختبار اللازم لإضافته إلى الترقية ، لكنهم وافقوا أخيرًا على تضمين EIP ومع ذلك ، إذا واجه المطور مشكلات في السعة أثناء الاختبار أو من جانب العميل ، فسيتم النظر في إزالته. على هذا النحو ، MCOPY في حالة تضمين مؤقتًا في ترقية كانكون.

تم التغيير: توفير تعليمات EVM فعالة لنسخ مناطق الذاكرة.

الأهمية: تعد نسخ الذاكرة عملية أساسية ، ولكن هناك تكلفة لتنفيذها على جهاز EVM.

مع توفر تعليمات MCOPY ، يمكن نسخ كلمات وجمل الكود بشكل أكثر دقة ، مما سيزيد من أداء نسخ الذاكرة بحوالي 10.5٪ ، وهو أمر مفيد للغاية لمختلف العمليات الحسابية المكثفة ؛

سيكون من المفيد أيضًا للمجمعين إنشاء رمز ثانوي أكثر كفاءة وأصغر ؛

يمكن أن يوفر قدرًا معينًا من تكلفة الغاز من أجل التجميع المسبق للهوية ، لكنه لا يمكنه في الواقع تعزيز تحقيق هذا الجزء.

قائمة المرشحين EIP

في 15 يونيو 23 ، ناقش اجتماع إجماع المطورين أي برامج EIP مركزة على CL لتضمينها في Deneb ، ومن بينها ، تم اقتراح إضافة EIP6988 و EIP7044 و EIP7045.

EIP6988：X

ملخّص: يمنع المدققين المقتوعين من انتخابهم كمقترحي الكتلة.

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

EIP7044 ： X

ملخص: التأكد من أن مخارج المدقق الموقعة صالحة بشكل دائم.

الأهمية: يمكنها تحسين تجربة الراكب إلى حد ما.

EIP7045 ： X

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

الأهمية: تعزيز أمن الشبكة.

حذف تحليل EIP

في الاجتماع رقم 160 لـ Ethereum ACDE في 29 و 23 أبريل ، تم تأكيد إزالة EVMMAX و EOF من هذه الترقية ، وقد يتم إدخال التغييرات المتعلقة بـ EOF في الترقيات اليومية اللاحقة

EVMMAXEIPs ：

ملخص: يهدف EVMMAX إلى توفير قدر أكبر من المرونة للعمليات الحسابية وخطط التوقيع على Ethereum. يوجد حاليًا مقترحان من EVMMAX ، أحدهما مع EOF والآخر بدون EOF.

EIP6601: ملحقات حسابية معيارية EVM (EVMMAX)

التغيير: هو تكرار لـ EIP5843 ، والفرق عن EIP5843 هو:

يقدم 6601 نوع قسم EOF جديدًا يخزن المعامل ، معلمة Montgomery التي تم حسابها مسبقًا ، وعدد القيم التي سيتم استخدامها (لا يزال المعامل القابل للتكوين في وقت التشغيل مدعومًا) ؛

يستخدم 6601 مساحة ذاكرة منفصلة لقيم EVMMAX ، مع رموز تشغيل تحميل / تخزين جديدة لنقل القيم بين ذاكرة EVM <-> EVMMAX ؛

يدعم 6601 العمليات على وحدات تصل إلى 4096 بت (الحد المبدئي المذكور في EIP).

الأهمية: يقدم EIP-5843 إضافة وطرح ومضاعفة معيارية فعالة لجهاز Ethereum Virtual Machine ، ويعتمد EIP-6601 على ذلك من خلال تقديم قسم إعداد ومساحة ذاكرة منفصلة وأكواد تشغيل جديدة لعمليات حسابية معيارية يوفر تنظيمًا ومرونة أفضل مع دعم وحدات أكبر وتحسين أداء EVM.

كعقد EVM ، يتيح العمليات الحسابية للمنحنى البيضاوي على منحنيات مختلفة ، بما في ذلك BLS12-381 ؛

يقلل MULMOD من تكلفة الغاز للتشغيل بقيم تصل إلى 256 بت بنسبة 90-95٪ مقارنة بأكواد التشغيل الحالية ADDMOD ؛

يسمح بالتجميع المسبق للوضعيات ليتم تنفيذه كعقود EVM ؛

تقليل تكلفة التحقق من ZKP بشكل كبير في وظائف التجزئة الجبرية (مثل MiMC / Poseidon) و EVM.

EIP6690 ：

التغيير: EIP-6990 هو اقتراح مقتبس من EIP-6601 لتقديم عمليات حسابية معيارية محسّنة إلى EVM دون الاعتماد على EOF. بينما يتطلب EIP-6601 EIP-4750 و EIP-3670 كتبعيات ، يوفر EIP-6990 حلاً أكثر استقلالية. يوفر نهجًا أكثر بساطة عن طريق إزالة التبعية على EOF.

الأهمية: يحتفظ بالوظائف الأساسية لـ EIP-6601 لإجراء عمليات حسابية معيارية محسنة على وحدات فردية تصل إلى 4096 بت ، ويسمح هذا التبسيط بتنفيذ واعتماد أكثر كفاءة مع الاستمرار في توفير الفوائد المرتبطة بـ EIP-6601.

التغييرات الإلكترونية ：

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

EIP663：

موجز: تعليمات غير محدودة SWAP و DUP

الأهمية: من خلال تقديم تعليمتين جديدتين: SWAPN و DUPN ، والتي تختلف عن SWAP و DUP عن طريق زيادة عمق المكدس من 16 عنصرًا إلى 256 عنصرًا

EIP3540 ：

مقدمة:

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

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

دلالة:

يؤدي التحكم في الإصدار إلى إدخال وظائف جديدة أو إهمالها في المستقبل (مثل إدخال تجريد الحساب) ؛

يعتبر فصل رمز العقد والبيانات مفيدًا للتحقق من المستوى الثاني (المرجع) ، مما يقلل من تكلفة الغاز لمدققي المستوى 2. وفي الوقت نفسه ، يعد فصل رمز العقد والبيانات أكثر ملاءمة أيضًا لأدوات تحليل البيانات على السلسلة.

EIP3670

مقدمة: استنادًا إلى EIP-3540 ، الهدف هو التأكد من أن رمز عقد EOF متوافق مع التنسيق وصالح. بالنسبة للعقود التي لا تتوافق مع التنسيق ، سيتم منع نشرها ولن يتأثر رمز Legacybytecode.

الأهمية: استنادًا إلى الحاوية التي تم تقديمها بواسطة 3540 ، يضمن EIP-3670 أن الكود الموجود في عقد EOF صالح أو يمنع نشره. هذا يعني أنه لا يمكن نشر أكواد التشغيل غير المحددة في عقود EOF ، والتي لها فائدة إضافية تتمثل في تقليل عدد إصدارات EOF التي يجب إضافتها.

EIP4200 ：

مقدمة:

تم تقديم رموز التشغيل الأولى الخاصة بـ EOF: RJUMP و RJUMPI و RJUMPV ، والتي تشفر الوجهات كقيم فورية موقعة. يمكن للمجمعين استخدام أكواد تشغيل JUMP الجديدة هذه لتحسين تكلفة الغاز لنشر وتنفيذ JUMP لأنها تلغي وقت التشغيل المطلوب لإجراء تحليل سريع لأكواد تشغيل JUMP و JUMPI الحالية. يعد برنامج EIP هذا مكملاً للقفز الديناميكي.

بالمقارنة مع عملية JUMP التقليدية ، يتمثل الاختلاف في أن عمليات مثل RJUMP لا تحدد موضع إزاحة معين ، ولكنها تحدد موضع إزاحة نسبي (من القفزات الديناميكية -> القفزات الثابتة) ، لأن القفزات الثابتة غالبًا ما تكون كافية.

الأهمية: تحسين الشبكة وتقليل التكاليف.

EIP4750 ：

خذ وظيفة 4200 خطوة إلى الأمام: من خلال تقديم اثنين من أكواد التشغيل الجديدة من CALLF و RETF ، يتم تحقيق حل بديل للموقف الذي لا يمكن استبداله بـ RJUMP و RJUMPI و RJUMPV ، بحيث لم تعد هناك حاجة لـ JUMPDEST في عقد EOF ، وهذا يعني أنه تم تعطيل القفزة الديناميكية.

الأهمية: تحسين الكود عن طريق تقسيم الكود إلى عدة أجزاء.

EIP5450 ：

الخلفية: لا تزال الخلفية مفادها أن عقد Ethereum لا يتم فحصه عند نشره ، ويتم إجراء سلسلة من عمليات التحقق فقط عندما يكون قيد التشغيل ، سواء أكان المكدس قد تجاوز (الحد الأعلى هو 1024) ، وما إذا كان الغاز كافيًا ، و قريباً.

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

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

بعد تحديث اجتماع المطور في 26 مايو ، كان تغيير نوع المعاملة من SSZ إلى RLP المتعلق بـ EIP4844 يعني أنه لم تعد هناك حاجة إلى اثنين من SSZEIPs في كانكون ، لذلك تم نقل EIPs 6475 و 6493 من كانكون للترقية

EIP6475X

مقدمة: اقتراح مصاحب لـ EIP4844. يقدم Proto-danksharding نوع معاملة جديدًا يستخدم ترميز SSZ بدلاً من تشفير RLP الذي تستخدمه أنواع المعاملات الأخرى.

تحديث: خلال اجتماع المطورين الأساسيين لطبقة تنفيذ Ethereum رقم 161 ، كشفت المناقشات حول تنسيق تسلسل SSZ لـ EIP4844 أن المطورين في البداية يميلون إلى تقديم تكرارات مبكرة من تنسيق SSZ إلى EL عبر معاملات blob ، وفي النهاية يخطط المطورون لإحضار كل نوع المعاملة تمت ترقيته من RLP إلى SSZ ، لكن المطورين كانوا يزنون إزالة SSZ من EIP-4844 نظرًا لمساره غير الواضح وبالتأكيد غير قادر على تنفيذه في ترقية كانكون. بعد العديد من المناقشات ، وافق المطورون على إزالة SSZ من تطبيق EL لـ EIP-4844 ، لكنهم لم يزيلوا EIP6475 بعد. بعد تحديث 26 مايو ، سيعني تغيير SSZ-> RLP أنه لم تعد هناك حاجة إلى اثنين من SSZEIPs في كانكون: وبالتالي سيتم نقل EIPs 6475 و 6493 من كانكون للترقيات.

EIP6493X

مقدمة: مخطط توقيع معاملات SSZ. يحدد EIP هذا مخطط توقيع للمعاملات المشفرة بالتسلسل البسيط (SSZ) وسيتناول كيفية تعامل العقد مع أنواع معاملات blob المنسقة بتنسيق SSZ على CL ولكن تم ترميزها بشكل مختلف على EL. يعد برنامج EIP هذا جزءًا من تحديث لتنسيق تسلسل Ethereum من أجل الاتساق عبر الطبقات ؛

الخلفية: SSZchanges

مقدمة: SimpleSerialiZe هي طريقة التسلسل المستخدمة في سلسلة المنارة.

يتضمن SSZchanges أيضًا ثلاثة مقترحات داعمة أخرى ، هذه المرة تم تقديم 6465 فقط.

EIP6465: جذر انسحاب SSZ ، والذي يحدد عملية الترحيل لالتزامات Merkle-PatriciaTrie (MPT) الحالية لعمليات سحب التسلسل البسيط (SSZ) ؛

EIP6404 / EIP6466 ：

كلاهما يحدد عملية ترحيل التزامات Merkle-PatriciaTrie (MPT) الحالية إلى التسلسل البسيط (SSZ).

EIP-6404 - جذر معاملة SSZ

EIP-6466— قاعدة استلام SSZ

اقترح Tim Beiko في اجتماع المطورين الأساسيين في 26 مايو أن المحادثات المستقبلية حول توسيع نطاق كانكون تقتصر على خمسة برامج EIP التالية: EIP5920 و 5656 و 7069 و 4788 و 2537 ، وأن المقترحات اللاحقة سيتم إنشاؤها ضمن هذا النطاق. تم تأكيد EIP5656 و EIP4788 اللاحقين كمقترحات ترقية رسمية ، وتمت إزالة 5920 و 7069 و 2537. من بينها ، كان EIP5920 بسبب مخاوف المطورين بشأن الآثار الجانبية المحتملة لطريقة نقل ETH ، بالإضافة إلى التفكير غير المكتمل والاختبار ، والعمل الأمني. تمت إزالته من الترقية.

EIP5920 ： X

مقدمة: رمز تشغيل الدفع. يقدم كود التشغيل الجديد PAY لتحويلات Ethereum ، والذي يرسل Ether إلى عنوان دون استدعاء أي من وظائفه.

السبب: في الوقت الحالي ، يتطلب إرسال ether إلى عنوان أن يقوم المستخدم باستدعاء وظيفة على هذا العنوان ، والتي بها عدة مشاكل:

أولاً ، يفتح متجهًا لهجمات إعادة الدخول ، حيث يمكن للمتلقي معاودة الاتصال بالمرسل ؛

ثانيًا ، يفتح ناقل DoS ، لذلك يجب أن تدرك الوظيفة الرئيسية أن جهاز الاستقبال قد ينفد من الغاز أو رد الاتصال ؛

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

يتغير:

تم تقديم كود تشغيل جديد: (PAY) PAY \ _OPCODE ، حيث:

انبثق قيمتين من المكدس: addrthenval.

نقل وي من val عنوان التنفيذ إلى عنوان العنوان. إذا كان العنوان هو صفر ، فسيتم برمجة valwei من عنوان التنفيذ.

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

الأهمية: حفظ الغاز.

تحديث: في 09.06.23 ، تمت إزالة PAY من الترقية بسبب مخاوف بشأن الآثار الجانبية المحتملة التي يمكن أن توجد في طريقة نقل ETH ، والتفكير ، والاختبار ، والعمل الأمني المطلوب لتمرير الاقتراح.

EIP7069X

مقدمة: تعليمات CALL المعدلة

التغيير: تم تقديم ثلاثة تعليمات استدعاء جديدة ، CALL2 و DELEGATECALL2 و STATICCALL2 ، والتي لها تأثير على تبسيط الدلالات. يهدف إلى إزالة إمكانية ملاحظة الغاز من التوجيه الجديد وفتح الباب أمام فئة جديدة من العقود التي لا تتأثر بإعادة التسعير.

خلفية:

القاعدة 63/64: حدد عمق المكالمة وتأكد من أن المتصل لديه غاز متبقي لإجراء تغييرات الحالة بعد عودة المستدعى ؛

قبل إدخال القواعد 63/64 ، كان من الضروري حساب الغاز المتاح للمتصل بدقة إلى حد ما. لدى Solidity قاعدة معقدة تحاول تقدير التكلفة من جانب المتصل لتنفيذ المكالمة نفسها من أجل تعيين قيمة غاز معقولة.

تم تقديم القاعدة 63/64 حاليًا:

تمت إزالة فحص عمق المكالمة ؛

تأكد من الاحتفاظ بما لا يقل عن 5000 غاز قبل تنفيذ السلوك المطلوب ؛

تأكد من توفر 2300 غاز على الأقل للسلوك المطلوب.

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

الأهمية: تمهيد الطريق لإدخال EOF في المستقبل ، وتسهيل إدارة العقود الكبيرة.

إزالة خيار الغاز: لا يسمح الأمر الجديد بتحديد حد الغاز ، ولكنه يعتمد على "قاعدة 63/64" (تشير بشكل أساسي إلى إعادة تسعير الغاز لعدد كبير من عمليات الإدخال والإخراج في EIP-150 ، مما يزيد الغاز استهلاك عمليات محددة) للحد من الغاز ، هذا التحسين المهم هو تبسيط القواعد حول "الدعم" ، بغض النظر عما إذا تم إرسال القيمة أم لا ، لا يحتاج المتصل إلى إجراء الحسابات المتعلقة بالغاز ؛

من خلال تقديم الاقتراح الجديد ، يمكن للمستخدمين دائمًا التغلب على خطأ Outof Gas عن طريق إرسال المزيد من الغاز في المعاملة (وفقًا لحد حظر الغاز بالطبع).

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

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

أكواد إرجاع حالة أكثر ملاءمة: تم تقديم وظائف ملائمة تقوم بإرجاع رموز حالة أكثر تفصيلاً: نجاح (0) ، تراجع (1) ، فشل (2) ، وقابلة للتوسيع في المستقبل.

EIP2537 ： X

موجز: تجميع مسبق لمعالجة منحنى BLS12-381.

تم التغيير: تمت إضافة عمليات على منحنى BLS12-381 كمجمعات مسبقة إلى المجموعة اللازمة لأداء العمليات بكفاءة مثل التحقق من توقيع BLS وإجراء التحقق من SNARKs.

الأهمية: يمكن أن تنشئ Ethereum أدلة تشفير أكثر أمانًا وتسمح بإمكانية التشغيل البيني بشكل أفضل مع سلسلة المنارات.

تم ذكر PR3175 ، ولكن لم يتم وضعه في القائمة المختصرة مطلقًا ، ولا مزيد من المناقشة

PR3175 ： X

ملخّص: سيمنع هذا الاقتراح المدققين المعاقبين من اقتراح الكتل عند إلغاء الصفة. إذا تمت معاقبة أكثر من 50٪ من المدققين على السلوك الضار ، فسيظل هؤلاء المدققون قادرين على اقتراح عمليات حظر أثناء الإزالة القسرية من الشبكة. يقول المطورون إن تغيير هذا المنطق هو تغيير طفيف نسبيًا في طبقة CL يوفر الحماية ضد "أوضاع الفشل العالية".

وفقًا لاجتماع إجماع مطوري Ethereum الأساسي رقم 108 في الرابع من مايو ، فإن PR3175 في طور التهيئة كـ EIP ، وسيتم تغييره إلى EIP-6987 ، أي لأسباب أمنية ، لمنع تحديد عقد التحقق المقطوع. اقتراح كتلة.

مستقبل

بناءً على المعلومات الواردة أعلاه ، توصلنا إلى الاستنتاجات التالية:

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

مما لا شك فيه أن الأولوية الأولى للتوسع هي (4844).

تأتي السلامة وتوفير الغاز في المرتبة الثانية (6780 و 1153 و 5656 و 7045) ، مع مراعاة تجربة مطور معينة ؛

والثالث هو إمكانية التشغيل البيني ، مثل تحسين الاتصال والتواصل وقابلية التشغيل البيني بين dapps (4788 و 7044 و 6988) ؛

البيانات المتوقعة: يمكن أن يقلل Testnet 4844 من تكلفة opsiderollup بنسبة 50٪ ؛ لم تكشف الحلول التقنية لـ EigenLayer و Celestia عن الكثير ، ولا يمكن تقييم بياناتهما ؛ تقدر Ethstorage أن تكلفة DA ستنخفض إلى 5٪ من الأصل ؛ من المتوقع أن تقلل Topia التكلفة بمقدار 100 ~ 1000 مرة.

2. الفترة القادمة من 2 إلى 5 سنوات عند ترقية كانكون إلى Danksharding هي فترة التطوير الذهبية لمشاريع طبقات DA

يعتمد الحد الأعلى للأمان للطبقة الثانية على طبقة DA التي تتبناها. ستفيد Proto-Danksharding بروتوكولات التخزين والبروتوكولات المعيارية وشبكات توسيع التخزين L1 من خلال تخزين بيانات الحالة الأرخص.

أولاً ، يعود Danksharding إلى جوهر آلة دولة Ethereum. ذكر V God أن الغرض من بروتوكول إجماع Ethereum ليس ضمان التخزين الدائم لجميع البيانات التاريخية. بدلاً من ذلك ، يتمثل الغرض في توفير لوحة إعلانات في الوقت الفعلي عالية الأمان وإتاحة مساحة للبروتوكولات اللامركزية الأخرى للتخزين طويل الأجل (الغرض من بروتوكول توافق Ethereum ليس ضمان تخزين جميع البيانات التاريخية إلى الأبد. بدلاً من ذلك ، الغرض هو توفير لوحة إعلانات في الوقت الفعلي آمنة للغاية ، وترك مساحة للبروتوكولات اللامركزية الأخرى للقيام بالتخزين على المدى الطويل.) ؛

ثانيًا ، يقلل Danksharding من تكلفة DA ، ولكن يجب أيضًا حل مشكلات وقت الهبوط الفعلي وتوافر البيانات.

تخفيض تكلفة DA: قبل هذا التحديث ، كان من الضروري استدعاء بيانات calldata لإصدار البيانات من التراكمي إلى سلسلة Ethereum الرئيسية ، وكانت رسوم الغاز لاستدعاء هذا الرمز باهظة الثمن ، والتي كانت أكبر نفقات في الطبقة 2. يقدم EIP4844 كتل بيانات مثل التجميعات ستعمل مساحة البيانات الإضافية الفريدة على تقليل تكاليف التخزين بشكل كبير ، وبالتالي تقليل تكاليف DA.

وقت الهبوط الفعلي طويل ، ولا تزال TPS التي يمكن تحسينها والغاز الذي يمكن تقليله محدودة ، لذا فهي جيدة للتطوير المستمر لمشاريع طبقة DA في المستقبل:

في مقالة تجزئة بيانات الأمن iablesecurity في Polynya حول danksharding ، تُظهر أن الأمر سيستغرق 2-5 سنوات للتنفيذ ؛

حتى إذا هبطت ، فإن TPS يمكن زيادتها ومستوى الغاز الذي يمكن أن تخفضه لا يزال محدودًا:

يدعم EIP4844 حاليًا 6 نقاط ، ولا يمكن حل مشكلة التوسع المستقبلية إلا عن طريق Danksharding ؛

تبلغ مساحة كتلة Ethereum الحالية حوالي 200 كيلو بايت. بعد Danksharding ، الحجم المخطط في المواصفات هو 32 ميغا بايت ، وهو حوالي 100 ضعف. في الوقت الحالي ، يبلغ TPS من Ethereum حوالي 15 ، وفي حالة مثالية ، سيكون حوالي 1500 بعد زيادته بمقدار 100 مرة ، وهو ليس تحسنًا كبيرًا في الحجم.

لذلك ، فإن وقت التنفيذ الطويل + التغييرات الفعلية المحدودة ستفيد مشاريع طبقة DA. لا يزال بإمكان بعض مشاريع DA مثل Celestia و Eigenda التنافس مع Danksharding من خلال تكاليف أرخص و TPS أسرع.يمكن أيضًا لمشاريع DA الجديدة مثل ETHstoragetopia سد فجوة السوق السابقة.

يجب أيضًا معالجة المشكلات الفنية مثل تخزين البيانات وقضايا توفر البيانات:

هناك نوعان من التكاليف الرئيسية لـ DA ، أحدهما تكلفة النطاق الترددي للشبكة ، والآخر هو تكلفة التخزين ، و 4844 نفسه لا يحل مشكلة التخزين ومشكلة النطاق الترددي لسلسلة البلوكشين

سيتم تخزين blob على طبقة إجماع Ethereum لمدة 3 أسابيع تقريبًا ثم يتم حذفها. إذا كنت ترغب في تخزين سجلات تاريخية كاملة وإتاحة جميع البيانات ، فإن الحلول الحالية تشمل: dapp نفسه يخزن البيانات المتعلقة بنفسه ، وشبكة بوابة Ethereum (قيد التطوير حاليًا) أو بروتوكولات الطرف الثالث مثل مستكشفات الكتل أو البيانات التاريخية في BitTorrent أو التخزين التلقائي بواسطة المستخدمين الفرديين.

لذلك ، ستستفيد Proto-Danksharding من بروتوكولات التخزين والبروتوكولات المعيارية وشبكات توسيع التخزين L1:

سيؤدي الطلب على استدعاء البيانات التاريخية إلى قناة تطوير جديدة لبروتوكولات التخزين اللامركزية أو بروتوكولات فهرس الجهات الخارجية ؛

يمكن للاتفاقيات النموذجية اللاحقة تنفيذ المعاملات من خلال Rollup عالي السرعة ، وتكون طبقة التسوية الآمنة مسؤولة عن التسوية ، وتكون طبقة توفر البيانات منخفضة التكلفة وذات السعة الكبيرة مسؤولة عن الضمان ؛

إنه جيد لشبكة توسيع التخزين L1 ، مثل Ethstorage ، والتي يمكن أن توفر حلاً من الدرجة الثانية للتخزين القابل للبرمجة بتكلفة تخزين أقل.

3. ترقية كانكون مفيدة لتنوع L2 و L3 و RAAS وتوافر البيانات والمسارات الأخرى

تحليل المسار L2:

الطبقة العليا 2 ، ستستفيد خمسة مشاريع مثل ArbitrumOrbit و OPStack و Polygon2.0 و FractalScaling (ضمن StarkWare) و HyperChain (ضمن zkSync). سيؤدي تخفيض رسوم التخزين الذي تجلبه البيانات الثنائية الكبيرة إلى تحسين السلسلة السابقة من مشكلات التكلفة وقابلية التوسع التي حدت من تطوير الطبقة 2 ، وتحسين إنتاجية البيانات بشكل كبير. بعد حل مشكلة التكلفة ، ستتاح للطبقة الرئيسية 2 الفرصة لمواصلة نشر محددة وظائف ، بيئة L3 متزامنة متعددة السلاسل مخصصة عالية المستوى ؛

سيتم تضييق الفجوة في تكاليف التشغيل بين الطبقة الثانية من الطبقة الثانية والطبقة الثانية السائدة ، مما يمنح بعض المشاريع الصغيرة المزيد من الفرص للتنمية ، مثل Aztec و Metis و Boba و ZKspace و layer2.finance وما إلى ذلك ؛

على الرغم من أنه لا يزال يتعين التحقق من الاحتياجات الحقيقية لمشاريع blockchain المعيارية ، إلا أن لغات البرمجة المتنوعة لا تزال ممكنة ، مثل Starkware's Cario و Move series languages و Wasm المدعومة من C و c ++ و C # و Go series ، والتي يمكن أن تقدم المزيد من العديد من لغات الويب 2 المطورين.

تحليل مسار Raas:

تكمن ميزة Raas نفسها في درجة التخصيص العالية والمتطلبات المخصصة> التكلفة والكفاءة الخالصة ، لذا فإن خفض التكلفة يعد ميزة كبيرة للتجميع المخصص.

لكن المشكلة في مسار RAAS هي أنه قد يكون OverHype ، وهناك شكوك حول مسار RAAS نفسه. في مواجهة المنافسة من أعلى 5 layer2s وظهور العديد من DAs الجديدة ، علينا وضع علامة استفهام حول ما إذا كانت المشاريع الجديدة يمكن أن تشكل مسارًا.

بادئ ذي بدء ، تكمن ميزة نشر سلسلة تطبيقات الطبقة 2 الرئيسية في سلامة إطار عمل الشبكة وأمن البيئة بين السلاسل ، وتكمن ميزة RAAS في التخصيص والحرية ؛

ومع ذلك ، فإن الحواجز التقنية RAAS لسلسلة OP و ZK ليست قوية في الوقت الحالي ، ولا تزال في مرحلة الاختبار على المدى القصير ، ولا يوجد تفاعل فعلي مع المنتج. بالنظر إلى التقدم الفعلي لـ RAAS ، والنماذج الفنية ، و المزايا البيئية للطبقة 3 في المستقبل ، فإن الطلب الفعلي على RAAS مشكوك فيه.

سلسلة OP: على الرغم من أن ترقية حجر الأساس +4844 لمكدس OP قد جلبت بعض التحسينات الصغيرة في التكلفة والكفاءة ، إلا أن جاذبية التحسينات ليست قوية ؛

سلسلة ZK: في الوقت الحالي ، تتبع العديد من المشاريع الرائدة مسار ZKEVM وتولي مزيدًا من الاهتمام للتوافق مع Ethereum ، وبالتالي فإن تصميم الدائرة سيضحي بكفاءة معينة ، وهو ليس مستهدفًا مثل سلسلة OP. ومع ذلك ، لا تزال معظم ZKRAAS الموجودة حاليًا في السوق تستخدم المشاريع الرائدة (مثل ZkSync) لتقسيم السلسلة ، ولا تزال الحواجز غير قوية.

لذلك ، على المدى القصير ، لا يزال لدى OPRAAS مجال للتطوير قبل أراضي الطبقة 3. على المدى الطويل ، قد يكون ZKRAAS و layer3 هو الاتجاه المستقبلي.

ZKRAAS له عيب أكبر في التكلفة بعد 4844 ، ويستهلك طاقة حوسبة أكبر بكثير من OP. على الرغم من أن تكلفة التحميل إلى L1 أقل من تكلفة OP ، إلا أن هذا ليس سوى انخفاض في المجموعة مقارنة بتكلفة عملية الإثبات ، بينما OP الميزة هي أنه يمكن بناء بيئة بسرعة في فترة زمنية قصيرة ، ولا يزال هناك مجال للتطوير قبل أراضي الطبقة 3 ؛

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

4. تعمل ترقية Cancun على تحسين تجربة المطور والمستخدم

الاقتراح الثاني المهم لترقية كانكون ، إزالة SELFDESTRUCT ، سيحسن أمان Ethereum.

يضيف الاقتراح الثالث EIP1153 الذي تمت ترقيته بواسطة كانكون أكواد التشغيل المؤقتة للتخزين ، والتي يمكنها أولاً توفير الغاز ، وثانيًا حل مشكلة الاتصال بين الإطارات ، وتمهيد الطريق أخيرًا لتصميم التخزين المستقبلي ، مثل Verkle tree لن تحتاج إلى التفكير في استرداد سؤال تخزين عابر

يقدم EIP5656 ، الاقتراح الرابع لترقية كانكون ، تعليمات نسخ ذاكرة MCOPY ، والتي يمكنها نسخ كلمات وجمل الكود بدقة أكبر ، مما يحسن أداء نسخ الذاكرة بحوالي 10٪ ؛

الاقتراح الخامس لترقية كانكون هو EIP4788 ، والذي يمكن أن يجعل الاتصال بين البروتوكولات والتطبيقات المختلفة في شبكة Ethereum أكثر كفاءة وأمانًا ، ويسمح أيضًا بمزيد من التصاميم غير الموثوقة للتجمعات المجمعة وبروتوكولات التجسير وإعادة العمل ؛

تقترح آخر ترقية في كانكون (15 يونيو 23) إضافة ترقيات EIP الخاصة بـ CL-centric: EIP6988 و EIP7044 و EIP7045 ، والتي تعمل على تحسين أمان Ethereum وإمكانية استخدامه بالتفصيل ، مثل تحسين تجربة التعهد وتحسين أمان الشبكة ، إلخ.

من بين المقترحات المحذوفة ، تسبب انتقال SSZ-> RLP في إزالة اثنين من SSZEIPs (EIP6475 و EIP6493) من ترقية كانكون ؛ تمت إزالة المقترحات المتعلقة بـ EOF من ترقية كانكون مرة أخرى بعد إزالتها من ترقية شنغهاي ، ويتم النظر فيها حاليًا ممكن سيتم تنفيذه مباشرة في الترقيات اليومية اللاحقة ؛ تمت إزالة EVMMAX أيضًا من كانكون للترقيات مع EOF لأنها مجموعة فرعية من EIP المتعلقة بتنفيذ EOF ؛ مع الأخذ في الاعتبار الآثار الجانبية المحتملة التي قد تكون موجودة في طريقة نقل ETH ، والحاجة لتمرير الاقتراح المنطق والاختبار والعمل الأمني ، EIP5920 تمت إزالته من الترقية.

5. العلاقة مع zkml وتجريد الحساب

** تأثير ضئيل على zkml **

ZKML هو مزيج من Zero Knowledge Proof (ZeroKnowledge) والتعلم الآلي (Machine Learning) ؛ الجمع بين blockchain ونموذج ML يحل مشاكل حماية الخصوصية وإمكانية التحقق من التعلم الآلي:

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

إمكانية التحقق: تشتمل تقنية إثبات المعرفة الصفرية على مجموعة واسعة من التطبيقات ، ويسمح ZKP للمستخدمين بمعرفة صحة المعلومات دون التحقق. ونظرًا لأن نموذج التعلم الآلي يتطلب الكثير من العمليات الحسابية ، يمكن لنموذج ML إنشاء أدلة من خلال ZK-SNARK ، مما يقلل من حجم الدليل ويخفف من الطلب على طاقة الحوسبة لـ ML.

لا علاقة لمتطلبات تخزين ZKML مع DA: يلزم وجود بنية تخزين منفصلة مثل Space and Time ، وتقنيتها الأساسية هي بروتوكول الأمان الجديد "SQL Proof". أو توصيل البيانات على السلسلة وخارج السلسلة بطريقة بسيطة تنسيق SQL وتحميل النتائج مباشرة في العقود الذكية ؛

ZK-SNARKs هو الشكل الرئيسي لـ ZK في ZKML ، والذي يمكنه التكيف مع متطلبات طاقة الحوسبة لـ ML على السلسلة. مع تطوير التشفير ، ستفيد أدلة SNARK العودية بشكل خاص في تنفيذ ZKML على السلسلة:

تتميز ZK-SNARKs بانضغاط عالٍ. يسمح استخدام ZK-SNARKs للمثقف بإنشاء دليل قصير ، ولا يحتاج المدقق إلى التفاعل ويحتاج فقط إلى إجراء قدر صغير من العمليات الحسابية للتحقق من صحته. وهذا يتطلب مثلاً واحدًا فقط إن طبيعة التفاعل مع أدوات التحقق تجعل ZK-SNARKs فعالة وعملية في التطبيقات العملية ، وهي أكثر ملاءمة لمتطلبات طاقة الحوسبة على السلسلة في ML.

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

ترجع مشكلة ML الحالية بشكل أكبر إلى متطلبات طاقة الحوسبة غير المرضية والأداء المنخفض الناجم عن قيود الخوارزمية (لا يمكن حسابها بالتوازي). يثبت الطراز الكبير ZK أن قوة الحوسبة الأعلى مطلوبة ، والتي لا يمكن دعمها على السلسلة. تدعم ZK-SNARKs الصغيرة فقط إثبات حجم المعرفة الصفري لـ ML والكمية الصغيرة من الحساب ، أي أن الحد من قوة الحوسبة هو عامل رئيسي يؤثر على تطوير تطبيقات ZKML blockchain ، ويمكن للسلسلة فقط تخزين نتائج إيقاف التشغيل - حسابات السلسلة.

** تجريد حساب جيد **

بادئ ذي بدء ، يمكن أن تقلل ترقية كانكون من تكلفة إثبات ZKrollup إلى حد معين:

تعتمد رسوم معاملة zkSync الحالية على 3 جوانب:

تكلفة الموارد الثابتة التي يستهلكها المدقق لإنشاء شهادة SNARK والتحقق من أنها مرتفعة نسبيًا ؛

رسوم الغاز عندما يقدم المدقق إثبات SNARK إلى شبكة Ethereum الرئيسية ، فإن هذا الجزء من الرسوم سيزيد وفقًا لذلك بسبب ازدحام الشبكة الرئيسية ؛

رسوم الخدمة التي يدفعها المستخدم للمدقق ، بما في ذلك تأكيد المعاملة ، وبث الرسائل ، وما إلى ذلك.

لذلك ، إذا تم تقديم 4844 ، فسيتم تخفيف مشكلة زيادة رسوم الغاز الناتجة عن ازدحام الشبكة الرئيسية ، ويمكن تقليل تكلفة أدلة ZKP إلى حد معين.لا ينبغي التقليل من اتجاه تطوير سلسلة ZK.

ثانيًا ، يحول تجريد الحساب معاملات tx التقليدية إلى عمليات مستخدم ، ثم يحزم عمليات المستخدم في كتل مع ECDSA ، والتي تشغل مساحة تخزين أكبر على السلسلة أكثر من ذي قبل ، وبالتالي فإن متطلبات التخزين أعلى ؛

بعد ذلك ، يمكن أن يكمل تجريد الحساب و ZKrollup بعضهما البعض:

في الوقت الحالي ، تكمن مشكلة استخراج الحساب في أن GasFee باهظة الثمن ، نظرًا لوجود العديد من الخطوات والعقود الذكية ، فهناك الكثير من البيانات ، مما يجعل GasFee باهظة الثمن ، وتتمثل ميزة ZKRollup في قدرتها على تقليل البيانات ؛

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

أخيرًا ، بالنظر إلى صعود تقنية الذكاء الاصطناعي ، يمكن أن تساعد في تعزيز أمان العقود عبر السلسلة وتحسين المعاملات على السلسلة أو خطوات النشاط:

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

تحسين الذكاء الاصطناعي وأنشطة السلسلة: تشمل الأنشطة على blockchain المعاملات وتنفيذ العقود وتخزين البيانات. من خلال قدرات التحليل والتنبؤ الذكية للذكاء الاصطناعي ، يمكن تحسين الأنشطة على السلسلة بشكل أفضل وتحسين الكفاءة والأداء بشكل عام. يمكن أن يساعد الذكاء الاصطناعي في تحديد أنماط المعاملات ، واكتشاف النشاط غير المعتاد ، وتقديم توصيات في الوقت الفعلي لتحسين تخصيص الموارد لشبكات blockchain من خلال تحليل البيانات والتدريب على النموذج.

لذلك ، ستفيد ترقية كانكون تدريجياً في التطوير المستقبلي لسحب الحساب من توسيع مساحة التخزين ، إلى التكامل مع ZKrollup ، ثم إلى الدمج مع تقنية الذكاء الاصطناعي.

6. بالنظر إلى خارطة طريق Ethereum ، ما التالي

في الوقت الحالي ، لا تتمتع Layer2 بأداء مشابه لأداء Solana (من حيث زمن الانتقال والإنتاجية) ، ولا تتمتع بأداء تجزئة مثل Near ، ولا تتمتع بأداء تنفيذ موازٍ مثل Sui و Aptos. لقد أدت ترقية كانكون إلى تحسين قيادة Ethereum باعتبارها قائد؛

بعد ترقية كانكون ، تشير التقديرات إلى أن العديد من أوقات التطوير الرئيسية ستكون عبارة عن مشاركة رديئة بالكامل (2 ~ 5 سنوات) ، وهبوط MEV و PBS (1 ~ 3 سنوات) ، وتجريد الحساب (1 ~ 2 سنة) ، و ZK كل شيء (3 ~ 6 سنوات)) ، و EOF وتجربة المطور (كم مرة رأيت التمديد؟).

** TheScourge **

الهدف: التركيز على حل مشاكل MEV.

الحل: قلل MEV في طبقة التطبيق من خلال "Proposer-Builder Separation (PBS)". في هذا الوقت ، قد يتم تحسين blobs ، وقد يتم تقديم خدمات التأكيد المسبق أو الحماية المسبقة.

PBS هو الفصل بين منشئي الكتل والفرازات. عامل الفرز مسؤول فقط عن الفرز ، بغض النظر عن السلسلة ، ولا يهتم منشئ الكتل بالمعاملة ، ويختار مباشرة الحزمة التي أنشأها الفارز ويضعها في السلسلة. ستجعل هذه العملية العملية برمتها أكثر إنصافًا وتخفيف مشكلة MEV ، وهي فكرة إخراج MEV.

لا تزال درجة إتمام PBS منخفضة جدًا في الوقت الحالي ، والأكثر نضجًا هو التعاون مع حلول MEV الخارجية - mevboost of flashbots.

يحتوي الإصدار المتقدم من "Enshrined Proposer-Builder Separation (ePBS)" على درجة أقل من الاكتمال ودورة أطول ، ومن المقدر أنه لن يتم تنفيذه على المدى القصير. بالإضافة إلى ذلك ، هناك إصدارات تقدمية من PEPC و ترحيل متفائل ، والذي يعزز المرونة والقدرة على التكيف في إطار عمل دعم السلوك الإيجابي

الحافة

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

في الوقت نفسه ، تمت إضافة ZKization لـ L1 بوضوح إلى خارطة طريق Verge. سيكون ZK هو الاتجاه العام للتوسع والتسريع في المستقبل ؛

الحل: تقديم zk-SNARKs لاستبدال نظام الإثبات القديم ، بما في ذلك عملاء الإضاءة المستندة إلى SNARK ؛ SNARKs مع تغييرات حالة الإجماع ؛ EnshrinedRollups.

تعد أشجار Verkle بديلاً أكثر فاعلية لأشجار Merkle الخاصة بالحالة والتي لا تحتاج إلى توفير مسار من كل عقدة شقيقة (العقد التي تشترك في نفس الأصل) إلى العقدة المختارة ، ولكن فقط المسار نفسه كدليل. جزئياً ، Verkle البراهين أكثر كفاءة بثلاث مرات من براهين Merkle.

يشير EnshrinedRollup إلى تراكم يحتوي على نوع من التوافق في الآراء بشأن L1. وتتمثل الميزة في أنه يرث إجماع L1 ولا يحتاج إلى رموز الحوكمة لإجراء ترقيات التجميع. وفي الوقت نفسه ، من خلال إجراء العمليات الحسابية خارج السلسلة والنشر فقط النتائج إلى blockchain ، يمكن أن تزيد من عدد المعاملات ، لكن الصعوبة التقنية للتنفيذ كبيرة نسبيًا. سيكون الجمع بين هذه المجموعات في المستقبل قادرًا على تلبية معظم احتياجات نظام blockchain البيئي في العقود القليلة القادمة.

التطهير

يشير ThePurge إلى هدف تبسيط البروتوكول عن طريق تقليل متطلبات التخزين للمشاركة في التحقق من الشبكة. يتم تحقيق ذلك في المقام الأول من خلال السبات وإدارة التاريخ والحالة. سكون البيانات التاريخية (EIP-4444) يسمح للعملاء بتقليم البيانات التاريخية الأقدم من عام واحد والتوقف عن تقديم الخدمات على مستوى P2P.

دولة نائمة. عندما يتعلق الأمر بالتعامل مع نمو الدولة ، هناك هدفان رئيسيان: ضعف انعدام الجنسية ، والذي يشير إلى الهدف المتمثل في استخدام الدولة فقط لبناء الكتل وليس التحقق منها ؛ الدولة التي يتم الوصول إليها. يجب أن يقلل إسبات الحالة من حاجة عُقد الحالة إلى التخزين بما مجموعه 20-50 غيغابايت.

في المرحلة الخامسة من التطهير ، تمت كتابة EIP4444 بشكل صريح في خارطة الطريق. يتطلب EIP-4444 من العميل مسح البيانات الأقدم من عام واحد. وفي الوقت نفسه ، هناك بعض مهام تحسين EVM في هذه المرحلة ، مثل تبسيط آلية التجميع المسبق لـ GAS و EVM ، وما إلى ذلك ؛

** TheSplurge **

في المرحلة السادسة الأخيرة من Splurge ، تمت الإشارة أيضًا إلى EIP4337. كاقتراح تخطيط طويل الأجل لبيئة المحفظة ، سيؤدي سحب الحساب إلى تحسين سهولة استخدام المحافظ في المستقبل ، بما في ذلك استخدام العملات المستقرة لدفع ثمن الغاز ومحافظ الاسترداد الاجتماعي ، إلخ.؛

! [ترقية Ethereum Cancun تقترب ، راجع ترقية كانكون في الماضي والحاضر والمستقبل] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-f84d733b8f-dd1a6f-1c6801)