إثيريوم تواجه تحديًّا يتمثل في أن التضخم والتعقيد لأي بروتوكول بلوكتشين سيزداد بمرور الوقت بشكل افتراضي. يحدث هذا في جانبين:
البيانات التاريخية: يجب تخزين أي معاملة تمت في أي لحظة تاريخية وأي حساب تم إنشاؤه بشكل دائم بواسطة جميع العملاء، ويجب على أي عميل جديد تنزيلها، مما يسمح بالتزامن الكامل مع الشبكة. ستؤدي هذه العملية إلى زيادة حمل العملاء ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.
لضمان استمرارية إثيريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم بمرور الوقت. ولكن في نفس الوقت، نحتاج إلى الحفاظ على واحدة من الخصائص الأساسية التي تجعل البلوكتشين عظيمة: الدوام. يمكنك وضع 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 في بورتال
كيفية زيادة حد الغاز (بارادايم)
ماذا تحتاج أن تفعل بعد؟ ماذا تحتاج أن توازن؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية ستشمل أيضًا الإجماع و blob. الحل الأبسط هو (i) ببساطة إدخال مكتبات التورنت الموجودة، و (ii) المعروف باسم حل إثيريوم الأصلي Portal Network. بمجرد إدخال أي من هذه، يمكننا فتح 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.
سهولة الاستخدام للمطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بمؤشر تاريخ انتهاء (يمكن تمديد تاريخ الانتهاء عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا عند القراءة أو الكتابة في أي وقت)، ويكون لديك عملية تتكرر عبر الحالة لحذف كائنات حالة تاريخ الانتهاء. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى احتياجات التخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما أن المطورين يجدون صعوبة في الاستدلال على حالات الحافة التي تتضمن تخزين القيم التي يتم إعادة تعيينها أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء في نطاق العقد، فإن ذلك يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يأخذوا في الاعتبار كيفية "تحويل" تكاليف التخزين المستمرة إلى المستخدم.
هذه هي القضايا التي كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها على مدار سنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء من المقترحات وركزنا على فئتين من "أقل الحلول السيئة المعروفة":
حلول انتهاء صلاحية بعض الحالات
توصيات انتهاء الحالة بناءً على دورة العنوان.
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يتم تخزين "الخريطة العليا" بشكل دائم للجميع، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
الاختلاف الرئيسي بين هذه الاقتراحات هو: (i) كيف نحدد "الأخير"، و (ii) أنا
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
6
مشاركة
تعليق
0/400
OnchainGossiper
· منذ 9 س
مزامنة العميل بطيئة جدًا، أريد أن أتقيأ.
شاهد النسخة الأصليةرد0
MidnightSnapHunter
· 07-26 22:22
هل سيتعين على فيتاليك بوتيرين أخيرًا تصفية؟
شاهد النسخة الأصليةرد0
PriceOracleFairy
· 07-24 21:24
بروتوكول ngl متضخم حقًا... كوابيس التوسع تبقيني مستيقظًا في الساعة 3 صباحًا حقًا
شاهد النسخة الأصليةرد0
WhaleWatcher
· 07-24 21:14
Vitalik Buterin ساعدني في حساب تكاليف التخزين من فضلك
فيتالك يتحدث عن التطهير: طريق الاستدامة الطويلة لإثيريوم
فيتاليك: المستقبل المحتمل لإثيريوم، التطهير
إثيريوم تواجه تحديًّا يتمثل في أن التضخم والتعقيد لأي بروتوكول بلوكتشين سيزداد بمرور الوقت بشكل افتراضي. يحدث هذا في جانبين:
البيانات التاريخية: يجب تخزين أي معاملة تمت في أي لحظة تاريخية وأي حساب تم إنشاؤه بشكل دائم بواسطة جميع العملاء، ويجب على أي عميل جديد تنزيلها، مما يسمح بالتزامن الكامل مع الشبكة. ستؤدي هذه العملية إلى زيادة حمل العملاء ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.
لضمان استمرارية إثيريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم بمرور الوقت. ولكن في نفس الوقت، نحتاج إلى الحفاظ على واحدة من الخصائص الأساسية التي تجعل البلوكتشين عظيمة: الدوام. يمكنك وضع 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.
مع ما هي الروابط مع الأبحاث الحالية؟
ماذا تحتاج أن تفعل بعد؟ ماذا تحتاج أن توازن؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية ستشمل أيضًا الإجماع و blob. الحل الأبسط هو (i) ببساطة إدخال مكتبات التورنت الموجودة، و (ii) المعروف باسم حل إثيريوم الأصلي Portal Network. بمجرد إدخال أي من هذه، يمكننا فتح 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.
سهولة الاستخدام للمطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بمؤشر تاريخ انتهاء (يمكن تمديد تاريخ الانتهاء عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا عند القراءة أو الكتابة في أي وقت)، ويكون لديك عملية تتكرر عبر الحالة لحذف كائنات حالة تاريخ الانتهاء. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى احتياجات التخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما أن المطورين يجدون صعوبة في الاستدلال على حالات الحافة التي تتضمن تخزين القيم التي يتم إعادة تعيينها أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء في نطاق العقد، فإن ذلك يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يأخذوا في الاعتبار كيفية "تحويل" تكاليف التخزين المستمرة إلى المستخدم.
هذه هي القضايا التي كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها على مدار سنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء من المقترحات وركزنا على فئتين من "أقل الحلول السيئة المعروفة":
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يتم تخزين "الخريطة العليا" بشكل دائم للجميع، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
الاختلاف الرئيسي بين هذه الاقتراحات هو: (i) كيف نحدد "الأخير"، و (ii) أنا