Vitalik: يعد EIP-6780 خطوة أساسية في تبسيط بروتوكول Ethereum

المؤلف: ترجمة فيتاليك: شان أوبا، Golden Finance

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

p>

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

كيف يعمل EIP-6780 على تبسيط بروتوكول Ethereum؟

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

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

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

في السابق، لم يكن أي من هذه الثوابت صحيحًا:

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

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

أصبحت هذه الثوابت الآن جميع صحيحة، مما يجعل بناء عملاء Ethereum والأنواع الأخرى من البنية التحتية أسهل . في غضون سنوات قليلة، من المأمول أن تتمكن EIPs المستقبلية من إكمال هذا العمل والقضاء على SELFDESTRUCT تمامًا.

ما هي "عمليات التطهير" الأخرى التي تحدث؟

• أزال Geth مؤخرًا آلاف الأسطر من التعليمات البرمجية، مما أدى إلى إزالة الدعم لـ (PoW) المدمج مسبقًا ) دعم الشبكة.

• يجسد EIP هذا رسميًا حقيقة أننا لم نعد بحاجة إلى تعليمات برمجية للقلق بشأن "الحسابات الفارغة" (راجع: EIP- 161, الذي قدم هذا المفهوم كجزء من إصلاح هجوم Shanghai DoS)

• نافذة تخزين النقط في Dencun هي 18 يومًا، وهو ما يعني أن عقدة الإيثريوم تحتاج فقط إلى حوالي 50 جيجابايت لتخزين بيانات blob، ولن يزيد هذا المقدار بمرور الوقت

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

ما الذي قد يلزم مسحه أيضًا؟

التجميع المسبق

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

اليوم، يعد استخدام التجميع المسبق ناجحًا للغاية، خاصة لتمكين التطبيقات المستندة إلى ZK-SNARK من خلال التجميع المسبق للمنحنى الإهليلجي. ومع ذلك، هناك مترجمات مسبقة أخرى نادرًا ما يتم استخدامها:

• RIPEMD-160 < /code>: تم تقديم وظيفة التجزئة لدعم توافق أفضل مع Bitcoin

• الهوية

  code>: تجميع مسبق يُرجع مخرجات مطابقة لمدخلاته

• BLAKE2: إدخال وظائف التجزئة قيد التنفيذ من أجل دعم توافق أفضل مع Zcash

• MODEXP يقدم الأسي المعياري الكبير جدًا للدعم استنادًا إلى التشفير باستخدام RSA

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

هناك طريقتان لإزالة هذه التصنيفات المسبقة:

1. فقط قم بإزالة الترجمة المسبقة، على سبيل المثال. تمت إزالة EIP-7266 BLAKE2. هذا أمر بسيط، ولكنه سيعطل أي تطبيق لا يزال يستخدمه.

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

ol >

السجل (EIP-4444)

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

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

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

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

أو بتنسيق meme:



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

إصلاح السجل

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

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

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

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

الانتقال إلى SSZ

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

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



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

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

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

• المواصفات أبسط وأوضح

• مقارنة بشجرة Merkle Patricia الحالية المكونة من ستة فروع، في معظم الحالات Merkle تم تقليل طول الدليل بعامل 4

• طول إثبات Merkle محدد مقارنة بالطول للغاية السيناريو الأسوأ (على سبيل المثال، إثبات رمز العقد أو مخرجات الإيصال الطويل)

• لا حاجة إلى تنفيذ تعليمات برمجية معقدة لمعالجة البتات (مطلوبة لـ RLP)

• بالنسبة لحالات استخدام ZK-SNARK، غالبًا ما يكون من الممكن إعادة استخدام التطبيقات الحالية المبنية حول أشجار Merkle الثنائية

اليوم، هناك ثلاثة أنواع من هياكل البيانات المشفرة في الإيثريوم: الأشجار الثنائية SHA256، وقوائم التجزئة SHA3 RLP، وأشجار باتريشيا السداسية العشرية. بمجرد الانتهاء من الانتقال إلى SSZ، سيتبقى لدينا اثنتين فقط: الأشجار الثنائية SHA256 وأشجار Verkle. على المدى الطويل، بمجرد أن نصبح جيدين بما فيه الكفاية في تجزئة SNARKing، فمن المحتمل أن نستبدل أشجار SHA256 الثنائية وVerkle بأشجار Merkle الثنائية التي تستخدم تجزئة SNARK الصديقة (بنية بيانات مشفرة تعمل مع جميع أشجار Ethereum).