إثيريوم المستقبل المحتمل: The Purge

منذ 14 أكتوبر، نشر مؤسس إثيريوم فيتاليك بوتيرين سلسلة من المقالات النقاشية حول تطوير إثيريوم في المستقبل، بدءًا من "The Merge" وصولاً إلى "The Purge"، حيث عرض رؤيته لتطوير الشبكة الرئيسية لإثيريوم وحل المشكلات الحالية.

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

انتهاء صلاحية التاريخ

ماذا تحل؟

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

ما هو؟ كيف يعمل؟

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

إثيريوم قد بدأت في التخلص من نمط تخزين جميع التاريخ بشكل دائم من قبل جميع العقد. الكتل التوافقية تخزن فقط لمدة حوالي 6 أشهر، والبلوب تخزن فقط لمدة حوالي 18 يوماً. يهدف EIP-4444 إلى تقديم فترة تخزين لمدة عام للكتل التاريخية والإيصالات. الهدف على المدى الطويل هو إنشاء فترة تخزين موحدة تبلغ حوالي 18 يوماً، ثم إنشاء شبكة P2P تتكون من عقد إثيريوم لتخزين البيانات القديمة بشكل موزع.

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

ماذا تحتاج لفعل, وما الذي يجب مراعاته؟

تشمل الأعمال الرئيسية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية. أبسط الحلول هو إدخال مكتبة التورنت الحالية أو ما يسمى بحل إثيريوم الأصلي لشبكة البوابة.

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

مع تفاعل أجزاء أخرى من خارطة الطريق

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

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

انتهاء صلاحية الحالة

ما هي المشكلة التي تحلها؟

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

ما هو؟ كيف يعمل؟

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

هناك نوعان رئيسيان من المخططات:

1. انتهاء حالة جزء منها: تقسيم الحالة إلى أجزاء، وتخزين البيانات التي تم الوصول إليها مؤخرًا فقط. تقترح EIP-7736 حلاً يعتمد على شجرة Verkle، حيث يتم تخزين 32 بايت فقط من الجذر للبيانات التي لم يتم الوصول إليها منذ 6 أشهر.

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

ماذا تحتاج للقيام به، وما الذي يجب موازنته؟

الطرق المحتملة في المستقبل تشمل:

1. تحقيق عدم الحالة، وعدم إدخال حالة انتهاء الصلاحية. تستمر الحالة في النمو ولكن تحتاج فقط إلى تخزين خاص للمستخدم.

2. تنفيذ جزء من حالة انتهاء الصلاحية، وقبول معدل نمو دائم منخفض ولكن غير صفري.

3. تحقيق انتهاء الحالة من خلال توسيع مساحة العنوان. يتطلب عملية طويلة لضمان أمان وفعالية تحويل تنسيق العنوان.

4. تحقيق انتهاء الحالة من خلال تقليص مساحة العنوان. يتطلب الأمر سنوات من العملية لضمان معالجة جميع مخاطر الأمان.

بغض النظر عن الخيار المستخدم، يجب معالجة مشكلة توسيع وتقلص مساحة العنوان، لأن هجمات تصادم العناوين في المستقبل ستصبح أسهل.

تنظيف الميزات

ماذا يحل؟

بسيط بروتوكول هو المفتاح للأمان والوصول والحياد الموثوق. لكن البروتوكول سيصبح افتراضيًا أكثر تعقيدًا مع مرور الوقت. نحن بحاجة إلى القدرة على إزالة الوظائف وتقليل التعقيد.

ما هو ، كيف يعمل؟

لا توجد إصلاحات كبيرة واحدة يمكن أن تقلل من تعقيد البروتوكول، بل يتطلب الأمر العديد من الحلول الصغيرة. تشمل بعض الأمثلة الرئيسية:

• تحويل RLP إلى SSZ: استبدال ترميز RLP بـ SSZ الأفضل
• حذف نوع المعاملة القديمة
• إصلاح LOG: حذف وظائف مثل فلتر بلون غير المستخدم
• حذف آلية لجنة تنسيق سلسلة الإشارات
• توحيد تنسيق البيانات
• حذف لجنة سلسلة الإشارة
• إزالة ترتيب البايت المختلط

أمثلة في EVM:

• تبسيط آلية الغاز
• حذف الترجمة المسبقة
• إزالة قابلية ملاحظة الغاز
• تحسين التحليل الثابت: إزالة التحويل الديناميكي

ماذا يجب أن نفعل بعد ذلك، وما الذي يجب موازنته؟

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

تنسيق كائن EVM ( EOF ) اقترح مجموعة من التغييرات على EVM، والهدف هو السماح بمزيد من التحديثات. من الضروري الموازنة بين التعقيد المتزايد وهدف تبسيط EVM بالكامل.

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