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

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

الهدف الرئيسي من The Purge:

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

انتهاء التاريخ

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

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

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

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

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

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

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

ماذا تحتاج أن تفعل بعد؟ ماذا تحتاج أن توازن؟

تشمل الأعمال الرئيسية المتبقية بناء وتكامل حل موزع محدد لتخزين السجلات التاريخية------على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و blob. الحل الأكثر بساطة هو (i) إدخال مكتبة torrent الحالية، و (ii) التي تُعرف باسم الحل الأصلي لإيثريوم Portal Network. بمجرد إدخال أي من هذه، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صعبًا، لكنه يحتاج بالفعل إلى إصدار جديد من بروتوكول الشبكة. لذلك، يعد تفعيلها لجميع العملاء في نفس الوقت ذا قيمة، وإلا فهناك خطر من أن العميل قد يتعطل بسبب الاتصال بعقد أخرى يتوقع تحميل السجل التاريخي الكامل ولكنه لم يحصل على ذلك فعليًا.

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

1. كيف نبذل جهدًا لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟

2. ما مدى عمق دمج تخزين التاريخ في البروتوكول؟

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

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

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

إذا أردنا جعل تشغيل أو بدء العقدة سهلًا للغاية، فإن تقليل متطلبات تخزين التاريخ يمكن أن يُعتبر أكثر أهمية من عدم الحالة: من بين 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي حالة، بينما حوالي 800 جيجابايت أصبحت تاريخًا. فقط من خلال تحقيق عدم الحالة وEIP-4444 يمكن تحقيق الرؤية التي تتمثل في تشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في دقائق.

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

![فيتاليك: مستقبل إثيريوم المحتمل، التطهير])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###

انتهاء الدولة

( ماذا يحل؟

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

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

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

اليوم، عند إنشاء كائن حالة جديد، يمكن أن يحدث ) بأحد الطرق الثلاث التالية: ### i ( إرسال ETH إلى حساب جديد، ( ii ) استخدام الرمز لإنشاء حساب جديد، ( iii ) إعداد فتحة تخزين لم يتم لمسها من قبل (، يظل كائن الحالة في تلك الحالة إلى الأبد. على العكس، ما نريد هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:

• الكفاءة: لا حاجة إلى حسابات إضافية كبيرة لتشغيل عملية الانتهاء.

• سهولة الاستخدام: إذا دخل شخص ما إلى الكهف لمدة خمس سنوات وعاد، فلا يجب أن يفقد الوصول إلى مراكز ETH و ERC20 و NFT و CDP...

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

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

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

• حلول انتهاء صلاحية بعض الحالات
• اقتراح انتهاء حالة بناءً على周期 العنوان.

(# انتهاء حالة جزئية

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

الفرق الرئيسي بين هذه الاقتراحات هو: ) i ### كيف نحدد "مؤخراً"، و ( ii ) كيف نحدد "كتلة"؟ اقتراح محدد هو EIP-7736، الذي يبني على تصميم "الأغصان" الذي تم تقديمه لشجرة Verkle ( على الرغم من أنه متوافق مع أي شكل من أشكال الحالة غير الحالة، مثل الشجرة الثنائية ). في هذا التصميم، يتم تخزين الرؤوس، الكود، وفتحات التخزين المجاورة لبعضها البعض تحت نفس "الجذع". يمكن أن تكون البيانات المخزنة تحت جذع واحد بحد أقصى 256 * 31 = 7936 بايت. في العديد من الحالات، سيتم تخزين جميع الرؤوس والكود الخاصة بالحساب، بالإضافة إلى العديد من فتحات التخزين، تحت نفس الجذع. إذا لم تتم قراءة أو كتابة البيانات الموجودة تحت الجذع المعين خلال 6 أشهر، فلن يتم تخزين تلك البيانات بعد الآن، ولكن سيتم فقط تخزين التزام 32 بايت لهذه البيانات ( "جذر" ). ستتطلب المعاملات التي ترغب في الوصول إلى تلك البيانات في المستقبل "إحياء" البيانات، وتقديم دليل على الفحص بناءً على الجذر.

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

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