أحد التحديات التي تواجه إثيريوم هو أنه، بشكل افتراضي، فإن تضخم وتعقيد أي بروتوكول بلوكتشين سيزداد مع مرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب أن يتم تخزين جميع المعاملات التي تمت في أي لحظة تاريخية وأي حسابات تم إنشاؤها بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها، مما يؤدي إلى تزامن كامل مع الشبكة. سيؤدي ذلك إلى زيادة الحمل على العميل ووقت التزامن بمرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: إضافة ميزات جديدة أسهل بكثير من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.
لضمان استمرار إيثريوم على المدى الطويل، نحتاج إلى تطبيق ضغط مضاد قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على أحد الخصائص الرئيسية التي تجعل البلوكشين عظيمًا: الديمومة. يمكنك وضع NFT، أو رسالة حب في بيانات مكالمة تداول، أو عقد ذكي يحتوي على مليون دولار على السلسلة، ثم دخول كهف لمدة عشر سنوات، وعند الخروج تجدها لا تزال هناك في انتظارك للقراءة والتفاعل. لجعل DApp قادرة على أن تكون لامركزية تمامًا وإزالة مفاتيح الترقية، يحتاجون إلى التأكد من أن الاعتماد الخاص بهم لن يتم ترقيته بطريقة تدمرهم - خاصة L1 نفسها.
إذا عزمنا على تحقيق التوازن بين هذين الاحتياجين، وتقليل أو عكس التكدس، التعقيد والانحدار مع الحفاظ على الاستمرارية، فإن ذلك ممكن تمامًا. يمكن للكائنات الحية القيام بذلك: على الرغم من أن معظم الكائنات الحية تزداد شيخوخة مع مرور الوقت، إلا أن عددًا قليلاً من المحظوظين لا يفعلون. حتى الأنظمة الاجتماعية يمكن أن يكون لها عمر طويل جدًا. في بعض الحالات، حقق إثيريوم النجاح: اختفى إثبات العمل، واختفى رمز العملية SELFDESTRUCT في الغالب، وقد خزنت عقد سلسلة الإشارة بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذه الطريق لإثيريوم بطريقة أكثر شمولية والسير نحو نتيجة نهائية مستقرة على المدى الطويل هو التحدي النهائي لقابلية التوسع على المدى الطويل لإثيريوم، واستدامة التكنولوجيا، وحتى الأمان.
التطهير: الهدف الرئيسي.
تقليل متطلبات تخزين العميل من خلال تقليل أو القضاء على الحاجة إلى كل عقدة لتخزين جميع السجلات التاريخية أو حتى الحالة النهائية بشكل دائم.
خفض تعقيد البروتوكول من خلال إزالة الوظائف غير الضرورية.
فهرس المقالة:
تاريخ انتهاء الصلاحية（历史记录到期）
انتهاء الحالة（状态到期）
تنظيف الميزة
انتهاء التاريخ
ماذا تحل؟
حتى وقت كتابة هذه المقالة، تحتاج عقدة إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى حاجة لمئات الجيجابايت من مساحة القرص لعميل الإجماع. معظم هذه البيانات تاريخية: تتعلق بالكتل التاريخية والمعاملات والإيصالات، حيث أن معظمها يعود لسنوات عديدة. وهذا يعني أنه حتى لو لم تزد قيود الغاز على الإطلاق، فإن حجم العقدة سيستمر في الزيادة بمئات الجيجابايت سنويًا.
ما هو؟ كيف يعمل؟
تتمثل إحدى السمات الرئيسية لتبسيط مشكلة التخزين التاريخي في أنه نظرًا لأن كل كتلة تشير إلى الكتلة السابقة من خلال روابط التجزئة (وبنى أخرى)، فإن الوصول إلى توافق في الآراء الحالي يكفي للوصول إلى توافق في الآراء التاريخي. طالما أن الشبكة تتوصل إلى توافق في الآراء بشأن الكتلة الأخيرة، يمكن لأي مشارك فردي تقديم أي كتلة تاريخية أو معاملة أو حالة (رصيد الحساب، رقم عشوائي، كود، تخزين) بالإضافة إلى إثبات ميركل، مما يسمح لأي شخص آخر بالتحقق من صحته. التوافق هو نموذج ثقة N/2 من N، بينما التاريخ هو نموذج ثقة N من 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) ببساطة إدخال مكتبة torrent الموجودة، و (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، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
7
إعادة النشر
مشاركة
تعليق
0/400
Hash_Bandit
· 08-06 19:58
رأيت هذا من قبل... مثل أيام التعدين عندما قمنا بتحسين مزامنة العقد. يحتاج الإيث إلى مزيد من كفاءة معدل التجزئة بصراحة.
شاهد النسخة الأصليةرد0
ILCollector
· 08-04 07:11
يوصى بتغليف البيانات باستخدام L2
شاهد النسخة الأصليةرد0
TokenomicsTrapper
· 08-03 21:09
أطلقت على هذه المشكلة منذ شهور... دوامة الموت الكلاسيكية للديون التقنية قادمة
شاهد النسخة الأصليةرد0
HackerWhoCares
· 08-03 21:09
تخزين التضخم لا يزال مشكلة صعبة
شاهد النسخة الأصليةرد0
DefiPlaybook
· 08-03 21:07
تحليل البيانات يشير إلى أن مشكلة انفجار الحالة قد أثرت على 87% من العقدة داخل السلسلة
فيتالك يفسر مستقبل تطوير إثيريوم: تحليل خطة التطهير
فيتاليك: المستقبل المحتمل لإثيريوم، التطهير
أحد التحديات التي تواجه إثيريوم هو أنه، بشكل افتراضي، فإن تضخم وتعقيد أي بروتوكول بلوكتشين سيزداد مع مرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب أن يتم تخزين جميع المعاملات التي تمت في أي لحظة تاريخية وأي حسابات تم إنشاؤها بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها، مما يؤدي إلى تزامن كامل مع الشبكة. سيؤدي ذلك إلى زيادة الحمل على العميل ووقت التزامن بمرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: إضافة ميزات جديدة أسهل بكثير من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.
لضمان استمرار إيثريوم على المدى الطويل، نحتاج إلى تطبيق ضغط مضاد قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على أحد الخصائص الرئيسية التي تجعل البلوكشين عظيمًا: الديمومة. يمكنك وضع NFT، أو رسالة حب في بيانات مكالمة تداول، أو عقد ذكي يحتوي على مليون دولار على السلسلة، ثم دخول كهف لمدة عشر سنوات، وعند الخروج تجدها لا تزال هناك في انتظارك للقراءة والتفاعل. لجعل DApp قادرة على أن تكون لامركزية تمامًا وإزالة مفاتيح الترقية، يحتاجون إلى التأكد من أن الاعتماد الخاص بهم لن يتم ترقيته بطريقة تدمرهم - خاصة L1 نفسها.
إذا عزمنا على تحقيق التوازن بين هذين الاحتياجين، وتقليل أو عكس التكدس، التعقيد والانحدار مع الحفاظ على الاستمرارية، فإن ذلك ممكن تمامًا. يمكن للكائنات الحية القيام بذلك: على الرغم من أن معظم الكائنات الحية تزداد شيخوخة مع مرور الوقت، إلا أن عددًا قليلاً من المحظوظين لا يفعلون. حتى الأنظمة الاجتماعية يمكن أن يكون لها عمر طويل جدًا. في بعض الحالات، حقق إثيريوم النجاح: اختفى إثبات العمل، واختفى رمز العملية SELFDESTRUCT في الغالب، وقد خزنت عقد سلسلة الإشارة بيانات قديمة لمدة تصل إلى ستة أشهر. إن العثور على هذه الطريق لإثيريوم بطريقة أكثر شمولية والسير نحو نتيجة نهائية مستقرة على المدى الطويل هو التحدي النهائي لقابلية التوسع على المدى الطويل لإثيريوم، واستدامة التكنولوجيا، وحتى الأمان.
التطهير: الهدف الرئيسي.
تقليل متطلبات تخزين العميل من خلال تقليل أو القضاء على الحاجة إلى كل عقدة لتخزين جميع السجلات التاريخية أو حتى الحالة النهائية بشكل دائم.
خفض تعقيد البروتوكول من خلال إزالة الوظائف غير الضرورية.
فهرس المقالة:
تاريخ انتهاء الصلاحية（历史记录到期）
انتهاء الحالة（状态到期）
تنظيف الميزة
انتهاء التاريخ
ماذا تحل؟
حتى وقت كتابة هذه المقالة، تحتاج عقدة إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى حاجة لمئات الجيجابايت من مساحة القرص لعميل الإجماع. معظم هذه البيانات تاريخية: تتعلق بالكتل التاريخية والمعاملات والإيصالات، حيث أن معظمها يعود لسنوات عديدة. وهذا يعني أنه حتى لو لم تزد قيود الغاز على الإطلاق، فإن حجم العقدة سيستمر في الزيادة بمئات الجيجابايت سنويًا.
ما هو؟ كيف يعمل؟
تتمثل إحدى السمات الرئيسية لتبسيط مشكلة التخزين التاريخي في أنه نظرًا لأن كل كتلة تشير إلى الكتلة السابقة من خلال روابط التجزئة (وبنى أخرى)، فإن الوصول إلى توافق في الآراء الحالي يكفي للوصول إلى توافق في الآراء التاريخي. طالما أن الشبكة تتوصل إلى توافق في الآراء بشأن الكتلة الأخيرة، يمكن لأي مشارك فردي تقديم أي كتلة تاريخية أو معاملة أو حالة (رصيد الحساب، رقم عشوائي، كود، تخزين) بالإضافة إلى إثبات ميركل، مما يسمح لأي شخص آخر بالتحقق من صحته. التوافق هو نموذج ثقة N/2 من N، بينما التاريخ هو نموذج ثقة N من 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) ببساطة إدخال مكتبة torrent الموجودة، و (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.
ودية للمطورين: لا يحتاج المطورون إلى التحول إلى نماذج تفكير غير مألوفة تمامًا. بالإضافة إلى ذلك، يجب أن تظل التطبيقات الحالية التي أصبحت جامدة وغير محدثة تعمل بشكل طبيعي.
من السهل حل المشكلات عندما لا يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء (يمكن تمديد تاريخ انتهاء الصلاحية من خلال حرق ايثر، وهذا قد يحدث تلقائيًا عند القراءة أو الكتابة في أي وقت)، ويكون لديك عملية تتكرر عبر الحالة لحذف كائنات حالة تاريخ الانتهاء. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى متطلبات تخزين)، ومن المؤكد أنه لا يمكن أن يستوفي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج الحالات الحدودية التي تشمل قيم التخزين التي تعاد إلى الصفر أحيانًا. إذا قمت بإعداد مؤقت انتهاء داخل نطاق العقد، فإن ذلك من الناحية الفنية سيجعل حياة المطورين أسهل، لكنه سيجعل الأمور الاقتصادية أكثر صعوبة: يجب على المطورين أن يأخذوا في الاعتبار كيفية "تحويل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه كلها مشكلات كان مجتمع مطوري إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء الاقتراحات وركزنا على فئتين من "أقل الحلول السيئة المعروفة":
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يحتفظ الجميع بـ "خريطة أعلى" بشكل دائم.