من التحديات التي تواجه إثيريوم هو أن التضخم والتعقيد لأي بروتوكول بلوكتشين سيزداد مع مرور الوقت بشكل افتراضي. يحدث هذا في جانبين:
البيانات التاريخية: يجب على جميع العملاء تخزين جميع المعاملات التي تتم وأي حسابات يتم إنشاؤها في أي لحظة تاريخية بشكل دائم، ويجب على أي عميل جديد تحميلها، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العميل ووقت المزامنة بمرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة الاتفاقية: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
لكي تستمر إثيريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على أحد الخصائص الرئيسية التي تجعل blockchain عظيمة: الديمومة. يمكنك وضع NFT، أو رسالة حب في بيانات اتصال المعاملات، أو عقد ذكي يحتوي على مليون دولار على السلسلة، ثم الدخول إلى كهف لمدة عشر سنوات، وعندما تخرج تجدها لا تزال هناك في انتظارك للقراءة والتفاعل. لكي يتمكن DApp من أن يكون لامركزياً تمامًا وإزالة مفاتيح الترقية، يحتاجون إلى التأكد من أن اعتماداتهم لن تتطور بطرق تدمرهم - خاصة L1 نفسها.
إذا عزمنا على تحقيق التوازن بين هذين الطلبين، وتقليل أو عكس البدانة، التعقيد والانحدار مع الحفاظ على الاستمرارية، فهذا ممكن تمامًا. يمكن للكائنات الحية القيام بذلك: بينما تعاني معظم الكائنات الحية من الشيخوخة مع مرور الوقت، فإن القلة المحظوظة لا تفعل ذلك. حتى الأنظمة الاجتماعية يمكن أن تعيش لفترات طويلة جدًا. في بعض الحالات، حققت إثيريوم النجاح: اختفى إثبات العمل، واختفى رمز العملية SELFDESTRUCT في معظم الأحيان، وقد خزنت عقد سلسلة الإشارة بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذا الطريق لإثيريوم بطريقة أكثر عمومية والسير نحو نتيجة نهائية مستقرة على المدى الطويل هو التحدي النهائي لقابلية التوسع على المدى الطويل لإثيريوم، والاستدامة التقنية وحتى الأمان.
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.
ما هي الروابط مع الأبحاث الحالية؟
EIP-4444 ؛
التورنتات و EIP-4444؛
شبكة البوابة؛
شبكة البوابة و EIP-4444؛
التخزين الموزع واسترجاع كائنات SSZ في البوابة؛
كيفية زيادة حد الغاز (بارادايم).
ماذا لا يزال يتعين القيام به، وما الذي يجب موازنته؟
تشمل المهام الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية ستشمل أيضًا الإجماع و blob. الحل الأسهل هو (i) ببساطة إدخال مكتبة التورنت الموجودة، و (ii) المعروفة باسم حل إيثيريوم الأصلي لشبكة Portal. بمجرد إدخال أي من هذه، يمكننا فتح 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...
سهولة التعامل مع المطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف بالكامل. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات المتجمدة وغير المحدثة في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء (يمكن تمديد تاريخ الانتهاء عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا في أي وقت عند القراءة أو الكتابة)، ولديك عملية تقوم بتكرار الحالة لإزالة كائنات حالة تاريخ انتهاء. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى متطلبات تخزين)، ومن المؤكد أنه لن يلبي متطلبات سهولة الاستخدام. كما أن من الصعب على المطورين استنتاج الحالات الحدية التي تتضمن إعادة تعيين القيم المخزنة أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فإنه من الناحية التقنية يجعل حياة المطورين أسهل، لكنه يجعل الاقتصاد أكثر تعقيدًا: يجب على المطورين التفكير في كيفية "نقل" تكلفة التخزين المستمرة إلى المستخدم.
هذه كلها مشكلات كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، قمنا بدمج أفضل أجزاء المقترحات وركزنا على نوعين من "أفضل الحلول المعروفة التي ليست الأسوأ":
حلول لحالات انتهاء الصلاحية الجزئية
اقتراح انتهاء الحالة بناءً على دورة العنوان.
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقسم الحالة إلى كتل. يخزن الجميع "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
إثيريوم The Purge: خفض التعقيد وزيادة الاستدامة والأمان
إثيريوم المستقبل المحتمل: The Purge
من التحديات التي تواجه إثيريوم هو أن التضخم والتعقيد لأي بروتوكول بلوكتشين سيزداد مع مرور الوقت بشكل افتراضي. يحدث هذا في جانبين:
البيانات التاريخية: يجب على جميع العملاء تخزين جميع المعاملات التي تتم وأي حسابات يتم إنشاؤها في أي لحظة تاريخية بشكل دائم، ويجب على أي عميل جديد تحميلها، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العميل ووقت المزامنة بمرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة الاتفاقية: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
لكي تستمر إثيريوم على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على أحد الخصائص الرئيسية التي تجعل blockchain عظيمة: الديمومة. يمكنك وضع NFT، أو رسالة حب في بيانات اتصال المعاملات، أو عقد ذكي يحتوي على مليون دولار على السلسلة، ثم الدخول إلى كهف لمدة عشر سنوات، وعندما تخرج تجدها لا تزال هناك في انتظارك للقراءة والتفاعل. لكي يتمكن DApp من أن يكون لامركزياً تمامًا وإزالة مفاتيح الترقية، يحتاجون إلى التأكد من أن اعتماداتهم لن تتطور بطرق تدمرهم - خاصة L1 نفسها.
إذا عزمنا على تحقيق التوازن بين هذين الطلبين، وتقليل أو عكس البدانة، التعقيد والانحدار مع الحفاظ على الاستمرارية، فهذا ممكن تمامًا. يمكن للكائنات الحية القيام بذلك: بينما تعاني معظم الكائنات الحية من الشيخوخة مع مرور الوقت، فإن القلة المحظوظة لا تفعل ذلك. حتى الأنظمة الاجتماعية يمكن أن تعيش لفترات طويلة جدًا. في بعض الحالات، حققت إثيريوم النجاح: اختفى إثبات العمل، واختفى رمز العملية SELFDESTRUCT في معظم الأحيان، وقد خزنت عقد سلسلة الإشارة بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذا الطريق لإثيريوم بطريقة أكثر عمومية والسير نحو نتيجة نهائية مستقرة على المدى الطويل هو التحدي النهائي لقابلية التوسع على المدى الطويل لإثيريوم، والاستدامة التقنية وحتى الأمان.
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.
ما هي الروابط مع الأبحاث الحالية؟
EIP-4444 ؛
التورنتات و EIP-4444؛
شبكة البوابة؛
شبكة البوابة و EIP-4444؛
التخزين الموزع واسترجاع كائنات SSZ في البوابة؛
كيفية زيادة حد الغاز (بارادايم).
ماذا لا يزال يتعين القيام به، وما الذي يجب موازنته؟
تشمل المهام الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية ستشمل أيضًا الإجماع و blob. الحل الأسهل هو (i) ببساطة إدخال مكتبة التورنت الموجودة، و (ii) المعروفة باسم حل إيثيريوم الأصلي لشبكة Portal. بمجرد إدخال أي من هذه، يمكننا فتح 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...
سهولة التعامل مع المطورين: لا يحتاج المطورون إلى الانتقال إلى نموذج تفكير غير مألوف بالكامل. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات المتجمدة وغير المحدثة في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء (يمكن تمديد تاريخ الانتهاء عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا في أي وقت عند القراءة أو الكتابة)، ولديك عملية تقوم بتكرار الحالة لإزالة كائنات حالة تاريخ انتهاء. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى متطلبات تخزين)، ومن المؤكد أنه لن يلبي متطلبات سهولة الاستخدام. كما أن من الصعب على المطورين استنتاج الحالات الحدية التي تتضمن إعادة تعيين القيم المخزنة أحيانًا إلى صفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فإنه من الناحية التقنية يجعل حياة المطورين أسهل، لكنه يجعل الاقتصاد أكثر تعقيدًا: يجب على المطورين التفكير في كيفية "نقل" تكلفة التخزين المستمرة إلى المستخدم.
هذه كلها مشكلات كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، قمنا بدمج أفضل أجزاء المقترحات وركزنا على نوعين من "أفضل الحلول المعروفة التي ليست الأسوأ":
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقسم الحالة إلى كتل. يخزن الجميع "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة.