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

إحدى التحديات التي تواجه إثيريوم هي أن التضخم والتعقيد لأي بروتوكول بلوكتشين يزيد بمرور الوقت بشكل افتراضي. يحدث هذا في مكانين:

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

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

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

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

الطرد: الهدف الرئيسي.

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

• تقليل تعقيد البروتوكول من خلال إزالة الوظائف غير الضرورية.

فهرس المقالة:

• تاريخ انتهاء الصلاحية
• انتهاء الحالة
• تنظيف الميزات

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

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

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

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

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

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

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

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

ما هي العلاقة مع الأبحاث الحالية؟

• EIP-4444 ؛
• تورنتات و EIP-4444؛
• شبكة البوابة؛
• شبكة البوابة وEIP-4444؛
• التخزين والاسترجاع الموزع لكائنات SSZ في البوابة؛
• كيفية زيادة حد الغاز (بارادايم).

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

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

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

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

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

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

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

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

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

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

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

ماذا يحل؟

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

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

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

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

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

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

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

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

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

• حلول انتهاء صلاحية الحالة الجزئية
• اقتراح انتهاء حالة بناءً على دورة العنوان.

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

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