من المتوقع أن يبدأ Pectra Hard Fork في تنفيذ شبكة الرئيسية في مارس 2025. يتضمن ترقية Pectra 11 بروتوكول تقني (EIP)، وهي على التوالي:
EIP-2537: عمليات منحنى BLS12-381 المُعدّة مُسبقًا
EIP-2935: الاحتفاظ بقيم تجريدية للكتل السابقة في الحالة
EIP-6110: توفير عروض الودائع للمحققين على السلسلة
EIP-7002: تنفيذ طبقة تفجير
EIP-7251: زيادة الحد الأقصى للرصيد الفعال
EIP-7549: نقل فهرس اللجنة خارج التحقق
EIP-7623: زيادة تكلفة calldata
EIP-7685: طلب طبقة التنفيذ العامة
EIP-7691: زيادة كمية استيعاب Blob
EIP-7702: تعيين رمز حساب EOA
EIP-7840: إضافة خطة Blob إلى ملف تكوين EL
البروتوكولات التقنية ذات الصلة بالرهن
EIP-6110: عمليات منحنى BLS12-381 مُعدّة مُسبقًا
تبسيط عملية مشاركة المستخدمين في الرهن، وتقليل الوقت المستغرق في الانتظار بشكل كبير.
الطريقة التي يشارك بها المستخدمون في التخزين هي إيداع 32 ETH على طبقة التنفيذ وتسجيلها بواسطة سجل الأحداث، ثم تقوم طبقة الإجماع بإجراء تحليل سجل الأحداث لتحديد ما إذا كان شخص ما يشارك في التخزين أم لا، ومن ثم يصبح المستخدم الذي يشارك في التخزين مدققا.
ومع ذلك، يحتاج محققو طبقة الاتفاق في البداية إلى تحديد النقطة الزمنية التي يجب أن يتم فيها التوافق، وإلا فسيتبين أن بعض المحققين رأوا 5 إيداعات جديدة، بينما رأى بعض المحققين فقط 3، ولهذا سيصوت محققو طبقة الاتفاق لتحديد أي كتلة تنفيذية (eth1data) يجب الرجوع إليها، لضمان أن الجميع يرى نفس كتلة تنفيذية.
ومع ذلك، في البداية، تم تصميمها لتجنب حدوث أخطاء كبيرة في طبقة التنفيذ تؤدي إلى تشعب السلسلة، لذلك ستكون طبقة البيانات التنفيذية المرجعية (eth1data) عبارة عن كتلة تنفيذية قبل نحو 10 ساعات، لضمان أن لدى مطوري الطبقة الموافقة وقت كافٍ للرد في حالة حدوث أخطاء كبيرة، ومع ذلك، يؤدي هذا أيضًا إلى الحاجة إلى انتظار أكثر من 10 ساعات قبل أن يصبح الرهن فعالًا بأسرع وقت.
!
△ 10900000 eth1data في كتلة CL ، تجزئة الكتلة المسجلة فيها هي 21683339 كتلة طبقة التنفيذ ، والتي ظهرت قبل 10 ساعات.
بعد تنفيذ البروتوكول الفني EIP-6110 ، ستصبح بيانات تعهد المستخدم في العقد جزءا مباشرا من طبقة التنفيذ ، ولأن كتلة طبقة الإجماع نفسها ستحتوي على كتلة طبقة التنفيذ (ولكن ليس eth1data) ، لم يعد مدققو طبقة الإجماع بحاجة إلى النظر في مشكلة "تأكيد أن كتلة ذاكرة طبقة التنفيذ المرجعية هي نفسها" ، طالما تم التصويت على كتلة ذاكرة طبقة الإجماع من قبل أكثر من ثلثي المدققين ، سيتوصل الجميع إلى توافق في الآراء بشأن نفس كتلة طبقة التنفيذ. لذلك ، بعد المشاركة في التعهد ، يمكن للمستخدم الانتظار حتى تكمل كتلة ذاكرة طبقة التنفيذ المعالجة في حوالي 13 دقيقة على أقرب تقدير ، ويمكن لعميل طبقة الإجماع أيضا إزالة المنطق المعقد المستخدم في الأصل لمعالجة بيانات Staking .
EIP-7002: الاحتفاظ بقيم تجزئة الكتل التاريخية في الحالة
يمكن استخدامها لتحسين عملية خروج المحققين من الرهن أو سحب الوديعة والعوائد، وتقليل مخاطر المحققين.
يحتاج المشاركون في الاقتراع إلى مفتاحين ، هما مفتاح المحقق ومصادقة السحب.
مفتاح المحقق يستخدم لمحتوى عمل المحقق، وثيقة السحب تستخدم لخروج المحقق عند الكفالة، وسيتم سحب الوديعة والعوائد إلى العنوان الذي يتم فيه التحقق منه، بالإضافة إلى ذلك، يجب في الوقت الحالي استخدام مفتاح المحقق للخروج عند الكفالة.
إذا فقد مفتاح المحقق، لن يتمكن من القيام بعمل المحقق ولن يتمكن من سحب الإيداع؛ وإذا فُقدت شهادة السحب، سيتم فقدان جميع الودائع والأرباح. بالإضافة إلى ذلك، يستخدم بعض المستخدمين خدمات الوديعة من الطرف الثالث مثل Lido، وعند استخدام هذه المنصات، يجب على المستخدمين الاحتفاظ بشهادة السحب بأنفسهم، بينما يتم الاحتفاظ بمفتاح المحقق من قبل مزود الخدمة وتنفيذ عمل المحقق نيابة عنهم.
بتنفيذ بروتوكول EIP-7002، يمكن للمستخدم استدعاء “Withdrawal Credential” للخروج من الرهن (Exit) أو سحب الضمان والعوائد الجزئية (Partial Withdrawal) من خلال استدعاء “Withdraw” الذي يتم نشره في 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA، مما يمكن أن يقلل من المخاطر المحتملة المتعلقة باستخدام خدمات الرهن من الطرف الثالث. إذا فقد المستخدم مفتاح المحقق بنفسه أثناء المشاركة في الرهن، فيمكنه أيضًا الخروج من الرهن من خلال هذا الأسلوب.
تتضمن معلمات الطلب validator_pubkey و amount: validator_pubkey هو مفتاح محقق Validator (Public)، و amount هو الكمية التي يتم سحبها.
يجب أن يكون إثبات السحب الذي تم إرساله مع الطلب إثبات سحب محقق validator_pubkey.
عند استدعاء عقد السحب لتقديم طلب ، يجب دفع رسوم Gas (ETH) ، وستتم حساب رسوم Gas استنادًا إلى كمية طلبات السحب الحالية ، إذا كانت كمية الطلبات كبيرة ، فسوف ترتفع رسوم Gas.
إذا كانت بيانات اعتماد السحب الخاصة بالمستخدم عبارة عن عقد ، فيمكنك الانتقال إلى عقد السحب للحصول على مبلغ الرسوم الحالي ، ثم بدء طلب وإرفاق الرسوم ؛ ومع ذلك ، إذا كانت بيانات اعتماد السحب عبارة عن حساب EOA ، فلا توجد طريقة للحصول على رسوم دقيقة ، لذلك يمكنك فقط محاكاة خارج السلسلة مقدما ودفع الرسوم الزائدة (التي لن يتم ردها) لضمان تنفيذ الطلب بنجاح.
ملاحظة: إذا كانت بيانات انسحابك لا تزال في تنسيق مفتاح BLS العام، فلا تنسَ تغييرها أولاً وتحويلها إلى تنسيق عنوان EL.
EIP-7251: إضافة MAX_EFFECTIVE_BALANCE
يمكن زيادة الحد الأقصى لمبلغ الرهن بشكل كبير لتقليل عدد المحققين، ويمكن للمحققين الذين لم يصلوا إلى الحد الأقصى تلقي العوائد على الرهن تلقائيًا.
يجب على المستخدم الذي يريد أن يصبح محققًا أن يقدم كمية من ETH تساوي MAX_EFFECTIVE_BALANCE ، لا أقل ولا أكثر (حاليًا MAX_EFFECTIVE_BALANCE هو 32 ETH). إذا كان لدى المستخدم 1024 ETH للرهن ، فيمكنه المشاركة في الرهان 32 مرة ، وتشغيل 32 محققًا ، وتشغيل 32 عقدة محقق. والمشاركة النشطة في الرهان أدت أيضًا إلى وجود حوالي مليون محقق حاليًا وزيادة مستمرة ، وهذا ليس فقط يجعل بيانات حالة طبقة الاتفاق أكبر وأكثر ، بل يزيد من الضغط على طبقة p2p في الشبكة النقطية لطبقة الاتفاق ، لأن كل فترة (كل 12 ثانية) يجب أن تنتقل وتجتمع عدة آلاف من توقيعات المحققين في الشبكة النقطية.
بعد تنفيذ بروتوكول EIP-7251، لا يزال الحد الأدنى للرهن (MIN_ACTIVATION_BALANCE) هو 32 ETH، ولكن الحد الأقصى (MAX_EFFECTIVE_BALANCE) سيتم رفعه بشكل كبير إلى 2048 ETH، يمكنك رهن أي كمية من ETH بين 32 و 2048، ويمكنك الحصول على عوائد الرهن، ولم يعد من الضروري سحب العوائد بانتظام، بعد تجميع 32 ETH يمكنك متابعة الرهن الجديد.
حاليًا، لا يحتاج مقدمو الخدمة الحاليين إلى الخروج بشكل خاص من الرهن قبل الاندماج مرة أخرى وإعادة الرهن معًا، بل يمكنهم استخدام مباشرة عقد "الرهن المدمج" الجديد الموجود على الطبقة التنفيذية (المنتشر في 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb)، حيث يقوم مقدمو الخدمة باستدعاء عنوان انسحابهم للعقد لبدء عملية دمج الرهن.
معلمات طلب الإيداع المدمج تتضمن source_pubkey و target_pubkey: هذان المفتاحان هما مفتاح المحقق Validator Key، حيث يقوم محقق source بالدمج إلى محقق target.
يجب أن يكون إثبات السحب الذي تم إجراؤه مصدرًا إلى إثبات سحب المحقق.
عند الاتصال بعقد إيداع الاندماج لبدء طلب ، سيتم إرفاق رسوم (ETH) ، وسيتم احتساب الرسوم وفقا لعدد الطلبات الحالي ، إذا كان عدد الطلبات كبيرا ، ستزيد الرسوم.
إذا كانت بيانات اعتماد السحب الخاصة بالمستخدم عبارة عن عقد ، فيمكنك الاتصال بعقد إيداع الدمج للحصول على مبلغ الرسوم الحالي ، ثم بدء طلب وإرفاق الرسوم ؛ ومع ذلك ، إذا كانت بيانات اعتماد السحب عبارة عن حساب EOA ، فلا توجد طريقة للحصول على رسوم دقيقة ، لذلك يمكنك فقط محاكاة خارج السلسلة مقدما ودفع الرسوم الزائدة (التي لن يتم ردها) لضمان تنفيذ الطلب بنجاح.
ملاحظة: إذا كانت شهادة السحب الخاصة بك بتنسيق مفتاح BLS ، فيجب تحويلها أولاً ، وتحويلها إلى تنسيق عنوان EL.
EIP-7685: طلب طبقة التنفيذ العامة
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 إجراء عملية واحدة فقط لكل معاملة ، على سبيل المثال ، إذا كنت تريد الذهاب إلى Uniswap لتبادل USDT مقابل ETH ، فيجب عليك أولا بدء معاملة للموافقة على USDT ، وبعد ذلك يمكنك إرسال معاملة أخرى لتنفيذ التبادل.
عدم تفصيل إدارة الصلاحيات ، مثل تسليم بعض العمليات في الحساب إلى طرف ثالث للقيام بها ، يجب على المستخدم التعامل شخصيًا مع كل شيء وتوقيع كل عملية وإجراء مرة واحدة.
لا يوجد آلية استرداد، يجب على الشخص الاحتفاظ بمفتاح خاص أو كلمة تذكير بنفسه، إذا فقدتها، فلن يمكن استعادة أصول الحساب مرة أخرى.
إذا كان الحساب عقد ذكي (مثل Safe)، يمكن حل جميع المشاكل المذكورة أعلاه:
يمكن للمستخدمين استخدام مفتاح خاص موجود في رقاقة الأمان في الهاتف المحمول (أو الكمبيوتر) لتوقيع التفويض، دون الحاجة إلى تذكر أي مفتاح خاص أو كلمات مساعدة، أو يمكن توقيع التفويض باستخدام البريد الإلكتروني، أو بأي شكل آخر من أشكال التفويض.
يمكن تجميع عمليات متعددة معا في نفس المعاملة ، ويمكن إكمال عمليات DApp المعقدة الأصلية بتفويض توقيع واحد فقط ومعاملة واحدة.
يمكن للمستخدمين تفويض أطراف ثالثة للتحكم في حساباتهم ، ولكن في نفس الوقت تحديد قيود مثل "العقود التي يمكن التفاعل معها" ، أو "الإجراءات التي لا يمكن تنفيذها" ، أو "عدد الأصول التي لا يمكن استخدامها إلا عندما تنطوي على عمليات نقل الأصول" ، أو "عدد العمليات التي لا يمكن إجراؤها في الأسبوع".
يمكن إضافة آلية الاسترداد ، حتى في حالة فقدان كلمة الاسترداد الخاصة بك أو الهاتف المحمول أو البريد الإلكتروني ، يمكنك أيضًا نقل أصول حسابك إلى حساب جديد من خلال آلية الاسترداد.
يمنح الاقتراح EIP-7702 حسابات EOA القدرة على أن تصبح حسابات عقود. يوقع المستخدم الرسالة المحولة باستخدام مفتاح EOA الخاص ، والذي يتضمن "معرف السلسلة" و "عنوان العقد المتغير" و "قيمة EOA Nonce":
Chain ID: يُستخدم لمنع التوقيع على سلسلة A من التكرار في سلسلة B. ومع ذلك، إذا كان مُعرّف السلسلة (Chain ID) يُعبأ بالقيمة 0، فإن ذلك يعني الاستعداد للتحول في كل سلسلة.
عنوان العقد الذي تريد أن تصبح: إذا قمت بملء عنوان عقد آمن ، فسيصبح حساب EOA الخاص بك عقدا آمنا ؛ إذا قمت بملء العنوان الفارغ (العنوان (0)) ، فهذا يعني أنك تريد إلغاء التغيير والعودة إلى حساب EOA خالص.
قيمة Nonce لـ EOA: تستخدم لمنع إعادة التوقيع. إذا زادت قيمة Nonce، فإن التوقيع الأصلي سيصبح غير صالح.
لكن هناك بعض النقاط التي يجب مراعاتها:
يمكن استخدام مفتاح EOA نفسه بشكل مستمر
حتى إذا أصبح حساب EOA الخاص بالمستخدم عقدا ، فيمكنه الاستمرار في استخدامه بنفس طريقة حساب EOA الأصلي. على سبيل المثال، إذا أصبح حساب EOA الخاص بك عقدا آمنا، فيمكنك استخدام الواجهة الآمنة أو متابعة عملية المعاملة الآمنة أو متابعة توقيع المعاملات وإرسالها باستخدام محفظة EOA الأصلية. ومع ذلك ، هذا يعني أيضا أن أمان الحساب لا يزال مقصورا على المفتاح الخاص.
لا يزال أمان مفتاح EOA
حتى إذا أصبح EOA الخاص بالمستخدم MultiSig ، طالما أنه لا يفقد مفتاح EOA الخاص ، فإن أمان حسابه سيكون دائما أمان مفتاح EOA الخاص: لا يزال يتعين عليه الحفاظ على مفتاحه الخاص أو عبارة ذاكري آمنة ، ولن يصبح حسابه آمنا مثل MultiSig.
لم يتم تنسيق تخزين حساب EOA.
عندما يتحول حساب EOA إلى عقد ويكتب البيانات إلى التخزين الخاص به ، ما لم يتم حذف البيانات صراحة ، فلن يتم تنسيق البيانات المكتوبة إلى التخزين لأن حساب EOA يتحول إلى عقد آخر أو يلغي التحويل ، لذلك يجب على المطورين توخي الحذر لعدم قراءة البيانات التي خلفها عقد التحويل السابق ، يمكنك الرجوع إلى ERC-7201.
لا تتضمن عملية EIP-7702 التهيئة
بشكل عام، سيحتاج حساب العقد إلى خطوة تهيئة لكتابة معلومات مالك الحساب بشكل متزامن (مثل المفتاح العام أو العنوان) عند نشر الحساب، وذلك لتجنب فقدان ملكية الحساب بسبب التشغيل الأمامي لخطوة النشر. عادة ما يتم تنفيذ ذلك بواسطة عقد المصنع الذي ينشر حساب العقد لإجراء "النشر + التهيئة" ، ولكن نظرا لأن EIP-7702 هو تغيير مباشر ، بدلا من مصنع ينشر العقد إلى EOA، يمكن للمهاجم نسخ توقيع تحويل المستخدم وإرسال المعاملة بشكل استباقي إلى السلسلة للتحويل للمستخدم ولكن تهيئة الحساب ليكون قابلا للتحكم من قبل المهاجم ، لذلك يحتاج المطورون إلى الانتباه إلى EIP-7702. تتمثل إحدى طرق الدفاع المحتملة في التحقق من توقيع حساب EOA في وظيفة التهيئة ، بحيث حتى إذا تم استباقه ، فلن يتمكن المهاجم من إنشاء توقيع حساب EOA لإكمال التهيئة.
يجب على المحفظة أن تراقب طلبات التغيير
يجب على المحفظة أن تقوم بمراقبة المستخدمين بشكل جيد ، ومنع طلبات التحول الخبيثة من مواقع DApp وتحذير المستخدمين عندما يتم ذلك ، وإلا فإذا قام المستخدم بتوقيع صفقة تحويل خبيثة ، فسيؤدي ذلك إلى سرقة الأصول على الفور. فيما يلي بعض أمثلة على تنفيذ عقود التحول:
تعديل الحساب الآمن ايثاكا
حساب إيثاكا
بروتوكول تقنية DApp
** EIP-2537: برنامج التحويل البرمجي المسبق لتشغيل المنحنى BLS12-381 **
قلل التكلفة واجعلها أكثر جدوى لتطبيقات إثبات المعرفة الصفرية القائمة على منحنى BLS.
EIP-2537 يضيف عدة عقود معدّة مسبقًا لتوفير عمليات منحنى BLS الرخيصة، مما يجعل تطوير تطبيقات البرهان الصفري على أساس منحنى BLS أكثر جدوى.
EIP-2935: الاحتفاظ بقيم تشفيرية لكتل السجل في State
يسمح للمطورين أو العقد بقراءة تجزئة الكتلة لكتل الذاكرة السابقة مباشرة من تخزين عقد النظام.
إذا كان المطور بحاجة إلى إثبات محتوى كتلة ذاكرة سابقة معينة، على سبيل المثال، إذا افترضنا أن التحدي الغش في تقنية Optimismtic Rollup يتطلب إثبات وجود 1000 كتلة ذاكرة سابقة لصفقة معينة، فإن المتحدث لا يمكنه القول مباشرة.
"صدقوني ، 1000 كتلة من الذاكرة كانت موجودة بالفعل من قبل" ، كان عليه أن يقدم أدلة ، ولكن لم يكن هناك دليل مباشر لإثبات أن "1000 كتلة سابقة من الذاكرة تحتوي على هذه المحتويات" ، لذلك كان عليه إثبات المعاملة في "سلسلة" من كتل الذاكرة ، كتلة تلو الأخرى ، حتى وصلت إلى 1000 كتلة سابقة ، ثم إثبات أن المعاملة موجودة في الكتلة.
!
△ تشير كل كتلة إلى كتلة أصل ، حتى تتمكن من إثبات أي كتلة في التاريخ طوال الطريق.
فرضا أن كان هناك كتلة ذاكرة تحمل الرقم 10000 حاليًا، وإذا كان تحدي الاحتيالي يجب أن يقدم دليلاً على وجود كتلة ذاكرة تحمل الرقم 9000 تتضمن صفقة X، فيجب على المتحدي البدء من قيمة التشفير الهاش للكتلة 10000، ثم إثبات قيمة التشفير الهاش للكتلة الأم 9999 المتصلة بالكتلة 10000، ثم الإثبات مرة أخرى للكتلة 9998... وهكذا حتى الوصول إلى الكتلة 9000، وأخيرًا تقديم دليل على أن محتوى الكتلة 9000 يتضمن الصفقة X.
بعد EIP-2935 ، سيكون هناك عقد نظام (تم نشره على 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) يخزن تجزئات تصل إلى 8192 كتلة ذاكرة سابقة. في كل مرة يتم فيها إنشاء كتلة جديدة من الذاكرة ، سيتم تحديث عقد النظام تلقائيا لكتابة تجزئة الكتلة السابقة في عقد النظام (ستتم إعادة كتابة تجزئة كتل الذاكرة السابقة 8192).
في مثال تحدي الغش في Optimismtic Rollup، لا يلزم منافسٌ الآن أن يُثبت ببطء حالة كتلة الذاكرة بكتلة ذاكرة بكتلة، بل يمكنه الآن أن يُثبت مباشرة أن قيمة تخزين معينة (تُقابل كتلة ذاكرة 9000) في حالة السلسلة الحالية لكتلة 10000 هي قيمة التجزئة لكتلة ذاكرة 9000. إذا تجاوز المدى 8192، على سبيل المثال كتلة ذاكرة 1000، فإن الأمر لا يتجاوز خطوة واحدة، حيث يجب أن يُثبت أولاً قيمة التجزئة لكتلة 1808 (= 10000 - 8192)، ثم يُثبت بعد ذلك أن قيمة تخزين معينة في حالة السلسلة الحالية لكتلة 1808 هي قيمة التجزئة لكتلة ذاكرة 1000.
يمهد هذا أيضا الطريق لعميل عديم الجنسية في المستقبل: في المستقبل ، لن تحتاج العقد الخفيفة بعد الآن إلى تخزين رؤوس الكتل لجميع كتل الذاكرة التاريخية ، ولكنها ستحتاج فقط إلى مطالبة شخص آخر بتقديم دليل باستخدام طريقة الإثبات في مثال تحدي الاحتيال السابق عندما يكون من الضروري استخدام تجزئة كتلة الذاكرة في التاريخ أو محتويات كتلة الذاكرة.
EIP-7623: : زيادة تكلفة calldata
قم بزيادة تكلفة نشر البيانات باستخدام بيانات المكالمات لتوفير مساحة آمنة كافية لزيادة حد غاز الكتلة وحد النقطة.
مع تزايد الطلب على إصدار البيانات من المجموعات ، بعد إدخال النقط في EIP-4844 للسماح للمجموعات بوضع البيانات بطريقة رخيصة جدا ، كانت زيادة عدد النقط بمثابة ترقية يتطلع إليها المجتمع.
!
△ أعرب المزيد والمزيد من المدققين عن دعمهم لزيادة حد غاز الكتلة.
ولكن سواء زادت حدود غاز الكتلة أو كمية الكتلة، فإن زيادة حجم بيانات المعاملات ستضع المزيد من الضغط على شبكة Ethereum الند للند، مما سيزيد من كفاءة الهجومين، ما لم يتم زيادة تكلفة نشر البيانات أيضًا.
بعد إصدار بروتوكول EIP-7623 ، ستتم زيادة تكلفة بيانات المكالمة بمقدار 2.5 مرة من "صفر بايت: 4 غاز ، غير صفر بايت: 16 غاز" إلى "صفر بايت: 10 غاز ، غير صفر بايت: 40 غاز".
إذا قام المهاجم في الأصل بتخصيص كل حد أقصى لغاز الكتلة (30 مليون) لبيانات القمامة ، فإن حجم كتلة الذاكرة سيكون حوالي 1.79 ميجابايت (30 مليون / 16) ، بالمقارنة مع حجم كتلة الذاكرة المتوسطة البالغ حوالي 100 كيلوبايت. بينما إذا تم زيادة حد أقصى لغاز الكتلة إلى 40 مليون ، يمكن للمهاجم إنتاج كتلة ذاكرة بحجم حوالي 2.38 ميجابايت. عند زيادة تكلفة calldata بمعامل 2.5 ، ستقل كفاءة المهاجم بشكل ملحوظ ، لتصبح 0.72 ميجابايت كحد أقصى ل 30 مليون و 0.95 ميجابايت كحد أقصى ل 40 مليون ، وبذلك يمكن زيادة حد أقصى لغاز الكتلة وكمية Blob بشكل أكبر. ومع ذلك ، لا يرغب بروتوكول التقنية هذا في التأثير على "المستخدمين العاديين الذين لا يقومون بنشر البيانات باستخدام calldata" ، لذا سيتم حساب إجمالي كمية الغاز المستخدمة في المعاملتين بطريقتين ، وسيتم اختيار الكمية الأعلى:
يتم حساب الطريقة الأصلية لحساب استخدام الغاز للمعاملة بتكلفة بيانات المكالمة القديمة: أي ، يتم حساب بيانات المكالمة بطريقة "صفر بايت: 4 غاز ، غير صفر بايت: 16 غاز" ، ويتم إضافة الغاز الذي يستهلكه تنفيذ المعاملة والغاز الذي يستهلكه عقد النشر.
ما عليك سوى حساب كمية غاز calldata ، ولكن استخدم التكلفة الجديدة لحساب: أي أن بيانات الاتصال يتم حسابها بطريقة "صفر بايت: 10 غاز ، غير صفر بايت: 40 غاز" ، ولكنها لا تشمل الغاز الذي يستهلكه التنفيذ أو الغاز المستهلك عن طريق نشر العقد ، لذلك بالنسبة للمستخدمين الذين "لا يستخدمون calldata بشكل عام لنشر البيانات" (مثل الذهاب إلى Uniswap للتبادل) ، فهو الغاز الرئيسي الاستهلاك هو جزء من التنفيذ ، وحتى إذا تم حساب بيانات المكالمة بتكلفة جديدة ، فلن تتجاوز الغاز الذي يستهلكه التنفيذ ، لذلك لن يتأثر المستخدمون العامون.
سيكون التأثير الحقيقي على عمليات التجميع الأصغر ، لأن النقط ذات حجم ثابت ورسوم ثابتة ، لذا فإن عمليات التجميع الصغيرة غير فعالة في استخدام النقط ، ومن الأكثر فعالية من حيث التكلفة استخدام بيانات المكالمات ، ولكن بعد EIP-7623 ، ستزداد تكلفة هذه المجموعات الصغيرة بمقدار 2.5 مرة ، وقد يضطرون إلى التبديل إلى استخدام النقط أو إيجاد طريقة لتوحيد القوى لمشاركة النقطة.
EIP-7691: زيادة كمية استهلاك Blob
زيادة عدد النقط وإضافة مساحة أكبر لنشر البيانات إلى التراكمات. *
EIP-7691 يزيد عدد Blob من 'الهدف: 3 Blob، الحد الأقصى: 6 Blob' إلى 'الهدف: 6 Blob، الحد الأقصى: 9 Blob'، مما يزيد من مساحة نشر المزيد من البيانات لـ Rollup.
ملاحظة: بالإضافة إلى ذلك ، هناك بعض التصاميم في سوق رسوم Blob التي تحتاج إلى ضبط دقيق ، مثل سرعة تعديل الرسوم ليست فورية بما فيه الكفاية وأرضية الرسوم منخفضة للغاية ، ولكن هذا ليس في المشكلة التي يهدف هذا البروتوكول الفني إلى حلها.
البروتوكولات التقنية الأخرى
**EIP-7549: نقل فهرس اللجنة خارج نطاق التحقق **
اضبط محتوى تصويت المدقق لتسهيل تجميع الأصوات وتقليل الضغط على شبكة P2P.
سيتم توزيع الحكام عشوائيًا في كل حقبة إلى مجموعة من اللجان واللجان
في تصويت كتلة الذاكرة ، يمكن تجميع أصوات المدققين في كل لجنة معا ، مما يقلل من عدد الأصوات التي تم تمريرها في شبكة P2P ، لكن أصوات المدقق ستحتوي على معلومات حول عدد اللجان التي ينتمي إليها المدقق ، مما يعني أنه لا يمكن تجميع أصوات اللجان المختلفة ، حتى لو صوتوا جميعا على نفس كتلة الذاكرة.
EIP-7549 يقوم بنقل معلومات 'أي مجلس ينتمي إليه المحقق' خارج محتوى التصويت، مما يتيح تجميع المحققين من مجالس مختلفة على نفس محتوى التصويت، مما يقلل بشكل أكبر من عدد التصويتات التي تنتقل في شبكة p2p ويقلل من الضغط على شبكة p2p.
** EIP-7840: إضافة خطة Blob إلى ملف تعريف EL **
قم بإنشاء ملف تكوين لمعلمات blob في طبقة التنفيذ، مما يوفر على عقدة طبقة التنفيذ عناء سؤال عقدة طبقة الإجماع عن المعلمات المتعلقة ب blob.
يتم تخزين المعلمات المتعلقة ب Blob حاليا في عقد طبقة الإجماع ، لكن عقد طبقة التنفيذ لا تزال بحاجة إلى هذه المعلمات في بعض الحالات (على سبيل المثال ، RPC eth \ _feeHistory) ، لذلك يجب أن تسأل عقد طبقة الإجماع.
في EIP-7840 ، يتم إنشاء ملف تعريف لمعلمات Blob في طبقة التنفيذ ، حيث يمكن لجميع العقد في طبقة التنفيذ قراءة معلمات Blob مباشرة من هذا الملف التعريفي دون الحاجة إلى الاستفسار من عقد طبقة الاتفاق.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مقدمة عن هارد فورك إيثريوم بكترا
بواسطة NIC Lin, متوسط
من المتوقع أن يبدأ Pectra Hard Fork في تنفيذ شبكة الرئيسية في مارس 2025. يتضمن ترقية Pectra 11 بروتوكول تقني (EIP)، وهي على التوالي:
البروتوكولات التقنية ذات الصلة بالرهن
EIP-6110: عمليات منحنى BLS12-381 مُعدّة مُسبقًا
تبسيط عملية مشاركة المستخدمين في الرهن، وتقليل الوقت المستغرق في الانتظار بشكل كبير.
الطريقة التي يشارك بها المستخدمون في التخزين هي إيداع 32 ETH على طبقة التنفيذ وتسجيلها بواسطة سجل الأحداث، ثم تقوم طبقة الإجماع بإجراء تحليل سجل الأحداث لتحديد ما إذا كان شخص ما يشارك في التخزين أم لا، ومن ثم يصبح المستخدم الذي يشارك في التخزين مدققا.
ومع ذلك، يحتاج محققو طبقة الاتفاق في البداية إلى تحديد النقطة الزمنية التي يجب أن يتم فيها التوافق، وإلا فسيتبين أن بعض المحققين رأوا 5 إيداعات جديدة، بينما رأى بعض المحققين فقط 3، ولهذا سيصوت محققو طبقة الاتفاق لتحديد أي كتلة تنفيذية (eth1data) يجب الرجوع إليها، لضمان أن الجميع يرى نفس كتلة تنفيذية.
ومع ذلك، في البداية، تم تصميمها لتجنب حدوث أخطاء كبيرة في طبقة التنفيذ تؤدي إلى تشعب السلسلة، لذلك ستكون طبقة البيانات التنفيذية المرجعية (eth1data) عبارة عن كتلة تنفيذية قبل نحو 10 ساعات، لضمان أن لدى مطوري الطبقة الموافقة وقت كافٍ للرد في حالة حدوث أخطاء كبيرة، ومع ذلك، يؤدي هذا أيضًا إلى الحاجة إلى انتظار أكثر من 10 ساعات قبل أن يصبح الرهن فعالًا بأسرع وقت.
!
△ 10900000 eth1data في كتلة CL ، تجزئة الكتلة المسجلة فيها هي 21683339 كتلة طبقة التنفيذ ، والتي ظهرت قبل 10 ساعات.
بعد تنفيذ البروتوكول الفني EIP-6110 ، ستصبح بيانات تعهد المستخدم في العقد جزءا مباشرا من طبقة التنفيذ ، ولأن كتلة طبقة الإجماع نفسها ستحتوي على كتلة طبقة التنفيذ (ولكن ليس eth1data) ، لم يعد مدققو طبقة الإجماع بحاجة إلى النظر في مشكلة "تأكيد أن كتلة ذاكرة طبقة التنفيذ المرجعية هي نفسها" ، طالما تم التصويت على كتلة ذاكرة طبقة الإجماع من قبل أكثر من ثلثي المدققين ، سيتوصل الجميع إلى توافق في الآراء بشأن نفس كتلة طبقة التنفيذ. لذلك ، بعد المشاركة في التعهد ، يمكن للمستخدم الانتظار حتى تكمل كتلة ذاكرة طبقة التنفيذ المعالجة في حوالي 13 دقيقة على أقرب تقدير ، ويمكن لعميل طبقة الإجماع أيضا إزالة المنطق المعقد المستخدم في الأصل لمعالجة بيانات Staking .
EIP-7002: الاحتفاظ بقيم تجزئة الكتل التاريخية في الحالة
يمكن استخدامها لتحسين عملية خروج المحققين من الرهن أو سحب الوديعة والعوائد، وتقليل مخاطر المحققين.
يحتاج المشاركون في الاقتراع إلى مفتاحين ، هما مفتاح المحقق ومصادقة السحب.
مفتاح المحقق يستخدم لمحتوى عمل المحقق، وثيقة السحب تستخدم لخروج المحقق عند الكفالة، وسيتم سحب الوديعة والعوائد إلى العنوان الذي يتم فيه التحقق منه، بالإضافة إلى ذلك، يجب في الوقت الحالي استخدام مفتاح المحقق للخروج عند الكفالة.
إذا فقد مفتاح المحقق، لن يتمكن من القيام بعمل المحقق ولن يتمكن من سحب الإيداع؛ وإذا فُقدت شهادة السحب، سيتم فقدان جميع الودائع والأرباح. بالإضافة إلى ذلك، يستخدم بعض المستخدمين خدمات الوديعة من الطرف الثالث مثل Lido، وعند استخدام هذه المنصات، يجب على المستخدمين الاحتفاظ بشهادة السحب بأنفسهم، بينما يتم الاحتفاظ بمفتاح المحقق من قبل مزود الخدمة وتنفيذ عمل المحقق نيابة عنهم.
بتنفيذ بروتوكول EIP-7002، يمكن للمستخدم استدعاء “Withdrawal Credential” للخروج من الرهن (Exit) أو سحب الضمان والعوائد الجزئية (Partial Withdrawal) من خلال استدعاء “Withdraw” الذي يتم نشره في 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA، مما يمكن أن يقلل من المخاطر المحتملة المتعلقة باستخدام خدمات الرهن من الطرف الثالث. إذا فقد المستخدم مفتاح المحقق بنفسه أثناء المشاركة في الرهن، فيمكنه أيضًا الخروج من الرهن من خلال هذا الأسلوب.
ملاحظة: إذا كانت بيانات انسحابك لا تزال في تنسيق مفتاح BLS العام، فلا تنسَ تغييرها أولاً وتحويلها إلى تنسيق عنوان EL.
EIP-7251: إضافة MAX_EFFECTIVE_BALANCE
يمكن زيادة الحد الأقصى لمبلغ الرهن بشكل كبير لتقليل عدد المحققين، ويمكن للمحققين الذين لم يصلوا إلى الحد الأقصى تلقي العوائد على الرهن تلقائيًا.
يجب على المستخدم الذي يريد أن يصبح محققًا أن يقدم كمية من ETH تساوي MAX_EFFECTIVE_BALANCE ، لا أقل ولا أكثر (حاليًا MAX_EFFECTIVE_BALANCE هو 32 ETH). إذا كان لدى المستخدم 1024 ETH للرهن ، فيمكنه المشاركة في الرهان 32 مرة ، وتشغيل 32 محققًا ، وتشغيل 32 عقدة محقق. والمشاركة النشطة في الرهان أدت أيضًا إلى وجود حوالي مليون محقق حاليًا وزيادة مستمرة ، وهذا ليس فقط يجعل بيانات حالة طبقة الاتفاق أكبر وأكثر ، بل يزيد من الضغط على طبقة p2p في الشبكة النقطية لطبقة الاتفاق ، لأن كل فترة (كل 12 ثانية) يجب أن تنتقل وتجتمع عدة آلاف من توقيعات المحققين في الشبكة النقطية.
بعد تنفيذ بروتوكول EIP-7251، لا يزال الحد الأدنى للرهن (MIN_ACTIVATION_BALANCE) هو 32 ETH، ولكن الحد الأقصى (MAX_EFFECTIVE_BALANCE) سيتم رفعه بشكل كبير إلى 2048 ETH، يمكنك رهن أي كمية من ETH بين 32 و 2048، ويمكنك الحصول على عوائد الرهن، ولم يعد من الضروري سحب العوائد بانتظام، بعد تجميع 32 ETH يمكنك متابعة الرهن الجديد.
حاليًا، لا يحتاج مقدمو الخدمة الحاليين إلى الخروج بشكل خاص من الرهن قبل الاندماج مرة أخرى وإعادة الرهن معًا، بل يمكنهم استخدام مباشرة عقد "الرهن المدمج" الجديد الموجود على الطبقة التنفيذية (المنتشر في 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb)، حيث يقوم مقدمو الخدمة باستدعاء عنوان انسحابهم للعقد لبدء عملية دمج الرهن.
ملاحظة: إذا كانت شهادة السحب الخاصة بك بتنسيق مفتاح BLS ، فيجب تحويلها أولاً ، وتحويلها إلى تنسيق عنوان EL.
EIP-7685: طلب طبقة التنفيذ العامة
CL لتسهيل إرسال طلبات مباشرة إلى طبقة الاتفاق من قبل المستخدمين وخدمات الرهن.
يمكن للمستخدمين إرسال الطلبات مباشرة من طبقة التنفيذ إلى طبقة الاتفاق ، ويمكن لخدمات الرهن (مثل Lido) العمل بشكل أكثر لامركزية. على سبيل المثال ، طلب الخروج من الرهن المذكور سابقًا EIP-7002 وطلب دمج الوديعة EIP-7251. إذا لم يكن لديك هذا البروتوكول التقني ، فإن مستخدمي Lido يجب أن يثقوا في أن مزودي خدمات العقد Lido سينفذون الخروج من الرهن أو دمج الوديعة بشكل صحيح في طبقة الاتفاق ؛ مع هذا البروتوكول التقني ، يمكن لمستخدمي Lido إرسال الطلبات مباشرة عبر عقود الحوكمة في طبقة التنفيذ.
سيكون لهذه الطلبات نوع الطلب لتمييز أنواع مختلفة من الطلبات، وسيتم إطلاق هذه الطلبات من خلال عقود مختلفة، وفي النهاية سيتم كتابة هذه الطلبات في كتل الذاكرة القابلة للتنفيذ، وبالتالي يمكن لطبقة الاتفاق الوصول مباشرة إلى هذه المعلومات من خلال كتل الذاكرة القابلة للتنفيذ، دون الحاجة إلى كتابة منطق تحليلي فردي.
تستند كل من EIP-6110 وEIP-7002 وEIP-7251 إلى المعايير المحددة بواسطة EIP-7685:
بادئ ذي بدء الطلب (0x00000000219ab540356cbb839cbe05303d7705fa).
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) تقديم طلب.
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) تقديم طلب.
البروتوكول التقني لتحسين تجربة الاستخدام
EIP-7702: إعداد رمز حساب EOA
يسمح بتحويل حسابات EOA إلى حسابات آجلة حسب الرغبة ، مما يحسن بشكل كبير من تجربة المستخدم.
هناك بعض أوجه القصور في استخدام حسابات EOA ، بما في ذلك:
إذا كان الحساب عقد ذكي (مثل Safe)، يمكن حل جميع المشاكل المذكورة أعلاه:
يمنح الاقتراح EIP-7702 حسابات EOA القدرة على أن تصبح حسابات عقود. يوقع المستخدم الرسالة المحولة باستخدام مفتاح EOA الخاص ، والذي يتضمن "معرف السلسلة" و "عنوان العقد المتغير" و "قيمة EOA Nonce":
لكن هناك بعض النقاط التي يجب مراعاتها:
حتى إذا أصبح حساب EOA الخاص بالمستخدم عقدا ، فيمكنه الاستمرار في استخدامه بنفس طريقة حساب EOA الأصلي. على سبيل المثال، إذا أصبح حساب EOA الخاص بك عقدا آمنا، فيمكنك استخدام الواجهة الآمنة أو متابعة عملية المعاملة الآمنة أو متابعة توقيع المعاملات وإرسالها باستخدام محفظة EOA الأصلية. ومع ذلك ، هذا يعني أيضا أن أمان الحساب لا يزال مقصورا على المفتاح الخاص.
حتى إذا أصبح EOA الخاص بالمستخدم MultiSig ، طالما أنه لا يفقد مفتاح EOA الخاص ، فإن أمان حسابه سيكون دائما أمان مفتاح EOA الخاص: لا يزال يتعين عليه الحفاظ على مفتاحه الخاص أو عبارة ذاكري آمنة ، ولن يصبح حسابه آمنا مثل MultiSig.
عندما يتحول حساب EOA إلى عقد ويكتب البيانات إلى التخزين الخاص به ، ما لم يتم حذف البيانات صراحة ، فلن يتم تنسيق البيانات المكتوبة إلى التخزين لأن حساب EOA يتحول إلى عقد آخر أو يلغي التحويل ، لذلك يجب على المطورين توخي الحذر لعدم قراءة البيانات التي خلفها عقد التحويل السابق ، يمكنك الرجوع إلى ERC-7201.
بشكل عام، سيحتاج حساب العقد إلى خطوة تهيئة لكتابة معلومات مالك الحساب بشكل متزامن (مثل المفتاح العام أو العنوان) عند نشر الحساب، وذلك لتجنب فقدان ملكية الحساب بسبب التشغيل الأمامي لخطوة النشر. عادة ما يتم تنفيذ ذلك بواسطة عقد المصنع الذي ينشر حساب العقد لإجراء "النشر + التهيئة" ، ولكن نظرا لأن EIP-7702 هو تغيير مباشر ، بدلا من مصنع ينشر العقد إلى EOA، يمكن للمهاجم نسخ توقيع تحويل المستخدم وإرسال المعاملة بشكل استباقي إلى السلسلة للتحويل للمستخدم ولكن تهيئة الحساب ليكون قابلا للتحكم من قبل المهاجم ، لذلك يحتاج المطورون إلى الانتباه إلى EIP-7702. تتمثل إحدى طرق الدفاع المحتملة في التحقق من توقيع حساب EOA في وظيفة التهيئة ، بحيث حتى إذا تم استباقه ، فلن يتمكن المهاجم من إنشاء توقيع حساب EOA لإكمال التهيئة.
يجب على المحفظة أن تقوم بمراقبة المستخدمين بشكل جيد ، ومنع طلبات التحول الخبيثة من مواقع DApp وتحذير المستخدمين عندما يتم ذلك ، وإلا فإذا قام المستخدم بتوقيع صفقة تحويل خبيثة ، فسيؤدي ذلك إلى سرقة الأصول على الفور. فيما يلي بعض أمثلة على تنفيذ عقود التحول:
بروتوكول تقنية DApp
** EIP-2537: برنامج التحويل البرمجي المسبق لتشغيل المنحنى BLS12-381 **
قلل التكلفة واجعلها أكثر جدوى لتطبيقات إثبات المعرفة الصفرية القائمة على منحنى BLS.
EIP-2537 يضيف عدة عقود معدّة مسبقًا لتوفير عمليات منحنى BLS الرخيصة، مما يجعل تطوير تطبيقات البرهان الصفري على أساس منحنى BLS أكثر جدوى.
EIP-2935: الاحتفاظ بقيم تشفيرية لكتل السجل في State
يسمح للمطورين أو العقد بقراءة تجزئة الكتلة لكتل الذاكرة السابقة مباشرة من تخزين عقد النظام.
إذا كان المطور بحاجة إلى إثبات محتوى كتلة ذاكرة سابقة معينة، على سبيل المثال، إذا افترضنا أن التحدي الغش في تقنية Optimismtic Rollup يتطلب إثبات وجود 1000 كتلة ذاكرة سابقة لصفقة معينة، فإن المتحدث لا يمكنه القول مباشرة.
"صدقوني ، 1000 كتلة من الذاكرة كانت موجودة بالفعل من قبل" ، كان عليه أن يقدم أدلة ، ولكن لم يكن هناك دليل مباشر لإثبات أن "1000 كتلة سابقة من الذاكرة تحتوي على هذه المحتويات" ، لذلك كان عليه إثبات المعاملة في "سلسلة" من كتل الذاكرة ، كتلة تلو الأخرى ، حتى وصلت إلى 1000 كتلة سابقة ، ثم إثبات أن المعاملة موجودة في الكتلة.
!
△ تشير كل كتلة إلى كتلة أصل ، حتى تتمكن من إثبات أي كتلة في التاريخ طوال الطريق.
فرضا أن كان هناك كتلة ذاكرة تحمل الرقم 10000 حاليًا، وإذا كان تحدي الاحتيالي يجب أن يقدم دليلاً على وجود كتلة ذاكرة تحمل الرقم 9000 تتضمن صفقة X، فيجب على المتحدي البدء من قيمة التشفير الهاش للكتلة 10000، ثم إثبات قيمة التشفير الهاش للكتلة الأم 9999 المتصلة بالكتلة 10000، ثم الإثبات مرة أخرى للكتلة 9998... وهكذا حتى الوصول إلى الكتلة 9000، وأخيرًا تقديم دليل على أن محتوى الكتلة 9000 يتضمن الصفقة X.
بعد EIP-2935 ، سيكون هناك عقد نظام (تم نشره على 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) يخزن تجزئات تصل إلى 8192 كتلة ذاكرة سابقة. في كل مرة يتم فيها إنشاء كتلة جديدة من الذاكرة ، سيتم تحديث عقد النظام تلقائيا لكتابة تجزئة الكتلة السابقة في عقد النظام (ستتم إعادة كتابة تجزئة كتل الذاكرة السابقة 8192).
في مثال تحدي الغش في Optimismtic Rollup، لا يلزم منافسٌ الآن أن يُثبت ببطء حالة كتلة الذاكرة بكتلة ذاكرة بكتلة، بل يمكنه الآن أن يُثبت مباشرة أن قيمة تخزين معينة (تُقابل كتلة ذاكرة 9000) في حالة السلسلة الحالية لكتلة 10000 هي قيمة التجزئة لكتلة ذاكرة 9000. إذا تجاوز المدى 8192، على سبيل المثال كتلة ذاكرة 1000، فإن الأمر لا يتجاوز خطوة واحدة، حيث يجب أن يُثبت أولاً قيمة التجزئة لكتلة 1808 (= 10000 - 8192)، ثم يُثبت بعد ذلك أن قيمة تخزين معينة في حالة السلسلة الحالية لكتلة 1808 هي قيمة التجزئة لكتلة ذاكرة 1000.
يمهد هذا أيضا الطريق لعميل عديم الجنسية في المستقبل: في المستقبل ، لن تحتاج العقد الخفيفة بعد الآن إلى تخزين رؤوس الكتل لجميع كتل الذاكرة التاريخية ، ولكنها ستحتاج فقط إلى مطالبة شخص آخر بتقديم دليل باستخدام طريقة الإثبات في مثال تحدي الاحتيال السابق عندما يكون من الضروري استخدام تجزئة كتلة الذاكرة في التاريخ أو محتويات كتلة الذاكرة.
EIP-7623: : زيادة تكلفة calldata
قم بزيادة تكلفة نشر البيانات باستخدام بيانات المكالمات لتوفير مساحة آمنة كافية لزيادة حد غاز الكتلة وحد النقطة.
مع تزايد الطلب على إصدار البيانات من المجموعات ، بعد إدخال النقط في EIP-4844 للسماح للمجموعات بوضع البيانات بطريقة رخيصة جدا ، كانت زيادة عدد النقط بمثابة ترقية يتطلع إليها المجتمع.
!
△ أعرب المزيد والمزيد من المدققين عن دعمهم لزيادة حد غاز الكتلة.
ولكن سواء زادت حدود غاز الكتلة أو كمية الكتلة، فإن زيادة حجم بيانات المعاملات ستضع المزيد من الضغط على شبكة Ethereum الند للند، مما سيزيد من كفاءة الهجومين، ما لم يتم زيادة تكلفة نشر البيانات أيضًا.
بعد إصدار بروتوكول EIP-7623 ، ستتم زيادة تكلفة بيانات المكالمة بمقدار 2.5 مرة من "صفر بايت: 4 غاز ، غير صفر بايت: 16 غاز" إلى "صفر بايت: 10 غاز ، غير صفر بايت: 40 غاز".
إذا قام المهاجم في الأصل بتخصيص كل حد أقصى لغاز الكتلة (30 مليون) لبيانات القمامة ، فإن حجم كتلة الذاكرة سيكون حوالي 1.79 ميجابايت (30 مليون / 16) ، بالمقارنة مع حجم كتلة الذاكرة المتوسطة البالغ حوالي 100 كيلوبايت. بينما إذا تم زيادة حد أقصى لغاز الكتلة إلى 40 مليون ، يمكن للمهاجم إنتاج كتلة ذاكرة بحجم حوالي 2.38 ميجابايت. عند زيادة تكلفة calldata بمعامل 2.5 ، ستقل كفاءة المهاجم بشكل ملحوظ ، لتصبح 0.72 ميجابايت كحد أقصى ل 30 مليون و 0.95 ميجابايت كحد أقصى ل 40 مليون ، وبذلك يمكن زيادة حد أقصى لغاز الكتلة وكمية Blob بشكل أكبر. ومع ذلك ، لا يرغب بروتوكول التقنية هذا في التأثير على "المستخدمين العاديين الذين لا يقومون بنشر البيانات باستخدام calldata" ، لذا سيتم حساب إجمالي كمية الغاز المستخدمة في المعاملتين بطريقتين ، وسيتم اختيار الكمية الأعلى:
سيكون التأثير الحقيقي على عمليات التجميع الأصغر ، لأن النقط ذات حجم ثابت ورسوم ثابتة ، لذا فإن عمليات التجميع الصغيرة غير فعالة في استخدام النقط ، ومن الأكثر فعالية من حيث التكلفة استخدام بيانات المكالمات ، ولكن بعد EIP-7623 ، ستزداد تكلفة هذه المجموعات الصغيرة بمقدار 2.5 مرة ، وقد يضطرون إلى التبديل إلى استخدام النقط أو إيجاد طريقة لتوحيد القوى لمشاركة النقطة.
EIP-7691: زيادة كمية استهلاك Blob
EIP-7691 يزيد عدد Blob من 'الهدف: 3 Blob، الحد الأقصى: 6 Blob' إلى 'الهدف: 6 Blob، الحد الأقصى: 9 Blob'، مما يزيد من مساحة نشر المزيد من البيانات لـ Rollup.
ملاحظة: بالإضافة إلى ذلك ، هناك بعض التصاميم في سوق رسوم Blob التي تحتاج إلى ضبط دقيق ، مثل سرعة تعديل الرسوم ليست فورية بما فيه الكفاية وأرضية الرسوم منخفضة للغاية ، ولكن هذا ليس في المشكلة التي يهدف هذا البروتوكول الفني إلى حلها.
البروتوكولات التقنية الأخرى
**EIP-7549: نقل فهرس اللجنة خارج نطاق التحقق **
اضبط محتوى تصويت المدقق لتسهيل تجميع الأصوات وتقليل الضغط على شبكة P2P.
سيتم توزيع الحكام عشوائيًا في كل حقبة إلى مجموعة من اللجان واللجان
في تصويت كتلة الذاكرة ، يمكن تجميع أصوات المدققين في كل لجنة معا ، مما يقلل من عدد الأصوات التي تم تمريرها في شبكة P2P ، لكن أصوات المدقق ستحتوي على معلومات حول عدد اللجان التي ينتمي إليها المدقق ، مما يعني أنه لا يمكن تجميع أصوات اللجان المختلفة ، حتى لو صوتوا جميعا على نفس كتلة الذاكرة.
EIP-7549 يقوم بنقل معلومات 'أي مجلس ينتمي إليه المحقق' خارج محتوى التصويت، مما يتيح تجميع المحققين من مجالس مختلفة على نفس محتوى التصويت، مما يقلل بشكل أكبر من عدد التصويتات التي تنتقل في شبكة p2p ويقلل من الضغط على شبكة p2p.
** EIP-7840: إضافة خطة Blob إلى ملف تعريف EL **
قم بإنشاء ملف تكوين لمعلمات blob في طبقة التنفيذ، مما يوفر على عقدة طبقة التنفيذ عناء سؤال عقدة طبقة الإجماع عن المعلمات المتعلقة ب blob.
يتم تخزين المعلمات المتعلقة ب Blob حاليا في عقد طبقة الإجماع ، لكن عقد طبقة التنفيذ لا تزال بحاجة إلى هذه المعلمات في بعض الحالات (على سبيل المثال ، RPC eth \ _feeHistory) ، لذلك يجب أن تسأل عقد طبقة الإجماع.
في EIP-7840 ، يتم إنشاء ملف تعريف لمعلمات Blob في طبقة التنفيذ ، حيث يمكن لجميع العقد في طبقة التنفيذ قراءة معلمات Blob مباشرة من هذا الملف التعريفي دون الحاجة إلى الاستفسار من عقد طبقة الاتفاق.