مقدمة إلى شوكة Ethereum Pectra Hard

المؤلف: نيك لين ، متوسط

من المتوقع أن تبدأ الشوكة الصلبة في البكترا في نشر Mainnet في مارس 2025.تحتوي ترقية Pectra على 11 بروتوكولات تقنية (EIPS) ، وهي:

• EIP-2537: BLS12-381 Curve Operation Precompilation

• EIP-2935: حفظ قيمة تجزئة الكتلة التاريخية في الدولة

• EIP-6110: توفير ودائع التحقق من السلسلة

• EIP-7002: يخرج طبقة التنفيذ

• EIP-7251: تمت إضافة MAX_EFFECTION_BALANCE

• EIP-7549: نقل مؤشر اللجنة خارج التحقق

• EIP-7623: زيادة تكلفة CallData

• EIP-7685: طلب طبقة التنفيذ العامة

• EIP-7691: زيادة إنتاجية النقطة

• EIP-7702: إعداد رمز حساب EOA

• EIP-7840: إضافة خطط Blob إلى ملفات التكوين EL

الاتفاقات الفنية المتعلقة بالتعهد

EIP-6110: BLS12-381 Curve Operation Precompilation

تبسيط عملية المعالجة للمستخدمين للمشاركة في التعهد وتقصير وقت الانتظار بشكل كبير.

تتمثل الطريقة التي يشارك بها المستخدمون في إيداع 32 ETH على طبقة التنفيذ وتسجيلها من خلال سجل الأحداث (سجل الحدث). في الخداع يصبح المدقق.

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

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

△ 10900000 eth1data في كتلة CL ، تجزئة الكتلة المسجلة فيها هي كتلة طبقة التنفيذ 21683339 ، والتي ظهرت قبل 10 ساعات.

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

EIP-7002: حفظ قيمة تجزئة الكتلة التاريخية في الدولة

يمكن استخدامه لتحسين عملية التحقق من التعهد أو سحب الودائع والفوائد ، وتقليل خطر التحقق.

تتطلب المشاركة في التعهد مفتاحين ، وهما مفتاح التحقق من مراقبة وبيانات الاعتماد.

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

إذا فقدت مفتاح المدقق ، فلا يمكن تنفيذ أعمال التحقق ولا يمكن سحب الخداع ؛بالإضافة إلى ذلك ، سيستخدم بعض المستخدمين خدمات جهة خارجية مثل Lido. المدقق.

تنفيذ الاتفاقية الفنية EIP-7002 ، ويمكن للمستخدمين استخدام بيانات اعتماد الانسحاب لاستدعاء “عقد السحب” (أي تم نشرها على 0x0C15F14308530B7CDB84600944BB9CC28B9AAA) للخروج من الودائع (الخروج) أو الدخل (سحب partial) وقلل من استخدام ثلث- حصص الحزب.إذا شارك المستخدم في التعهد بنفسه ولكنه يفقد مفتاح التحقق ، فيمكنه أيضًا استخدام هذا للخروج من التعهد.

• تتضمن المعلمات لبدء الطلب Valitator_PubKey المبلغ: Valitator_Pubkey هو مفتاح التحقق (العام) للمقاومة ، والمبلغ هو الرقم الذي سيتم جمعه.

• يجب أن تكون بيانات اعتماد السحب التي بدأت الطلب هي بيانات الاعتماد السحب لمقحة Valitator_Pubkey.

• عند استدعاء عقد السحب لبدء طلب ، سيتم حساب رسوم الغاز (ETH).

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

ملاحظة: إذا كانت بيانات اعتماد السحب الخاصة بك لا تزال في تنسيق مفتاح BLS العمومي ، تذكر أن تبديله أولاً وقم بتغييره إلى تنسيق عنوان EL.

EIP-7251: تمت إضافة MAX_EFFECTION_BALANCE

يمكن أن يزيد بشكل كبير من الحد الأعلى لمبلغ التعهد لتقليل عدد المدققين ، ويمكن للتحققات التي لا تصل إلى الحد الأعلى تلقائيًا يتمتع بدخل التعهد.

حصص المستخدم لتصبح التحقق من ذلك لتوفير max_ffective_balance مع عدد ETH ، والتي لا يمكن أن تكون أقل أو أكثر (حاليًا MAX_EFFECTIVE_BALANCE هي 32 ETH).إذا كان المستخدم يحمل 1024 ETH ليكون مخادعًا ، فيمكنه المشاركة في الحصة في 32 مرة ، وتمكين 32 من المدققين ، وتشغيل 32 عقد التحقق.وقد أدت المشاركة النشطة لكل شخص في Staking إلى حقيقة أن هناك حوالي مليون صدق وتستمر الزيادة. تعتبر طبقة الشبكة أكثر أهمية ، لأن كل فتحة (كل 12 ثانية) تحتوي على عشرات الآلاف من توقيعات المصادقة التي يتم تمريرها وتجميعها بشكل مستمر في طبقة شبكة P2P.

بعد تنفيذ الاتفاقية الفنية EIP-7251 ، لا يزال الحد الأدنى من التعهد (min_activation_balance) 32 ETH ، ولكن سيتم زيادة الحد الأعلى (MAX_EFFICTION_BALANCE) إلى 2048 ETH. يمكنك الحصول على دخل التعهد.

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

• تتضمن معلمات طلب الإيداع المدمج Source_Pubkey و Target_Pubkey: هاتان المفتاحان هما مفتاحان التحقق من المدقق ، وسيتم دمج التحقق من المصدر في التحقق المستهدف.

• يجب أن تكون بيانات الاعتماد على السحب التي بدأت الطلب هي اعتماد السحب للمؤدي المصدر.

• عند استدعاء عقد الإيداع المدمج لبدء طلب ، يجب إرفاق رسوم المناولة (ETH).

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

ملاحظة: إذا كانت بيانات اعتماد السحب الخاصة بك عبارة عن تنسيق مفتاح BLS العام ، فأنت بحاجة إلى تبديله أولاً وتغييره إلى تنسيق عنوان EL.

EIP-7685: طلب طبقة التنفيذ العامة

إنشاء خط أنابيب IL -& GT الرسمي ؛

يمكن للمستخدمين إرسال الطلبات مباشرة من طبقة التنفيذ إلى طبقة الإجماع ، ويمكن أن تعمل خدمات الاهتمام (مثل LIDO) بطريقة غير مركزية.على سبيل المثال ، طلب الحصول على eip-7002 المذكورة أعلاه وطلب الإيداع الموحد لـ EIP-7251.إذا لم تكن هذه الاتفاقية الفنية متوفرة ، فيجب أن يعتقد مستخدمو Lido أن مزود خدمة Lido سيقوم حقًا بتنفيذ حصة أو دمج إيداع في طبقة الإجماع ؛ .

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

EIP-6110 و EIP-7002 و EIP-7251 جميعهم تتطلب الطلبات بناءً على المعايير المحددة بواسطة EIP-7685:

• eip-6110 انضم إلى طلب التعهد: نوع الطلب = 0 ، من خلال عقد الإيداع

  (0x00000000219AB540356CBB839CBE05303D7705FA) بدء الطلب.

• طلب تعهد الخروج EIP-7002: نوع الطلب = 1 ، من خلال عقد السحب

  (0x0C15F14308530B7CDB8460094BB9CC28B9AAAAA) بدء الطلب.

• طلب إيداع توحيد EIP-7251: نوع الطلب = 2 ، من خلال عقد التوحيد

  (0x00431F263CE400F4455C2DCF564E53007CA4BBBB) يبدأ الطلب.

الاتفاق الفني لتحسين تجربة المستخدم

EIP-7702: إعداد رمز حساب EOA

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

تشمل بعض أوجه القصور التي تستخدم حسابات EOA:

• يجب تسجيل مفاتيح خاصة أو كلمات ذاكرية ، والتي لديها عتبة عالية للمستخدمين الجدد للتسجيل والاستخدام.

• يمكن لمعاملة حساب EOA إجراء عملية واحدة فقط.

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

• بدون آلية الاسترداد ، يمكنك فقط الحفاظ على مفتاحك الخاص أو كلماتك ذات الذكريات بنفسك.

إذا كان حساب عقد ذكي (مثل آمن) ، فيمكن حل جميع المشكلات المذكورة أعلاه:

• يمكن للمستخدمين التوقيع على المفتاح الخاص في شريحة الأمن لهاتفهم المحمول (أو الكمبيوتر).

• يمكن تجميع عمليات متعددة معًا في نفس المعاملة.

• يمكن أن يكون هناك التحكم التفصيلي للغاية ، ويمكن للمستخدمين تفويض أطراف ثالثة للتحكم في حساباتهم الخاصة ، ولكن في نفس الوقت حدد “ما يمكن تفاعل العقد” ، “ما هي العمليات التي لا يمكن تنفيذها” ، “هناك فقط تلك المشاركة في نقل الأصول.

• يمكن إضافة آلية استرداد جديدة ، بحيث يمكن نقل أصول الحساب إلى حساب جديد من خلال آلية الاسترداد عندما تفقد كلماتك المساعد أو الهاتف المحمول أو البريد الإلكتروني.

يتمثل اقتراح EIP-7702 في إعطاء حسابات EOA القدرة على تحويل حسابات العقد.يستخدم المستخدم المفتاح الخاص EOA للتوقيع على الرسالة المحولة.

• معرف السلسلة: يستخدم لمنع توقيع السلسلة A من نقله إلى السلسلة B وإعادة تشغيله.ومع ذلك ، إذا تم ملء معرف السلسلة في 0 ، فهذا يعني أنك على استعداد للتحويل في كل سلسلة.

• عنوان العقد الذي تريده: إذا قمت بملء عنوان عقد آمن ، فسيصبح حساب EOA الخاص بك عقدًا آمنًا ؛ يعود إلى حساب EOA بسيط.

• قيمة nonce من EOA: تستخدم لمنع التوقيعات من إعادة التشغيل.إذا زادت قيمة nonce ، فإن التوقيع الأصلي سيكون غير صالح.

ومع ذلك ، هناك بعض النقاط التي يجب ملاحظة:

1. يمكن أيضًا استخدام المفتاح الخاص EOA

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

2. لا يزال أمن مفاتيح EOA الخاصة

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

3. لن يتم تنسيق تخزين حساب EOA

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

4. لا تشمل عملية EIP-7702 التهيئة

بشكل عام ، تتطلب حسابات العقود خطوة تهيئة ، تتم مزامنة معلومات مالك الحساب (مثل المفتاح العام أو العنوان) عند نشر الحساب ، لتجنب خلعها (Frontrun) ويفقد ملكية الحساب.عادة ما يتم تنفيذ ذلك من خلال عقد المصنع الذي ينشر حساب العقد لأداء “عملية النشر + التهيئة” ، ولكن نظرًا لتغيير EIP-7702 مباشرة ، بدلاً من أن ينشر المصنع العقد إلى EOA ، يمكن للمهاجم نسخ تحويل المستخدم وتوقيعه وإرسال المعاملات أولاً إلى الرابط لتحويل المستخدم ولكن تهيئة الحساب ليتم التحكم فيه من قبل المهاجم ، لذلك يحتاج المطورون إلى الانتباه إلى EIP-7702.طرق الوقاية المحتملة مثل التحقق من توقيع حساب EOA ضمن وظيفة التهيئة ، بحيث حتى لو تم إزالتها ، فلن يتمكن المهاجم من توقيع حساب EOA لإكمال التهيئة.

5. المحفظة تحتاج إلى التحقق من التغييرات

تحتاج المحفظة إلى التحقق من المستخدم ، ووقف الطلب وتحذير من المستخدم عندما يطلب موقع DAPP الخبيث المستخدم لتوقيع معاملة التحول.فيما يلي بعض الأمثلة على تنفيذ عقد التحول:

• حساب آمن من إيثاكا

• حساب إيثاكا

اتفاقية DAPP التقنية

EIP-2537: BLS12-381 Curve Operation Precompilation

جعل تكلفة تطبيق الإثبات على المعرفة الصفرية بناءً على منحنيات BLS أكثر جدوى.

أضافت EIP-2537 العديد من العقود المسبقة (precompile) لتوفير عمليات منحنى BLS الرخيصة ، لذلك سيكون من الممكن تطوير تطبيقات إثبات المعرفة الصفرية بناءً على منحنيات BLS.

EIP-2935: حفظ قيمة تجزئة الكتلة التاريخية في الدولة

اسمح للمطورين أو العقد بقراءة قيمة التجزئة لكتل ​​الذاكرة السابقة مباشرة من تخزين عقد النظام.

إذا احتاج المطور إلى إثبات أن محتوى كتلة الذاكرة السابقة ، على سبيل المثال ، لنفترض أن تحدي الاحتيال في Rollup التفاؤل يجب أن يثبت أن هناك معاملة في 1000 كتل ذاكرة سابقة ، لا يمكن لـ Challenger أن يقولها مباشرة.

“يرجى الاعتقاد بأن هذه الصفقة كانت موجودة بالفعل في 1000 كتل ذاكرة. Block “سلسلة” هي إثبات حظر الذاكرة كتلة واحدة من الذاكرة للأمام حتى يتم الوصول إلى 1000 كتل الذاكرة السابقة ، ثم تثبت أن المعاملة موجودة في كتلة الذاكرة.

△ ستشير كل كتلة إلى كتلة الوالدين ، بحيث يمكنك إثبات أي كتلة في التاريخ على طول الطريق إلى الأمام.

على افتراض أنها حاليًا كتلة ذاكرة بلوقة 10000 ، ويحتاج تحدي الاحتيال إلى تقديم دليل على وجود معاملة X في كتلة ذاكرة بلغ 9000 ، يحتاج Challenger إلى البدء بقيمة التجزئة البالغة 10000 من كتلة الذاكرة التي تثبت أولاً أن الذاكرة الكتلة هي 10000. قيمة تجزئة كتلة الذاكرة الأصل المتصلة 9999 ، ثم تثبت كتلة الذاكرة 9998 … حتى كتلة الذاكرة 9000 ، وأخيرا محتوى كتلة الذاكرة 9000 يحتوي على المعاملة X.

بعد EIP-2935 ، سيكون هناك عقد نظام (تم نشره في 0x0F792BE4B0C0C0CB4DAE440EF133E90C0ECD48CCC) ، وسوف تخزين تخزينه كحد أقصى 8192 قيم هيش الذاكرة السابقة.كلما تم إنشاء كتلة ذاكرة جديدة ، سيتم تحديث عقد النظام تلقائيًا وسيتم كتابة قيمة التجزئة في كتلة الذاكرة السابقة في عقد النظام (سيتم نسخ قيمة التجزئة البالغة 8192 كتل الذاكرة السابقة).

وبهذه الطريقة ، في مثال تحدي الاحتيال على التفاؤل ، لا يتعين على Challenger إثبات ذلك ببطء إلى كتلة الذاكرة السابقة وكتلة الذاكرة ، ولكن يمكن أن تثبت مباشرة أن حالة السلسلة الحالية في كتلة الذاكرة 10000 هي نظام معين العقد.إذا تجاوز النطاق 8192 ، مثل كتلة الذاكرة 1000 ، فإن خطوة واحدة هي إثبات قيمة التجزئة لكتلة الذاكرة 1808 (= 10000 – 8192) ، ثم تثبت أن كتلة الذاكرة 1808 موجودة في حالة السلسلة الحالية ، في عقد العقد النظام قيمة كتلة الذاكرة 1000.

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

EIP-7623 :: زيادة تكلفة CallData

قم بزيادة تكلفة استخدام CallData لنشر البيانات لتحويل مساحة أمان كافية لزيادة عدد الحد من الغاز والباطل.

نظرًا لأن الطلب على بيانات Rollup يصبح أعلى وأعلى ، بعد إدخال النقط في EIP-4844 للسماح لـ Rollup بوضع البيانات بطريقة رخيصة للغاية ، فإن زيادة عدد النقط كانت دائمًا ترقية. من قبل المجتمع لرفع حد غاز الكتلة ، فإنه يعكس الحاجة إلى البيئة لزيادة الموارد.

△ يقول المزيد والمزيد من المدققين إنهم يدعمون رفع حد غاز الكتلة.

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

بعد إطلاق بروتوكول EIP-7623 ، ستزداد تكلفة Calldata بمقدار 2.5 مرة من “صفر بايت: 4 غاز ، بايت غير صفري: 16 غاز” إلى “صفر بايت: 10 غاز ، غير صفري بايت : 40 الغاز “.

في الأصل ، إذا كان المهاجم يستخدم جميع حدود الغاز (30 مترًا) لوضع البيانات غير المرغوب فيها ، كان حجم بيانات كتلة الذاكرة 1.79 ميغابايت (30 م / 16) ، والذي كان حوالي 100 كيلو بايت مقارنة بحجم كتلة الذاكرة ؛ يتم رفع حد الغاز إلى 40 مترًا ، يمكن للمهاجم إنشاء كتلة ذاكرة تبلغ حوالي 2.38 ميغابايت.عندما تتم زيادة تكلفة CallData إلى 2.5 مرة ، ستنخفض كفاءة المهاجم ، مما تصبح بحد أقصى 0.72 ميجابايت و 40 مترًا بحد أقصى 0.95 ميجابايت ، حتى تتمكن من زيادة عدد حد الغاز الكتل والنقام بثقة أكبر.ومع ذلك ، لا يريد هذا الاتفاق التقني التأثير على المستخدمين العاديين الذين “لا يستخدمون CallData لنشر البيانات” ، لذلك سيحسب إجمالي استخدام الغاز للمعاملات بطريقتين ثم يأخذ واحدة أعلى:

1. يتم حساب طريقة حساب غاز التداول الأصلية بتكلفة CallData القديمة: أي ، يتم حساب CallData في شكل “صفر بايت: 4 غاز ، بايت غير صفري: 16 غاز” ، ويتم تنفيذ المعاملة والغاز المستهلك عن طريق نشر العقود.

2. ما عليك سوى حساب كمية غاز Calldata ، ولكن يتم حسابها بتكلفة جديدة: أي حساب CallData في شكل “صفر بايت: 10 غاز ، بايت غير صفري: 40 غاز” ، ولكن لا يحسب الغازات التي تستهلكها بواسطة التنفيذ أو الغاز المستهلك عن طريق نشر العقد. تكلفة جديدة.

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

EIP-7691: زيادة إنتاجية النقطة

زيادة عدد النقط وزيادة مساحة أكبر لنشر البيانات إلى Rollup.

يرفع EIP-7691 عدد النقط من “الهدف: 3 نقاط ، الحد الأعلى: 6 نقاط” إلى “الهدف: 6 نقاط ، الحد الأعلى: 9 النقط” ، إضافة مساحة أكبر لنشر معلومات إلى Rollup.

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

اتفاقيات تقنية أخرى

EIP-7549: نقل مؤشر اللجنة خارج التحقق

اضبط محتوى التصويت على المدقق لجعل الأصوات أكثر ملاءمة لتجميع وتقليل الضغط على شبكة P2P.

سيتم تعيين التحقق عشوائيا لمجموعة من اللجان و

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

يزيل EIP-7549 معلومات “أي لجنة ينتمي هذا التحقيق إلى” من محتوى التصويت ، بحيث يمكن تجميع التحقق من اللجان المختلفة مع نفس محتوى التصويت ، مما يقلل من الأصوات في شبكة P2P. تم تخفيضه إلى ضغط شبكة P2P.

EIP-7840: إضافة خطة blob في ملف تكوين EL

قم بإنشاء ملف إعداد لمعلمات BLOB في طبقة التنفيذ ، مما يلغي مشكلة عقدة طبقة التنفيذ التي تطلب المعلمات المتعلقة بـ BLOB لعقدة طبقة الإجماع.

يتم تخزين المعلمات ذات الصلة BLOB حاليًا في عقد طبقة الإجماع ، ولكن لا تزال عقد طبقة التنفيذ تحتاج إلى هذه المعلمات (مثل RPC eth_feehistory) ، لذلك يجب أن يُطلب منها من عقد طبقة الإجماع.

يقوم EIP-7840 بإنشاء ملف إعداد للمعلمات المتعلقة بالـ Blob في طبقة التنفيذ.

<-style-type>