مقدمة عن شوكة إيثريوم بيكترا الصلبة

المؤلف: NIC Lin، Medium

من المتوقع أن يطلق شوكة Pectra الصلبة نشر الشبكة الرئيسية في مارس 2025. يتضمن ترقية Pectra 11 بروتوكولًا فنيًا (EIPs)، وهي:

• EIP-2537: التجميع المسبق لعملية منحنى BLS12-381

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

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

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

• EIP-7251: زيادة MAX_EFFECTIVE_BALANCE

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

• EIP-7623: زيادة تكلفة بيانات المكالمة

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

• EIP-7691: زيادة إنتاجية الكائن

• EIP-7702: تعيين رمز حساب EOA

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

البروتوكولات الفنية المتعلقة بالمشاركة

EIP-6110: عملية منحنى BLS12-381 التجميع المسبق

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

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

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

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

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

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

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

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

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

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

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

من خلال تنفيذ البروتوكول الفني EIP-7002، يمكن للمستخدمين استخدام بيانات اعتماد السحب لاستدعاء "عقد السحب" (المنشور في 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) للخروج من التخزين (الخروج) أو سحب الودائع والأرباح (السحب الجزئي)، مما قد يقلل من المخاطر المرتبطة باستخدام خدمات التخزين التابعة لجهات خارجية. إذا شارك المستخدم في المشاركة بمفرده ولكنه فقد مفتاح التحقق، فيمكنه أيضًا استخدام هذا للانسحاب من المشاركة.

• تتضمن المعلمات لبدء الطلب validator_pubkey و amount: validator_pubkey هو مفتاح التحقق (العام) الخاص بالمحقق، و amount هو المبلغ الذي سيتم سحبه.

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

• عند الاتصال بعقد السحب لبدء طلب، يجب إرفاق رسوم الغاز (ETH). سيتم حساب رسوم الغاز بناءً على عدد طلبات السحب الحالية. إذا كان عدد الطلبات كبيرًا، فستزداد رسوم الغاز.

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

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

EIP-7251: زيادة MAX_EFFECTIVE_BALANCE 

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

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

بعد تنفيذ الاتفاقية الفنية EIP-7251، سيظل الحد الأدنى للإيداع (MIN_ACTIVATION_BALANCE) 32 ETH، ولكن سيتم زيادة الحد الأقصى (MAX_EFFECTIVE_BALANCE) بشكل كبير إلى 2048 ETH. يمكنك إيداع أي مبلغ من ETH بين 32 و2048، ويمكنك الحصول على دخل من الإيداع. لم تعد بحاجة إلى سحب الدخل بانتظام. يمكنك الاستمرار في إيداع ETH جديدة بعد تجميع 32 ETH.

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

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

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

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

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

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

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

إنشاء خط أنابيب معلومات رسمي EL -> CL لتسهيل قيام المستخدمين وخدمات التخزين بإرسال الطلبات مباشرة إلى طبقة الإجماع.

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

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

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

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

  (0x00000000219ab540356cbb839cbe05303d7705fa).

• طلب سحب حصة EIP-7002: نوع الطلب=1، ابدأ الطلب من خلال عقد السحب

  (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA).

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

  (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb).

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

EIP-7702: تعيين رمز حساب EOA

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

تعاني حسابات EOA من بعض العيوب في الاستخدام، بما في ذلك:

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

• لا يمكن لحساب EOA سوى إجراء عملية واحدة في معاملة واحدة. على سبيل المثال، إذا كنت تريد استبدال USDT بـ ETH على Uniswap، فيجب عليك أولاً بدء معاملة للموافقة على USDT، ثم إرسال معاملة أخرى لتنفيذ التبادل.

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

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

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

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

• يمكن تنفيذ عمليات متعددة معًا في نفس المعاملة. يمكن إكمال عمليات DApp المعقدة الأصلية بتفويض توقيع واحد ومعاملة واحدة فقط.

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

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

يتمثل اقتراح EIP-7702 في منح حسابات EOA القدرة على التحول إلى حسابات تعاقدية. يوقع المستخدم الرسالة المحولة باستخدام المفتاح الخاص لـ EOA. يتضمن محتوى التوقيع "معرف السلسلة" و"عنوان العقد المحول" و"قيمة Nonce لـ EOA":

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

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

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

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

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

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

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

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

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

عند تحويل حساب EOA إلى عقد وكتابة البيانات في التخزين الخاص به، ما لم يتم حذف البيانات صراحةً، فلن يتم تنسيق البيانات المكتوبة في التخزين لأن حساب EOA يتحول إلى عقد آخر أو يتم إلغاء التحويل. لذلك، يجب على المطورين الانتباه إلى التخزين حتى لا يقرأوا البيانات المتبقية من عقد التحويل السابق. يرجى الرجوع إلى ERC-7201. 4. لا تتضمن عملية EIP-7702 التهيئة

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

• حساب Ithaca الآمن المعدل

• حساب Ithaca

بروتوكول تقنية DApp

EIP-2537: BLS12-381 عملية التجميع المسبق للمنحنى

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

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

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

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

△ يشير كل كتلة إلى كتلة رئيسية، لذلك يمكن إثبات أي كتلة في التاريخ حتى النهاية.

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

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

وبهذه الطريقة، في مثال تحدي الاحتيال Optimismtic Rollup، لا يتعين على المتحدي إثباته كتلة ذاكرة واحدة في كل مرة، ولكن يمكنه إثبات مباشرة أنه في الحالة الحالية لسلسلة كتلة الذاكرة 10000، فإن قيمة تخزين معينة لعقد النظام (المقابل لكتلة الذاكرة 9000) هي قيمة التجزئة لكتلة الذاكرة 9000. إذا تجاوز النطاق 8192، مثل كتلة الذاكرة 1000، ففي أقصى تقدير توجد خطوة واحدة أخرى، أولًا إثبات قيمة التجزئة لكتلة الذاكرة 1808 (= 10000 - 8192)، ثم إثبات قيمة التجزئة لكتلة الذاكرة 1000 في عقد النظام في حالة السلسلة الحالية لكتلة الذاكرة 1808.

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

EIP-7623: زيادة تكلفة بيانات المكالمة

زيادة تكلفة نشر البيانات باستخدام بيانات المكالمة لإنشاء مساحة أمان كافية لزيادة حد الغاز المحظور وعدد الكتل.

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

△ أعرب عدد متزايد من المحققين عن دعمهم لرفع حد الغاز الكتلي.

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

بعد إصدار بروتوكول EIP-7623، سيتم زيادة تكلفة بيانات المكالمة بمقدار 2.5 مرة من "صفر بايت: 4 غاز، بايت غير صفري: 16 غاز" الأصلي إلى "صفر بايت: 10 غاز، بايت غير صفري: 40 غاز". في الأصل، إذا استخدم المهاجم حد الغاز الكتلي (30M) بالكامل لتخزين بيانات القمامة، فإن حجم بيانات كتلة الذاكرة سيكون حوالي 1.79 ميجا بايت (30M / 16)، مقارنة بحجم كتلة الذاكرة المتوسط ​​​​الذي يبلغ حوالي 100 كيلو بايت فقط؛ وإذا تم رفع حد الغاز الكتلي إلى 40M، يمكن للمهاجم إنشاء كتلة ذاكرة بحجم حوالي 2.38 ميجا بايت. عندما يتم زيادة تكلفة بيانات المكالمة بمقدار 2.5 مرة، ستنخفض كفاءة المهاجم إلى الحد الأقصى وهو 0.72 ميجا بايت لـ 30 ميجا بايت و0.95 ميجا بايت لـ 40 ميجا بايت، بحيث يمكن زيادة حد الغاز المحظور وعدد الكتل بثقة أكبر. ومع ذلك، لا يريد هذا البروتوكول الفني التأثير على المستخدمين العاديين الذين "لا يستخدمون بيانات الاتصال لنشر البيانات"، لذلك سوف يحسب إجمالي استخدام Gas للمعاملة بطريقتين ويأخذ الطريقة الأعلى:

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

2. احسب ببساطة استخدام بيانات المكالمة للغاز، ولكن استخدم التكلفة الجديدة: أي احسب بيانات المكالمة على أنها "صفر بايت: 10 غاز، بايت غير صفري: 40 غاز"، ولكن لا تتضمن الغاز المستهلك عن طريق التنفيذ أو الغاز المستهلك عن طريق نشر العقد. لذلك، بالنسبة للمستخدمين الذين "لا يستخدمون بيانات المكالمة لنشر البيانات" (مثل التبادل على Uniswap)، فإن استهلاك الغاز الرئيسي يكون في جزء التنفيذ. حتى إذا تم حساب بيانات المكالمة بالتكلفة الجديدة، فلن تتجاوز الغاز المستهلك عن طريق التنفيذ، لذلك لن يتأثر المستخدمون العامون.

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

EIP-7691: زيادة إنتاجية الكائنات

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

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

بروتوكولات تقنية أخرى

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

ضبط محتوى تصويت المُحقق لتسهيل تجميع الأصوات وتقليل الضغط على شبكة نظير إلى نظير.

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

يقوم EIP-7549 بإزالة معلومات "أي لجنة ينتمي إليها المُحقق" من محتوى التصويت، بحيث يمكن تجميع المُحققين من لجان مختلفة معًا عندما يكون محتوى التصويت هو نفسه، مما يقلل بشكل أكبر من عدد الأصوات المنقولة في شبكة p2p ويقلل الضغط على شبكة p2p.

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

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

يقوم EIP-7840 بإنشاء ملف تكوين للمعلمات المتعلقة بالكائنات في طبقة التنفيذ. يمكن لعقد طبقة التنفيذ قراءة المعلمات المتعلقة بالكائن مباشرة من خلال ملف التكوين هذا دون الحاجة إلى طلب ذلك من عقد طبقة الإجماع.