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

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

ترجمة: كيف كان

أود أن أشكر بشكل خاص Justin Drake و Tim Beiko و Matt Garnett و Piper Merriam و Marius van der Wijden و Tomasz Stanczak على ملاحظاتهم ومراجعتهم.

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

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

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

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

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

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

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

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

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

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

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

تنظيف الميزة

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

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

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

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

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

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

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

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

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

EIP-4444 ؛

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

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

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

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

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

ماذا تحتاج للقيام به، وما الذي يجب موازنته؟

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

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

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

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

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