آخر مقال لـ Vitalik: ماذا تحتاج إلى إزالته في مرحلة تطهير Ethereum

المؤلف: Vitalik ، مؤسس Ethereum ؛

واحدة من EIPs غير المعروفة في شوكة Dencun الصلبة الأخيرة هي EIP-6780 ، والتي تحذف معظم وظيفة رمز التشغيل الذاتي.

هذا EIP هو مثال رئيسي لتطوير اتفاق Ethereum.من خلال القضاء على التعقيد والإضافةجديدضمان الأمن لتبسيط جهود الاتفاقية.هذا جزء مهم من “التطهير” الذي أسميه: Ethereum مبسط وتطهير مشاريع الديون الفنية.سيكون هناك المزيد من EIP مع روح مماثلة ، لذلكتجدر الإشارة إلى كيفية تطهير EIP-6780 ، والتي يمكن مسحها في التطهير في المستقبل.

كيف تقوم EIP-6780 بتبسيط اتفاقية Ethereum؟

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

1. بعد EIP-6780 ، يكون عدد فتحات التخزين التي يمكن تحريرها في كتلة واحدة الحد الأقصى (تقريبًا: حد الغاز / 5000).

2. إذا كان العقد يحتوي على رمز غير فارغ في بداية المعاملة أو الكتلة ، فسيكون له نفس الرمز في نهاية المعاملة أو نهاية الكتلة.

في السابق ، لم تكن هذه المتغيرات الثابتة صحيحة:

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

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

الآن ، هذه ليست متغيراتالجميعTrue يجعل من السهل بناء عميل Ethereum وأنواع أخرى من البنية التحتية.بعد بضع سنوات ، آمل أن يتمكن مستقبل EIP من إكمال هذا العمل وتدمير الذاتتم القضاء عليه تمامًا.

ما هي “عمليات التطهير” الأخرى المستمرة؟

قامت Geth مؤخرًا بحذف آلاف خطوط الكود وحذفت الدعم لشبكة POW قبل الحركة.
يعكس هذا EIP رسميًا مثل هذه الحقيقة: لم نعد بحاجة إلى رمز للقلق بشأن “الحسابات الفارغة” (انظر: EIP-161 ، يقدم هذا المفهوم كجزء من إصلاح هجوم Shanghai DOS)
تبلغ نافذة التخزين في Dencun 18 يومًا ، مما يعني أن عقد Ethereum تحتاج فقط إلى حوالي 50 جيجابايت لتخزين بيانات النقطة ، ولن يزداد هذا الرقم بمرور الوقت.

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

ما الأشياء الأخرى التي قد تتطلب تطهير؟

مسبقًا (مسبقًا)

ما قبل التجميع هو عقد Ethereum.هذه الفكرة هي أنه يمكن استخدام التوسع المسبق لتحقيق التنسيقات المعقدة التي لا يمكن تنفيذها بشكل فعال في EVM.

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

RIPEMD-160: إدخال وظيفة التجزئة هو دعم توافق أفضل مع Bitcoin
هوية: العودة إلى ما قبل الانضمام لنفس الإخراج مثل الإدخال
Blake2: إدخال وظيفة التجزئة هو دعم توافق أفضل مع ZCASH
modexpقدم قوة العفن الكبيرة جدًا لدعم التشفير القائم على RSA

لقد أثبتت الحقائق أن احتياجات هذه التجسيد المسبقبعيداًأدناه مما كان متوقعا.هويةيتم استخدامه على نطاق واسع لأنه أسهل طريقة لنسخ البيانات ، ولكن منذ Dencun ، فإن رمز التشغيل McOpy قد استبدلها.لسوء الحظ ، تعتبر هذه التثبيت المسبق مصدرًا كبيرًا لأخطاء الإجماع ، وهو أيضًا مصدر كبير للألم الذي حققته EVM الجديدة ، بما في ذلك دائرة ZK-Snark ، والتحقق الرسمي من الإدراك الودي.

هناك طريقتان لحذف هاتين المسبقين:

فقط حذف ما قبل الانسياب ، على سبيل المثال.EIP-7266 حذف Blake2.هذا بسيط ، لكنه سيدمر أي تطبيق لا يزال يستخدمه.
استبدل عملية التجميع المسبقة إلى كتلة رمز EVM التي تؤدي نفس العملية (على الرغم من أنها ستولد حتماً تكاليف غاز أعلى) ، على سبيل المثال.تتم مشروع EIP هذا من أجل التوسع قبل الهوية.هذا أكثر صعوبة ، لكنه بالتأكيد لن يدمر التطبيق باستخدامه (ما لم تكن هناك حالات قليلة جدًا ، فإن تكلفة غاز رمز EVM الجديد تتجاوز نسبة حدود غازات كتلة المدخلات)

كتلة تاريخية (EIP-4444)

اليوم ، من المتوقع أن تخزن كل عقدة Ethereum بشكل دائم جميع الكتل التاريخية.لفترة طويلة ، كان الناس يعتقدون دائمًا أن هذه طريقة مضيئة للغاية ، وبسبب متطلبات التخزين العالية ، أصبح من غير الضروري تشغيل عقدة Ethereum.في Dencun ، قدمنا Blob ، والتي تحتاج فقط لتخزين حوالي 18 يومًا.بعد استخدام EIP-4444 ، بعد فترة من الزمن ، سيتم حذف كتلة Ethereum أيضًا من عقدة Ethereum الافتراضية.

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

يعد ethereum blockchain دائم ، ولكن من المطلوب أن تكون كل عقدة لتخزين جميع البيانات إلى الأبد طريقة “مبالغة” للغاية لتحقيق ذلك دائم.

طريقة واحدة هي استهداف شبكة Torrent النقطة البسيطة للتاريخ القديم.والآخر هو اتفاق أوضح لاستخدام Ethereum ، مثل شبكة البوابة.

أو ، تنسيق العامل:

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

سجل الإصلاح

اقتبس هذا المسودة EIP:

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

في الواقع ، هذه الآلية بطيئة للغاية.جميع DAPPs تقريبًا التي تزور السجلات التاريخية ليست في النهاية من خلال مكالمات RPC لعقد Ethereum (وحتى عقد الاستضافة عن بُعد) ، ولكن من خلال بروتوكولات إضافية مركزية.

ماذا يمكننا أن نفعل؟يمكننا حذف مرشح الإزهار والتبسيطسجلرمز التشغيل ، بهذه الطريقةهو – هيما تفعله هو إنشاء قيمة تضع التجزئة في الحالة.بعد ذلك ، يمكننا إنشاء بروتوكول منفصل ، باستخدام حساب ZK-Snark وزيادة التزايدية (IVC) لإنشاء “شجرة السجل” الصحيحة ، ويشير إلى أن جميع السجلات المعطاة سهلة البحث عن جدول البحث الذي يسهل البحث عنهعنوانوإذا كنت بحاجة إلى سجلات وتطبيقات تريد أن تكون مركزية ، فيمكنك استخدام هذه البروتوكولات المنفصلة.

انتقل إلى SSZ

اليوم ، لا تزال معظم هياكل الكتلة (بما في ذلك المعاملات والإيصالات) من Ethereum تستخدم تنسيقًا قديمًا يعتمد على أشجار RLP و Merkle Patricia للتخزين.هذا يجعل من الصعوبات غير الضرورية لتطوير التطبيقات باستخدام هذه البيانات.

لقد تحولت طبقة إجماع Ethereum إلى Simpleserialize الأكثر نظافة وأكثر كفاءة (SSZ):

المصدر: https://eth2book.info/altair/part2/building_blocks/merkleization/

ومع ذلك ، ما زلنا بحاجة إلى إكمال التحويل ونقل طبقة التنفيذ إلى نفس الهيكل.

تشمل المزايا الرئيسية لـ SSZ:

المواصفات أبسط وواضحة
بالمقارنة مع شجرة ميركل باتريشيا السداسية الحالية ، في معظم الحالات ، تم اختصار طول دليل ميركل بمقدار 4 مرات
بالمقارنة مع أسوأ حالات وأسوأ ، فإن طول دليل Merkle محدود (على سبيل المثال ، رمز العقد أو إخراج الإيصال الطويل)
لا حاجة لتحقيق رمز التشغيل المعقد (احتياجات RLP)
بالنسبة لحالات استخدام ZK-Snark ، يمكن إعادة استخدام التنفيذ الحالي للتنفيذ الحالي لشجرة Merkle الثنائية

اليوم ، هناك ثلاثة أنواع من هياكل البيانات المشفرة في Ethereum: SHA256 Tree Binary Tree ، SHA3 RLP Hash ، وشجرة Patricia السداسية.بمجرد الانتهاء من الانتقال إلى SSZ ، سيكون لدينا اثنين فقط: SHA256 شجرة ثنائية وشجرة Verkle.على المدى الطويل ، بمجرد أن نجعلنا جيدًا في تجزئة Snarking بما فيه الكفاية ، من المحتمل أن نستخدم شجرة Merkle الثنائية لاستبدال شجرة SHA256 الثنائية و Verkle بشجرة Merkle الثنائية التي تستخدم تجزئة Snark الودية (نوع من بنية البيانات المشفرة لـ كل Ethereum).