إثيريوم تواجه تحديًا يتمثل في أن التوسع والتعقيد الافتراضي لأي بروتوكول بلوكتشين سيزداد مع مرور الوقت. يحدث هذا في جانبين:
البيانات التاريخية: يجب تخزين جميع المعاملات والحسابات التي تم إنشاؤها في أي وقت بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها للتزامن الكامل مع الشبكة. وهذا يؤدي إلى زيادة الحمل على العملاء ووقت التزامن باستمرار، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
للحفاظ على إيثريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على الاتجاهين، مع تقليل التعقيد والتضخم بمرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الاحتفاظ بإحدى الخصائص الأساسية التي تجعل البلوكشين عظيمًا: الدوام. يمكنك وضع 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 الموزعة في Portal;
كيف يمكن زيادة حد الغاز ( Paradigm ).
ماذا يجب أن نفعل بعد ذلك، وما الذي يجب أن نوازن بينه؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية------على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع وblob. الحل الأبسط هو (i) ببساطة إدخال مكتبة التورنت الموجودة، بالإضافة إلى (ii) المعروفة باسم حل إيثريوم الأصلي Portal network. بمجرد إدخال أي من هذين، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صارمًا، لكنه يتطلب إصدار بروتوكول شبكة جديد. لذلك، من المهم تفعيله لجميع العملاء في نفس الوقت، وإلا فإن هناك خطر تعطل العملاء بسبب اتصالهم بعقد أخرى يتوقعون تحميل السجلات التاريخية الكاملة ولكنهم لم يحصلوا عليها فعليًا.
تتعلق الموازنة الرئيسية بكيفية سعيينا لتوفير بيانات تاريخية "قديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الموجودة ومزودي الخدمات المركزية المختلفين للنسخ. هذا سهل، لكنه يضعف وضع إثيريوم كمكان للسجلات الدائمة. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي بناء وتكامل شبكة التورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نبذل جهدًا لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما مدى عمق تكامل تخزين التاريخ في البروتوكول؟
تتضمن طريقة متطرفة للغاية من أجل ( إثبات الحفظ: تطلب فعليًا من كل مُصادق على إثبات الملكية تخزين نسبة معينة من السجلات التاريخية، والتحقق منها بانتظام بطريقة مشفرة. الطريقة الأكثر اعتدالاً هي تعيين معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ )2(، فإن التنفيذ الأساسي يتضمن فقط العمل الذي اكتمل اليوم: لقد خزّن Portal ملفات 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
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 11
أعجبني
11
7
مشاركة
تعليق
0/400
NotGonnaMakeIt
· 07-16 18:58
البلوكتشين الضخم 累死新机器了吧
شاهد النسخة الأصليةرد0
MysteryBoxBuster
· 07-15 00:26
هذه السلسلة أصبحت ثقيلة بشكل متزايد
شاهد النسخة الأصليةرد0
SquidTeacher
· 07-14 03:56
لدي فكرة، كل شيء على ما يرام.
شاهد النسخة الأصليةرد0
GasFeeCrier
· 07-14 03:53
الآن هو الوقت الأكثر سمنة، أليس كذلك؟
شاهد النسخة الأصليةرد0
DefiOldTrickster
· 07-14 03:52
داخل السلسلة يبدو أنه نبي عظيم آخر
شاهد النسخة الأصليةرد0
GasBandit
· 07-14 03:47
متى يمكننا أن نتفوق على التضخم
شاهد النسخة الأصليةرد0
StablecoinArbitrageur
· 07-14 03:29
*يعدل جداول البيانات* بناءً على تحليل علاقتي، كفاءة التطهير = استدامة الشبكة * -0.89
إثيريوم The Purge: بناء نظام إيكولوجي مستدام على المدى الطويل للبلوكتشين
إثيريوم المستقبل المحتمل: The Purge
إثيريوم تواجه تحديًا يتمثل في أن التوسع والتعقيد الافتراضي لأي بروتوكول بلوكتشين سيزداد مع مرور الوقت. يحدث هذا في جانبين:
البيانات التاريخية: يجب تخزين جميع المعاملات والحسابات التي تم إنشاؤها في أي وقت بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها للتزامن الكامل مع الشبكة. وهذا يؤدي إلى زيادة الحمل على العملاء ووقت التزامن باستمرار، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
للحفاظ على إيثريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على الاتجاهين، مع تقليل التعقيد والتضخم بمرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الاحتفاظ بإحدى الخصائص الأساسية التي تجعل البلوكشين عظيمًا: الدوام. يمكنك وضع NFT، أو رسالة حب، أو عقد ذكي يحتوي على مليون دولار على السلسلة، والدخول إلى كهف لمدة عشر سنوات، وعند الخروج تجدها لا تزال موجودة هناك في انتظارك للقراءة والتفاعل. لكي تكون DApp مطمئنة تمامًا لعدم المركزية وحذف مفتاح الترقية، يحتاجون إلى التأكد من أن تبعياتهم لن يتم ترقيتها بطريقة تضر بهم - وخاصة L1 نفسها.
إذا عزمنا على تحقيق توازن بين هذين الطلبين، وتقليل أو عكس التكتل، التعقيد والانحدار مع الحفاظ على الاستمرارية، فإن هذا ممكن تمامًا. تستطيع الكائنات الحية القيام بذلك: على الرغم من أن معظم الكائنات الحية تتقدم في العمر مع مرور الوقت، فإن عددًا قليلاً من المحظوظين لا يفعلون ذلك. حتى الأنظمة الاجتماعية يمكن أن تتمتع بعمر طويل جدًا. في بعض الحالات، حقق إثيريوم النجاح: اختفى إثبات العمل، واختفى معظم رمز العملية SELFDESTRUCT، وقد خزنت عقدة سلسلة الإشارة بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذا الطريق لإثيريوم بطريقة أكثر عمومية، والسير نحو نتيجة نهائية مستقرة على المدى الطويل، هو التحدي النهائي لقابلية التوسع على المدى الطويل، والاستدامة التقنية وحتى الأمان لإثيريوم.
الطهر: الهدف الرئيسي.
تقليل متطلبات تخزين العميل من خلال تقليل أو القضاء على الحاجة إلى تخزين جميع السجلات التاريخية أو حتى الحالة النهائية من قبل كل عقدة بشكل دائم.
تقليل تعقيد البروتوكول من خلال إزالة الوظائف غير الضرورية.
محتويات المقال:
تاريخ انتهاء الصلاحية(سجل التاريخ انتهى) حالة انتهاء الصلاحية(حالة انتهاء الصلاحية) تنظيف المميزات(特征清理)
تاريخ انتهاء الصلاحية
ما هي المشكلة التي يتم حلها؟
حتى وقت كتابة هذه المقالة، يحتاج عقد إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى مئات الجيجابايت من مساحة القرص لعميل الإجماع. معظم هذه البيانات هي تاريخية: بيانات حول الكتل التاريخية، والمعاملات، والإيصالات، والتي يعود تاريخ معظمها لعدة سنوات. وهذا يعني أنه حتى إذا لم تزد قيود الغاز على الإطلاق، فإن حجم العقد سيستمر في الزيادة بمئات الجيجابايت سنويًا.
! فيتاليك: مستقبل Ethereum المحتمل ، The Purge
ما هو، كيف يعمل؟
تتمثل إحدى الميزات الرئيسية لتبسيط مشكلة التخزين التاريخي في أنه نظرًا لأن كل كتلة مرتبطة بالكتلة السابقة من خلال التجزئة ( وهياكل أخرى )، فإن التوصل إلى توافق بشأن الحالة الحالية يكفي للتوصل إلى توافق بشأن التاريخ. طالما أن الشبكة تتفق على الكتلة الأحدث، يمكن لأي مشارك فردي توفير أي كتلة تاريخية أو معاملة أو حالة ( من أرصدة الحسابات، أو الأرقام العشوائية، أو الشفرات، أو التخزين )، بالإضافة إلى دليل ميركل، ويسمح هذا الدليل لأي شخص آخر بالتحقق من صحته. التوافق هو نموذج ثقة 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 الموزعة في Portal;
كيف يمكن زيادة حد الغاز ( Paradigm ).
ماذا يجب أن نفعل بعد ذلك، وما الذي يجب أن نوازن بينه؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية------على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع وblob. الحل الأبسط هو (i) ببساطة إدخال مكتبة التورنت الموجودة، بالإضافة إلى (ii) المعروفة باسم حل إيثريوم الأصلي Portal network. بمجرد إدخال أي من هذين، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صارمًا، لكنه يتطلب إصدار بروتوكول شبكة جديد. لذلك، من المهم تفعيله لجميع العملاء في نفس الوقت، وإلا فإن هناك خطر تعطل العملاء بسبب اتصالهم بعقد أخرى يتوقعون تحميل السجلات التاريخية الكاملة ولكنهم لم يحصلوا عليها فعليًا.
تتعلق الموازنة الرئيسية بكيفية سعيينا لتوفير بيانات تاريخية "قديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الموجودة ومزودي الخدمات المركزية المختلفين للنسخ. هذا سهل، لكنه يضعف وضع إثيريوم كمكان للسجلات الدائمة. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي بناء وتكامل شبكة التورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نبذل جهدًا لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما مدى عمق تكامل تخزين التاريخ في البروتوكول؟
تتضمن طريقة متطرفة للغاية من أجل ( إثبات الحفظ: تطلب فعليًا من كل مُصادق على إثبات الملكية تخزين نسبة معينة من السجلات التاريخية، والتحقق منها بانتظام بطريقة مشفرة. الطريقة الأكثر اعتدالاً هي تعيين معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ )2(، فإن التنفيذ الأساسي يتضمن فقط العمل الذي اكتمل اليوم: لقد خزّن Portal ملفات ERA التي تحتوي على تاريخ إثيريوم بالكامل. سيتضمن التنفيذ الأكثر شمولاً ربطه فعلياً بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة سجل التاريخ الكامل من عقد التخزين أو عقد الأرشفة، حتى لو لم يكن هناك أي عقد أرشفة أخرى متاحة على الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة من شبكة البوابة.
)# كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟
إذا أردنا جعل تشغيل أو بدء العقدة سهلاً للغاية، فإن تقليل متطلبات التخزين التاريخي يمكن أن يُعتبر أكثر أهمية من عدم الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي الحالة، والباقي حوالي 800 جيجابايت أصبح تاريخياً. فقط من خلال تحقيق عدم الحالة وEIP-4444 يمكن تحقيق الرؤية لتشغيل عقدة إيثريوم على ساعة ذكية وإعدادها في بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن أيضًا تنفيذ عقد إثيريوم الأحدث بشكل أكثر قابلية للتطبيق، حيث تدعم فقط أحدث إصدار من البروتوكول، مما يجعلها أكثر بساطة. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي أنشئت خلال هجوم DoS في عام 2016 قد تم حذفها بالكامل. الآن بعد أن أصبح التحول إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
انتهاء الدولة
ما المشكلة التي تحلها؟
حتى لو أزلنا الحاجة إلى تخزين سجل العميل, ستستمر متطلبات التخزين لدى العميل في النمو, بمعدل حوالي 50 جيجابايت سنويًا, لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية, وكود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة, مما يؤدي إلى تحميل عبء دائم للعملاء الحاليين والمستقبليين لإثيريوم.
الحالة أكثر صعوبة من التاريخ "منتهية الصلاحية"، لأن EVM مصممة أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن قراءته في أي وقت من قبل أي معاملة. إذا أدخلنا عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة محددة من منشئي الكتل تحتاج إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى ### حتى قائمة التوليد! ( أن تعمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إننا لا نريد الاعتماد كثيرًا على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة منتهية الصلاحية للحفاظ على لامركزية إيثيريوم.
![فيتالك: مستقبل إثيريوم المحتمل، التطهير])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(
)# ما هو، كيف يعمل
اليوم، عندما تقوم بإنشاء كائن حالة جديد، يمكن أن يحدث ### بإحدى الطرق الثلاث التالية: ( i ( إرسال ETH إلى حساب جديد، ) ii ( إنشاء حساب جديد باستخدام الكود، ) iii ( تعيين فتحة تخزين لم تُستخدم من قبل )، ويظل هذا الكائن في تلك الحالة إلى الأبد. على العكس، ما نريده هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو تحقيق ذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا حاجة إلى الكثير من الحسابات الإضافية لتشغيل عملية انتهاء الصلاحية.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH وERC20 وNFT وCDP.
سهولة استخدام المطورين: لا يتعين على المطورين الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي لم تعد مُحدثة والتي أصبحت متجمدة في العمل بشكل طبيعي.
من السهل جدًا حل المشكلات إذا لم يتم تحقيق هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية يمكن تمديده عن طريق حرق ETH، وهذا قد يحدث تلقائيًا في أي وقت يتم فيه القراءة أو الكتابة، ويكون هناك عملية للتكرار عبر الحالة لحذف كائنات الحالة ذات تواريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية إضافية حتى متطلبات تخزين، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما أن المطورين يجدون صعوبة في التفكير في الحالات الحدية التي تتضمن قيم التخزين التي يتم إعادة تعيينها أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فإن ذلك يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يفكروا في كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدم.
هذه كلها قضايا كان مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات عديدة، بما في ذلك اقتراحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء الاقتراحات وركزنا على نوعين من "أفضل الحلول المعروفة الأقل سوءًا":
)# انتهاء حالة جزئية
تتبع بعض مقترحات الحالة المنتهية نفس المبادئ. نحن نقسم الحالة إلى كتل. يقوم الجميع بتخزين "خريطة القمة" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. سيتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
الفرق الرئيسي بين هذه الاقتراحات هو: (i) كيف نعرف "الأخيرة"، و(ii) كيف نعرف "الكتلة"؟ أحد الاقتراحات المحددة هو EIP-7736، الذي يعتمد على تصميم "الزنبور" الذي تم تقديمه لشجرة Verkle ### على الرغم من توافقه مع أي شكل من أشكال الحالة غير الحالة، مثل الشجرة الثنائية (. في هذا التصميم، يتم تخزين الرؤوس والرموز وفتحات التخزين المجاورة لبعضها البعض تحت "الجذع" نفسه. يمكن أن تصل البيانات المخزنة تحت جذع واحد إلى 256 * 31 = 7,936