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

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

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

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

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

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

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

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

تقليل تعقيد البروتوكول عن طريق إزالة الميزات غير الضرورية.

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

تاريخ انتهاء الصلاحية (历史记录到期)

حالة انتهاء الصلاحية（状态到期）

تنظيف الميزة

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

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

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

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

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

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

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

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

ما هي الروابط مع الأبحاث الحالية؟

EIP-4444 ؛

التورنتات وEIP-4444؛

شبكة البوابة؛

شبكة البوابة و EIP-4444؛

تخزين واسترجاع الكائنات SSZ في Portal بشكل موزع؛

كيف يمكن زيادة حد الغاز (بارادايم).

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

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

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

كيف نسعى لضمان أن أكبر مجموعة من العقد تخزن جميع البيانات بالفعل؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الفرق الرئيسي بين هذه الاقتراحات هو: (i) كيف نعرّف "الأخيرة" ،