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

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

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

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

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

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

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.

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

EIP-4444 ؛

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

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

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

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

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

ماذا تحتاج للقيام به بعد ذلك، وما الذي يجب weighing عليه؟

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

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

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

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

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

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

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