الحياة الماضية

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

• تتمثل رؤية Ethereum في أن تصبح أكثر قابلية للتوسع وأكثر أمانًا في ظل فرضية اللامركزية. تلتزم الترقية الحالية لـ Ethereum أيضًا بحل هذه المشكلة الثلاثية ، لكنها واجهت تحديات كبيرة.
• مشاكل مع Ethereum:
• في الوقت الحالي ، فإن TPS والأداء منخفضان ، ورسوم الغاز مرتفعة والازدحام خطير. وفي الوقت نفسه ، تتزايد مساحة القرص المطلوبة لتشغيل عميل Ethereum أيضًا بسرعة. في الجزء السفلي ، العمل على ضمان الأمان واللامركزية في Ethereum لقد أصبح تأثير خوارزمية توافق الحجم على البيئة بأكملها أكثر وأكثر أهمية.
• لذلك ، في ظل فرضية اللامركزية ، فإن كيفية نقل المزيد من البيانات وتقليل الغاز لتعزيز قابلية التوسع ، وكيفية تحسين خوارزمية الإجماع لضمان الأمان هي جميع الجهود التي تبذلها Ethereum حاليًا.
• من أجل حل ثلاثية الأمان واللامركزية وقابلية التوسع ، استخدمت Ethereum آلية PoW-to-PoS لزيادة تقليل عتبة العقدة ، وتخطط أيضًا لاستخدام سلسلة المنارات لتعيين محققين عشوائيًا لتحسين الأمان. من قابلية التوسع ، تنظر Ethereum في استخدام التجزئة لتقليل عبء العمل على العقد ، مما يمكّن Ethereum أيضًا من إنشاء كتل متعددة في نفس الوقت وتعزيز قابلية التوسع.
• المساحة الحالية لكل كتلة من Ethereum حوالي 200 ~ 300 KB ، يبلغ الحد الأدنى لحجم كل معاملة حوالي 100 بايت ، أي حوالي 2000 معاملة ، مقسومة على وقت الكتلة البالغ 12 ثانية ، والحد الأعلى لـ TPS من Ethereum يقتصر على حوالي 100. من الواضح أن هذه البيانات لا يمكن أن تلبي احتياجات Ethereum.
• لذلك ، تركز Ethereum Layer 2 على كيفية وضع كمية كبيرة من البيانات في الكتلة في الفضاء ، يتم ضمان الأمان من خلال إثباتات الاحتيال وإثباتات الصلاحية ، ولهذا السبب تحدد طبقة DA الحد الأعلى للأمان ، وهو أيضًا المحتوى الأساسي لترقية كانكون.
• لا يمكن للمسار التكراري لبيئة Ethereum بناء أداء معيار Solana (من حيث التأخير والإنتاجية) ، ولن يتم رؤية أداء التجزئة لـ Near على المدى القصير ، ولا أداء التنفيذ الموازي لـ Sui و Aptos. على المدى القصير ، يمكن لـ Ethereum فقط بناء هيكل متعدد الطبقات مع Rollup كقلب أساسي ، لذلك يقوم Cancun بترقية حل TPS ، الغاز الرسوم وتجربة المطور أمر بالغ الأهمية لخارطة طريق Ethereum.

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

• آخر ترقيات مهمة وأهدافها *

• • 2020 ** سنة ** 12 ** شهر ** 1 ** تم إطلاق سلسلة منارات التنبيه الإلكترونية رسميًا ، مما يمهد الطريق لترقية ** نقاط البيع ** *
• • 2021 **** 8 ** شهر ** 5 ** ترقية لندن ، ** EIP1559 ** تغير النموذج الاقتصادي لإيثريوم ؛ *
• • 2022 ** سنة ** 9 ** شهر ** 15 ** ترقية باريس (** دمج **) ، مكتمل ** POW ** التبديل ** POS ** ؛ *
• • 2023 ** سنة ** 4 ** شهر ** 12 ** تمت ترقيته في شنغهاي ، وحل مشكلة سحب التعهدات ؛ *
• • تم الانتهاء من النموذج الاقتصادي والترقيات المرتبطة بـ ** POS ** ، وحلت الترقيات القليلة التالية مشاكل أداء Ethereum و ** TPS ** وتجربة المطور ؛ *
• • الخطوة التالية هي التركيز على خارطة طريق Ethereum * * ملف طفرة* .

• هدف: تحقيق 100000+ TPS في Rollup.

• ** هناك مخططات **** 2 **** ، على السلسلة وخارج السلسلة: **

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

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

• ** تحليل مخطط التقاسم: **

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

• Danksharding هو تصميم تجزئة جديد مقترح لـ Ethereum ، فكرتها الأساسية هي ** إنتاج البلوك المركزي ** ** + ** ** التحقق اللامركزي ** ** + ** ** مقاومة الرقابة ** يرتبط هذا أيضًا بتوفر البيانات المذكورة أدناه أخذ العينات (DAS) ، فصل الكتل المنتج عن الحزم (PBS) وقائمة مقاومة الرقابة (قائمة Crlist). تكمن الأهمية الكبرى لفكرة Danksharding الأساسية في تحويل Ethereum L1 إلى تسوية موحدة (تسوية) وتوافر البيانات (توفر البيانات) التوفر） 层。

*** ينقسم مخطط التجزئة إلى خطوات **** 2 ****** ، حاليًا مقسم إلى **** Proto- **** التجزئة ***** و **** كامل التراكمي ******. ***

• **لذلك- danksharding **** ： **
• يقدم: ساعد في تقليل رسوم L2 وزيادة الإنتاجية من خلال إدخال النقط ، في نفس الوقت كحل مسبق للتجزئة لتمهيد الطريق للتجزئة الكاملة. من المتوقع أن يستغرق تنفيذ المشاركة danksharing من 2 إلى 5 سنوات.
• المحتوى: الميزة الرئيسية لـ proto-danksharding هي تقديم نوع جديد من معاملات blob. تتميز Blob بخصائص السعة الكبيرة والتكلفة المنخفضة. يمكن أن تسمح إضافة حزم البيانات هذه إلى Ethereum بتخزين جميع بيانات التجميع في blob ، وهو ما يؤدي إلى حد كبير يخفف العبء على السلسلة الرئيسية ، كما يمكن أن يقلل ضغط التخزين من تكلفة التجميع.
• ** تراكمي بالكامل **
• مقدمة: تم توسيع التراكم بالكامل ، مع التركيز على الاستفادة من توافر البيانات.
• محتوى:
• تصميم P2P لـ DAS: بعض الأعمال والأبحاث التي تتضمن مشاكل اتصال شبكة تجزئة البيانات ؛
• عميل أخذ عينات توفر البيانات: تطوير عميل خفيف الوزن يمكنه تحديد ما إذا كانت البيانات متاحة بسرعة عن طريق أخذ عينات عشوائية من بضعة كيلوبايت ؛
• الإصلاح الذاتي الفعال لـ DA: قادر على إعادة بناء جميع البيانات بكفاءة في ظل ظروف الشبكة الأسوأ (على سبيل المثال ، هجوم المدقق الخبيث ، أو التعطل طويل الأجل للعقد ذات الكتلة الكبيرة).

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

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

• التعريف: اجتماع المطورين الأساسي هو مؤتمر أسبوعي عبر الهاتف يعقده مجتمع تطوير Ethereum ، حيث يناقش المساهمون الأساسيون من المنظمات المختلفة القضايا الفنية وينسقون العمل المستقبلي على Ethereum. إنهم يحددون الاتجاه التقني المستقبلي لبروتوكول Ethereum ، وهم أيضًا السلطة التي تتخذ قرارات فعلية بشأن ترقية Ethereum. وهم مسؤولون عن تحديد ما إذا كان EIP مدرجًا في الترقية ، وما إذا كان من الضروري تغيير خارطة الطريق وغيرها من الأمور المهمة القضايا.
• العملية الأساسية: عملية الترقية التي تتمحور حول برنامج EIP هي تقريبًا على النحو التالي. أولاً ، يتم قبول برنامج EIP مبدئيًا في مؤتمر المطورين الأساسيين (اختصارًا ACD) ، ثم يقوم فريق العميل باختباره بغض النظر عما إذا كان برنامج EIP مدرجًا في قم بالترقية أم لا ، وبعد الاختبار النهائي ، قم بمراجعته مرة أخرى ، ثم قرر ما إذا كنت تريد تضمينه في الترقية الفعلية بناءً على المناقشة.
• ** المؤتمرات مقسمة إلى **** 2 **** فئات ، وهي اجتماع طبقة الإجماع واجتماع الطبقة التنفيذية ، والتي تُعقد بالتناوب كل أسبوعين: **
• ** اجتماع طبقة التوافق (**** الكل إجماع المطورين الأساسي - ACDC ****) ، مع التركيز على طبقة إجماع Ethereum (إثبات الحصة ، سلسلة منارة ، إلخ) ؛ **
• ** اجتماع على المستوى التنفيذي (** ** الكل حل المطورين الأساسي - ACDE ) ، والذي يركز على طبقة تنفيذ Ethereum ( EVM **** ، **** Gas ** ** Schedule ، إلخ.) **.
• هناك 3 أنواع من المشرفين الأساسيين على Ethereum ، بشكل أساسي المنظمات الرسمية أو المنتديات التطوعية التي تناقش المقترحات:
• AllCoreDevs: مشرفو الكود ، المسؤولون عن عميل شبكة ETH1 ، ترقية ، صيانة كود Ethereum والبنية الأساسية ؛
• قسم “إدارة المشروع”: دعم مطوري Ethereum ، وتنسيق الهارد فورك ، ومراقبة EIP ، وما إلى ذلك ، ومساعدة AllCoreDevs بشكل مباشر في الاتصالات والعمليات ؛
• إيثريوم السحرة: “منتدى” يريد مناقشات حول برنامج EIP ومواضيع فنية أخرى.

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

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

** المرحلة 1 - تقديم سمات الترقية **

*** تقديم مهام جديدة ****** proto-danksharding ****** ****** ****** ****** و ****** ****** selfdestruct “***** * * رمز التشغيل ، مناقشة سطحية لمحتوى ترقية شنغهاي ***

• بعد اكتمال دمج Ethereum في 15 سبتمبر 22 ، تم تعليق اجتماع المطورين لمدة 4 أسابيع ، مما سمح للمطورين بالتحقق من EIP الذي تمت مناقشته في الترقية اللاحقة لمدة شهر واحد ؛
• في 28 ، 22 أكتوبر ، اقترح أول اجتماع للمطورين بعد الاندماج تنفيذ التقاسم الأولي ، و EOF وكود التشغيل “التدمير الذاتي” لأول مرة. في هذا الوقت ، لم يتم تحديد النطاق المحدد لـ proto-danksharding ، وبعض المطورين مبدئيون في رأيي ، يمكن تقسيم ترقية شنغهاي إلى عدة ترقيات صغيرة ، مثل تمكين عمليات سحب ETH المتعهد بها أولاً ، ثم ترقية EIP 4844 ، ولكن تعتقد مجموعة أخرى من المطورين أنه من المنطقي تنفيذ ترقية أكبر في خطوة واحدة.

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

في نهاية **** 2022 ****** ، يدور مؤتمر Ethereum بشكل أساسي حول ********* EOF ****** و ****** EIP 4844 ***** مناقشة ، مع الاستمرار في الترويج لـ **** EIP 4844 ***** حفل الإعداد المسبق المطلوب لحفل ****** KZG ****** ، سيكون المطورون في ********* 23 ** **** السنة **** 1 **** شهر تم التأكيد رسميًا على الترقية **** 4844 **** ستظهر في ***

• في 22 نوفمبر ، تم ذكر EOF أو proto-danksharding في المكالمة الجماعية رقم 149 لجميع مطوري Ethereum الأساسيين في هذا الوقت ، لا يزال المطورون يفكرون في وضعها في ترقية Shanghai ؛
• في اجتماع طبقة الإجماع في 2 و 22 ديسمبر ، ترينت ، رئيس النظام البيئي Ethereum قام Van Epps بتحديث برنامج EIP 4844 التقدم المحرز في تنفيذ حفل الإعداد الموثوق به المطلوب لإنشاء ملف رمز الحماية المستخدم في 4844. سيارة نقل تأمل Epps أن يكون الحفل واحدًا من أكبر الحفل على الإطلاق في مجال العملات المشفرة ، حيث سيجمع ما بين 8000 و 10000 مساهمة. وستستمر فترة المساهمة العامة للحفل حوالي شهرين وستبدأ في وقت ما في ديسمبر ؛
• في اجتماع المطورين الأساسيين في نفس اليوم ، كان هناك بعض النقاش حول EOF وإلغاء تنشيط رمز التشغيل الذاتي. اعترض مطور من مؤسسة Ethereum على تأجيل EOF إلى كانكون ، بحجة أنه إذا لم يتم تضمين تغييرات الكود في شنغهاي ، هل ستكون إمكانية دخول كانكون صغيرة جدًا ، فيما يتعلق برمز التدمير الذاتي ، فهناك مطورون يدافعون عن تطوير برنامج EIP في ذلك الوقت 4758 ، ولكن تعطيل كود التشغيل هذا بشكل مباشر سيؤدي إلى كسر بعض التطبيقات ، ويعتقد المطور أنه يجب وزن برنامج EIP هذا مرة أخرى لفترة من الوقت قبل إنشاء حالة حافة لحماية هذا النوع من العقود ؛
• في اجتماع المطورين الأساسيين في 9 ، 22 ديسمبر ، تم الترويج لتنفيذ حفل KZG فيما يتعلق بترقية كانكون ، و EIP الحالي 4844 حفل الإعداد الموثوق به جاهز ؛
• في اجتماع طبقة الإجماع في 16 ، 22 ديسمبر ، حول برنامج EIP 4844 ، ناقش المطورون دمج طلبين مختلفين للسحب (PRs) في المواصفات الخاصة بـ proto-danksharding ، أحدهما يتعلق بكيفية تعامل العقد مع توافر البيانات بعد نقطة معينة بعد تقليم البيانات ، والآخر عندما يتم تقديم رموز خطأ جديدة للكتلة للتنبيه العقد عندما تكون المعلومات الخاصة بالنقاط مفقودة
• خلال اجتماع التطوير الأساسي في 5 يناير 23 ، توصل المطورون إلى إجماع لإزالة تعديلات الكود المتعلقة بتنفيذ EOF من ترقية شنغهاي ، اقترحت Beiko في هذا الوقت أن تقرر بعد أسبوعين ما إذا كان يجب تضمين EOF في كانكون قيد الترقية ؛

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

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

• في اجتماع المطورين الأساسيين في 20 ، 23 يناير ، تم نقل EOF إلى كانكون للترقية ؛
• في اجتماع المطورين الأساسيين في 6 ، 23 مارس ، كان الاقتراح الأولي لترقية كانكون هو: EIP 4788 (جذر حالة سلسلة المنارة العامة) ، EIP 2537 (تنفيذ عمليات بكفاءة مثل التحقق من توقيع BLS والتحقق من SNARKs) و EIP-5920 (يقدم كود التشغيل الجديد PAY) و EIP تطبيق مشترك لـ 6189 (لجعل SELFDESTRUCT متوافقًا مع أشجار Verkle) و EIP-6190 (تغيير وظيفة SELFDESTRUCT لإحداث عدد محدود فقط من تغييرات الحالة) ؛
• في اجتماع المطورين الأساسيين في 16 و 23 مارس ، باستثناء EOF و EIP 4844 ، تم النظر في المقترحات التالية للإدراج في كانكون: تنسيق SSZ ، حذف SELFDESTRUCT ، EIP 2537 ، EVMMAX ، EIP

1153. تعليمات غير محدودة من SWAP و DUP ، وإدخال رموز الدفع وجذور حالة المنارة في EVM ؛

• في اجتماع المطورين الأساسيين في 30 مارس 23 ، تم طرح اقتراح EIP-6780 بشأن تعطيل SELFDESTRUCT لأول مرة ، وهو أيضًا اقتراح لتعطيل SELFDESTRUCT الذي قررت كانكون أخيرًا استخدامه. لكن فيما يتعلق بتنفيذ EOF ، من Erigon (EL) قال مطور من فريق العميل EOF “الكثير من التغيير” للتنافس مع EIP لاقتراح تحسين Ethereum في ترقية Cancún القادمة 4844 ، كان هناك اقتراح لتنفيذ EOF في هارد فورك بعد وقت قصير من ترقية كانكون ؛

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

في **** 23 ************ 4 ****** شهرًا ، هناك اتجاه واضح للمقترحات التي ينبغي تغطيتها من خلال ترقية كانكون ، والعقد الرئيسية في **** 4 *********************************************** **************************************************** *********** برنامج EIP ****** و ********* tim ****** أجرى أيضًا مناقشة أكثر تعمقًا حول المقترحات البديلة ، في ********* 4 ****** month ** في الاجتماع يوم **** 27 ******، ****** EIP 6780 ****** 、 ****** EIP 6475 ***** و ****** EIP تم تحديد 1153 ***** ليتم تضمينها في كانكون ، وفي نفس الوقت ********* EOF ****** و **** EVMMAX ****** (مع * تمت إزالة ***** EOF ***** المتعلقة بالتنفيذ ***** EIP ****** المجموعة الفرعية) من ترقية كانكون ، وتساعد ترقية ********* ****** ****** بشكل أساسي ****** ****** EVM يقوم بالتحكم في الإصدار ، ويمكنه تشغيل مجموعات متعددة من قواعد العقد في نفس الوقت ، مما سيساعد في التوسع اللاحق لـ Ethereum ، ولكن مع مراعاة جدوى الترقية بأكملها ، ** * *** EOF ***** قد يتم متابعة الترقية مع الترقية اليومية ***

• ** 23 ******** 4 **** month **** 12 **** ، اكتملت ترقية Ethereum Shanghai ؛ **
• خلال اجتماع التطوير الأساسي في 13.04.23 ، ناقش المطورون خطة EIP 4844 (لفضح البيانات حول جذر حالة CL في EL) ، هناك ما لا يقل عن تسعة برامج EIP أخرى قيد النظر للترقية ، وهي ** EIP 4844 ****، **** SELFDESTRUCT ** ** تمت الإزالة ** (EIP-6780، EIP 4758 EIP 6046 、 EIP 6190） 、 ** EIP 5920 **** 、 **** EIP 1153 **** 、 **** EIP 2537 **** 、 **** EIP 4788 **** 、 **** EVMMAX EIPs ** （EIP 6601 و EIP

6690. ، ** SS التغييرات ** （EIP 6475 、 EIP 6493 、 EIP 6465 、 EIP 6404 و EIP 6466） 、 ** EIP 5656 **** و **** EIP 6193 ** ；

• في اجتماع المطورين الأساسيين في 27 ، 23 أبريل ، تم التركيز على العديد من التقدم والمفاضلات. أولاً ، يستمر تحديد EIP4844 لإدراجها في ترقية كانكون ، مع إضافة برامج EIP التالية: 6780 (يغير وظائف كود التشغيل SELFDESTRUCT) ، EIP 6475 (نوع تسلسل بسيط جديد (SSZ) لتمثيل القيم الاختيارية) ، EIP 1153 (أضف كود تشغيل جديد لحالة التشغيل) ؛ ثانيًا ، EIP الذي يتم النظر فيه ولكن لم يتم تضمينه رسميًا في الترقية هو EIP 6913 (مقدمة تعليمات SETCODE) ، EIP 6493 (تحديد مخطط التوقيع للمعاملات المشفرة بـ SSZ) ، EIP 4788 (كشف جذر كتلة سلسلة المنارة في رأس كتلة EL) ، EIP 2537 (يضيف منحنى BLS12-381 كتجميع مسبق) و EIP 5656 (يقدم تعليمات EVM جديدة لنسخ مناطق الذاكرة) ؛ أخيرًا ، ** EOF ** ** و ** ** EVMMAX **** (** ** EOF ** ** يعتمد التنفيذ ** * * EIP ** ** مجموعة فرعية) من ترقية كانكون. **** EOF ** ** تم نقل الترقية من شنغهاي في مؤتمر مطوري Ethereum في بداية **** 2023 ******** 1 **** ، وتمت ترقيتها لاحقًا من * *** من نهاية **** 1 **** إلى بداية **** 4 **** في 23 **** ، سيظهر في ترقية كانكون افتراضيًا ، ولكن في ** تمت إزالة ** 23 **** **** EOF ** ** مرة أخرى في اجتماع المطور في **** 29 ****، **** 4 ****. **

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

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

• اجتماع إجماع إيثريوم الأساسي في 5/5/23 ، لمناقشة خطة الاستثمار السارية الأخيرة المذكورة 4788 ، أثناء إضافة EIP 6987 و EIP المناقشة في 6475 ، هذان الاقتراحان حول المحققين ومعاملات SSZ على التوالي ؛
• في اجتماع الطبقة التنفيذية 161st Ethereum في 11 و 23 مايو ، تيم قال Beiko أنه لا يزال من الممكن تعديل نطاق ترقية كانكون في الأسابيع القليلة المقبلة ، ولكن بدون نصيحة صريحة من المطورين ، سيظل نطاق ترقية كانكون في الحالة “الافتراضية” ، ويظهر النقاش حول EIP-4844 أن التطوير وافق المؤلف على إزالة SSZ من تطبيق EL لـ EIP-4844 ، ** لكنه لم يؤثر بعد على التقدم المستمر ** ** 6475 ** **. ** بالإضافة إلى ذلك ، ناقش المطورون أيضًا بإيجاز اثنين من برامج EIP للنظر فيها في كانكون ، وهما EIP 6969 （EIP

1559. و EIP 5656 (تعليمات EVM فعالة لنسخ مناطق الذاكرة) ؛

• تمت مناقشة التطورات في 4844 بإيجاز في اجتماع إجماع المطورين في 18-May-23 ، مثل السماح لتطبيقات العقود الذكية على EL بالتحقق من إثبات حالة CL ؛
• تمت مناقشة إلغاء تنشيط SELFDESTRUCT ، وتغييرات مواصفات EIP-4844 ، وإدارة كود التشغيل ، وإضافات كانكون النهائية المحتملة في الاجتماع 162 Ethereum Core في 25 مايو 2023. تيم توصي شركة Beiko بأن تقتصر المحادثات المستقبلية حول توسيع نطاق كانكون على خمس برامج EIP التالية: ** EIP-5920 **** ، **** 5656 **** ، **** 7069 **** ، * ** * 4788 ** ** و ** ** 2530 . سيؤكد المطورون في الأسابيع القليلة المقبلة ** ** Dencun **** ( Deneb

• النطاق الكامل لـ Cancun ****) ؛ **

• في الاجتماع رقم 110 لطبقة توافق Ethereum في 1 يونيو 2023 ، قدم باحث من مؤسسة Ethereum نتائج تجربة بيانات حول قدرة عقد Ethereum mainnet على نشر كميات كبيرة من البيانات. ومن هذه النتيجة ، اقترح الباحث أن EIP تمت زيادة مواصفات 4844 من 4 نقاط كحد أقصى إلى 6 نقاط لكل كتلة. في الوقت نفسه ، يفكر المطورون في EIP 4788 المدرجة في ترقية كانكون ؛
• في اجتماع المطورين الأساسي في 13 يونيو 2023 ** أكد المطورون رسميًا نطاق الترقية ، بما في ذلك **** EIP 4844 **** 、 **** EIP 1153 **** 、 **** EIP 5656 **** 、 **** EIP 6780 **** 、 **** EIP 4788 **** ； **
• في الاجتماع الإجماعي في 15 يونيو 2023 ، تمت مناقشة أي خطط EIP مركزة على CL لتضمينها في Deneb ، ومن بينها EIP-6988 و EIP-7044 و EIP-7045 التي تم اقتراح إضافتها ، ووافق فريق عميل CL إلى ما يلي شبكة اختبار EIP-4844 Devnet6 ستختبر العدد المتزايد من النقاط وتتخذ قرارًا نهائيًا بشأن هذه المسألة في غضون أسبوعين ، بينما باحث مؤسسة Ethereum Michael اقترح Neuder إزالة غطاء Staking 32 ETH للمساعدة في تقليل نمو مجموعة المدقق النشطة ؛
• في الاجتماع الذي عقد في 22 يونيو 2023 ، اقترح تيم نقل العنوان المترجم مسبقًا 4844 إلى 0xA ، وتعبئتها ونقل BLS إلى عنوان آخر ، على الرغم من الترجمة مسبقًا عبر EIP 2537 ، ولكن لن يتم النظر فيه في كانكون ؛
• في اجتماع الإجماع في 29 يونيو 2023 ، واصل المطورون مناقشة عدد النقاط ، مما حد من النقطة المستهدفة تمت الزيادة من 2 إلى 3 ، وزيادة الحد الأقصى للنقاط الثنائية الكبيرة من 4 إلى 6 ، و 4844 اختبار شبكة Devnet

7 قريبا.

هذه الحياة

• المحتوى الأساسي هو EIP 4844 ， 即 Proto-Danksharding
• نطاق EIP النهائي لترقية كانكون هو: ** EIP 4844 **** 、 **** EIP 1153 **** 、 **** EIP 5656 **** 、 **** EIP 6780 **** 、 **** EIP 4788 **. وفي الوقت نفسه ، في الاجتماع 111 لشركة Ethereum ACDC في 19 يونيو ، واصل المطورون مناقشة ** EIP 6988 **** 、 ** ** EIP 7044 **** 、 **** EIP 7045 ** للتضمين في ذنب. قال المطورون إنهم يخططون لدمج EIPs الثلاثة المذكورة أعلاه في مواصفات Deneb في الأسابيع المقبلة.

** تحليل ** مفتاح **** EIP ******

** EIP 4844 **

• مقدمة:
• اسم اقتراح EIP4844 هو Proto-Danksharding ، وهو البروتوكول المسبق للنسخة الكاملة لتوسيع التجزئة Danksharding. تستند المجموعة الكاملة لمخططات التجزئة في الواقع إلى Rollup للتوسع على السلسلة. ** الغرض من البرنامج هو توسيع ** ** 2 ** ** layer ** ** Rollup —— **** من خلال مساعدة **** L2 **** في خفض الرسوم وزيادة الإنتاجية ، بينما يمهد الطريق للتجزئة الكاملة (**** التجزئة ****). **
• في المكالمة الجماعية التي ستعقد في 23 فبراير ، سيقوم مطورو Ethereum ببرنامج EIP تمت تسمية ترقية 4844 باسم Deneb ، وهو اسم نجم من الدرجة الأولى في كوكبة Cygnus ، وهو EIP على إصدار GitHub ذي الصلة في المستقبل سيتم تحديث تسمية 4844 إلى Deneb ؛ في الاجتماع الذي سيعقد في 1 يونيو 23 ، ستكون هناك بعض التغييرات في مواصفات الترقية التالية لـ Ethereum ، والتي تسمى Deneb على جانب CL وكانكون على جانب EL ؛
• في اجتماع المطورين في 23 يونيو ، استعد المطورون لتحديث برنامج EIP العنوان المترجم مسبقًا 4844. حاليًا ، أضاف المطورون الأساسيون 9 مجموعات مسبقة إلى EVM وسيقومون بتنشيط EIP بواسطة 4844 و 4788 إنشاء جهازي تجميع مسبق تحت عناوين “0xA” و “0xB” على التوالي. في اجتماع الإجماع في 29 يونيو ، أصبحت EIP جاهزة للانطلاق 4844 شبكة اختبار مخصصة قصيرة المدى Devnet

7。

• ** EIP-4844 **** يقدم نوع معاملة جديد تمامًا - **** Blob Transcation ****。 **
• ملف تعريف Blob:
• Blob ، على غرار حزمة البيانات الإضافية ، 128 فقط في البداية مساحة تخزين KB ، في بداية مناقشة الاقتراح ، كان الهدف والحد الأقصى لـ Blob هو 2/4 ، وتم تعديله إلى 3/6 في اجتماع المطورين في 9 ، 23 يونيو. وهذا يعني أن كل معاملة في Ethereum يمكن أن تحمل ما يصل إلى ثلاث معاملات Blob ، أي 384 KB ، الهدف من كل كتلة سعة النقطة 6 ، أي 768 KB ، والتي يمكنها حمل ما يصل إلى 16 نقطة ، أي 2 ميغا بايت ؛
• قد يكون له تأثير معين على استقرار الشبكة ، لكن فريق تطوير Ethereum قرر إجراء الاختبار أولاً لتجنب الحاجة إلى شوكات صلبة لاحقة لتوسيع كتلة blob.
• ** Blob ** ** in ** ** KZG التزام التجزئة ** ** باعتباره ** ** Hash **** ، يُستخدم للتحقق من البيانات ، تشبه الوظيفة ** ** Merkle ** ** ؛ **
• تقوم العقدة بمزامنة النقطة على السلسلة بعد المعاملة ، ستنتهي صلاحية جزء البيانات الثنائية الكبيرة ويتم حذفها بعد فترة زمنية ، وتكون مدة التخزين ثلاثة أسابيع.
• وظيفة Blob - ** تحسين **** TPS **** من Ethereum ، مع تقليل التكاليف **
• في الوقت الحالي ، يبلغ إجمالي حجم البيانات في Ethereum بالكامل حوالي 1 تيرابايت فقط ، ويمكن أن يجلب Blob 2.5-5 تيرابايت من حجم البيانات الإضافي إلى Ethereum كل عام ، وهو ما يتجاوز بكثير دفتر الأستاذ نفسه بعدة مرات ؛
• بالنسبة للعقد ، لن يؤدي تنزيل 1 ميجابايت إلى 2 ميجابايت إضافية من بيانات blob لكل كتلة إلى عبء عرض النطاق الترددي ، وستؤدي مساحة التخزين فقط إلى زيادة المقدار الثابت لبيانات blob بحوالي 200 ~ 400 جيجابايت شهريًا ، وهو ما لن يؤثر على لا مركزية عقدة Ethereum بأكملها ، ولكن تم تحسين التوسع حول Rollup بشكل كبير ؛
• في الواقع ، لا تحتاج العقدة نفسها إلى تخزين جميع بيانات blob ، لأن blob عبارة عن حزمة بيانات مؤقتة ، لذلك في الواقع ، تحتاج العقدة فقط إلى تنزيل كمية ثابتة من البيانات لمدة ثلاثة أسابيع.
• ** دور EIP-4844 **** - لفتح الفصل الأول من سرد **** Danksharding **** **
• ** توسع عالي السعة: ** في الوقت الحالي ، يمكن لـ EIP-4844 توسيع سعة L2 مبدئيًا. يمكن للإصدار الكامل من Danksharding توسيع حجم بيانات Blob في EIP-4844 من 1 ميجابايت إلى 2 ميجابايت إلى 16 ميجابايت إلى 32 ميجابايت ، مما يضمن اللامركزية والأمان أثناء تحقيق توسع أعلى ؛
• ** رسوم منخفضة: ** يُظهر محللو بيرنشتاين أن تقنية Proto-dank-sharding يمكن أن تخفض رسوم شبكة الطبقة 2 إلى 10-100 ضعف المستوى الحالي ؛
• ** البيانات الفعلية **:
• نشرت شبكة اختبار Opside 4844 ، والتي يمكن أن تقلل من تكلفة التجميع بنسبة 50 ٪ وفقًا للملاحظات الحالية ؛
• لا يكشف الحل التقني DA من EigenLayer عن الكثير لتقييم بياناته ؛
• بالمعنى الدقيق للكلمة ، ليس لدى Celestia علاقة تذكر بـ Ethereum ، ولا يمكن تقييم تكلفة DA الخاصة بها الآن ، اعتمادًا على حلولها التقنية المحددة ؛
• يتمثل حل Ethstorage في تحميل شهادة تخزين Layer2 الخاصة بها ، وقد يتم تخفيض تكلفة DA الخاصة بها إلى 5٪ من الأصل ؛
• تتوقع Topia خفض التكلفة بمقدار 100 ~ 1000 مرة ، لأن شبكة Danksharding الرئيسية تحتاج أيضًا إلى مراعاة الأمان والتوافق مع بث شبكة Layer 1 P2P.
• ** DA **** الحل: **** Danksharding **** (حل تجزئة لتوسيع Ethereum) في الوقت الحالي ، إذا استمر التوسع ، فقد يكون عبء العقدة كبيرًا جدًا (**** 16 ميغابايت **** أعلاه) وتوافر بيانات غير كافٍ (**** 30 **** صلاحية). حل: **
• أخذ عينات توافر البيانات (البيانات توفر العينات) - يقلل العبء على العقد
• قص البيانات الموجودة في Blob إلى أجزاء بيانات ، واترك العقدة تتغير من تنزيل بيانات Blob إلى التحقق العشوائي من أجزاء بيانات Blob ، بحيث تتناثر أجزاء بيانات Blob في كل عقدة من Ethereum ، ولكن بيانات Blob الكاملة هي المخزنة في دفتر الأستاذ في Ethereum بالكامل ، الفرضية هي أن العقد يجب أن تكون كافية وغير مركزية ؛
• يستخدم DAS تقنيتين: رمز المحو (Erasure الترميز) والالتزام متعدد الحدود KZG (KZG التزام)؛
• Proposer-Packager Separation (PBS) —— حل مشكلة تقسيم عمل العقد ، والسماح للعقد ذات التكوين العالي الأداء أن تكون مسؤولة عن تنزيل جميع البيانات لتوزيع الترميز ، والسماح للعقد ذات التكوين المنخفض الأداء أن تكون مسؤولة عن التحقق الفوري.
• يمكن للعقد ذات التكوين العالي الأداء أن تصبح بناة. يحتاج البناة فقط إلى تنزيل بيانات البيانات الثنائية الكبيرة للترميز وإنشاء الكتل ، ثم البث إلى العقد الأخرى لإجراء فحوصات موضعية. بالنسبة للمُنشئين ، نظرًا لأن حجم بيانات المزامنة ومتطلبات النطاق الترددي عالية ، أن تكون مركزية نسبيًا ؛
• يمكن أن تصبح العقدة ذات التكوين المنخفض الأداء مقدمًا (مقدم العرض) ، ويحتاج مقدم العرض فقط للتحقق من صحة البيانات وإنشاء رأس الكتلة وبثها (Block Header) ، ولكن بالنسبة لمقدم الطلب (مقدم العرض) ، فإن حجم بيانات المزامنة ومتطلبات النطاق الترددي منخفضة ، لذلك ستكون لا مركزية.
• قائمة مكافحة الرقابة (crList) - تحل المشكلة التي يمكن أن يتجاهلها القائمون على الحزم عمدًا بعض المعاملات ويقومون بفرز وإدراج المعاملات التي يرغبون في الحصول عليها بشكل عشوائي من MEV نظرًا لقدرتهم المفرطة على المراجعة.
• قبل أن يقوم المنشئ (Builder) بحظر معاملات الحزم ، سينشر مقدم العرض (Proposer) أولاً قائمة مقاومة للمراجعة (crList) ، والتي تحتوي على جميع المعاملات في mempool ؛
• يمكن للمُنشئ (Builder) فقط اختيار حزم المعاملات وفرزها في crList ، مما يعني أنه لا يمكن للمُنشئ إدخال معاملته الخاصة للحصول على MEV ، ولا يمكنه رفض أي معاملة عمدًا (ما لم يكن Gas الحد ممتلئ) ؛
• بعد التعبئة ، يبث المنشئ الإصدار الأخير من قائمة المعاملات إلى مقدم العرض ، ويحدد مقدم العرض إحدى قوائم المعاملات لإنشاء رأس الكتلة (Block Header) والبث ؛
• عندما تقوم العقدة بمزامنة البيانات ، فإنها تحصل على رأس الكتلة من مقدم العرض (مقدم الاقتراح) ، ثم تحصل على نص الكتلة من أداة التجميع (منشئ) ، للتأكد من أن كتلة الكتلة هي النسخة النهائية المحددة.
• PBS مزدوج الفتحة - يحل مشكلة الحزم المركزية التي أصبحت أكثر مركزية من خلال الحصول على MEV
• استخدم وضع المزايدة لتحديد الكتلة:
• ينشئ المنشئ (Builder) رأس الكتلة لقائمة المعاملات بعد الحصول على crList والعطاءات ؛
• يختار مقدم العرض (مقدم العرض) رأس الكتلة والمنشئ (المنشئ) الذي قدم عرضًا أخيرًا بنجاح ، ويتلقى مقدم العرض دون قيد أو شرط رسوم العطاء الفائز (بغض النظر عما إذا تم إنشاء كتلة صالحة) ؛
• تؤكد لجنة التحقق (اللجان) رأس الكتلة الفائزة ؛
• يكشف المنشئ عن جسم الكتلة الفائزة ؛
• تؤكد لجنة التحقق (اللجان) على هيئة الكتلة الفائزة وتجري تصويتًا للتحقق (إذا تم تمرير الكتلة ، فسيتم إنتاج الكتلة ، وإذا لم يقم المعبئ عن عمد بإعطاء كتلة الكتلة ، فسيتم اعتبار الكتلة على أنها غير موجود).
• معنى:
• أولاً وقبل كل شيء ، يتمتع المنشئ (Builder) بقدرة أكبر على حزم المعاملات ، لكن crList المذكورة أعلاه تحد أولاً من إمكانية إدخال المعاملات مؤقتًا ، وثانيًا ، إذا كان المنشئ (Builder) يريد الربح عن طريق تغيير ترتيب المعاملات ، ثم يحتاج إلى دفع الكثير من تكاليف المزايدة في البداية للتأكد من أنه يمكنه الحصول على تأهيل رئيس الكتلة ، ثم سيتم تخفيض ربح MEV الذي يحصل عليه ، وبشكل عام سيكون له تأثير على الوسائل والقيمة الفعلية الحصول على MEV ؛
• ومع ذلك ، في المرحلة المبكرة ، قد يصبح عدد قليل من الأشخاص فقط من الحزم (بالنظر إلى مشكلات أداء العقدة) ، في حين أن معظم الأشخاص يصبحون فقط مقدمين ، مما قد يؤدي إلى مزيد من المركزية. وفي نفس الوقت ، يكون عدد الحزم نفسه كبيرًا جدًا صغير في حالة ، من المرجح أن يقدم بعض عمال المناجم ذوي الخبرة الذين يتمتعون بقدرات MEV عطاءات بنجاح ، مما سيؤثر على تأثير حل MEV الفعلي بشكل أكبر ؛
• له بعض التأثير على بعض حلول MEV باستخدام مزادات MEV.
• معنى:
• ** EIP 4844 ** ** في الواقع إصدار مبسط للغاية ** ** Danksharding ****: ** يوفر نفس واجهة التطبيق مثل Danksharding ، بما في ذلك كود تشغيل جديد يسمى Data تجزئة ؛ وكائن بيانات جديد يسمى ثنائي كائنات كبيرة ، أي Blob ؛
• ** proto-danksharding ** ** يُستخدم لتنفيذ ** ** Danksharding ** ** المواصفات “قوس” ** ** (**** هو تنسيق المعاملة وقواعد التحقق ****) * * ** الاقتراح **: ومع ذلك ، لم يتم تنفيذ أي تجزئة حتى الآن ، ولا يزال يتعين على جميع المدققين والمستخدمين التحقق مباشرة من توفر البيانات الكاملة ؛
• ** لماذا يختار المنظور طويل المدى ** ** proto-danksharding ** ** ليس ** ** EIP 4488 ** ** يقلل بشكل مباشر من رسوم ** ** layer2 ** ** ، لأنه لا يلزم سوى تعديل بسيط عند الترقية إلى جزء كامل في المستقبل **:
• EIP يتمثل الاختلاف العملي الرئيسي بين 4488 و proto-danksharding في أن EIP-4488 يحاول تقليل التغييرات التي يحتاجها Ethereum اليوم ، بينما يقوم proto-danksharding بإجراء المزيد من التغييرات على Ethereum اليوم من أجل الترقية إلى Ethereum في المستقبل. مطلوب لتقسيم النسخة الكاملة ؛
• على الرغم من أنها مهمة معقدة للغاية لتحقيق التجزئة الكاملة (مع أخذ عينات توفر البيانات ، وما إلى ذلك) ، ولا يزال هناك الكثير من العمل الذي يتعين القيام به بعد تنفيذ التقسيم الأولي ، سيتم التحكم في هذه التعقيدات على طبقة الإجماع. بمجرد نشر proto-danksharding ، لن يحتاج فريق عميل طبقة التنفيذ ومطورو التحديثات والمستخدمون إلى القيام بأي عمل إضافي للانتقال إلى التجزئة الكاملة.
• ** لتحقيق التجزئة الكاملة ، من الضروري إكمال التنفيذ الفعلي ** ** PBS **** ، وإثبات التفويض وأخذ عينات توفر البيانات ، ولكن هذه التعديلات ستتركز في ** ** CL ** * * طبقة ، ليست هناك حاجة للمطورين لإعادة ضبط **: يقوم 4844 حاليًا بتنفيذ نوع معاملة جديد ، وهو بالضبط نفس تنسيق المعاملة ، ومنطق التحقق المتبادل المتفق عليه ، ومنطق طبقة التنفيذ المطلوب في الجزء الكامل ، وأيضًا المشتقة من النقط ، وتسعير الغاز المستقل ذاتي الضبط ، من أجل تحقيق التجزئة الكاملة في المستقبل ، من الضروري إكمال التنفيذ الفعلي لـ PBS ، وإثبات التفويض وأخذ عينات توفر البيانات ، ولكن هذه التعديلات موجودة فقط في طبقة CL ، و لا تطلب من مطوري الطبقة أو التراكمية التعديل ، وهو أمر مناسب للتطوير بواسطة.

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

**تدمير الذات إزالة ** ** EIP-6780 **** ： ** X

• خلفية:
• في 21 مارس ، اقترح فيتاليك أن ضرر SELFDESTRUCT أكثر من نفعه لبيئة Ethereum. والسبب الرئيسي هو أنه الوحيد الذي يمكنه تغيير عدد لا حصر له من كائنات الحالة في كتلة واحدة ، مما يؤدي إلى تغييرات في رموز العقود ، ويمكن استخدامه بدون موافقة الحساب.يمكنه تعديل رمز تشغيل رصيد الحساب ، والذي ينطوي على مخاطر خفية كبيرة في أمان Ethereum ؛ **
• الطريقة الوحيدة لإزالة عقد على السلسلة هي SELFDESTRUCT. إذا قمت باستدعاء وظيفة التدمير الذاتي في العقد ، يمكنك تدمير العقد ذاتيًا. سيتم إرسال Ethereum المخزنة في العقد إلى العنوان المصمم. ستتم إزالة متغيرات الكود والتخزين المتبقية في جهاز الحالة. في الواقع ، يبدو إجراء تدمير العقد جيدًا من الناحية النظرية ، لكنه في الواقع خطير للغاية. على الرغم من أن وظيفة ** selfdestruct **** يمكن أن تساعد المطورين على حذف العقد الذكي وتحويل الرصيد في العقد إلى العنوان المحدد في حالة الطوارئ ، يتم استخدام هذه الميزة أيضًا من قبل المجرمين ، مما يجعلها وسيلة للهجوم. **
• في الاجتماع الأساسي للمطورين في 13 و 23 أبريل ، تم تقديم أربعة مقترحات حول SELFDESTRUCT للمشاركة في المناقشة ، وهي 6780 و 4758 و 6046 و 6190 ، و EIP اللاحقة. تم تعيين 6780 كاقتراح نهائي.
• مقدمة: التدمير الذاتي هو زر الطوارئ للعقد الذكي ، والذي يؤدي إلى إتلاف العقد وتحويل الـ ETH المتبقي إلى الحساب المخصص.
• EIP 6780: تعطيل SELFDESTRUCT ما لم تكن في نفس المعاملة في العقد.
• تحديث: في 26 مايو ، اقترح تيم إضافة رمز تشغيل آخر - SETCODE ، بالإضافة إلى إزالة SELFDESTRUCT ، للسماح بتحديث الحسابات الآلية. (أي تمت إضافة وظيفة التحديث ، ويتم تحديث الخاصية في العقد الذكي عن طريق التحديث / الترقية) ، هنا هو امتصاص EIP مزايا 4758 ، والتي يمكن أن تعطي مساحة للترقية.

• السبب: تطلبت معالجة رمز SELFDESTRUCT في الأصل تغييرات شاملة في حالة الحساب ، مثل حذف جميع الرموز والتخزين. يشكل هذا صعوبة في استخدام أشجار Verkle في المستقبل: سيتم تخزين كل حساب في العديد من مفاتيح الحساب المختلفة التي لن يتم ربطها صراحةً بحساب الجذر.
• تم التغيير: يقوم برنامج EIP هذا بتنفيذ تغييرات لإزالة SELFDESTRUCT ، باستثناء الحالتين التاليتين
• ستظل التطبيقات التي تُستخدم فقط لـ SELFDESTRUCT لسحب الأموال تعمل ؛
• لا يلزم تغيير SELFDESTRUCT المستخدم في نفس المعاملة في العقد.
• الأهمية: ** زيادة الأمن **
• في السابق ، كان هناك عقد على الشبكة الرئيسية يستخدم SELFDESTRUCT لتقييد من يمكنه بدء المعاملات من خلال العقد ؛
• منع المستخدمين من الاستمرار في إيداع الأموال والتداول في الخزنة بعد SELFDESTRUCT ، فقد يتسبب هذا الخزانة في قيام أي شخص بسرقة الرموز المميزة في الخزنة أثناء الاستخدام المتكرر.

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

• EIP-4758 ** (DEPRECATED) **: قم بتعطيل SELFDESTRUCT عن طريق تغيير SELFDESTRUCT إلى SENDALL ، والذي يعيد جميع الأموال إلى المتصل (يرسل كل الأثير الموجود في الحساب إلى المتصل) ، لكنه لا يحذف أي رمز أو مساحة تخزين.
• السبب: كما هو مذكور أعلاه ، تطلبت المعالجة السابقة لرمز SELFDESTRUCT تغييرات واسعة في حالة الحساب ، مثل حذف جميع الرموز والتخزين. يشكل هذا صعوبة في استخدام أشجار Verkle في المستقبل: سيتم تخزين كل حساب في العديد من مفاتيح الحساب المختلفة التي لن يتم ربطها صراحةً بحساب الجذر.
• يتغير:
• تمت إعادة تسمية رمز التشغيل SELFDESTRUCT إلى SENDALL ، والآن يقوم فقط بنقل جميع ETH في الحساب إلى المتصل ، ولم يعد هذا النظام يدمر الكود والتخزين ، أو يغير أرقامًا عشوائية ؛
• تم حذف جميع المبالغ المستردة المتعلقة بـ SELFDESTRUCT
• معنى:
• تم الحفاظ على الوظيفة الأصلية مقارنةً بـ EIP-6780 ، لأن بعض التطبيقات لا تزال / تحتاج إلى استخدام رمز SELFDESTRUCT.
• EIP-6046 ** (مهمل) **: استبدل SELFDESTRUCT بـ DEACTIVATE. غيّر SELFDESTRUCT لعدم حذف مفتاح التخزين واستخدم قيمة خاصة في حساب nonce للإشارة إلى التعطيل
• السبب: كما هو مذكور أعلاه ، مع شجرة Verkle ، سيتم تنظيم الحسابات بشكل مختلف: سيكون لخصائص الحساب (بما في ذلك التخزين) مفاتيح منفصلة ، ولكن سيكون من المستحيل اجتياز جميع المفاتيح المستخدمة والعثور عليها. تطلبت معالجة أكواد SELFDESTRUCT سابقًا تغييرات واسعة في حالة الحساب ، مما يجعل من الصعب جدًا الاستمرار في استخدام SELFDESTRUCT في أشجار Verkle.
• يتغير:
• قم بتغيير القواعد التي أدخلها EIP-2681 بحيث يتم تقييد الزيادة العادية في nonce بـ 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 (عنوان العقد ، nonce)) عند العنوان. الرقم العشوائي دائمًا هو 2 ^ 64-1.
• إذا تم إتلاف العقد ذاتيًا بعد إعادة توجيه المكالمة من خلال عقد اسم مستعار واحد أو أكثر ، فقم بتعيين فتحة التخزين 0 لعقد الاسم المستعار على العنوان المحسوب في الخطوة 2 ؛
• سيتم تحويل رصيد العقد بالكامل إلى العنوان الموجود أعلى المكدس ؛
• ظهر الجزء العلوي من المكدس.
• معنى:
• مصمم للسماح لـ SELFDESTRUCT بتشكيل أشجار Verkle لاحقًا مع الحد الأدنى من التغييرات ؛
• زادت تكلفة الغاز مع تطبيق EIP-2929.

*** يتبعه ****** EIP 1153 ****** ، مع توفير ****** ****** ****** الغاز ، مما يمهد الطريق لتصميم التخزين في المستقبل ***

** EIP 1153 ** X

• موجز: أكواد تشغيل المتجر العابر ، أضف أكواد التشغيل لمعالجة الحالة التي تتصرف مثل المتاجر ولكنها تتجاهل بعد كل معاملة.
• سبب:
• يمكن أن يؤدي إجراء معاملة في Ethereum إلى إنشاء العديد من إطارات التنفيذ المتداخلة ، كل إطار تم إنشاؤه بواسطة تعليمات CALL (أو تعليمات مماثلة). يمكن إعادة إدخال العقود في نفس المعاملة ، وفي هذه الحالة ينتمي أكثر من إطار واحد إلى عقد واحد.
• حاليًا ، يمكن لهذه الإطارات الاتصال بطريقتين: الإدخال / الإخراج عبر تعليمات CALL وعبر تحديثات المتجر. يعتبر الاتصال عبر I / O غير آمن إذا كان هناك إطار عمل وسيط ينتمي إلى عقد آخر غير موثوق به.
• مع إعادة الدخول قفل كمثال ، لا يمكن الاعتماد على الإطارات الوسيطة لتوصيل حالة القفل: اتصال SSTORE من خلال التخزين SLOAD مكلف ، والتخزين المؤقت هو حل مخصص وفعال للغاز لمشكلة الاتصال بين الإطارات.
• تم التغيير: تمت إضافة رمزين تشغيل جديدين ، TLOAD (0xb3) و TSTORE (0xb4) ، إلى EVM.
• التخزين المؤقت خاص بالعقد الذي يمتلكه ، تمامًا مثل التخزين الدائم ، يمكن فقط لإطار عقد المالك الوصول إلى التخزين المؤقت. عند الوصول إلى التخزين ، تصل جميع الإطارات إلى نفس التخزين المؤقت بنفس طريقة التخزين الدائم ، ولكن بشكل مختلف عن الذاكرة.
• حالات الاستخدام المحتملة:
• العودة قفل؛
• عناوين CREATE2 القابلة للحساب على السلسلة: تتم قراءة معلمات المُنشئ من عقد المصنع ، بدلاً من تمريرها كجزء من تجزئة رمز التهيئة ؛
• الموافقة على معاملة واحدة على EIP-20 ، على سبيل المثال #tporaryApprove (العنوان منفق ، مبلغ uint256) ；
• عقد رسوم التحويل: ادفع رسومًا لعقد الرمز المميز لفتح التحويلات أثناء المعاملات ؛
• وضع “حتى”: يسمح للمستخدم بتنفيذ جميع الإجراءات كجزء من رد الاتصال ، والتحقق مما إذا كانت “حتى” متوازنة في النهاية ؛
• البيانات الوصفية لاستدعاء الوكيل: قم بتمرير بيانات وصفية إضافية لتنفيذ العقود دون استخدام بيانات الاتصال ، مثل قيم معلمات مُنشئ الوكيل الثابت.
• معنى:
• ** وفر ** ** غاز ** ** ، مع أبسط ** ** غاز ** ** قواعد فوترة ؛ **
• ** حل مشكلة الاتصال بين الإطارات ؛ **
• ** لا تغير دلالات العمليات الحالية ؛ **
• ** لا حاجة لمسح خزان التخزين بعد الاستخدام ؛ **
• ** تصميمات التخزين المستقبلية (مثل ** ** Verkle ** ** الأشجار) لا تحتاج إلى النظر في المبالغ المستردة للتخزين الفوري. **

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

** EIP 4788 **** ： ** X

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

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

** EIP 5656 ** X

• مقدمة: MCOPY

• تعليمات نسخ الذاكرة.

• التحديث: 09.06.23 ، ذكر فريق التطوير أنه تم تقسيمهم في البداية على MCOPY لأنه بينما تم حل المشكلة الأمنية ، كانوا لا يزالون قلقين بشأن إضافتها إلى نطاق التطبيق + اختبار النطاق الترددي المطلوب للترقية ، لكنهم وافقوا أخيرًا على تضمين EIP ، ولكن سيتم النظر في إزالتها إذا واجه المطور مشكلات في السعة في الاختبار أو من جانب العميل. لذلك ، فإن ** MCOPY **** في حالة تم تضمينها مؤقتًا في ترقية كانكون. **
• تم التغيير: توفير تعليمات EVM فعالة لنسخ مناطق الذاكرة.
• الأهمية: نسخ الذاكرة عملية أساسية ، ولكن هناك تكلفة لتطبيقها على جهاز EVM.
• مع توفر تعليمات MCOPY ، يمكن نسخ كلمات وجمل الكود بشكل أكثر دقة ، مما سيزيد من أداء نسخ الذاكرة بحوالي 10.5٪ ، وهو أمر مفيد للغاية لمختلف العمليات الحسابية المكثفة ؛
• سيكون مفيدًا أيضًا للمترجمين لإنشاء رمز ثانوي أكثر كفاءة وأصغر ؛
• يمكن أن يوفر قدرًا معينًا من تكاليف الغاز المُجمَّع مسبقًا للهوية ، لكنه لا يمكنه في الواقع تعزيز تنفيذ هذا الجزء.

** القائمة المختصرة **** EIP **

في **** 23 ************ 6 ****** month ****** 15 ****** ، تمت مناقشة اجتماع إجماع المطورين في *** الذي **** EIP ****** المتمحور حول ********* CL ****** مدرجة في *** Deneb ****** ، حيث **** ** EIP 6988 ****** 、 ****** EIP 7044 ****** 、 ****** EIP 7045 *** *** مقترح للانضمام. ***

** EIP 6988 **** ： ** X

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

** EIP 7044 **** ： ** X

• ملخص: التأكد من أن مخارج المدقق الموقعة صالحة بشكل دائم.
• الأهمية: يمكن أن تحسن تجربة الرواد إلى حد معين.

** EIP 7045 **** ： ** X

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

** حذف تحليل **** EIP ******

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

** EVMMAX EIPs **** ： **

• موجز: يهدف EVMMAX إلى زيادة المرونة في العمليات الحسابية وخطط التوقيع على Ethereum. يوجد حاليًا مقترحان من EVMMAX ، أحدهما مع EOF والآخر بدون EOF.
• EIP 6601: ملحقات حسابية معيارية EVM (EVMMAX)
• التغيير: هو EIP 5843 التكرارات ، مع EIP الفرق 5843 هو:
• يقدم 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 ؛
• يسمح بالتجميع المسبق modexp كعقد EVM ؛
• يقلل بشكل كبير من تكلفة التحقق من ZKP في وظائف التجزئة الجبرية (مثل MiMC / Poseidon) و EVM.
• EIP 6690 ：
• التغيير: EIP-6990 هو اقتراح مقتبس من EIP-6601 لتقديم عمليات حسابية معيارية محسّنة إلى EVM دون الاعتماد على EOF. بينما يتطلب EIP-6601 EIP-4750 و EIP-3670 كعناصر تابعة ، يوفر EIP-6990 حلاً أكثر استقلالية. يوفر نهجًا أكثر بساطة عن طريق إزالة التبعية على EOF.
• الأهمية: يحتفظ بالوظائف الأساسية لـ EIP-6601 ، والتي يمكنها إجراء عمليات حسابية معيارية محسنة على وحدات فردية تصل إلى 4096 بت ، ويسمح هذا التبسيط بتنفيذ واعتماد أكثر كفاءة ، مع الاستمرار في توفير الفوائد المرتبطة بمزايا EIP-6601.

** EOF التغييرات **** ： **

• مقدمة: EOF عبارة عن ترقية إلى EVM ، والتي تقدم معايير تعاقدية جديدة وبعض أكواد التشغيل الجديدة.الرمز الثانوي EVM التقليدي (الرمز الثانوي) هو تسلسل تعليمات غير منظم (غير منظم تسلسل التعليمات) bytecode. يقدم EOF مفهوم الحاوية ، والذي يطبق كود بايت منظم. تتكون الحاوية من رأس وعدة أقسام لهيكلة الرمز الثانوي. بعد الترقية ، سيتمكن EVM من التحكم في الإصدار وتشغيل مجموعات متعددة من قواعد العقد في نفس الوقت.
• EIP 663
• موجز: تعليمات SWAP و DUP غير المقيدة
• الأهمية: من خلال تقديم تعليمتين جديدتين: SWAPN و DUPN ، والتي تختلف عن SWAP و DUP عن طريق زيادة عمق المكدس من 16 عنصرًا إلى 256 عنصرًا
• EIP 3540
• مقدمة:
• في الماضي ، لم يكن كود EVM الثانوي الذي تم نشره على السلسلة بهيكل محدد مسبقًا ، ولم يتم التحقق من الكود إلا قبل تشغيله في العميل. هذه ليست تكلفة غير مباشرة فحسب ، بل تمنع المطورين أيضًا من تقديم الميزات أو الميزات القديمة المهملة.
• يقدم برنامج EIP هذا حاوية يمكن توسيعها والتحكم في إصدارها لـ EVM ، وتعلن تنسيق عقد EOF. وبناءً على ذلك ، يمكن التحقق من الرمز عند نشر عقد EOF ، أي الإنشاء يعني التحقق من صحة الوقت أنه يمكن منع نشر العقود التي لا تتوافق مع تنسيق EOF. يطبق هذا التغيير التحكم في إصدار EOF ، والذي سيساعد في تعطيل تعليمات EVM الحالية أو تقديم وظائف واسعة النطاق (مثل استخراج الحساب) في المستقبل .
• معنى:
• يُفضي التحكم في الإصدار إلى إدخال وظائف جديدة أو إهمالها في المستقبل (مثل إدخال تجريد الحساب) ؛
• يعد فصل رمز العقد والبيانات مفيدًا للتحقق من المستوى الثاني (المرجع السابق) ، مما يقلل من تكلفة الغاز لمدققي المستوى 2. وفي الوقت نفسه ، يعد فصل رمز العقد والبيانات أكثر ملاءمة لعمل تحليل البيانات على السلسلة أدوات.
• EIP 3670
• مقدمة: استنادًا إلى EIP-3540 ، الغرض هو التأكد من أن رمز عقد EOF متوافق مع التنسيق وصالح ، وسيتم منع نشر العقود التي لا تتوافق مع التنسيق دون التأثير على Legacy bytecode
• الأهمية: استنادًا إلى الحاوية التي تم تقديمها بواسطة 3540 ، يضمن EIP-3670 أن الكود الموجود في عقد EOF صالح أو يمنع نشره. هذا يعني أنه لا يمكن نشر أكواد التشغيل غير المحددة في عقود EOF ، والتي لها فائدة إضافية تتمثل في تقليل عدد إصدارات EOF التي يجب إضافتها.
• EIP 4200
• مقدمة:
• تقديم رموز التشغيل الأولى الخاصة بـ EOF: RJUMP و RJUMPI و RJUMPV ، والتي تشفر الوجهات كقيم فورية موقعة. يمكن للمجمعين استخدام أكواد تشغيل JUMP الجديدة هذه لتحسين تكلفة الغاز عند نشر وتنفيذ JUMP لأنها تلغي الحاجة إلى أكواد تشغيل JUMP و JUMPI الحالية للقيام بأقصى سرعة وقت التشغيل المطلوب للتحليل. هذا برنامج EIP ديناميكي إضافة القفز.
• مقارنة بعمليات JUMP التقليدية ، يتمثل الاختلاف في أن عمليات مثل RJUMP لا تحدد موضع إزاحة معين ، ولكنها تحدد موضع إزاحة نسبي (من ديناميكي يقفز -> يقفز ثابت) ، لأن عدة مرات ثابتة القفزات كافية.
• الأهمية: تحسين الشبكة وتقليل التكاليف.
• EIP 4750
• خذ وظيفة 4200 خطوة إلى الأمام: من خلال تقديم CALLF يطبق رمزي التشغيل الجديدين و RETF حلاً بديلاً للموقف لا يمكن استبداله بـ RJUMP و RJUMPI و RJUMPV ، بحيث لم تعد هناك حاجة لـ JUMPDEST في عقد EOF ، لذلك يُحظر الديناميكي القفز。
• الأهمية: تحسين الكود عن طريق تقسيم الكود إلى عدة أجزاء.
• EIP 5450 ：
• الخلفية: لا تزال الخلفية مفادها أن عقد Ethereum لا يتم فحصه عند نشره ، ويتم إجراء سلسلة من الفحوصات فقط عند تشغيله ، سواء أكان المكدس قد تجاوز (الحد الأعلى هو 1024) ، وما إذا كان الغاز كافيًا ، وما إلى ذلك وهلم جرا.
• المحتوى: تمت إضافة فحص صلاحية آخر لعقود EOF ، هذه المرة حول المكدس. يمنع برنامج EIP هذا المواقف التي قد يتسبب فيها نشر عقد EOF في تدفق المكدس أو تجاوزه (المكدس التدفقات السفلية / الفائضة). بهذه الطريقة ، يمكن للعملاء تقليل عدد عمليات التحقق من الصلاحية التي يقومون بها أثناء تنفيذ عقود EOF.
• الأهمية: هناك تحسن كبير يتمثل في جعل هذه الفحوصات التي تحدث أثناء التنفيذ قليلة قدر الإمكان ، وتحدث المزيد من الفحوصات عند نشر العقد.

*** 5 ****** شهر ****** 26 ******************************** **************************************************** **************************************** 4844 ****** تغيير نوع المعاملة ذات الصلة من ****** SSZ ****** إلى ****** RLP ****** يعني أن كانكون هما ****** SSZ برامج EIPs ****** ، لذلك ****** EIPs تم نقل 6475 ****** و **** 6493 ****** خارج كانكون للترقية ***

** EIP 6475 ** X

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

** EIP 6493 ** X

• مقدمة: مخطط توقيع معاملات SSZ. يحدد EIP هذا مخطط توقيع للمعاملات المشفرة بالتسلسل البسيط (SSZ) وسيتناول كيفية تعامل العقد مع أنواع معاملات blob المنسقة بتنسيق SSZ على CL ولكن تم ترميزها بشكل مختلف على EL. يعد برنامج EIP هذا جزءًا من تحديث لتنسيق تسلسل Ethereum من أجل الاتساق عبر الطبقات ؛
• الخلفية: SSZ التغييرات
• مقدمة: بسيطة SerialiZe ، هي طريقة التسلسل المستخدمة في سلسلة المنارة.
• SS تشمل التغييرات أيضًا ثلاثة مقترحات داعمة أخرى ، هذه المرة تم تقديم 6465 فقط.
• EIP 6465: جذر انسحاب SSZ ، يحدد Merkle-Patricia الموجودة ارتحال التزامات Trie (MPT) إلى عمليات انسحاب التسلسل البسيط (SSZ) ؛
• EIP 6404 / EIP 6466
• كلاهما يحدد Merkle-Patricia الموجودة وعود Trie (MPT) في طور الانتقال إلى التسلسل البسيط (SSZ).
• EIP-6404

• جذر معاملة SSZ

• EIP-6466

• أساس استلام SSZ

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

** EIP 5920 **** ： ** X

• مقدمة: كود الدفع. يقدم كود التشغيل الجديد PAY لتحويلات Ethereum ، والذي يرسل Ether إلى عنوان دون استدعاء أي من وظائفه.
• السبب: في الوقت الحالي ، يتطلب إرسال ether إلى عنوان أن يقوم المستخدم باستدعاء وظيفة على هذا العنوان ، والتي بها عدة مشاكل:
• أولاً ، يفتح متجهًا لهجمات إعادة الدخول ، حيث يمكن للمتلقي معاودة الاتصال بالمرسل ؛
• ثانيًا ، يفتح ناقل DoS ، لذلك يجب أن تدرك الوظيفة الرئيسية أن جهاز الاستقبال قد ينفد من الغاز أو رد الاتصال ؛
• أخيرًا ، يعد كود التشغيل CALL مكلفًا بشكل غير ضروري لعمليات النقل البسيطة للإيثر ، لأنه يتطلب توسيع الذاكرة والمكدس ، وتحميل البيانات الكاملة للمستقبل ، بما في ذلك الكود والذاكرة ، وأخيراً يحتاج إلى إجراء مكالمة ، وربما القيام بأشياء أخرى بدون قصد.
• يتغير:
• تم تقديم كود تشغيل جديد: (PAY) PAY \ _OPCODE حيث:
• انبثاق قيمتين من المكدس: addrthen val.
• نقل وي من val عنوان التنفيذ إلى عنوان العنوان. إذا كان العنوان هو صفر ، فسيتم برمجة valwei من عنوان التنفيذ.
• المزالق المحتملة: سيتم استخدام العقود الحالية بشكل مستقل عن الرصيد الفعلي لمحفظتهم ، حيث من الممكن بالفعل إرسال ether إلى عنوان دون الاتصال به.
• المعنى: ** حفظ ** ** غاز ****. **
• التحديث: 09.06.23 تمت إزالة PAY من الترقية بسبب مخاوف بشأن الآثار الجانبية المحتملة لطريقة نقل ETH ، والمنطق والاختبار والعمل الأمني المطلوب لتمرير الاقتراح.

** EIP 7069 ** X

• مقدمة: تعليمات CALL معدلة
• تم التغيير: تم تقديم ثلاثة تعليمات مكالمة جديدة ، CALL2 و DELEGATECALL2 و STATICCALL2 ، والتي لها تأثير على تبسيط الدلالات. يهدف إلى إزالة إمكانية ملاحظة الغاز من التوجيه الجديد وفتح الباب أمام فئة جديدة من العقود التي لا تتأثر بإعادة التسعير.
• خلفية:
• قاعدة 63/64: حدد عمق المكالمة وتأكد من أن المتصل لديه غاز متبقي لإجراء تغييرات الحالة بعد عودة المستدعى ؛
• قبل إدخال القواعد 63/64 ، كان من الضروري إجراء حساب أكثر دقة للغاز المتوفر لدى المتصل. لدى Solidity قاعدة معقدة تحاول تقدير التكلفة من جانب المتصل لتنفيذ المكالمة نفسها من أجل تعيين قيمة غاز معقولة.
• ** نقدم حاليًا **** 63/64 ** ** القواعد: **
• فحص عمق المكالمة المحذوفة ؛
• تأكد من الاحتفاظ بما لا يقل عن 5000 غاز قبل تنفيذ السلوك المطلوب ؛
• تأكد من توفر 2300 غاز على الأقل للسلوك المطلوب.
• قواعد الدعم: مثل الدعم المعروف 2300 ، عندما يستدعي العقد عقدًا آخر ، سيحصل العقد المطلوب على 2300 يتم استخدام الغاز لأداء عمليات محدودة للغاية (يكفي لإجراء القليل من العمليات الحسابية وإنشاء سجل ، ولكن ليس بما يكفي لملء فتحة التخزين) ، وبما أنه يحدد كمية ثابتة من الغاز ، فلا توجد طريقة للأشخاص لتحديد هذه على أنها طالما أن سعر الغاز يمكن تعديله ما نوع الحسابات التي يمكن أن يدعمها الغاز؟
• الأهمية: ** يمهد الطريق لإدخال ** ** EOF ** ** في المستقبل ، وهو أكثر ملاءمة لتشغيل العقود الكبيرة. **
• اختيار الغاز المزال: التوجيهات الجديدة لا تسمح بتحديد الغاز حد ، ولكن الاعتماد على “قاعدة 63/64” (تشير بشكل أساسي إلى إعادة تسعير الغاز لعدد كبير من عمليات الإدخال والإخراج في EIP-150 ، مما يزيد من استهلاك الغاز لعمليات معينة) للحد من الغاز. هذا التحسين المهم يبسط العملية حول قاعدة “Allowance” ، بغض النظر عما إذا تم إرسال القيمة أم لا ، لا يحتاج المتصل إلى إجراء حسابات متعلقة بالغاز ؛
• بعد تقديم الاقتراح الجديد ، يمكن للمستخدمين دائمًا التغلب على Out عن طريق إرسال المزيد من الغاز في المعاملة (بالطبع ، وفقًا لحد أقصى حد للغاز) من خطأ الغاز.
• في السابق عند زيادة تكاليف التخزين (على سبيل المثال ، زاد EIP-1884 من الغاز لبعض رموز التشغيل) ، تم كسر بعض العقود التي أرسلت كمية محدودة من الغاز إلى مكالماتهم بواسطة آلية التكلفة الجديدة. في السابق ، كان لبعض العقود سقف للغاز يحد بشكل دائم من كمية الغاز التي يمكنهم إنفاقها ، حتى لو أرسلوها إلى مكالماتهم الفرعية ، فلن ينجح الأمر ، بغض النظر عن مقدار الغاز الإضافي الذي أرسلوه ، لأن المكالمة ستحد من المبلغ المرسل.
• تمهيد الطريق لإدخال EOF: بمجرد إدخال تنسيق كائن EVM (EOF) ، يمكن رفض تعليمات الاتصال القديمة في عقد EOF ، مما يضمن أنها محصنة إلى حد كبير من تغيرات أسعار الغاز. نظرًا لأن هذه العمليات ضرورية لإزالة إمكانية ملاحظة الغاز ، فستطلبها EOF بدلاً من التعليمات الحالية ؛
• رموز إرجاع أكثر ملاءمة للحالة: تم تقديم وظائف ملائمة تعيد رموز حالة أكثر تفصيلاً: نجاح (0) ، استعادة (1) ، فشل (2) ، ويمكن تمديدها في المستقبل.

** EIP 2537 **** ： ** X

• مقدمة: تجميع مسبق لمعالجة منحنى BLS12-381.
• تم التغيير: تمت إضافة عمليات على منحنى BLS12-381 كما تم تجميعها مسبقًا إلى المجموعة المطلوبة لإجراء التحقق من توقيع BLS بكفاءة وإجراء عمليات التحقق من SNARKs وما إلى ذلك.
• الأهمية: ** يمكن أن تنشئ Ethereum أدلة تشفير أكثر أمانًا وتتيح إمكانية التشغيل البيني بشكل أفضل مع سلسلة الإشارات ****. **

*** العلاقات العامة 3175 *** *** مذكور ولكن ليس في القائمة المختصرة ، لا مزيد من المناقشة ***

** العلاقات العامة 3175 **** ： ** X

• موجز: سيمنع هذا الاقتراح المدققين المعاقبين من اقتراح الكتل عند إلغاء الصفة. إذا تمت معاقبة أكثر من 50٪ من المدققين على السلوك الضار ، فسيظل هؤلاء المدققون قادرين على اقتراح عمليات حظر أثناء الإزالة القسرية من الشبكة. يقول المطورون إن تغيير هذا المنطق هو تغيير طفيف نسبيًا في طبقة CL يوفر الحماية ضد “أوضاع الفشل العالية”.
• وفقًا لاجتماع إجماع مطوري Ethereum الأساسي رقم 108 في 4 مايو ، PR 3175 في طور التهيئة على أنه EIP وسيتم تغييره إلى EIP-6987 ، وذلك لأسباب أمنية لمنع المصادقين المقتطعين من أن يتم انتخابهم كمقترحين للكتلة.

مستقبل

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

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

• مما لا شك فيه أن التوسيع هو الأولوية الأولى (4844) ؛
• تأتي السلامة وتوفير الغاز في المرتبة الثانية (6780 و 1153 و 5656 و 7045) ، مع مراعاة تجربة مطور معينة ؛
• والثالث هو إمكانية التشغيل البيني ، مثل تحسين الاتصال والتواصل وقابلية التشغيل البيني بين dapps (4788 و 7044 و 6988) ؛
• البيانات المتوقعة: testnet 4844 يمكن أن تقلل opside 50٪ من تكلفة التجميع ؛ الحلول التقنية لـ EigenLayer و Celestia لم تكشف كثيرًا ، ولا يمكن تقييم بياناتهما ؛ تقدر Ethstorage أن تكلفة DA ستنخفض إلى 5٪ من الأصل ؛ تتوقع Topia تقليل التكلفة بنسبة 100 ~ 1000 مرة.

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

• طبقة يعتمد الحد الأعلى للأمان البالغ 2 على طبقة DA التي تتبناها.ستفيد Proto-Danksharding من بروتوكول التخزين والبروتوكول المعياري وشبكة توسيع التخزين L1 من خلال تخزين بيانات الحالة الأرخص.
• ** أولاً ، **** Danksharding ** ** يعود إلى جوهر آلة حالة Ethereum **. ذكر V God أن الغرض من بروتوكول إجماع Ethereum ليس ضمان التخزين الدائم لجميع البيانات التاريخية. بدلاً من ذلك ، فإن النية هي توفير لوحة إعلانات في الوقت الفعلي عالية الأمان وإتاحة مساحة للبروتوكولات اللامركزية الأخرى للتخزين على المدى الطويل (ال الغرض من بروتوكول إجماع Ethereum ليس الضمان تخزين جميع البيانات التاريخية إلى الأبد. بدلا من ذلك ، الغرض هو توفر لوحة إعلانات في الوقت الفعلي آمنة للغاية ، وتترك مساحة لها البروتوكولات اللامركزية الأخرى للقيام بالتخزين على المدى الطويل. ） ；
• ** ثانيًا ، يقلل **** Danksharding ** ** من تكلفة **** DA ** ** ، ولكن يلزم أيضًا حل مشكلات وقت الهبوط الفعلي وتوافر البيانات. **
• ** DA **** خفض التكلفة: ** قبل هذا التحديث ، كان من الضروري استدعاء calldata لنشر البيانات من التراكمي إلى سلسلة Ethereum الرئيسية ، وكانت رسوم الغاز للاتصال بهذا الرمز باهظة الثمن ، وهي طبقة أكبر دفعة بقيمة 2 ، EIP يقدم 4844 بيانات blob كمساحة بيانات إضافية فريدة من نوعها للتجميع ، مما سيقلل بشكل كبير من تكاليف التخزين ، وبالتالي تقليل تكاليف DA.
• ** وقت الهبوط الفعلي طويل ، وما زال المحسن ** ** TPS ** ** والمقلل ** ** الغاز ** ** محدودًا ، لذا فهو مناسب لـ ** ** DA ** * * مشاريع طبقات في التطوير المستمر اللاحق: **
• أنا قادر على danksharding في بولينيا في مقالة تقسيم البيانات الأمنية ، تمت الإشارة إلى أن تنفيذ الأمر سيستغرق من 2 إلى 5 سنوات ؛
• ** حتى لو هبطت ، يمكن أن تزيد ** ** TPS ** ** وتقلل ** ** الغاز ** ** لا تزال المقادير محدودة: **
• EIP يدعم 4844 حاليًا 6 نقاط ، ولا يمكن حل مشكلة التوسع المستقبلية إلا عن طريق Danksharding ؛
• تبلغ مساحة كتلة Ethereum الحالية حوالي 200 كيلو بايت. بعد Danksharding ، الحجم المخطط في المواصفات هو 32 ميغا بايت ، وهو حوالي 100 ضعف. في الوقت الحالي ، يبلغ TPS من Ethereum حوالي 15. في الحالة المثالية ، سيكون حوالي 1500 بعد زيادته بمقدار 100 مرة ، وهو ليس تحسنًا كبيرًا في الحجم.
• ** لذلك ، وقت طويل للهبوط ** ** + ** ** ستفيد التغييرات الفعلية المحدودة ** ** DA ** ** مشاريع ذات طبقات ، بعضها مثل **** Celestia **** ، ** ** Eigenda ** ** ** ** DA ** ** المشروع لا يزال بإمكانه تمرير تكلفة أرخص وأسرع ** ** TPS ** ** للتنافس مع ** ** Danksharding ** ** في المستقبل * ، ** تخزين ETH يمكن لمشاريع Topia **** وغيرها من مشاريع **** DA **** الأخرى سد فجوة السوق قبل الهبوط. **
• ** يجب أيضًا معالجة المشكلات الفنية مثل تخزين البيانات وقضايا توفر البيانات: **
• هناك نوعان من التكاليف الرئيسية لـ DA ، أحدهما تكلفة النطاق الترددي للشبكة ، والآخر تكلفة التخزين ، و 4844 نفسه لا يحل مشكلة التخزين ومشكلة النطاق الترددي لسلسلة البلوكشين
• سيتم تخزين blob على طبقة إجماع Ethereum لمدة 3 أسابيع تقريبًا ثم يتم حذفها. إذا كنت تريد تخزين سجلات تاريخية كاملة وإتاحة جميع البيانات ، فإن الحلول الحالية تشمل: dapp نفسه يخزن البيانات المتعلقة بنفسه ، شبكة بوابة Ethereum (قيد التطوير حاليًا) أو بروتوكولات الجهات الخارجية مثل مستكشفات الكتل أو البيانات التاريخية في BitTorrent أو التخزين التلقائي بواسطة المستخدمين الفرديين.
• لذلك ، ستستفيد Proto-Danksharding من بروتوكول التخزين والبروتوكول المعياري وشبكة توسيع التخزين L1:
• سيؤدي الطلب على استدعاء البيانات التاريخية إلى قناة تطوير جديدة لبروتوكولات التخزين اللامركزية أو بروتوكولات فهرس الجهات الخارجية ؛
• يمكن للاتفاقيات المعيارية اللاحقة تنفيذ المعاملات من خلال Rollup عالي السرعة ، وطبقة التسوية الآمنة هي المسؤولة عن التسوية ، وطبقة توفر البيانات منخفضة التكلفة وذات السعة الكبيرة هي المسؤولة عن الضمان ؛
• شبكة توسيع تخزين جيدة L1 ، مثل Eth التخزين ، والذي يمكن أن يوفر حلاً من الدرجة الثانية للتخزين القابل للبرمجة بتكلفة تخزين أقل.

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

• تحليل مسار L2:
• Head Layer2 ، مثل Arbitrum المدار 、 OP المكدس 、 المضلع 2.0 、 كسورية ستستفيد 5 مشاريع بما في ذلك Scaling (في إطار StarkWare) و HyperChain (في إطار zkSync). سيؤدي تخفيض رسوم التخزين الذي يجلبه blob إلى جعل السلسلة السابقة من الطبقة المقيدة 2 تم تحسين مشكلات تكلفة التطوير وقابلية التوسع بشكل كبير ، كما تم تحسين إنتاجية البيانات بشكل كبير. بعد حل مشكلة التكلفة ، تم تحسين طبقة الرأس 2 ستكون هناك فرصة لمواصلة نشر بيئة L3 متزامنة ومتعددة السلاسل ومخصصة للغاية لوظائف محددة ؛
• سيتم تضييق الفجوة في تكاليف التشغيل بين الطبقة الثانية Layer2 و Layer2 السائدة ، مما يمنح بعض المشاريع الصغيرة المزيد من الفرص للتطوير ، مثل Aztec و Metis و Boba و ZKspace و layer2.finance وما إلى ذلك ؛
• على الرغم من أنه لا يزال يتعين التحقق من الاحتياجات الحقيقية لمشروعات blockchain المعيارية ، إلا أن لغات البرمجة المتنوعة لا تزال ممكنة ، مثل لغات سلسلة Starkware’s Cario و Move series و C و c ++ و C # و Go التي تدعمها Wasm ، والتي يمكنها تقديم المزيد من مطوري web2.
• تحليل مسار Raas:
• تكمن ميزة Raas نفسها في درجة التخصيص العالية والمتطلبات المخصصة> التكلفة والكفاءة الخالصة ، لذا فإن خفض التكلفة يعد ميزة كبيرة للتجميع المخصص.
• لكن المشكلة مع مسار RAAS هي أنه قد يكون OverHype ، وهناك شكوك حول مسار RAAS نفسه. ** مواجهة منافسة ** ** 5 ** ** الرؤوس ** ** layer2 ** ** ، ظهور مختلف ** ** DA ** ** جديدة ، يمكن أن تشكل المشاريع الجديدة علينا أن نضع علامة استفهام على المسار. **
• أولاً ، طبقة الرأس 2 تكمن ميزة نشر سلسلة التطبيق في تكامل إطار عمل الشبكة وأمن البيئة بين السلاسل ، وتكمن ميزة RAAS في تخصيصها وحريتها ؛
• ومع ذلك ، فإن الحواجز التقنية RAAS لسلسلة OP و ZK ليست قوية في الوقت الحالي ، ولا تزال في مرحلة الاختبار على المدى القصير ، ولا يوجد تفاعل فعلي مع المنتج. بالنظر إلى التقدم الفعلي لـ RAAS ، والنماذج الفنية و المزايا البيئية للطبقة 3 في المستقبل ، فإن الطلب الفعلي على RAAS مشكوك فيه.
• قسم OP: على الرغم من OP ترقية حجر الأساس المكدس + أدى إطلاق 4844 إلى زيادة طفيفة في التكلفة والكفاءة ، لكن الزيادة ليست جذابة للغاية ؛
• سلسلة ZK: في الوقت الحالي ، تتبع العديد من المشاريع الرائدة مسار ZKEVM وتولي مزيدًا من الاهتمام للتوافق مع Ethereum ، وبالتالي فإن تصميم الدائرة سيضحي بكفاءة معينة ، وهو ليس مستهدفًا مثل سلسلة OP. لكن ZK حاليا في السوق لا تزال معظم RAAS تستخدم المشاريع الرائدة (مثل ZkSync) لتقسيم السلسلة ، ولا تزال الحواجز غير قوية.
• ** SO ، قصير المدى ** OP RAAS ** ** لا يزال هناك مجال للتطوير قبل ** ** layer3 ** ** الأراضي. على المدى الطويل ، ** ** ZK قد يكون RAAS ** ** و ** ** layer3 ** ** هو الاتجاه المستقبلي. **
• ZK RAAS له عيب أكبر في التكلفة بعد 4844 ، ويستهلك طاقة حوسبة أكبر بكثير من OP. على الرغم من أن تكلفة التحميل إلى L1 أقل من تكلفة OP ، إلا أن هذا ليس سوى انخفاض في المجموعة مقارنة بتكلفة عملية الإثبات ، بينما OP الميزة هي أنه يمكن بناء بيئة بسرعة في فترة زمنية قصيرة ، ولا يزال هناك مجال للتطوير قبل أراضي الطبقة 3 ؛
• بالنسبة للتطبيقات التقليدية وأسواق NFT ، لا يعد تحويل التراكمية مطلبًا صارمًا. فقط تطبيقات الدفع أو الألعاب التي تتطلب كفاءة عالية هي التي تتطلب طلبًا أقوى على التجميع. في المستقبل ، قد تكون مشاريع التحدي على المستوى 2 ، وقد تكون المشاريع الاجتماعية على المستوى 3 أو خارج السلسلة ، وأخيراً يتم وضع البيانات والعلاقات الأساسية في المستوى 2. يجب أن تنتقل مشاريع الألعاب إلى المستوى 3 أو التجميع ، ولكن مع الأخذ في الاعتبار أن معظم المشاريع الحالية ألعاب السلسلة هي في الأساس أموال ، وقد أدى عدم قدرة الرموز المميزة على التداول خارجيًا إلى حدوث اختناقات في التنمية ، إلى جانب ظهور الألعاب في السلسلة بأكملها ، فإن الجاذبية البيئية لـ l3 نفسها أكبر بكثير من تلك الخاصة بالتجميع.

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

• يقوم كانكون بترقية الاقتراح الثاني المهم SELFDESTRUCT ستؤدي الإزالة إلى تحسين أمان Ethereum.
• برنامج EIP للاقتراح الثالث لترقية كانكون يضيف 1153 رمز عملية التخزين العابر ، والذي يمكنه أولاً توفير الغاز ، وثانيًا حل مشكلة الاتصال بين الإطارات ، وتمهيد الطريق أخيرًا لتصميم التخزين المستقبلي ، مثل شجرة Verkle ، والتي لن تحتاج إلى النظر في مشكلة استرداد الأموال العابرة تخزين؛
• برنامج EIP للاقتراح الرابع لترقية كانكون يقدم 5656 تعليمات نسخ ذاكرة MCOPY ، والتي يمكنها نسخ كلمات وجمل الكود بشكل أكثر دقة ، مما يحسن أداء نسخ الذاكرة بحوالي 10٪ ؛
• الاقتراح الخامس لترقية كانكون هو EIP 4788 يمكن أن يجعل الاتصال بين البروتوكولات والتطبيقات المختلفة في شبكة Ethereum أكثر كفاءة وأمانًا ، ويسمح أيضًا بمزيد من التصاميم غير الموثوقة لمجموعات التعهدات وبروتوكولات التجسير وإعادة العمل ؛
• تقوم كانكون بترقية أحدث ترقيات EIP المقترحة (15 ، 23 يونيو) CL-centric: EIP 6988 、 EIP 7044 、 EIP 7045 ، والذي يعمل على تحسين أمان وإمكانية استخدام Ethereum بالتفصيل ، مثل تحسين تجربة المتعهدين وتحسين أمان الشبكة.
• من بين المقترحات المحذوفة ، SSZ-> تحول RLP يجعل اثنين من SSZs EIP （EIP 6475 و EIP

6493. من ترقية كانكون ؛ تمت إزالة المقترحات المتعلقة بـ EOF من ترقية كانكون بعد إزالتها من ترقية شنغهاي ، ويُعتبر حاليًا أنه يمكن تنفيذها مباشرةً في الترقية اليومية اللاحقة ؛ EVMMAX يرجع إلى بعض EIPs المتعلقة بالمجموعة الفرعية لتطبيق EOF ، لذلك تم نقلها أيضًا من كانكون للترقية مع EOF ؛ مع الأخذ في الاعتبار الآثار الجانبية المحتملة التي قد تكون موجودة في طريقة نقل ETH ، بالإضافة إلى المنطق والاختبار والعمل الأمني المطلوب لتمرير الاقتراح ، EIP تمت إزالة 5920 من الترقية.

** 5. **** العلاقة مع **** zkml **** وسحب الحساب **

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

• ZKML هو دليل على عدم المعرفة (صفر Knowledge) والتعلم الآلي (Machine التعلم) ؛ يعمل الجمع بين نموذج ** blockchain و ** ML ** ** ** على حل مشكلات حماية الخصوصية وإمكانية التحقق من التعلم الآلي: **
• حماية الخصوصية: سرية بيانات الإدخال ، مثل استخدام كمية كبيرة من المعلومات الشخصية كبيانات لتغذية الجهاز للتدريب ، وسرية المعلومات الشخصية هي مطلب رئيسي ؛ أو معلمات النموذج هي القدرة التنافسية الأساسية للمشروع ، و التشفير مطلوب أيضًا للحفاظ على حواجز المنافسة. عند وجود مثل هذه المشكلات المتعلقة بالثقة ، يتم إعاقة نماذج ML من الحصول على بيانات وتطبيقات واسعة النطاق.
• إمكانية التحقق: تشتمل تقنية إثبات المعرفة الصفرية على مجموعة واسعة من التطبيقات ، ويسمح ZKP للمستخدمين بمعرفة صحة المعلومات دون التحقق. ونظرًا لأن نموذج التعلم الآلي يتطلب الكثير من العمليات الحسابية ، يمكن لنموذج ML إنشاء أدلة من خلال ZK-SNARK ، مما يقلل من حجم الدليل ويخفف من الطلب على طاقة الحوسبة لـ ML.
• متطلبات التخزين ** ZKML ** ** لا علاقة لها ب ** ** DA ** **: ** تحتاج إلى شيء مثل الفضاء التكنولوجيا الأساسية لهيكل التخزين المنفصل هذا هو بروتوكول الأمان الجديد “SQL proof”. ببساطة ، إنه مستودع بيانات بجوار blockchain ، مما يسمح للمطورين بالاتصال على السلسلة وخارج السلسلة بتنسيق SQL بسيط. البيانات و تحميل النتائج مباشرة في العقد الذكي ؛
• ** ZK-SNARKs ** ** هو الشكل الرئيسي لـ ** ** ZK ** ** في ** ** ZKML ** ** ، ويمكن أن يتكيف مع الحساب على السلسلة ** ** ML ** ** مع تطور التشفير ، وخاصةً التكرار **** SNARK ** ** الإثبات سيكون مفيدًا ** ** ZKML ** ** الهبوط على السلسلة: **
• تتميز ZK-SNARKs بالاكتناز العالي. يسمح استخدام ZK-SNARKs للمثقف بإنشاء دليل قصير ، ولا يحتاج المدقق إلى التفاعل ويحتاج فقط إلى إجراء قدر صغير من الحساب للتحقق من صحته. هذا النوع من الإثبات يحتاج مرة واحدة فقط. طبيعة التفاعل بين المدقق والمدقق تجعل ZK-SNARKs فعالة وعملية في التطبيقات العملية ، وهي أكثر ملاءمة لمتطلبات طاقة الحوسبة لـ ML على السلسلة.
• ** من المستحيل حاليًا التدرب على السلسلة ، ويمكن تخزين نتائج الحسابات خارج السلسلة فقط: **
• ترجع مشكلة ML الحالية بشكل أكبر إلى متطلبات طاقة الحوسبة غير المرضية والأداء المنخفض الناجم عن قيود الخوارزمية (لا يمكن حسابها بالتوازي). تتطلب نماذج ZK الكبيرة قدرة حوسبة أعلى ، والتي لا يمكن دعمها على السلسلة. الشائع الحالي تدعم ZK-SNARKs إثبات عدم المعرفة الصفرية لـ ML باستخدام نطاق صغير وكمية صغيرة من الحسابات ، أي أن الحد من قوة الحوسبة هو عامل رئيسي يؤثر على تطوير تطبيقات ZKML blockchain ، ويمكن للسلسلة فقط تخزين نتائج off- سلسلة حسابات.

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

• ** أولاً وقبل كل شيء ، يمكن تقليل ترقية كانكون إلى حد معين ** ** ZK تراكمي ** ** إثبات الرسوم: **
• تعتمد رسوم معاملات zkSync الحالية على 3 جوانب:
• تكلفة الموارد الثابتة التي يستهلكها المدقق لإنشاء أدلة SNARK والتحقق منها مرتفعة نسبيًا ؛
• رسوم الغاز عندما يقدم المدقق إثبات SNARK إلى شبكة Ethereum الرئيسية ، سيزداد هذا الجزء من الرسوم وفقًا لذلك بسبب ازدحام الشبكة الرئيسية ؛
• رسوم الخدمة التي يدفعها المستخدم للمدقق ، بما في ذلك تأكيد المعاملة ، وبث الرسائل ، وما إلى ذلك.
• لذلك ، إذا تم تقديم 4844 ، فسيتم التخفيف من مشكلة زيادة رسوم الغاز الناتجة عن ازدحام الشبكة الرئيسية ، ويمكن تقليل تكلفة إثباتات ZKP إلى حد معين. على الرغم من أنها لا تُقارن كثيرًا بتكلفة البراهين ، بالنظر إلى أن ZK لا يزال في مراحله المبكرة ، لا ينبغي التقليل من اتجاه التطوير المستقبلي لسلسلة ZK.
• ** ثانيًا ، يحول استخراج الحساب المعاملات التقليدية ** ** tx ** ** إلى ** ** تشغيل المستخدم **** ، ثم ** ** عمليات المستخدم ** ** استخدام ** ** ECDSA * * * * معبأة في كتل ، يشغل التخزين على السلسلة أكثر من ذي قبل ، وبالتالي فإن متطلبات التخزين أعلى ؛ **
• ** بعد ذلك ، سحب الحساب و ** ** ZK تراكمي ** ** يمكن أن يكمل كل منهما الآخر: **
• المشكلة الحالية لسحب الحساب هي الغاز الرسوم باهظة الثمن ، لأن هناك الكثير من الخطوات والعقود الذكية متضمنة ، لذلك هناك الكثير من البيانات ، مما يؤدي إلى الغاز الرسوم باهظة الثمن ، و ZK ميزة Rollup هي أنه يمكن أن يقلل البيانات ؛
• يجعل تجريد الحساب من الصعب ضمان الأمان: نظرًا لأن AA تتضمن عقودًا متعددة ، فإن الأمان يمثل مشكلة ، ولكن بعد التكوين التدريجي لـ L2 في المستقبل ، لن يتم تغيير طبقة الإجماع ، وستكون للعقود الذكية المزيد من الاستخدامات ، والأمان يمكن أيضًا ضمان سحب الحساب بمساعدة ZK سيعمل التحقق الموثوق من مجموعة التحديثات على تحسين الأمان.
• ** أخيرًا ، نظرًا لظهور تقنية ** ** AI ** ** ، يمكن أن تساعد في تعزيز أمان العقود عبر السلسلة وتحسين المعاملات أو خطوات النشاط على السلسلة: **
• الذكاء الاصطناعي والأمن: يمكن استخدام تقنية الذكاء الاصطناعي لتعزيز الأمن وحماية الخصوصية للمعاملات عبر السلسلة. على سبيل المثال ، تستخدم منصة الأمان Web3 SeQure الذكاء الاصطناعي للكشف عن الهجمات الضارة والاحتيال وتسرب البيانات ومنعها ، وتوفر آليات للمراقبة والإنذار في الوقت الفعلي لضمان أمن واستقرار المعاملات على السلسلة ؛
• الذكاء الاصطناعي وتحسين الأنشطة على السلسلة: تشمل الأنشطة على blockchain المعاملات وتنفيذ العقود وتخزين البيانات. من خلال قدرات التحليل والتنبؤ الذكية للذكاء الاصطناعي ، يمكن تحسين الأنشطة على السلسلة بشكل أفضل وتحسين الكفاءة والأداء بشكل عام. يمكن أن يساعد الذكاء الاصطناعي في تحديد أنماط المعاملات ، واكتشاف النشاط غير المعتاد ، وتقديم توصيات في الوقت الفعلي لتحسين تخصيص الموارد لشبكات blockchain من خلال تحليل البيانات والتدريب على النموذج.
• ** لذلك ، ستكون ترقية كانكون من توسيع مساحة التخزين إلى التكامل مع ** ** ZK إن تكامل تجميع التحديثات ** ** والاندماج مع تقنية ** ** AI ** ** سيفيدان بشكل تدريجي التطوير المستقبلي لسحب الحساب. **

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

• ** حاليًا ، لا تتمتع **** Layer2 ** ** بأداء (من حيث زمن الانتقال والإنتاجية) مشابه لـ ** ** Solana ** ** ، ولا مثل ** ** قريب ** ** مثل أداء متقطع ، وعدم وجود أداء تنفيذ موازي مثل ** ** Sui ** ** و ** ** Aptos ** ** ، حسنت ترقية كانكون مكانة Ethereum الرائدة كشركة رائدة ؛ **
• ** بعد ترقية كانكون ، تم تقدير عدة أوقات تطوير رئيسية ** ** Danksharding بالكامل **** (**** 2 ~ 5 **** سنة) ، **** MEV ** * * و ** ** PBS **** هبوط (**** 1 ~ 3 **** سنة) ، سحب الحساب (**** 1 ~ 2 **** سنة) ، **** ZK * * * * كل شيء (**** 3 ~ 6 **** سنوات) ، **** EOF **** وتجربة المطور (كم مرة رأيت التمديد؟). **

**ال بلاء **

• الهدف: التركيز على حل مشاكل MEV.
• الحل: قلل MEV في طبقة التطبيق من خلال “Proposer-Builder Separation (PBS)”. في هذا الوقت ، قد يتم تحسين blobs ، وقد يتم تقديم خدمات التأكيد المسبق أو الحماية الاستباقية.
• PBS هو الفصل بين منتجي الكتل والفرازات. عامل الفرز مسؤول فقط عن الفرز ، بغض النظر عن السلسلة ، ولا يهتم منشئ الكتل بالمعاملة ، ويختار مباشرة الحزمة التي أنشأها الفارز ويضعها في السلسلة. ستجعل هذه العملية العملية برمتها أكثر إنصافًا وتخفيف مشاكل MEV ، وهي فكرة إخراج MEV.
• لا تزال درجة إتمام برنامج PBS منخفضة للغاية ، والأكثر نضجًا هم التعاون مع حلول MEV الخارجية - mevboost by flashbots.
• نسخة متقدمة من "Enshrined فصل مقدم العرض ومنشئه (ePBS) "لديه درجة إتمام أقل ودورة أطول ، ومن المقدر أنه لن يتم تنفيذه على المدى القصير. بالإضافة إلى ذلك ، هناك إصدارات تقدمية من PEPC و Optimistic الترحيل ، مما يعزز المرونة والقدرة على التكيف في إطار دعم السلوك الإيجابي

ال حافة

• الهدف: استخدم شجرة Verkel لاستبدال Merkle ، وتقديم حل لتقليل الثقة ، وتمكين العقد الخفيفة من الحصول على نفس الأمان مثل العقد الكاملة ، وجعل التحقق من الكتلة بسيطًا ومحمولًا قدر الإمكان.
• في الوقت نفسه ، تمت إضافة ZKization لـ L1 بوضوح إلى خارطة طريق Verge. سيكون ZK هو الاتجاه العام للتوسع والتسريع في المستقبل ؛
• الحل: تقديم zk-SNARKs لتحل محل نظام الإثبات القديم ، بما في ذلك عملاء الإضاءة المستندة إلى SNARK ؛ SNARKs لتغييرات حالة الإجماع ؛ Enshrined التراكمية。
• تعد أشجار Verkle بديلاً أكثر كفاءة لأشجار Merkle الخاصة بالحالة والتي لا تحتاج إلى توفير مسار من كل عقدة شقيقة (العقد التي تشترك في نفس الأصل) إلى العقدة المختارة ، ولكن فقط المسار نفسه كدليل جزء من Verkle البراهين أكثر كفاءة بثلاث مرات من براهين Merkle.
• مكرس يشير التراكمي إلى تراكم يحتوي على نوع من التوافق في الآراء حول L1. وتتمثل الميزة في أنه يرث إجماع L1 ولا يحتاج إلى رموز حوكمة لإجراء ترقيات مجمعة. وفي الوقت نفسه ، من خلال إجراء عمليات حسابية خارج السلسلة والنشر فقط النتائج إلى blockchain ، يمكن أن تزيد من عدد المعاملات ، لكن الصعوبة التقنية للتنفيذ كبيرة نسبيًا. سيكون الجمع بين هذه المجموعات في المستقبل قادرًا على تلبية معظم احتياجات نظام blockchain البيئي في العقود القليلة القادمة.

ال تطهير

• ال يشير التطهير إلى هدف تبسيط البروتوكول عن طريق تقليل متطلبات التخزين للمشاركة في التحقق من الشبكة. يتم تحقيق ذلك في المقام الأول من خلال السبات وإدارة التاريخ والحالة. سكون البيانات التاريخية (EIP-4444) يسمح للعملاء بتقليم البيانات التاريخية الأقدم من عام واحد والتوقف عن الخدمة على مستوى P2P.
• دولة نائمة. عندما يتعلق الأمر بالتعامل مع نمو الدولة ، هناك هدفان رئيسيان: ضعف انعدام الجنسية ، والذي يشير إلى هدف استخدام الدولة فقط لبناء كتلة ، ولكن ليس التحقق منها ؛ الدولة التي يتم الوصول إليها. يجب أن يقلل وضع الإسبات من الحالة التي تحتاجها العقدة لتخزينها بإجمالي 20-50 غيغابايت。
• في المرحلة الخامسة تطهير EIP تم كتابة 4444 بشكل صريح في Roadmap ، يتطلب EIP-4444 من العميل مسح البيانات الأقدم من عام واحد ، وفي هذه المرحلة لا يزال هناك بعض أعمال تحسين EVM ، مثل تبسيط آلية التجميع المسبق لـ GAS و EVM ، وما إلى ذلك ؛

ال تفاخر

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

** المواد المرجعية: **

• تحديث اجتماع إيثريوم كور ديف:
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 148 اكتب
• إيثريوم جميع المطورين الأساسيين ، اتصل بالرقم 149 اكتب
• إيثريوم دعوة طبقة الإجماع # 99 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 150 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 151 اكتب
• إيثريوم دعوة طبقة الإجماع # 100 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 152 اكتب
• إيثريوم جميع المطورين الأساسيين ution Call # 153 اكتب
• إيثريوم مناقشة منتدى السحرة الأصلي:
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 156 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 157 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 158 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 159 اكتب
• إيثريوم جميع المطورين الأساسيين ution Call # 160 اكتب
• إيثريوم إجماع جميع المطورين الأساسيين ، استدعاء رقم 108 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 161 اكتب
• إيثريوم إجماع جميع المطورين الأساسيين ، استدعاء رقم 109 اكتب
• إيثريوم جميع المطورين الأساسيين اتصل بالرقم 162 اكتب
• إيثريوم إجماع المطورين الأساسيين - استدعاء رقم 110 اكتب
• قام تيم بالتغريد حول أحدث ترقية لـ Ethereum Cancun (09.06.23):
• دعوة إجماع المطورين الأساسيين في Ethereum # 111 اكتب
• إيثريوم إجماع المطورين الأساسيين - استدعاء رقم 112 اكتب
• المحتوى المرتبط بترقية Ethereum:
• مقدمة في كود التدمير الذاتي:
• استكشف اقتراح EVMMAX و BLS12-381
• إلى جانب EIP-4844 ، ماذا ستشمل ترقية كانكون أيضًا؟ نظرة خاطفة على أحدث مكالمة إجماعية لـ Ethereum
• ما هو المحتوى الجديد الذي تمت إضافته في ترقية Ethereum Shanghai؟
• تغريدات:
• نعم المشاريع: بعد ترقية Ethereum Shanghai ، قامت كانكون بترقية فرص الاستثمار المحتملة- أخبار البصيرة
• بالإضافة إلى EIP-4844 رفيع المستوى ، ما هي المقترحات التي ستشملها ترقية كانكون؟
• V God: وظيفة EVM تستحق الدراسة للحذف
• Proto-Danksharding التعليمات
• أوصى به V God فهم متعمق لخارطة طريق Ethereum المبعثرة ، قراءة هذا التقرير كافية
• مقال لفهم Danksharding ، خطة الترقية الجديدة لـ Ethereum
• فك رموز الحقائق المثيرة والأسرار الخفية في أحدث خريطة طريق لشركة Ethereum
• Vitalik: لماذا تضر SELFDESTRUCT أكثر من نفعها لبيئة Ethereum
• رؤية Ethereum:
• بلوكوركس زميل باحث Brrr: كيف يعمل Proto-Danksharding على تسريع L1 في Ethereum قابلية التطوير التراكمي
• الاجتماع 111 لـ Ethereum ACDC: ناقش النطاق النهائي لترقية Deneb وثلاثة مقترحات بما في ذلك EIP-7044
• KOL نظرة خاطفة ستايسي مور على تطور حلول تحجيم Ethereum: OP كومة 、 تعسفي المدار 、 المضلع 2.0
• مقارنة أفقية بين ثلاثة أنواع من التراكمية: التراكمية الكلاسيكية (متفائلة / ZK التراكمية） 、 Enshrined التراكمية 、 السيادية التراكمية
• [AMA] نحن أبحاث إي أف (Pt.8: 07 يوليو ،

2022. ：

• 3 مسارات شهيرة تستحق إعادة النظر في عام 2023
• الجبل الأسود إيدكون أفكار في نهاية عام 2023: نظرة على اتجاهات البنية التحتية والتطبيقات
• الخيال اللانهائي لإمكانية الجمع بين الذكاء الاصطناعي والويب 3
• AI + Web3: استكشاف تكامل الذكاء الاصطناعي و blockchain
• مقارنة zk-rollup و op-rollup: تحليل سبب zkSync الحالي من طريقة التحقق رسوم الغاز مرتفعة
• “إضافة مجلدات إلى مجلدات”: حلول تجريد الحساب في عصر التجميع
• تفسير متعمق لـ ZKML: المبادئ التقنية ، سيناريوهات التطبيق ، المزايا والتحديات
• ZKML: تقنية نشر نموذجية تدمج الذكاء الاصطناعي و blockchain لتحقيق حماية الخصوصية
• iable بيانات الأمان التجزئة
• حوار مع Qi ، مؤسس EthStorage Zhou | توافر البيانات والتخزين اللامركزي
• اقرأ أحدث إصدار من خارطة طريق تطوير Ethereum في مقال واحد
• حول الفضاء و مقدمة موجزة عن الزمن
• الاقتراح الأصلي:
• EIP 4844
• EIP 6780
• EIP 1153 ：
• EIP 5920
• EIP 5656
• EIP 7069 ：
• EIP 4788
• EIP 2537
• EVMMAX EIPs ：
• EIP 6601
• EIP 6990 ：
• EOF التغييرات ：
• EIP 663
• EIP 3540
• EIP 3670
• EIP 4200
• EIP 4750
• EIP 5450 ：
• EIP 6475
• EIP 6493
• العلاقات العامة 3175