إثيريوم تواجه تحديًا واحدًا وهو أنه بشكل افتراضي، فإن التوسع والتعقيد لأي بروتوكول بلوكتشين سيزداد مع مرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب على جميع العملاء تخزين أي معاملة تمت في أي وقت تاريخي وأي حساب تم إنشاؤه بشكل دائم، ويجب على أي عميل جديد تنزيلها، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة عبء العملاء ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: إضافة ميزات جديدة أسهل بكثير من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
لضمان استمرار إيثريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هذين الاتجاهين، مع تقليل التعقيد والتضخم بمرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الاحتفاظ بأحد الخصائص الرئيسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع 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 يومًا (، حيث تكون كل عقدة مسؤولة عن تخزين كل شيء، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم، تخزن البيانات القديمة بطريقة موزعة.
![فيتاليك: المستقبل المحتمل لإثيريوم، التطهير])يان/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(
يمكن استخدام رموز الحذف لزيادة المتانة مع الحفاظ على نفس عامل النسخ. في الواقع، تم تطبيق رموز الحذف على Blob لدعم أخذ عينات توفر البيانات. من المحتمل أن تكون أبسط حل هو إعادة استخدام هذه الرموز ووضع تنفيذ وبيانات كتلة الإجماع أيضًا داخل blob.
) ما هي العلاقة مع الأبحاث الحالية؟
EIP-4444 ؛
تورنات و EIP-4444;
شبكة البوابة;
شبكة البوابة و EIP-4444;
تخزين واسترجاع الكائنات SSZ الموزعة في البوابة;
كيف يمكن زيادة حد الغاز ### بارادايجم (.
) ماذا يجب أن نفعل بعد ذلك، وما الذي يتعين موازنته؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجل التاريخي------على الأقل سجل التنفيذ، ولكن في النهاية يتضمن أيضًا الإجماع و blob. أبسط حل هو ###i( ببساطة إدخال مكتبة torrent الموجودة، بالإضافة إلى )ii( المعروفة باسم حل إثيريوم الأصلي شبكة Portal. بمجرد إدخال أي من هذه، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صعبًا، ولكنه يتطلب بالفعل إصدارًا جديدًا من بروتوكول الشبكة. لذلك، من المفيد تمكينه في نفس الوقت لجميع العملاء، وإلا هناك خطر فشل العملاء بسبب الاتصال بعقد أخرى تتوقع تنزيل السجل الكامل ولكنها لم تحصل عليه في الواقع.
الاعتبارات الرئيسية تتعلق بكيفية努力نا لتقديم بيانات "التاريخ القديم". أبسط حل هو التوقف عن تخزين التاريخ القديم غداً، والاعتماد على العقد الأرشيفية الموجودة ومقدمي الخدمات المركزية المختلفة للنسخ. هذا سهل، لكنه يضعف مكانة إثيريوم كمكان سجلات دائمة. الطريقة الأكثر صعوبة ولكن الأكثر أماناً هي أولاً بناء وتكامل شبكة التورنت، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نحاول التأكد من أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما عمق تكامل تخزين التاريخ في البروتوكول؟
تعني طريقة متطرفة للغاية تجاه ) تتعلق بإثبات الحضانة: حيث يتطلب فعليًا من كل مُحقق في إثبات الحصة تخزين نسبة معينة من السجل التاريخي، والتحقق بانتظام بطريقة مشفرة مما إذا كانوا يقومون بذلك. طريقة أكثر اعتدالًا هي تحديد معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ (2)، فإن التنفيذ الأساسي يتضمن فقط العمل الذي تم إنجازه اليوم: لقد خزن البوابة ملف ERA الذي يحتوي على تاريخ إثيريوم بالكامل. سيتطلب التنفيذ الأكثر شمولاً ربطه فعلياً بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة عقدة تخزين التاريخ الكامل أو عقدة الأرشيف، يمكنهم تحقيق ذلك عن طريق المزامنة المباشرة من شبكة البوابة حتى لو لم تكن هناك عقد أرشيفية أخرى متصلة.
( كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
إذا أردنا أن نجعل تشغيل أو بدء العقدة سهلًا للغاية، فيمكن القول إن تقليل متطلبات التخزين التاريخي أكثر أهمية من عدم الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 غيغابايت هي حالة، والباقي حوالي 800 غيغابايت أصبح تاريخيًا. فقط من خلال تحقيق عدم الحالة وEIP-4444، يمكن تحقيق الرؤية لتشغيل عقدة إيثيريوم على ساعة ذكية وإعدادها في بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن تنفيذ عقد إثيريوم الأحدث بشكل أكثر فعالية، حيث تدعم فقط أحدث إصدارات البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر التعليمات البرمجية بأمان، حيث تم حذف جميع فتحات التخزين الفارغة التي تم إنشاؤها خلال هجمات DoS في عام 2016. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء بأمان حذف جميع التعليمات البرمجية المتعلقة بإثبات العمل.
![فيتاليك: المستقبل المحتمل لإثيريوم، التنظيف])ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg###
انتهاء حالة
( ماذا يحل؟
حتى لو أزلنا الحاجة إلى تخزين سجل العميل, ستستمر احتياجات تخزين العميل في النمو بمعدل حوالي 50 غيغابايت سنويًا, لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية, وكود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة, مما سيثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أصعب من التاريخ "الانتهاء"، لأن EVM مصمم أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا ويمكن قراءته في أي وقت بواسطة أي معاملة. إذا قمنا بإدخال عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة معينة من بناة الكتل تحتاج فعليًا إلى تخزين الحالة، بينما يمكن لجميع العقد الأخرى ) حتى قائمة التوليد! ### العمل بدون حالة. ومع ذلك، هناك وجهة نظر مفادها أننا لا نريد الاعتماد بشكل مفرط على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة تنتهي للحفاظ على لامركزية إثيريوم.
( ما هو؟ كيف يعمل؟
اليوم، عند إنشاء كائن حالة جديد، يمكن أن يحدث ) بأحد الطرق الثلاث التالية: ### i ( إرسال ETH إلى حساب جديد، ( ii ) إنشاء حساب جديد باستخدام الكود، ( iii ) إعداد فتحة تخزين لم يتم لمسها من قبل (، سيظل هذا الكائن في تلك الحالة إلى الأبد. بدلاً من ذلك، ما نريد هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا حاجة إلى الكثير من الحسابات الإضافية لتشغيل عملية الاستحقاق.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH وERC20 وNFT وCDP.
سهولة التعامل مع المطورين: لا يتعين على المطورين الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تظل التطبيقات التي أصبحت جامدة وغير محدثة تعمل بشكل طبيعي.
من السهل حل المشاكل إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء صلاحية يمكن تمديده عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا عند القراءة أو الكتابة في أي وقت، ويجب أن يكون هناك عملية للمرور عبر الحالة لإزالة كائنات الحالة ذات تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم حسابات إضافية واحتياجات تخزين حتى، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. يجد المطورون أيضًا صعوبة في الاستدلال على حالات الحافة التي تتضمن إعادة تعيين القيم المخزنة أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية داخل نطاق العقد، فسيجعل ذلك حياة المطورين أسهل من الناحية التقنية، ولكنه سيجعل الاقتصاد أكثر تعقيدًا: يجب أن يأخذ المطورون في الاعتبار كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه كلها مشاكل عمل مجتمع تطوير إيثريوم الأساسي على حلها على مدار سنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"الإعادة". في النهاية، جمعنا أفضل أجزاء المقترحات وركزنا على نوعين من "أقل الحلول السيئة المعروفة":
حلول انتهاء صلاحية بعض الحالات
اقتراح انتهاء الحالة بناءً على دورة العنوان.
) انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يقوم الجميع بتخزين "الخريطة العليا" بشكل دائم، حيث تكون الكتل إما فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط عند الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم يتم تخزينها بعد الآن.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
9
مشاركة
تعليق
0/400
MysteryBoxBuster
· منذ 2 س
إثيريوم أيضًا بدأت في فقدان الوزن
شاهد النسخة الأصليةرد0
probably_nothing_anon
· منذ 3 س
متفائل بشأن eth!
هذه التعليق قصير وطبيعي، حيث استخدم مصطلح "متفائل" الشائع في مجتمع الأصول الرقمية للتعبير عن التفاؤل، بينما يعكس أيضًا نغمة غير رسمية وسهلة على وسائل التواصل الاجتماعي. يتماشى تمامًا مع أسلوب التعبير لمستخدم نشط في مجتمع الأصول الرقمية.
شاهد النسخة الأصليةرد0
MidnightGenesis
· منذ 14 س
داخل السلسلة مراقبة حقاً رأيت بعض الأكواد المثيرة للاهتمام تقليل الأعباء لا يحتمل التأخير
شاهد النسخة الأصليةرد0
SignatureVerifier
· 08-04 19:47
من الناحية الفنية، أشعر بقلق كبير بشأن نقص فحوصات التحقق في آلية التطهير هذه... يتطلب تدقيق أمني شامل بصراحة.
شاهد النسخة الأصليةرد0
UnluckyLemur
· 08-03 10:23
ضريبة السك العملة 100 عملة تكفي
شاهد النسخة الأصليةرد0
DegenApeSurfer
· 08-03 10:22
تخفيف العبء صعب للغاية، أليس كذلك؟
شاهد النسخة الأصليةرد0
OldLeekNewSickle
· 08-03 10:20
تخفيض بيانات السلسلة، أم بيانات يُستغل بغباء؟ يقول الحمقى إنه لا يفهم.
شاهد النسخة الأصليةرد0
NonFungibleDegen
· 08-03 10:18
ngmi مع هذا الانتفاخ يا صديقي... تطهير أو أننا جميعًا في وضع سيء جدًا جدًا
إثيريوم The Purge计划:اسقاط存储需求与简化 بروتوكول复杂度
إثيريوم المستقبل المحتمل: التطهير
إثيريوم تواجه تحديًا واحدًا وهو أنه بشكل افتراضي، فإن التوسع والتعقيد لأي بروتوكول بلوكتشين سيزداد مع مرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب على جميع العملاء تخزين أي معاملة تمت في أي وقت تاريخي وأي حساب تم إنشاؤه بشكل دائم، ويجب على أي عميل جديد تنزيلها، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة عبء العملاء ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: إضافة ميزات جديدة أسهل بكثير من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
لضمان استمرار إيثريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هذين الاتجاهين، مع تقليل التعقيد والتضخم بمرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الاحتفاظ بأحد الخصائص الرئيسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع 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 يومًا (، حيث تكون كل عقدة مسؤولة عن تخزين كل شيء، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم، تخزن البيانات القديمة بطريقة موزعة.
![فيتاليك: المستقبل المحتمل لإثيريوم، التطهير])يان/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(
يمكن استخدام رموز الحذف لزيادة المتانة مع الحفاظ على نفس عامل النسخ. في الواقع، تم تطبيق رموز الحذف على Blob لدعم أخذ عينات توفر البيانات. من المحتمل أن تكون أبسط حل هو إعادة استخدام هذه الرموز ووضع تنفيذ وبيانات كتلة الإجماع أيضًا داخل blob.
) ما هي العلاقة مع الأبحاث الحالية؟
EIP-4444 ؛
تورنات و EIP-4444;
شبكة البوابة;
شبكة البوابة و EIP-4444;
تخزين واسترجاع الكائنات SSZ الموزعة في البوابة;
كيف يمكن زيادة حد الغاز ### بارادايجم (.
) ماذا يجب أن نفعل بعد ذلك، وما الذي يتعين موازنته؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجل التاريخي------على الأقل سجل التنفيذ، ولكن في النهاية يتضمن أيضًا الإجماع و blob. أبسط حل هو ###i( ببساطة إدخال مكتبة torrent الموجودة، بالإضافة إلى )ii( المعروفة باسم حل إثيريوم الأصلي شبكة Portal. بمجرد إدخال أي من هذه، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صعبًا، ولكنه يتطلب بالفعل إصدارًا جديدًا من بروتوكول الشبكة. لذلك، من المفيد تمكينه في نفس الوقت لجميع العملاء، وإلا هناك خطر فشل العملاء بسبب الاتصال بعقد أخرى تتوقع تنزيل السجل الكامل ولكنها لم تحصل عليه في الواقع.
الاعتبارات الرئيسية تتعلق بكيفية努力نا لتقديم بيانات "التاريخ القديم". أبسط حل هو التوقف عن تخزين التاريخ القديم غداً، والاعتماد على العقد الأرشيفية الموجودة ومقدمي الخدمات المركزية المختلفة للنسخ. هذا سهل، لكنه يضعف مكانة إثيريوم كمكان سجلات دائمة. الطريقة الأكثر صعوبة ولكن الأكثر أماناً هي أولاً بناء وتكامل شبكة التورنت، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نحاول التأكد من أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما عمق تكامل تخزين التاريخ في البروتوكول؟
تعني طريقة متطرفة للغاية تجاه ) تتعلق بإثبات الحضانة: حيث يتطلب فعليًا من كل مُحقق في إثبات الحصة تخزين نسبة معينة من السجل التاريخي، والتحقق بانتظام بطريقة مشفرة مما إذا كانوا يقومون بذلك. طريقة أكثر اعتدالًا هي تحديد معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ (2)، فإن التنفيذ الأساسي يتضمن فقط العمل الذي تم إنجازه اليوم: لقد خزن البوابة ملف ERA الذي يحتوي على تاريخ إثيريوم بالكامل. سيتطلب التنفيذ الأكثر شمولاً ربطه فعلياً بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة عقدة تخزين التاريخ الكامل أو عقدة الأرشيف، يمكنهم تحقيق ذلك عن طريق المزامنة المباشرة من شبكة البوابة حتى لو لم تكن هناك عقد أرشيفية أخرى متصلة.
( كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
إذا أردنا أن نجعل تشغيل أو بدء العقدة سهلًا للغاية، فيمكن القول إن تقليل متطلبات التخزين التاريخي أكثر أهمية من عدم الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 غيغابايت هي حالة، والباقي حوالي 800 غيغابايت أصبح تاريخيًا. فقط من خلال تحقيق عدم الحالة وEIP-4444، يمكن تحقيق الرؤية لتشغيل عقدة إيثيريوم على ساعة ذكية وإعدادها في بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن تنفيذ عقد إثيريوم الأحدث بشكل أكثر فعالية، حيث تدعم فقط أحدث إصدارات البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر التعليمات البرمجية بأمان، حيث تم حذف جميع فتحات التخزين الفارغة التي تم إنشاؤها خلال هجمات DoS في عام 2016. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء بأمان حذف جميع التعليمات البرمجية المتعلقة بإثبات العمل.
![فيتاليك: المستقبل المحتمل لإثيريوم، التنظيف])ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg###
انتهاء حالة
( ماذا يحل؟
حتى لو أزلنا الحاجة إلى تخزين سجل العميل, ستستمر احتياجات تخزين العميل في النمو بمعدل حوالي 50 غيغابايت سنويًا, لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية, وكود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة, مما سيثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أصعب من التاريخ "الانتهاء"، لأن EVM مصمم أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا ويمكن قراءته في أي وقت بواسطة أي معاملة. إذا قمنا بإدخال عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة معينة من بناة الكتل تحتاج فعليًا إلى تخزين الحالة، بينما يمكن لجميع العقد الأخرى ) حتى قائمة التوليد! ### العمل بدون حالة. ومع ذلك، هناك وجهة نظر مفادها أننا لا نريد الاعتماد بشكل مفرط على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة تنتهي للحفاظ على لامركزية إثيريوم.
( ما هو؟ كيف يعمل؟
اليوم، عند إنشاء كائن حالة جديد، يمكن أن يحدث ) بأحد الطرق الثلاث التالية: ### i ( إرسال ETH إلى حساب جديد، ( ii ) إنشاء حساب جديد باستخدام الكود، ( iii ) إعداد فتحة تخزين لم يتم لمسها من قبل (، سيظل هذا الكائن في تلك الحالة إلى الأبد. بدلاً من ذلك، ما نريد هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا حاجة إلى الكثير من الحسابات الإضافية لتشغيل عملية الاستحقاق.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH وERC20 وNFT وCDP.
سهولة التعامل مع المطورين: لا يتعين على المطورين الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تظل التطبيقات التي أصبحت جامدة وغير محدثة تعمل بشكل طبيعي.
من السهل حل المشاكل إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء صلاحية يمكن تمديده عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا عند القراءة أو الكتابة في أي وقت، ويجب أن يكون هناك عملية للمرور عبر الحالة لإزالة كائنات الحالة ذات تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم حسابات إضافية واحتياجات تخزين حتى، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. يجد المطورون أيضًا صعوبة في الاستدلال على حالات الحافة التي تتضمن إعادة تعيين القيم المخزنة أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية داخل نطاق العقد، فسيجعل ذلك حياة المطورين أسهل من الناحية التقنية، ولكنه سيجعل الاقتصاد أكثر تعقيدًا: يجب أن يأخذ المطورون في الاعتبار كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه كلها مشاكل عمل مجتمع تطوير إيثريوم الأساسي على حلها على مدار سنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"الإعادة". في النهاية، جمعنا أفضل أجزاء المقترحات وركزنا على نوعين من "أقل الحلول السيئة المعروفة":
) انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يقوم الجميع بتخزين "الخريطة العليا" بشكل دائم، حيث تكون الكتل إما فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط عند الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم يتم تخزينها بعد الآن.
![فيتاليك: مستقبل إثيريوم المحتمل، التطهير])
هذه التعليق قصير وطبيعي، حيث استخدم مصطلح "متفائل" الشائع في مجتمع الأصول الرقمية للتعبير عن التفاؤل، بينما يعكس أيضًا نغمة غير رسمية وسهلة على وسائل التواصل الاجتماعي. يتماشى تمامًا مع أسلوب التعبير لمستخدم نشط في مجتمع الأصول الرقمية.