يُصدر Vitalik تعليمات حول الخطوات التالية لتبسيط بروتوكول Ethereum وتقليل حمل موارد العقدة (Purge)

نشر فيتاليك بوتيرين، المؤسس المشارك لشركة إيثريوم، تعليمات "التطهير" حول الخطوات التالية لتبسيط بروتوكول إيثريوم وتقليل حمل موارد العقدة. قال Vitalik إن EIP-6780 في شوكة Dencun الصلبة يزيل الكثير من وظائف كود التشغيل SELFDESTRUCT، مما يبسط البروتوكول عن طريق إزالة التعقيد وإضافة ضمانات أمنية جديدة. لذلك، اعتبرها Vitalik جزءًا مهمًا من "عملية التطهير". وفيما يتعلق بعمليات "التطهير" الأخرى التي تحدث، أعطى Vitalik ثلاثة أمثلة: 1. أسقطت Geth مؤخرًا دعمها لشبكة ما قبل الاندماج (PoW)، وتم حذف آلاف الأسطر من التعليمات البرمجية. إزالة. ;2.EIP-161 يضفي الطابع الرسمي على حقيقة أننا لم نعد بحاجة إلى الحصول على تعليمات برمجية للقلق بشأن "الحسابات الفارغة"، وقد قدم الاقتراح هذا المفهوم كجزء من إصلاح هجوم Shanghai DoS؛3.Blobs في Dencun الـ 18 يومًا تعني نافذة التخزين أن عقد إيثريوم تحتاج فقط إلى حوالي 500 جيجابايت لتخزين بيانات blob، ولن يزيد هذا المقدار بمرور الوقت. تعمل النقطتان الأوليتان على تحسين تجربة العمل لمطوري العملاء بشكل كبير، بينما تعمل النقطة الأخيرة على تحسين تجربة العمل لمشغلي العقد بشكل كبير. بالإضافة إلى ذلك، فيما يتعلق بالمناطق الأخرى التي قد تحتاج إلى "تطهير"، أدرج Vitalik التجميع المسبق وتسجيل التاريخ (EIP-4444) وإصلاح LOG والانتقال إلى SSZ. فيما يتعلق بالتجميع المسبق، أشار فيتاليك: "الطلب على التجميع المسبق الجزئي أقل بكثير من المتوقع، وهذه الوظائف المترجمة مسبقًا هي مصدر كبير لأخطاء الإجماع ونقطة ألم كبيرة لتطبيقات EVM الجديدة. هناك طريقتان لإزالة هذه التجميعات المسبقة: 1 . تحتاج فقط إلى إزالة التجميع المسبق، على سبيل المثال، سوف يقوم EIP-7266 بإزالة BLAKE2؛ 2. استبدل التجميع المسبق بقطعة من كود EVM الذي يؤدي نفس العملية (على الرغم من أنه حتما بتكلفة غاز أعلى)." فيما يتعلق بالتاريخ، أشار فيتاليك: "السؤال الرئيسي الذي يجب الإجابة عليه هو: إذا لم يتم تخزين التاريخ القديم بواسطة كل عقدة، فمن الذي سيقوم بتخزينه؟ في الواقع، الكيانات الكبيرة مثل مستكشفات الكتل ستفعل ذلك. ومع ذلك، من الممكن أيضًا ليس من الصعب إنشاء بروتوكولات شبكة نظير إلى نظير لتخزين هذه المعلومات وتسليمها، وهي أكثر ملاءمة لهذه المهمة. إن blockchain Ethereum دائم، ولكن مطالبة كل عقدة بتخزين جميع البيانات بشكل دائم هو نهج "منتهي" للغاية التنفيذ الدائم. شبكة تورنت قديمة بسيطة من نظير إلى نظير هي أحد الأساليب. البروتوكول المُحسّن بشكل أكثر وضوحًا للاستخدام بواسطة Ethereum هو أسلوب آخر. EIP-4444 يمكن أن يحسن بشكل كبير درجة اللامركزية لعقد Ethereum. إذا قامت كل عقدة بتخزين جزء صغير فقط من التاريخ بشكل افتراضي، فمن الناحية النظرية يمكن أن يكون عدد النسخ المخزنة لكل جزء معين من التاريخ هو نفسه تقريبًا كما هو الحال اليوم على الشبكة." فيما يتعلق بإصلاح LOG، أشار فيتاليك: "يمكننا إزالة الازدهار وتبسيط كود تشغيل LOG بحيث يقوم فقط بإنشاء قيمة وتجزئتها إلى الحالة. يمكننا بعد ذلك بنائه باستخدام ZK-SNARKs والبروتوكولات المنفصلة التزايدية لحساب التحقق (IVC) لإنشاء "أشجار سجل" صحيحة يمكن إثباتها والتي تمثل جداول سجل يمكن البحث فيها بسهولة لموضوع معين. يمكن للتطبيقات التي تتطلب سجلات وترغب في أن تكون لا مركزية استخدام هذه البروتوكولات المنفصلة. وفيما يتعلق بالانتقال إلى SSZ، قال فيتاليك: "لقد انتقلت طبقة إجماع إيثريوم إلى SimpleSerialize (SSZ) الأنظف والأكثر كفاءة، ومع ذلك لا يزال يتعين إكمال الانتقال ونقل طبقة التنفيذ إلى نفس البنية. واليوم، هناك ثلاثة التشفير في هياكل البيانات في إيثريوم: الأشجار الثنائية SHA256، وقوائم التجزئة SHA3 RLP، وأشجار باتريشيا السداسية. بمجرد الانتهاء من الانتقال إلى SSZ، لن يتبقى سوى اثنين: الأشجار الثنائية SHA256 وأشجار Verkle. في المستقبل الطويل، بمجرد أن نكون كذلك جيدة بما يكفي للتجزئة باستخدام SNARKs، من الممكن استبدال الأشجار الثنائية SHA256 وأشجار Verkle بأشجار Merkle الثنائية التي تستخدم خوارزمية تجزئة مناسبة لـ SNARKs."