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

المؤلف: فيتالik بوترين

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

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

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

لكي يتمكن إثيريوم من الاستمرار على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هاتين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في نفس الوقت، نحن بحاجة إلى الاحتفاظ بأحد الخصائص الرئيسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع 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؛

شبكة Portal؛

شبكة Portal و EIP-4444؛

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الفرق الرئيسي بين هذه المقترحات هو: (i) نحن كما