مقدمة عن محتوى الهارد فورك الخاص بـ Ethereum Dencun

يتكون Dencun من الاسمين Deneb وCancun، اللذين يمثلان الانقسام الصلب لطبقة إجماع Ethereum وطبقة التنفيذ على التوالي. تم الانتهاء من عملية Dencun الصلبة على شبكات اختبار Goerli وSepolia وHolesky، وسيتم إطلاق الشبكة الرئيسية في Epoch 269568 (13 مارس 2024 تقريبًا).

نصائح للقراءة

قبل قراءة هذه المقالة، تحتاج إلى لمعرفة تتضمن المعرفة الأساسية ما يلي:

• الشوكة الصلبة

< li >

ينقسم الإيثريوم إلى طبقة الإجماع وطبقة التنفيذ

ترقية Dencun يتضمن 9 EIPs، وهي:

• EIP- 1153: رموز تشغيل التخزين العابرة (تغييرات طبقة التنفيذ )

• EIP-4788: جذر كتلة المنارة في تغييرات EVM (طبقة التنفيذ وطبقة الإجماع)

• EIP-4844: معاملات Shard Blob (تغييرات طبقة التنفيذ وطبقة الإجماع)

< li>

EIP-5656: MCOPY - تعليمات نسخ الذاكرة (تغييرات طبقة التنفيذ)

• EIP-6780: SELFDESTRUCT فقط في نفس المعاملة (تغييرات طبقة التنفيذ)

• EIP-7044: عمليات الخروج الطوعية الموقعة الصالحة دائمًا (تغييرات طبقة الإجماع)

• EIP-7045: زيادة الحد الأقصى لفتحة تضمين المصادقة (تغييرات طبقة الإجماع)

• EIP-7514: إضافة حد الحد الأقصى للتغيير في العصر (تغييرات طبقة الإجماع)

• EIP-7516 : شفرة تشغيل BLOBBASEFEE (تغييرات طبقة التنفيذ)

ستقدم هذه المقالة تغييرات وتأثيرات EIPs (باستثناء EIP-4844). مقدمة إلى EIP-4844، يرجى الرجوع إلى:

منشور مجموعة التحديثات الكبير: Proto-Danksharding (1)

• https://medium.com/taipei-ethereum-meetup/rollup- and-the-boost-from-proto-danksharding -85d2fe0566b6

المقال الكبير للمجموعة: Proto- Danksharding (2)

• https://medium.com/taipei-ethereum -meetup/rollup-proto-danksharding-implementation-detail- 913a3c61fde8

المقدمة والتسلسل التاليان سيكونان تقريبًا مقسمين إلى "EIP المتعلق بتغييرات طبقة التنفيذ" و"EIP المتعلق بتغييرات طبقة الإجماع" و"EIP المرتبط بـ EIP-4844".

EIP-1153

• تغييرات طبقة التنفيذ

• EIP-1153: أكواد تشغيل التخزين العابرة

• https://eips. ethereum.org/EIPS/eip-1153

• EIP-1153: صفحة المعجبين< /p>

• https://www.eip1153.com/

• EIP-1153: أكواد تشغيل التخزين العابرة< /p>

• https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

يضيف EIP-1153 رمزي تشغيل جديدين: TSTORE وTLOAD، اللذان يستخدمان لكتابة وقراءة بيانات التخزين "المؤقتة". سيوفرون على العديد من مطوري العقود الكثير من تكاليف الغاز.

الخلفية

يشير التخزين إلى العقد الذكي من خلال يقوم SSTORE Opcode بكتابة البيانات في مساحة تخزين العقد، وبعد كتابة البيانات، ستكون موجودة بشكل دائم حتى يقوم العقد بإزالة البيانات بشكل فعال. تتم مقارنة خاصية "المؤقت" بـ "الوجود الدائم"، وتكون البيانات المكتوبة بواسطة TSTORE صالحة فقط حتى نهاية المعاملة، وبعد تنفيذ المعاملة، سيتم تجاهل القيمة المكتوبة بواسطة TSTORE.

تفاصيل العملية

TSTORE رخيص جدًا مقارنة بـ SSTORE هناك الكثير منها، ويمكن أن تمتد فترة صلاحيتها عبر المكالمات بين العقود المختلفة (حتى نهاية المعاملة)، على عكس الذاكرة، على الرغم من أنها رخيصة، إلا أن القيمة في الذاكرة حصرية لكل عقد نفسه.لا يمكن للعقد (أ) قراءة ذاكرة العقد ب. . وهذا مفيد جدًا للعديد من الأغراض:

1. قفل إعادة الدخول. في الوقت الحالي، لا يمكن محاكاة قفل إعادة الدخول إلا باستخدام SSTORE. على الرغم من أن قواعد SSTORE خفضت الكثير من تكاليف الغاز لاستخدامات مثل قفل إعادة الدخول بعد اجتياز EIP-2200، إلا أن TSTORE يمكنها تقليل التكلفة بشكل كبير: من 5000 إلى 100.

2. موافقة ERC-20 المستخدمة في معاملة واحدة. إذا تفاعل العقد "أ" مع العقد "ب"، وكان العقد "أ" بحاجة إلى نقل ERC-20 من العقد "ب"، فسيوافق العقد "ب" أولاً على ERC-20 للعقد "أ" ثم يستدعي العقد "أ". نظرًا لأن الموافقة على ERC-20 تتم من خلال SSTORE، فإن التكلفة ليست منخفضة، والتغيير لاستخدام TSTORE سيؤدي إلى تقليل التكلفة بشكل كبير.

3. معلمات النشر عند نشر العقد من خلال CREATE2. نظرًا لأن معلمات المُنشئ ستؤثر على عنوان العقد الذي يتم نشره بواسطة CREATE2، إذا كنت لا تريد أن تتأثر بمعلمات المُنشئ، فسيتم تصميم مُنشئ العقد لقراءة المعلمات من تخزين عقد النشر، مثل تجمع Uniswap V3. من خلال TSTORE، يمكن لهذا النموذج توفير الكثير من التكاليف.

ملاحظات

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

• تم إطلاق EIP-1153 في الإصدار 0.8.24 من Solidity، ويمكن للمطورين تجربته مقدماً. فيما يلي مثال Mutex الذي تم تنفيذه بواسطة المطور. سيتم أيضًا تشغيل Uniswap V4، الذي يعتمد على TSTORE، عبر الإنترنت بعد اكتمال ترقية Dencun.

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

EIP-4788

• تغييرات طبقة التنفيذ

• EIP-4788: كتلة المنارة الجذر في EVM

• https://eips.ethereum.org/EIPS/eip-4788

• EIP-4788: جذر الإشارة في EVM

• https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

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

التفاصيل التشغيلية

يمكن للمستخدمين أو العقود المرور عبر الاتصال بـ عقد للاستعلام عن جذر كتلة الطبقة المتفق عليها (Beacon Block Root) في وقت معين. يشبه جذر الكتلة قيمة التجزئة لمحتوى الكتلة (Beacon Block Hash)، وهو جذر Merkle Tree (Merkle Tree Root) الذي تم الحصول عليه عن طريق تشفير SSZ لمحتوى الكتلة. يقوم المتصل بتشفير الطابع الزمني (الطابع الزمني) في قيمة uint256 ويستخدمه كمحتوى المكالمة، وسيستخدم العقد الطابع الزمني للعثور على جذر كتلة طبقة الإجماع المقابلة في التخزين وإعادته.

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



△ يوفر المستخدمون إثبات Merkle وكتل طبقة الإجماع الطابع الزمني



△ Merkle Proof يتم استخدامه مع الاستعلام عن جذر الكتلة للتحقق من توازن أداة التحقق من الصحة في وقت معين

ومع ذلك، فإن جذر كتلة طبقة الإجماع المخزن في عقد BEACON_ROOTS_ADDRESS هو في الواقع هو جذر الكتلة للكتلة "الأصلية" (أي الكتلة السابقة)، وليس جذر الكتلة لنفس الكتلة مثل طبقة التنفيذ.



△ الطابع الزمني للكتلة 11001 (1234567) يتوافق مع جذر الكتلة للكتلة 11000. وبالمثل، فإن الطابع الزمني للكتلة 11000 (1234555) يتوافق مع جذر الكتلة للكتلة 10999.

ملاحظات

يمكن لـ BEACON_ROOTS_ADDRESS تخزين ما يصل إلى 8191 عنصرًا في جذر كتلة طبقة إجماع العقد، سيتم استبدال 8191 جذر كتلة سابق. على سبيل المثال، بافتراض أنها الكتلة 18191، فإن جذور الكتلة التي يمكن الوصول إليها في الوقت الحالي ستتراوح من الكتلة 10000 إلى الكتلة 18190.

EIP-5656

• تغييرات طبقة التنفيذ

• EIP-5656: MCOPY - تعليمات نسخ الذاكرة

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-5656

EIP-5656 إضافة جديد يتم استخدام MCOPY Opcode واحد خصيصًا لنسخ القيمة المخزنة في الذاكرة أثناء تنفيذ العقد. ستستفيد العقود من التوفير في تكلفة الغاز الذي يوفره رمز التشغيل هذا.

إذا أراد مطورو العقود استخدام MCOPY Opcode، فيجب عليهم تحديد إصدار المترجم كـ 0.8.24 (أو أعلى) وإصدار EVM كـ Cancun:



△ لاستخدام MCOPY، تحتاج إلى تعيين إصدار المترجم وإصدار EVM

ملاحظة: إصدار المترجم 0.8.24 يسمح فقط باستخدام MCOPY من خلال التجميع ( mcopy(), link)، ستسمح الإصدارات المستقبلية تلقائيًا للمترجم بتطبيق MCOPY حيث يلزم نسخ الذاكرة.

ملاحظات

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

EIP-6780

• تغييرات طبقة التنفيذ

• EIP-6780: SELFDESTRUCT فقط في نفس المعاملة

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-6780

• EIP-6780: إلغاء تنشيط SELFDESTRUCT، إلا إذا حدث ذلك في نفس المعاملة التي تم إنشاء العقد فيها

• < p style="text-align: left;">https://ethereum-magicians.org/t/eip-6780-deactivate-selfdestruct-except-where-it-occurs-in-the-same-transaction -in-what-a-contract-was-created/13539

EIP-6780 تم تعديل سلوك SELFDESTRUCT Opcode للتحضير لـ Verkle Tree وإزالة SELFDESTRUCT Opcode. يحتاج المطورون الذين تستخدم عقودهم SELFDESTRUCT Opcode إلى إيلاء اهتمام خاص.

الخلفية

SELFDESTRUCT السلوك الحالي لشفرة التشغيل هو : (1) احذف رمز العقد وتخزينه، و(2) انقل جميع عملات ETH الموجودة لديك إلى العنوان المحدد.

تم تصميم SELFDESTRUCT Opcode في الأصل بآلية استرداد الأموال لتشجيع المطورين على إزالة العقود غير المستخدمة ومساحة التخزين للمساعدة في الحفاظ على حالة Ethereum بحجم مناسب. ولكن لا يفعل الكثير من الناس هذا بالفعل، وبدلاً من ذلك، تسببت حوادث مثل Parity Multisig في تجميد مئات الآلاف من ETH بسبب SELFDESTRUCT، لذلك يأمل مجتمع Ethereum في التخلص التدريجي من SELFDESTRUCT Opcode. كانت هناك العديد من المقترحات لتعديل أو إزالة SELFDESTRUCT Opcode في الماضي، ويعد EIP-6780 واحدًا منها وتم تضمينه في النهاية في شوكة Dencun الصلبة.

ملاحظة: في شوكة شنغهاي الصلبة في أوائل عام 2023، أعلن EIP-6049 رسميًا أنه سيتم التخلص من SELFDESTRUCT.

Verkle Tree عبارة عن بنية تخزين حالة يتم بحثها وتطويرها حاليًا بواسطة مجتمع Ethereum، وسيتم استخدامها لتحل محل Merkle Patricia Tree الحالية. ستجعل Verkle Tree حجم إثبات حالة Ethereum أصغر، وبالتالي فهي أساسية في تصميم العميل عديم الجنسية. مع برنامج Stateless Client، سيتم تقليل أجهزة العقد، مما يسمح لعدد أكبر من الأشخاص بتشغيل العقد بأجهزة أخف وزنًا وأرخص، مما يحسن اللامركزية في الشبكة.

التفاصيل التشغيلية

بعد EIP-6780، كود التشغيل SELFDESTRUCT سيؤدي ذلك إلى إزالة سلوك (1) والاحتفاظ فقط بوظيفة (2) "نقل جميع ETH إليك إلى العنوان المحدد". سيظل رمز العقد وتخزينه دون تغيير ما لم يتم إنشاء العقد في نفس المعاملة ثم يتم تنفيذ SELFDESTRUCT.

لذا عند تشغيل SELFDESTRUCT:

• إذا لم يتم إنشاء العقد في نفس المعاملة، فسيظل رمز العقد وتخزينه دون تغيير، ولكن سيتم نقل كل ETH الموجود عليه إلى العنوان المحدد.

• إذا تم إنشاء العقد في نفس المعاملة، يكون السلوك هو نفسه كما كان من قبل (قبل EIP-6780 ) هي نفسها: ستتم إزالة رمز العقد والتخزين، وسيتم نقل ETH إلى العنوان المحدد.

بالنسبة لـ Verkle Tree، يجب إزالة سلوك (1)

قوي

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



△ تصميم شجرة الحالة الحالي (شجرة ميركل باتريشيا) عبارة عن بنية مكونة من طبقتين: يتوافق جذر الحالة مع شجرة مكونة من جميع العناوين، ويتوافق جذر التخزين مع شجرة مكونة من جميع وحدات التخزين الموجودة تحت عنوان ما.

مصدر الصورة: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html



△  شجرة حالة Verkle Tree عبارة عن شجرة مسطحة تمامًا ذات طبقة واحدة.

العقدة الحمراء في الصورة هي العنوان، والعقدة الخضراء هي قيمة تخزين العنوان.

مصدر الصورة: https://youtu.be/s7fm6Zz_G0I?t=572

< img src="https://img.jinse.cn/7188773_image3.png">

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

مصدر الصورة: https://youtu.be/s7fm6Zz_G0I?t=572

لذلك، من أجل الترحيب بـ Verkle Tree، يجب علينا تعطيل SELFDESTRUCT Opcode الذي يمكنه إزالة رمز العقد والتخزين.

ملاحظات

• إذا كان المطور يستخدم CREATE2 + SELFDESTRUCT للنشر بشكل متكرر على نفس العنوان، بعد Dencun، فلن يحدث هذا إلا في وقت واحد داخل نفس المعاملة لإكمالها.

• إذا كان المطور يستخدم CREATE2 + SELFDESTRUCT لتحقيق تأثير ترقية العقد (لذلك CREATE2 + SELFDESTRUCT لن يتم إكماله في نفس المعاملة) ولن يتمكن من المتابعة بعد Dencun، يرجى التبديل إلى وضع الترقية الذي لا يقوم عمومًا بـ SELFDESTRUCT.

EIP-7044

• تغييرات طبقة الإجماع

• EIP-7044: صالح دائمًا الخروج الطوعي الموقع

• https://eips.ethereum.org/EIPS/eip-7044

• EIP-7044: عمليات الخروج الطوعية الموقعة الصالحة بشكل دائم

• https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-طوعي-exits/14348

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

الخلفية

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

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

تفاصيل العملية

ولكن بسبب انسحاب يحتوي محتوى توقيع PoS على إصدار الشبكة الحالي (الهارد فورك)، مثل إصدار Shanghai الحالي أو الإصدار السابق من Capella. ستقوم الشبكة بمقارنة "إصدار الهارد فورك في شهادة الخروج" و"الإصدار الحالي للشبكة"، وإذا كان اختلاف الإصدار أكثر من نسختين، فسيتم اعتباره غير صالح. بمعنى آخر، نظرًا لأن الشبكة يتم تحديثها باستمرار، وبعد الانقسامات الصلبة والترقية إلى الإصدارات الجديدة، ستصبح شهادات الخروج القديمة جدًا غير صالحة.

على سبيل المثال، إصدارات الهارد فورك الحالية لطبقة الإجماع من القديم إلى الجديد هي Altair وBellatrix و(حاليًا) Capella. شهادة السحب الموقعة في وقت Altair ستصبح غير صالحة الآن؛ إذا تم تحديثها إلى الإصدار التالي من Deneb، فإن شهادة السحب الموقعة في وقت Altair وBellatrix ستصبح غير صالحة. ولمواجهة هذا الوضع، يجب على المستخدمين طلب شهادة خروج من مزود الخدمة في كل مرة يحدث فيها هارد فورك، وإذا لم يحصل المستخدم على شهادة الخروج مسبقًا، فقد يتمكن مزود الخدمة من "عدم الحصول على شهادة الخروج" " بعد الانقسام الكلي. "الخروج من PoS" يهدد بابتزاز المستخدمين.

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

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

ملاحظات

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

EIP-7045

• تغييرات طبقة الإجماع

• EIP-7045: زيادة الحد الأقصى لفتحة تضمين المصادقة

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-7045

• EIP-7045: زيادة الحد الأقصى للتصديق فتحة التضمين

• https://ethereum-magicians.org/t/eip-7045-increase-max-attestation-inclusion-slot/14342

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

الخلفية

تصويت المصادق الأصلي (الإقرار) يوجد حقبة واحدة (32 فتحة) من الوقت يمكن تضمينها. على سبيل المثال، افترض أن أداة التحقق Alice قد تم تعيينها للتصويت في الفتحة 10000، وبسبب مشاكل وقت انتظار الشبكة، قد لا تكمل تصويتها حتى الفتحة 10010 أو قد يكون تصويتها لن يتم بثها بنجاح حتى فتحة 10020. شبكة p2p، ولكن ستظل أصواتها مدرجة. ومع ذلك، إذا لم يظهر تصويتها حتى الفتحة 10033، فلن يتم تضمين صوتها وسيتم التعامل معه كما لو أنها لم تصوت.

تفاصيل العملية

سيتضمن EIP-7045 التصويت يتم تمديد فترة الصلاحية حتى نهاية فترة التصويت التالية على أبعد تقدير. على سبيل المثال، افترض أنه تم تعيين أداة التحقق أليس للتصويت في الفتحة 3205 من العصر 100. قبل EIP-7045، كان تصويتها صالحًا حتى الفتحة 3237 (3237 = 3205 + 32) على أبعد تقدير؛ وبعد EIP-7045، كان تصويتها يمكن تضمينه حتى نهاية العصر 101 (أي الفتحة 3263) على أبعد تقدير.

ملاحظة: العصر 0 يحتوي على الفتحات من 0 إلى 31؛ العصر 100 يحتوي على الفتحات من 3200 إلى 3231؛ العصر 101 يحتوي على الفتحات من 3232 إلى 3263.

EIP-7514

• تغييرات طبقة الإجماع

• EIP-7514: إضافة الحد الأقصى لزمن التغيير

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-7514

• EIP-7514: إضافة الحد الأقصى للعصر الحد الأقصى للتغيير

• https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

الخلفية

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



△ زادت قائمة انتظار الإدخال منذ سحب نقطة البيع من الافتتاح. مصدر الصورة: https://www.validatorqueue.com/

إذا استمر تسلسل انتظار أداة التحقق من الصحة ممتلئًا، فمن سبتمبر 2023 بحلول مايو بحلول عام 2024 (عندما يتم اقتراح EIP)، في غضون ثمانية أشهر تقريبًا، سيتم التعهد بـ 50٪ من ETH في إثبات الحصة، وبحلول سبتمبر 2024، سيتم التعهد بـ 75٪ من ETH. إن تخزين الكثير من ETH له العديد من العيوب، مثل وجود عدد كبير جدًا من أدوات التحقق من الصحة، مما يؤدي إلى عدد كبير جدًا من أصوات المدققين والتوقيعات المجمعة، مما يزيد العبء على شبكة المدقق p2p وتوسيع الدولة لسلسلة الإجماع. بالإضافة إلى ذلك، يعتقد بعض الناس أن الأمان الذي يتطلبه الإيثريوم لا يتطلب الكثير من التعهدات بالإيثريوم، فالتعهدات المتعددة للإيثريوم هي مضيعة من منظور أمني.

لماذا يستمر تدفق الكثير من ETH؟ لأنه حتى لو تم التعهد بنسبة 100% من الإيثيريوم، فإن المعدل السنوي لا يزال حوالي 1.6%، وقد أدى ظهور رمز التحصيص السائل (LST) إلى تحسين كفاءة استخدام رأس المال. إلى جانب دخل MEV، حولت عوامل مختلفة الرهن العقاري إلى عملية خيار جذاب للغاية.

لحسن الحظ، سوف تنحسر طفرة التحصيص تدريجيًا في النصف الثاني من عام 2023، مما سيبطئ نمو عدد المدققين.



△ سوف يتباطأ النمو في عدد المدققين في النصف الثاني من عام 2023، وفي فبراير 2024، سيتم التعهد بحوالي 25٪ من ETH. مصدر الصورة: https://www.validatorqueue.com/

تفاصيل العملية

في الأصل، يتغير الحد الأعلى لعدد قائمة انتظار الإدخال مع العدد الحالي للمدققين. مقابل كل زيادة أو نقصان في 65536 مدققًا، سيزيد الحد الأعلى لعدد قائمة انتظار الإدخال أو انخفاض بمقدار 1. 2024 الحد الأقصى لعدد قوائم انتظار الإدخال الشهرية هو 14 (العدد الحالي للمدققين هو حوالي 950,000).

سيعمل EIP-7514 على تثبيت الحد الأعلى لعدد قائمة انتظار الإدخال عند 8 ولن يزيد مع زيادة العدد الحالي للمدققين، وبالتالي يتباطأ أدى ذلك إلى انخفاض عدد المدققين، حيث تتيح السرعة للمجتمع مزيدًا من الوقت للتوصل إلى حلول طويلة المدى، مثل EIP-7251، والتي قد يتم تضمينها في الانقسام الصعب التالي.

EIP-4844 وEIP-7516

• EIP-4844: معاملات Shard Blob

• https://www.eip4844.com/

• المقال الكبير في مجموعة التحديثات: Proto-Danksharding (1)

• https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto- danksharding-85d2fe0566b6

• المقالة الكبيرة في مجموعة التحديثات: Proto-Danksharding (2)

  < /li>

  • https:// Medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

EIP-4844 تمت إضافة نوع معاملة جديد، وهي معاملة تستخدم خصيصًا لتخزين بيانات Blob. من خلال وضع البيانات في Blobs، سيتمكن Rollup من تقليل رسوم المعاملات بشكل أكبر.

EIP-4844 ليس تغييرًا للتوسيع والترقية، ولكنه أشبه بـ "زيادة حد غاز الكتلة" و"تقليل التكلفة" بحيث يمكن للكتلة أن يتم وضع تغيير لزيادة حجم المعاملات عن طريق إدخال المزيد من المعاملات (Rollup). لكن EIP-4844 يمهد الطريق أيضًا لحل توسعي حقيقي - Danksharding.

بالإضافة إلى ذلك، تعد معارض Blob التجارية والمعارض التجارية العامة بمثابة أسواق رسوم منفصلة ومستقلة. ولكل منها رسوم أساسية ورسوم أولوية خاصة بها، لذا فإن EIP-7516 عبارة عن تداول Blob تمت إضافة كود تشغيل BLOBBASEFEE إلى سوق الرسوم (الوظيفة تعادل كود تشغيل BASEFEE للمعاملات العامة)، بحيث يمكن لعقد التراكم معرفة الرسوم الأساسية لـ Blob من خلال كود التشغيل هذا.

الملخص والنقاط الرئيسية

• تتكون شوكة Dencun الصلبة من شوكة Deneb الصلبة في طبقة الإجماع وشوكة Cancun الصلبة في طبقة التنفيذ.

• بطل هذه الترقية هو EIP-4844. إن تقديم تنسيق معاملة Blob يسمح لـ Rollup بتقليل تكاليف المعاملات بشكل أكبر وفي في نفس الوقت توفير رصف Danksharding.

• تتضمن التغييرات في طبقة الإجماع EIP-7044 وEIP-7045 وEIP-7514.

• يسمح EIP-7044 للمدققين الذين يستخدمون خدمات التوقيع المساحي غير الحاضنة بعدم التأثر بالانقسامات الصلبة المستقبلية عند إلغاء الاشتراك في إثبات الحصة (PoS).

• يمكن اعتبار EIP-7045 وEIP-7514 تحديثات لزيادة استقرار شبكة PoS.

• تتضمن تغييرات طبقة التنفيذ EIP-1153 وEIP-4788 وEIP-5656 وEIP-6780 وEIP-7516.

• يسمح EIP-1153 بالعديد من أنماط تصميم العقود لتوفير الكثير من الغاز؛ كما يسمح EIP-5656 أيضًا بتخفيض تكلفة الغاز قليلاً مخفض.

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

• EIP-6780 يزيل أيضًا SELFDESTRUCT ويزيل قدرته على "إزالة رمز العقد وحالته".

• يجب على المطورين توخي الحذر حتى لا يعتمدوا على افتراض أنه "سيتم مسح التخزين المؤقت بعد المعاملة" عند استخدام EIP- 1153، وإذا كنت تستخدم SELFDESTRUCT، فتأكد من الانتباه إلى ما إذا كان عقدك سيتأثر أم لا.

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

البيانات المرجعية ومزيد من القراءة الموصى بها

< p style="text-align: left;">EIP-1153

• https://eips.ethereum.org/EIPS/eip-1153

• https://www.eip1153.com/

• https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

• https://hackmd.io/@-_WYFKbvSmip5m7MNB4b8A/SJFH66Eca

EIP-4788

• https ://eips.ethereum.org/EIPS/eip-4788

• https://ethereum -magicians.org/t/eip-4788-beacon-root-in-evm/8281

< قوي>EIP-5656

• https://eips.ethereum.org/EIPS/eip-5656

EIP-6780

• https:/ /eips.ethereum.org/EIPS/eip-6780

• https://ethereum-magicians .org/t/eip-6780-deactivate-selfdestruct-except-where-it-occurs-in-the-same-transaction-in-what-a-contract-was-created/13539

• https://www.youtube.com/watch?v=s7fm6Zz_G0I

EIP-7044

• https://eips.ethereum.org/EIPS/eip-7044

• < p style="text-align: left;">https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-طوعي-exits/14348

EIP-7514

• https://eips.ethereum.org/EIPS/eip-7514

• https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

EIP-4844 وEIP-7516

• https://www.eip4844.com/

• https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding -85d2fe0566b6

• https://medium.com/taipei-ethereum-meetup/rollup-proto -danksharding-implementation-detail-913a3c61fde8

• https://eips.ethereum.org/EIPS /eip-7516

• https://ethereum-magicians.org/t/eip-7516 -blobbasefee-opcode/15761