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

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

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

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

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

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

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

تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و blob. أبسط حل هو (i) ببساطة إدخال مكتبة torrent الموجودة، بالإضافة إلى (ii) المعروفة باسم حل إثيريوم الأصلي شبكة Portal. بمجرد إدخال أيٍّ منهما، يمكننا فتح 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) كيف نحدد "