من التحديات التي تواجه إثيريوم هي أن التوسع والتعقيد في أي بروتوكول بلوكتشين يزيدان بمرور الوقت بشكل افتراضي. يحدث ذلك في جانبين: البيانات التاريخية وميزات البروتوكول. لجعل إثيريوم قادرًا على الاستمرار على المدى الطويل، نحتاج إلى تطبيق ضغط مضاد قوي على هاتين الاتجاهين، مما يقلل من التعقيد والتوسع مع مرور الوقت. ولكن في نفس الوقت، نحتاج إلى الاحتفاظ بإحدى الخصائص الأساسية التي تجعل البلوكتشين عظيمًا: الديمومة.
الهدف الرئيسي من 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.
ماذا تحتاج للقيام به، وما الذي يجب موازنته؟
تشمل الأعمال الرئيسية المتبقية بناء وتكامل حل موزع محدد لتخزين السجلات التاريخية------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و blob. أبسط حل هو (i) إدخال مكتبة torrent الحالية، بالإضافة إلى (ii) المعروفة باسم الحل الأصلي لإثيريوم شبكة Portal. بمجرد إدخال أي من هذه، يمكننا فتح EIP-4444. EIP-4444 نفسه لا يتطلب انقسامًا صلبًا، ولكنه يتطلب بالفعل إصدارًا جديدًا من بروتوكول الشبكة. لذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا فهناك خطر أن يفشل العملاء بسبب اتصالهم بعقد أخرى تتوقع تنزيل السجل الكامل ولكن في الواقع لم يتم الحصول عليه.
تشمل الموازنة الرئيسية كيفية سعيينا لتوفير البيانات التاريخية "القديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الموجودة ومختلف مقدمي الخدمة المركزيين للنسخ. هذا سهل، لكنه يضعف وضع إثيريوم كمكان للسجلات الدائمة. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي بناء وتكامل شبكة تورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نكافح لضمان أن أكبر مجموعة من العقد تخزن جميع البيانات بالفعل؟
كم عمق تكامل تخزين التاريخ في البروتوكول؟
طريقة متطرفة للغاية للتطرف بشأن ( ستشمل إثبات الحفظ: تطلب فعليًا من كل موثق إثبات حصة تخزين نسبة معينة من السجل التاريخي، والتحقق منها بشكل دوري بطريقة مشفرة. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة ل )2(، يتضمن التنفيذ الأساسي فقط العمل الذي تم إنجازه اليوم: لقد قام البوابة بتخزين ملف ERA الذي يحتوي على تاريخ إثيريوم بالكامل. سيتطلب التنفيذ الأكثر شمولاً فعليًا ربطه بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة عقدة تخزين التاريخ الكامل أو عقدة أرشيف، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة من شبكة البوابة حتى لو لم تكن هناك عقد أرشيفية أخرى متصلة.
) كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
إذا كنا نريد جعل تشغيل أو بدء العقدة أمراً سهلاً للغاية، فيمكن القول إن تقليل متطلبات التخزين التاريخي أكثر أهمية من الحالة غير الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي حالة، والباقي حوالي 800 جيجابايت أصبح تاريخياً. فقط من خلال تحقيق الحالة غير الحالة و EIP-4444 يمكن تحقيق الرؤية التي تسمح بتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن تحقيق عقد إثيريوم الأحدث، حيث تدعم فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016 قد تم حذفها جميعًا. الآن بعد أن أصبح التحول إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
حتى لو قمنا بإزالة الحاجة إلى تخزين تاريخ العميل، فإن احتياجات التخزين للعميل ستستمر في النمو بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، كود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أصعب من التاريخ في "انتهاء الصلاحية"، لأن EVM صُممت أساسًا حول فرضية أنه بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة الوصول إليه في أي وقت. إذا أدخلنا عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئات مُنشئي الكتل المتخصصين تحتاج إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى ### حتى تضمين قائمة التوليد! ( العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إنه لا نريد الاعتماد بشكل مفرط على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة تنتهي صلاحيتها للحفاظ على لامركزية إثيريوم.
) ما هو؟ كيف يعمل؟
اليوم، عندما تقوم بإنشاء كائن حالة جديد، يمكن أن يحدث ### بواحدة من الطرق الثلاث التالية: ( i ( إرسال ETH إلى حساب جديد، ) ii ( إنشاء حساب جديد باستخدام الشيفرة، ) iii ( إعداد فتحة تخزين لم تُلمس من قبل )، حيث يبقى كائن الحالة في تلك الحالة إلى الأبد. على العكس من ذلك، ما نريده هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا حاجة للكثير من الحسابات الإضافية لتشغيل عملية انتهاء الصلاحية.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد حق الوصول إلى ETH و ERC20 و NFT و CDP...
سهولة استخدام المطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات الحالية المتجمدة والتي لا تتلقى تحديثات في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم الوفاء بهذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية، ويمكن تمديد تاريخ انتهاء الصلاحية من خلال حرق ETH، وقد يحدث هذا تلقائيًا عند القراءة أو الكتابة في أي وقت، ويكون هناك عملية لتكرار الحالة لحذف كائنات حالة تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية إضافية حتى متطلبات تخزين، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في الاستدلال على حالات الحافة التي تتضمن تخزين القيم التي تعيد تعيينها أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية داخل نطاق العقد، فإن هذا يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يصعب الأمور من الناحية الاقتصادية: يجب على المطورين التفكير في كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
تلك هي المشاكل التي عملت عليها مجتمع تطوير إثيريوم الأساسي لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، قمنا بدمج أفضل أجزاء من المقترحات وركزنا على فئتين من "أفضل الحلول المعروفة الأقل سوءًا":
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يحتفظ الجميع بـ "خريطة القمة" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
الاختلاف الرئيسي بين هذه الاقتراحات هو: (i )كيف نعرف "الأحدث"، و (ii )كيف نعرف "الكتلة"؟ اقتراح محدد هو EIP-7736، الذي يعتمد على تصميم "الجذع" الذي تم تقديمه لشجرة Verkle ###على الرغم من توافقه مع أي شكل من أشكال الحالة بدون حالة، مثل الشجرة الثنائية (. في هذا التصميم، يتم تخزين الرؤوس، الكود، وفتحات التخزين المجاورة لبعضها البعض تحت "الجذع" نفسه. يمكن أن يكون الحد الأقصى للبيانات المخزنة تحت الجذع 256 * 31 = 7,936 بايت. في العديد من الحالات، سيتم تخزين كامل رأس الحساب والكود والعديد من فتحات التخزين في نفس الجذع. إذا لم يتم قراءة أو كتابة البيانات المخزنة تحت الجذع المعطى خلال 6 أشهر، فلن تُخزن تلك البيانات بعد الآن، بل سيتم فقط تخزين الالتزام البالغ 32 بايت لتلك البيانات )"الجذع" (. ستحتاج المعاملات للوصول إلى تلك البيانات في المستقبل إلى "إعادة إحياء" البيانات، وتقديم دليل للتحقق بناءً على الجذع.
هناك طرق أخرى لتحقيق أفكار مماثلة. على سبيل المثال، إذا كانت دقة مستوى الحساب غير كافية، يمكننا وضع خطة يتحكم فيها كل جزء من 1/232 من الشجرة بواسطة آلية مشابهة للساق والأوراق.
نظرًا للعوامل التحفيزية، أصبح هذا الأمر أكثر تعقيدًا: يمكن للمهاجمين "تحديث الشجرة" من خلال إدخال كميات كبيرة من البيانات في شجرة فرعية واحدة وإرسال معاملة واحدة سنويًا، مما يجبر العميل على تخزين حالة كبيرة بشكل دائم. إذا جعلت تكلفة التجديد تتناسب مع حجم الشجرة ) أو تتناسب عكسيًا مع مدة التجديد (، فقد يتمكن شخص ما من إيذاء مستخدمين آخرين من خلال إدخال كميات كبيرة من البيانات في نفس الشجرة الفرعية الخاصة بهم. يمكن للناس محاولة تقييد هذين المشكلتين من خلال جعل الدقة ديناميكية بناءً على حجم الشجرة الفرعية: على سبيل المثال، يمكن اعتبار كل 216= 65536 كائن حالة كـ "مجموعة". ومع ذلك، فإن هذه الأفكار أكثر تعقيدًا؛ فأسلوب القاعدة بسيط، ويمكن تعديل الحوافز، لأن القاعدة عادةً تحت
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 6
أعجبني
6
6
إعادة النشر
مشاركة
تعليق
0/400
AirdropHunterXiao
· منذ 15 س
أشعر بشيء من التوقعات لتنظيف بيانات القمامة
شاهد النسخة الأصليةرد0
pumpamentalist
· منذ 15 س
ايثر又整新活儿嗷
شاهد النسخة الأصليةرد0
MevHunter
· منذ 15 س
متى سيتم إطلاق الـ purge يا إخوان، أرى أن التكاليف قد ارتفعت مرة أخرى.
شاهد النسخة الأصليةرد0
MysteriousZhang
· منذ 15 س
من الجيد أن ننظف قليلاً، فبيانات التاريخ هذه متضخمة للغاية.
شاهد النسخة الأصليةرد0
EntryPositionAnalyst
· منذ 15 س
الخبز المسطح ليس كبيرا بما يكفي ~ استمر في ترميز الكود
إثيريوم مستقبل خارطة الطريق: The Purge يهدف إلى تبسيط بروتوكول اسقاط التضخم
إثيريوم المستقبل المحتمل: The Purge
من التحديات التي تواجه إثيريوم هي أن التوسع والتعقيد في أي بروتوكول بلوكتشين يزيدان بمرور الوقت بشكل افتراضي. يحدث ذلك في جانبين: البيانات التاريخية وميزات البروتوكول. لجعل إثيريوم قادرًا على الاستمرار على المدى الطويل، نحتاج إلى تطبيق ضغط مضاد قوي على هاتين الاتجاهين، مما يقلل من التعقيد والتوسع مع مرور الوقت. ولكن في نفس الوقت، نحتاج إلى الاحتفاظ بإحدى الخصائص الأساسية التي تجعل البلوكتشين عظيمًا: الديمومة.
الهدف الرئيسي من 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.
ماذا تحتاج للقيام به، وما الذي يجب موازنته؟
تشمل الأعمال الرئيسية المتبقية بناء وتكامل حل موزع محدد لتخزين السجلات التاريخية------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و blob. أبسط حل هو (i) إدخال مكتبة torrent الحالية، بالإضافة إلى (ii) المعروفة باسم الحل الأصلي لإثيريوم شبكة Portal. بمجرد إدخال أي من هذه، يمكننا فتح EIP-4444. EIP-4444 نفسه لا يتطلب انقسامًا صلبًا، ولكنه يتطلب بالفعل إصدارًا جديدًا من بروتوكول الشبكة. لذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا فهناك خطر أن يفشل العملاء بسبب اتصالهم بعقد أخرى تتوقع تنزيل السجل الكامل ولكن في الواقع لم يتم الحصول عليه.
تشمل الموازنة الرئيسية كيفية سعيينا لتوفير البيانات التاريخية "القديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الموجودة ومختلف مقدمي الخدمة المركزيين للنسخ. هذا سهل، لكنه يضعف وضع إثيريوم كمكان للسجلات الدائمة. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي بناء وتكامل شبكة تورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
طريقة متطرفة للغاية للتطرف بشأن ( ستشمل إثبات الحفظ: تطلب فعليًا من كل موثق إثبات حصة تخزين نسبة معينة من السجل التاريخي، والتحقق منها بشكل دوري بطريقة مشفرة. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة ل )2(، يتضمن التنفيذ الأساسي فقط العمل الذي تم إنجازه اليوم: لقد قام البوابة بتخزين ملف ERA الذي يحتوي على تاريخ إثيريوم بالكامل. سيتطلب التنفيذ الأكثر شمولاً فعليًا ربطه بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة عقدة تخزين التاريخ الكامل أو عقدة أرشيف، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة من شبكة البوابة حتى لو لم تكن هناك عقد أرشيفية أخرى متصلة.
) كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
إذا كنا نريد جعل تشغيل أو بدء العقدة أمراً سهلاً للغاية، فيمكن القول إن تقليل متطلبات التخزين التاريخي أكثر أهمية من الحالة غير الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي حالة، والباقي حوالي 800 جيجابايت أصبح تاريخياً. فقط من خلال تحقيق الحالة غير الحالة و EIP-4444 يمكن تحقيق الرؤية التي تسمح بتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن تحقيق عقد إثيريوم الأحدث، حيث تدعم فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016 قد تم حذفها جميعًا. الآن بعد أن أصبح التحول إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
![فيتاليك: مستقبل إثيريوم المحتمل، التطهير]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(
انتهاء صلاحية الدولة
) ماذا تحل؟
حتى لو قمنا بإزالة الحاجة إلى تخزين تاريخ العميل، فإن احتياجات التخزين للعميل ستستمر في النمو بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، كود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أصعب من التاريخ في "انتهاء الصلاحية"، لأن EVM صُممت أساسًا حول فرضية أنه بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة الوصول إليه في أي وقت. إذا أدخلنا عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئات مُنشئي الكتل المتخصصين تحتاج إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى ### حتى تضمين قائمة التوليد! ( العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إنه لا نريد الاعتماد بشكل مفرط على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة تنتهي صلاحيتها للحفاظ على لامركزية إثيريوم.
) ما هو؟ كيف يعمل؟
اليوم، عندما تقوم بإنشاء كائن حالة جديد، يمكن أن يحدث ### بواحدة من الطرق الثلاث التالية: ( i ( إرسال ETH إلى حساب جديد، ) ii ( إنشاء حساب جديد باستخدام الشيفرة، ) iii ( إعداد فتحة تخزين لم تُلمس من قبل )، حيث يبقى كائن الحالة في تلك الحالة إلى الأبد. على العكس من ذلك، ما نريده هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
من السهل حل المشكلات إذا لم يتم الوفاء بهذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية، ويمكن تمديد تاريخ انتهاء الصلاحية من خلال حرق ETH، وقد يحدث هذا تلقائيًا عند القراءة أو الكتابة في أي وقت، ويكون هناك عملية لتكرار الحالة لحذف كائنات حالة تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية إضافية حتى متطلبات تخزين، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في الاستدلال على حالات الحافة التي تتضمن تخزين القيم التي تعيد تعيينها أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية داخل نطاق العقد، فإن هذا يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يصعب الأمور من الناحية الاقتصادية: يجب على المطورين التفكير في كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
تلك هي المشاكل التي عملت عليها مجتمع تطوير إثيريوم الأساسي لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، قمنا بدمج أفضل أجزاء من المقترحات وركزنا على فئتين من "أفضل الحلول المعروفة الأقل سوءًا":
![فيتالك: مستقبل إثيريوم المحتمل، التطهير])https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp(
)# انتهاء الحالة الجزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يحتفظ الجميع بـ "خريطة القمة" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
الاختلاف الرئيسي بين هذه الاقتراحات هو: (i )كيف نعرف "الأحدث"، و (ii )كيف نعرف "الكتلة"؟ اقتراح محدد هو EIP-7736، الذي يعتمد على تصميم "الجذع" الذي تم تقديمه لشجرة Verkle ###على الرغم من توافقه مع أي شكل من أشكال الحالة بدون حالة، مثل الشجرة الثنائية (. في هذا التصميم، يتم تخزين الرؤوس، الكود، وفتحات التخزين المجاورة لبعضها البعض تحت "الجذع" نفسه. يمكن أن يكون الحد الأقصى للبيانات المخزنة تحت الجذع 256 * 31 = 7,936 بايت. في العديد من الحالات، سيتم تخزين كامل رأس الحساب والكود والعديد من فتحات التخزين في نفس الجذع. إذا لم يتم قراءة أو كتابة البيانات المخزنة تحت الجذع المعطى خلال 6 أشهر، فلن تُخزن تلك البيانات بعد الآن، بل سيتم فقط تخزين الالتزام البالغ 32 بايت لتلك البيانات )"الجذع" (. ستحتاج المعاملات للوصول إلى تلك البيانات في المستقبل إلى "إعادة إحياء" البيانات، وتقديم دليل للتحقق بناءً على الجذع.
هناك طرق أخرى لتحقيق أفكار مماثلة. على سبيل المثال، إذا كانت دقة مستوى الحساب غير كافية، يمكننا وضع خطة يتحكم فيها كل جزء من 1/232 من الشجرة بواسطة آلية مشابهة للساق والأوراق.
نظرًا للعوامل التحفيزية، أصبح هذا الأمر أكثر تعقيدًا: يمكن للمهاجمين "تحديث الشجرة" من خلال إدخال كميات كبيرة من البيانات في شجرة فرعية واحدة وإرسال معاملة واحدة سنويًا، مما يجبر العميل على تخزين حالة كبيرة بشكل دائم. إذا جعلت تكلفة التجديد تتناسب مع حجم الشجرة ) أو تتناسب عكسيًا مع مدة التجديد (، فقد يتمكن شخص ما من إيذاء مستخدمين آخرين من خلال إدخال كميات كبيرة من البيانات في نفس الشجرة الفرعية الخاصة بهم. يمكن للناس محاولة تقييد هذين المشكلتين من خلال جعل الدقة ديناميكية بناءً على حجم الشجرة الفرعية: على سبيل المثال، يمكن اعتبار كل 216= 65536 كائن حالة كـ "مجموعة". ومع ذلك، فإن هذه الأفكار أكثر تعقيدًا؛ فأسلوب القاعدة بسيط، ويمكن تعديل الحوافز، لأن القاعدة عادةً تحت