تتمثل إحدى التحديات التي تواجه إثيريوم في أن التوسع والتعقيد لأي بروتوكول Blockchain سيزداد بمرور الوقت بشكل افتراضي. يحدث هذا من ناحيتين:
البيانات التاريخية: يجب تخزين جميع المعاملات التي تمت في أي وقت في التاريخ وأي حسابات تم إنشاؤها بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تحميلها، مما يؤدي إلى تزامن كامل مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العملاء ووقت التزامن مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة الاتفاقية: من الأسهل بكثير إضافة ميزات جديدة مقارنةً بإزالة الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة بمرور الوقت.
لضمان استمرار إثيريوم على المدى الطويل، نحتاج إلى تطبيق ضغط قوي على هذين الاتجاهين، مما يقلل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على واحدة من الخصائص الأساسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع NFT، رسالة حب في بيانات مكالمة تجارية، أو عقد ذكي يحتوي على مليون دولار على السلسلة، ثم الدخول إلى كهف لمدة عشر سنوات، وعند الخروج تجد أنه لا يزال هناك في انتظارك لقراءته والتفاعل معه. لكي تتمكن DApp من اللامركزية بالكامل وإلغاء مفاتيح الترقية، بحاجة إلى التأكد من أن اعتمادها لن يتطور بطريقة تدمرهم - خاصة L1 نفسها.
إذا عزمنا على تحقيق التوازن بين هذين النوعين من الطلبات، وتقليل أو عكس التجاوزات والتعقيد والانحطاط مع الحفاظ على الاستمرارية، فهذا ممكن تمامًا. يمكن للكائنات الحية أن تفعل ذلك: في حين أن معظم الكائنات الحية تتقدم في السن مع مرور الوقت، فإن القلة المحظوظة لا تفعل ذلك. حتى الأنظمة الاجتماعية يمكن أن تكون لها أعمار طويلة جدًا. في بعض الحالات، حققت إيثيريوم النجاح: اختفى إثبات العمل، واختفى رمز العملية SELFDESTRUCT في معظمه، وقد خزنت عقدة سلسلة الإشارات بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذه الطريق لإيثيريوم بطريقة أكثر عمومية والسير نحو نتيجة نهائية مستقرة على المدى الطويل هو التحدي النهائي لقابلية إيثيريوم للتوسع على المدى الطويل، واستدامته التقنية، بل وأمنه.
التطهير: الهدف الرئيسي.
عن طريق تقليل أو إزالة الحاجة إلى تخزين جميع السجلات التاريخية أو حتى الحالة النهائية بشكل دائم في كل عقدة، يتم تقليل متطلبات تخزين العميل.
من خلال إزالة الميزات غير الضرورية لتقليل تعقيد البروتوكول.
محتويات المقالة:
تاريخ انتهاء الصلاحية（历史记录到期）
تاريخ انتهاء الصلاحية（状态到期）
تنظيف الميزات
تاريخ انتهاء الصلاحية
ما هي المشكلة التي تحلها؟
حتى وقت كتابة هذه المقالة، تحتاج عقدة إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى مئات الجيجابايت من مساحة القرص لعميل التوافق. معظم هذه المساحة هي تاريخية: بيانات حول الكتل التاريخية، والمعاملات، والإيصالات، ومعظمها له تاريخ يمتد لسنوات. وهذا يعني أنه حتى إذا لم يزداد حد الغاز على الإطلاق، فإن حجم العقدة سيستمر في الزيادة بمئات الجيجابايت كل عام.
ما هو، وكيف يعمل؟
تتمثل إحدى الميزات المبسطة الأساسية لمشكلة تخزين التاريخ في أنه نظرًا لأن كل كتلة تشير إلى الكتلة السابقة من خلال روابط تجزئة (وبنى أخرى)، فإن الوصول إلى توافق في الآراء الحالي يكفي للوصول إلى توافق في الآراء التاريخي. طالما أن الشبكة تتفق على أحدث كتلة، يمكن لأي مشارك فردي تقديم أي كتلة تاريخية أو معاملة أو حالة (رصيد الحساب، رقم عشوائي، كود، تخزين) بالإضافة إلى إثبات ميركل، ويسمح هذا الإثبات لأي شخص آخر بالتحقق من صحته. التوافق هو نموذج ثقة N/2-of-N، بينما التاريخ هو نموذج ثقة N-of-N.
هذا يوفر لنا العديد من الخيارات حول كيفية تخزين السجلات التاريخية. خيار طبيعي هو شبكة حيث يخزن كل عقدة فقط جزءًا صغيرًا من البيانات. هذه هي الطريقة التي تعمل بها الشبكات البذور منذ عقود: بينما تخزن الشبكة وتوزع ملايين الملفات، يخزن كل مشارك ويوزع فقط عددًا قليلًا من تلك الملفات. ربما على عكس الحدس، فإن هذه الطريقة لا تعني بالضرورة تقليل متانة البيانات. إذا كان بإمكاننا بناء شبكة تضم 100,000 عقدة حيث تخزن كل عقدة 10% عشوائي من السجلات التاريخية، فإن كل قطعة بيانات ستُنسخ 10,000 مرة - وهو نفس عامل النسخ في شبكة مكونة من 10,000 عقدة، حيث تخزن كل عقدة كل المحتوى.
الآن، بدأ إثيريوم في التخلص من نموذج تخزين جميع التاريخ بشكل دائم من قبل جميع العقد. الكتل المتوافقة (أي الجزء المتعلق بالإجماع القائم على إثبات الحصة) تخزن فقط حوالي 6 أشهر. البلوكات تخزن فقط حوالي 18 يومًا. تهدف EIP-4444 إلى إدخال فترة تخزين لمدة عام للكتل التاريخية والإيصالات. الهدف الطويل الأمد هو إنشاء فترة موحدة (قد تكون حوالي 18 يومًا) حيث تكون كل عقدة مسؤولة عن تخزين كل المحتويات، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم، حيث يتم تخزين البيانات القديمة بطريقة موزعة.
يمكن استخدام رموز الحذف لزيادة القوة ، مع الحفاظ على نفس عامل النسخ. في الواقع ، تم استخدام رموز الحذف في blob لدعم عينة توافر البيانات. من المحتمل أن تكون أبسط الحلول هي إعادة استخدام هذه الرموز ، ووضع بيانات التنفيذ وبيانات كتلة الإجماع أيضًا في blob.
ما هي العلاقة مع الأبحاث الحالية؟
EIP-4444 ؛
التورنت وإي آي بي-4444؛
شبكة البوابة؛
شبكة البوابة وEIP-4444؛
تخزين واسترجاع الكائنات SSZ في Portal بشكل موزع؛
كيف يمكن زيادة حد الغاز (بارادايم).
ماذا يجب أن أفعل بعد؟ ما الذي يجب مراعاته؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع وblob. أبسط حل هو (i) ببساطة إدخال مكتبات التورنت الموجودة، بالإضافة إلى (ii) الحل الأصلي لإثيريوم المعروف باسم شبكة Portal. بمجرد إدخال أي من هذين، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صلبًا، ولكنه يحتاج إلى إصدار جديد من بروتوكول الشبكة. لذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا فإن هناك خطر حدوث فشل للعملاء بسبب الاتصال بعقد أخرى تتوقع تنزيل السجلات التاريخية الكاملة ولكنها لم تحصل عليها بالفعل.
التوازن الرئيسي يتعلق بكيفية جهودنا لتوفير بيانات التاريخ "القديمة". الحل الأسهل هو التوقف عن تخزين التاريخ القديم غدًا والاعتماد على العقد الأرشيفية الحالية ومجموعة متنوعة من مقدمي الخدمة المركزيين للتكرار. هذا سهل، لكن هذا يضعف من مكانة إثيريوم كمكان سجل دائم. الطريق الأكثر صعوبة ولكنه أكثر أمانًا هو بناء وتكامل شبكة التورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نبذل جهدًا لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
إلى أي عمق تم دمج تخزين التاريخ في البروتوكول؟
تتضمن طريقة متطرفة للغاية لـ (1) إثبات الحفظ: تتطلب فعليًا من كل مُصادق على إثبات الحصة تخزين نسبة معينة من السجلات التاريخية، والتحقق منها بشكل دوري بطريقة مشفرة لمعرفة ما إذا كانوا يفعلون ذلك. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ (، تتعلق التنفيذات الأساسية فقط بالعمل الذي تم إنجازه اليوم: لقد قام البوابة بتخزين ملفات ERA التي تحتوي على تاريخ إثيريوم بالكامل. ستتضمن التنفيذات الأكثر شمولاً ربطها فعليًا بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة عقدة تخزين التاريخ الكامل أو عقدة الأرشفة، حتى لو لم تكن هناك عقد أرشفة أخرى متصلة على الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة من شبكة البوابة.
)# كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟
إذا أردنا جعل تشغيل أو بدء العقدة سهلاً للغاية، فإن تقليل متطلبات التخزين التاريخي يمكن أن يُعتبر أكثر أهمية من عدم الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي الحالة، والباقي حوالي 800 جيجابايت أصبح تاريخيًا. فقط من خلال تحقيق عدم الحالة وEIP-4444 يمكن تحقيق الرؤية لتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في دقائق فقط.
تقييد التخزين التاريخي يجعل من الممكن أكثر تنفيذ عقد إثيريوم الأحدث، حيث تدعم فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016 قد تم حذفها بالكامل. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
حتى لو قُمنا بإزالة الحاجة إلى تخزين سجل العميل، ستستمر متطلبات تخزين العميل في النمو، بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، وأكواد العقود وتخزين العقود. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يُثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أكثر صعوبة في "انتهاء الصلاحية" من التاريخ، لأن EVM مصممة أساسًا حول فرضية مفادها: بمجرد إنشاء كائن الحالة، فإنه سيبقى موجودًا دائمًا، ويمكن قراءته في أي وقت بواسطة أي معاملة. إذا قمنا بإدخال عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة بناء الكتل المتخصصة تحتاج إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى (حتى تلك التي تتضمن إنشاء القوائم!) العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إننا لا نريد الاعتماد كثيرًا على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة تنتهي للحفاظ على لامركزية إثيريوم.
ما هو، وكيف يعمل
اليوم، عندما تقوم بإنشاء كائن حالة جديدة (يمكن أن يحدث ذلك من خلال واحدة من الطرق الثلاث التالية: (i) إرسال ETH إلى حساب جديد، (ii) إنشاء حساب جديد باستخدام الكود، (iii) إعداد فتحة تخزين لم يتم لمسها من قبل)، فإن كائن الحالة يظل في تلك الحالة إلى الأبد. على العكس، ما نريده هو أن الكائن ينتهي تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا حاجة إلى قدر كبير من الحسابات الإضافية لتشغيل عملية الاستحقاق.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
سهولة استخدام المطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل جداً حل المشكلة إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضاً عداد تاريخ انتهاء الصلاحية (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق إيثر، وهو ما قد يحدث تلقائياً عند القراءة أو الكتابة في أي وقت)، ولديك عملية تتكرر عبر الحالة لإزالة كائنات حالة تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم حساباً إضافياً (حتى متطلبات تخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج حالات الحافة التي تتضمن قيم التخزين التي تعيد تعيينها أحياناً إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية ضمن نطاق العقد، سيجعل ذلك حياة المطورين أسهل من الناحية التقنية، لكنه سيجعل الأمور الاقتصادية أكثر تعقيداً: يجب على المطورين التفكير في كيفية "نقل" تكلفة التخزين المستمرة إلى المستخدم.
هذه كلها مشكلات كان مجتمع مطوري إثيريوم الأساسي يعمل على حلها لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار البلوكتشين" و"الإحياء". في النهاية، قمنا بدمج أفضل أجزاء المقترحات والتركيز على نوعين من "أقل الحلول سوءًا المعروفة":
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يخزن الجميع "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد محفوظة.
الفرق الرئيسي بين هذه الاقتراحات هو: (i) كيف نعرف "الأخيرة"، و (ii) كيف نحن
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 9
أعجبني
9
4
إعادة النشر
مشاركة
تعليق
0/400
0xTherapist
· منذ 2 س
كان من المفترض أن يأتي إعادة التشغيل منذ فترة طويلة، حان الوقت لفقدان الوزن.
شاهد النسخة الأصليةرد0
NoodlesOrTokens
· 08-10 22:26
داخل السلسلة塞的太满啦 赶紧清理
شاهد النسخة الأصليةرد0
PumpDetector
· 08-10 22:18
المال الذكي كان يراقب هذا الشيء الخاص بالتطهير... بالضبط ما حذرنا منه في 2017 بصراحة
شاهد النسخة الأصليةرد0
LiquidatorFlash
· 08-10 22:12
داخل السلسلة البيانات التاريخية +3.47T، المخاطر الارتفاع، قم بالتحوط قبل أن يتم تصفيرها
إثيريوم The Purge خطة: تاريخ انتهاء الحالة وتبسيطها لمواجهة تضخم التعقيد
إثيريوم المستقبل المحتمل: The Purge
تتمثل إحدى التحديات التي تواجه إثيريوم في أن التوسع والتعقيد لأي بروتوكول Blockchain سيزداد بمرور الوقت بشكل افتراضي. يحدث هذا من ناحيتين:
البيانات التاريخية: يجب تخزين جميع المعاملات التي تمت في أي وقت في التاريخ وأي حسابات تم إنشاؤها بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تحميلها، مما يؤدي إلى تزامن كامل مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العملاء ووقت التزامن مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة الاتفاقية: من الأسهل بكثير إضافة ميزات جديدة مقارنةً بإزالة الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة بمرور الوقت.
لضمان استمرار إثيريوم على المدى الطويل، نحتاج إلى تطبيق ضغط قوي على هذين الاتجاهين، مما يقلل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على واحدة من الخصائص الأساسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع NFT، رسالة حب في بيانات مكالمة تجارية، أو عقد ذكي يحتوي على مليون دولار على السلسلة، ثم الدخول إلى كهف لمدة عشر سنوات، وعند الخروج تجد أنه لا يزال هناك في انتظارك لقراءته والتفاعل معه. لكي تتمكن DApp من اللامركزية بالكامل وإلغاء مفاتيح الترقية، بحاجة إلى التأكد من أن اعتمادها لن يتطور بطريقة تدمرهم - خاصة L1 نفسها.
إذا عزمنا على تحقيق التوازن بين هذين النوعين من الطلبات، وتقليل أو عكس التجاوزات والتعقيد والانحطاط مع الحفاظ على الاستمرارية، فهذا ممكن تمامًا. يمكن للكائنات الحية أن تفعل ذلك: في حين أن معظم الكائنات الحية تتقدم في السن مع مرور الوقت، فإن القلة المحظوظة لا تفعل ذلك. حتى الأنظمة الاجتماعية يمكن أن تكون لها أعمار طويلة جدًا. في بعض الحالات، حققت إيثيريوم النجاح: اختفى إثبات العمل، واختفى رمز العملية SELFDESTRUCT في معظمه، وقد خزنت عقدة سلسلة الإشارات بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذه الطريق لإيثيريوم بطريقة أكثر عمومية والسير نحو نتيجة نهائية مستقرة على المدى الطويل هو التحدي النهائي لقابلية إيثيريوم للتوسع على المدى الطويل، واستدامته التقنية، بل وأمنه.
التطهير: الهدف الرئيسي.
عن طريق تقليل أو إزالة الحاجة إلى تخزين جميع السجلات التاريخية أو حتى الحالة النهائية بشكل دائم في كل عقدة، يتم تقليل متطلبات تخزين العميل.
من خلال إزالة الميزات غير الضرورية لتقليل تعقيد البروتوكول.
محتويات المقالة:
تاريخ انتهاء الصلاحية（历史记录到期）
تاريخ انتهاء الصلاحية（状态到期）
تنظيف الميزات
تاريخ انتهاء الصلاحية
ما هي المشكلة التي تحلها؟
حتى وقت كتابة هذه المقالة، تحتاج عقدة إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى مئات الجيجابايت من مساحة القرص لعميل التوافق. معظم هذه المساحة هي تاريخية: بيانات حول الكتل التاريخية، والمعاملات، والإيصالات، ومعظمها له تاريخ يمتد لسنوات. وهذا يعني أنه حتى إذا لم يزداد حد الغاز على الإطلاق، فإن حجم العقدة سيستمر في الزيادة بمئات الجيجابايت كل عام.
ما هو، وكيف يعمل؟
تتمثل إحدى الميزات المبسطة الأساسية لمشكلة تخزين التاريخ في أنه نظرًا لأن كل كتلة تشير إلى الكتلة السابقة من خلال روابط تجزئة (وبنى أخرى)، فإن الوصول إلى توافق في الآراء الحالي يكفي للوصول إلى توافق في الآراء التاريخي. طالما أن الشبكة تتفق على أحدث كتلة، يمكن لأي مشارك فردي تقديم أي كتلة تاريخية أو معاملة أو حالة (رصيد الحساب، رقم عشوائي، كود، تخزين) بالإضافة إلى إثبات ميركل، ويسمح هذا الإثبات لأي شخص آخر بالتحقق من صحته. التوافق هو نموذج ثقة N/2-of-N، بينما التاريخ هو نموذج ثقة N-of-N.
هذا يوفر لنا العديد من الخيارات حول كيفية تخزين السجلات التاريخية. خيار طبيعي هو شبكة حيث يخزن كل عقدة فقط جزءًا صغيرًا من البيانات. هذه هي الطريقة التي تعمل بها الشبكات البذور منذ عقود: بينما تخزن الشبكة وتوزع ملايين الملفات، يخزن كل مشارك ويوزع فقط عددًا قليلًا من تلك الملفات. ربما على عكس الحدس، فإن هذه الطريقة لا تعني بالضرورة تقليل متانة البيانات. إذا كان بإمكاننا بناء شبكة تضم 100,000 عقدة حيث تخزن كل عقدة 10% عشوائي من السجلات التاريخية، فإن كل قطعة بيانات ستُنسخ 10,000 مرة - وهو نفس عامل النسخ في شبكة مكونة من 10,000 عقدة، حيث تخزن كل عقدة كل المحتوى.
الآن، بدأ إثيريوم في التخلص من نموذج تخزين جميع التاريخ بشكل دائم من قبل جميع العقد. الكتل المتوافقة (أي الجزء المتعلق بالإجماع القائم على إثبات الحصة) تخزن فقط حوالي 6 أشهر. البلوكات تخزن فقط حوالي 18 يومًا. تهدف EIP-4444 إلى إدخال فترة تخزين لمدة عام للكتل التاريخية والإيصالات. الهدف الطويل الأمد هو إنشاء فترة موحدة (قد تكون حوالي 18 يومًا) حيث تكون كل عقدة مسؤولة عن تخزين كل المحتويات، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم، حيث يتم تخزين البيانات القديمة بطريقة موزعة.
يمكن استخدام رموز الحذف لزيادة القوة ، مع الحفاظ على نفس عامل النسخ. في الواقع ، تم استخدام رموز الحذف في blob لدعم عينة توافر البيانات. من المحتمل أن تكون أبسط الحلول هي إعادة استخدام هذه الرموز ، ووضع بيانات التنفيذ وبيانات كتلة الإجماع أيضًا في blob.
ما هي العلاقة مع الأبحاث الحالية؟
EIP-4444 ؛
التورنت وإي آي بي-4444؛
شبكة البوابة؛
شبكة البوابة وEIP-4444؛
تخزين واسترجاع الكائنات SSZ في Portal بشكل موزع؛
كيف يمكن زيادة حد الغاز (بارادايم).
ماذا يجب أن أفعل بعد؟ ما الذي يجب مراعاته؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع وblob. أبسط حل هو (i) ببساطة إدخال مكتبات التورنت الموجودة، بالإضافة إلى (ii) الحل الأصلي لإثيريوم المعروف باسم شبكة Portal. بمجرد إدخال أي من هذين، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقسامًا صلبًا، ولكنه يحتاج إلى إصدار جديد من بروتوكول الشبكة. لذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا فإن هناك خطر حدوث فشل للعملاء بسبب الاتصال بعقد أخرى تتوقع تنزيل السجلات التاريخية الكاملة ولكنها لم تحصل عليها بالفعل.
التوازن الرئيسي يتعلق بكيفية جهودنا لتوفير بيانات التاريخ "القديمة". الحل الأسهل هو التوقف عن تخزين التاريخ القديم غدًا والاعتماد على العقد الأرشيفية الحالية ومجموعة متنوعة من مقدمي الخدمة المركزيين للتكرار. هذا سهل، لكن هذا يضعف من مكانة إثيريوم كمكان سجل دائم. الطريق الأكثر صعوبة ولكنه أكثر أمانًا هو بناء وتكامل شبكة التورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نبذل جهدًا لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
إلى أي عمق تم دمج تخزين التاريخ في البروتوكول؟
تتضمن طريقة متطرفة للغاية لـ (1) إثبات الحفظ: تتطلب فعليًا من كل مُصادق على إثبات الحصة تخزين نسبة معينة من السجلات التاريخية، والتحقق منها بشكل دوري بطريقة مشفرة لمعرفة ما إذا كانوا يفعلون ذلك. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ (، تتعلق التنفيذات الأساسية فقط بالعمل الذي تم إنجازه اليوم: لقد قام البوابة بتخزين ملفات 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 و ERC20 و NFT و CDP.
سهولة استخدام المطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل جداً حل المشكلة إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضاً عداد تاريخ انتهاء الصلاحية (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق إيثر، وهو ما قد يحدث تلقائياً عند القراءة أو الكتابة في أي وقت)، ولديك عملية تتكرر عبر الحالة لإزالة كائنات حالة تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم حساباً إضافياً (حتى متطلبات تخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج حالات الحافة التي تتضمن قيم التخزين التي تعيد تعيينها أحياناً إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية ضمن نطاق العقد، سيجعل ذلك حياة المطورين أسهل من الناحية التقنية، لكنه سيجعل الأمور الاقتصادية أكثر تعقيداً: يجب على المطورين التفكير في كيفية "نقل" تكلفة التخزين المستمرة إلى المستخدم.
هذه كلها مشكلات كان مجتمع مطوري إثيريوم الأساسي يعمل على حلها لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار البلوكتشين" و"الإحياء". في النهاية، قمنا بدمج أفضل أجزاء المقترحات والتركيز على نوعين من "أقل الحلول سوءًا المعروفة":
![فيتالك: مستقبل إثيريوم المحتمل، التطهير]###https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp(
)# انتهاء الحالة الجزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يخزن الجميع "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد محفوظة.
الفرق الرئيسي بين هذه الاقتراحات هو: (i) كيف نعرف "الأخيرة"، و (ii) كيف نحن