إثيريوم تواجه تحديًا واحدًا وهو أنه بشكل افتراضي، فإن التضخم والتعقيد لأي بروتوكول بلوكتشين يزداد مع مرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب أن يتم تخزين أي صفقة تمت في أي لحظة تاريخية وأي حساب تم إنشاؤه بشكل دائم بواسطة جميع العملاء، ويجب أن يتم تنزيلها بواسطة أي عميل جديد، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.
لكي يتمكن إثيريوم من الاستمرار على المدى الطويل، نحتاج إلى تطبيق ضغط قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على أحد الخصائص الأساسية التي تجعل blockchain عظيمة: الديمومة. يمكنك وضع NFT، رسالة حب في بيانات مكالمة تجارية، أو عقد ذكي يحتوي على 1 مليون دولار على السلسلة، والدخول إلى كهف لمدة عشر سنوات، لتجد أنه لا يزال هناك في انتظارك للقراءة والتفاعل. لكي تتمكن التطبيقات اللامركزية من الذهاب بالكامل إلى اللامركزية بثقة وحذف مفاتيح الترقية، يحتاجون إلى التأكد من أن اعتماداتهم لن تتطور بطريقة تدمرهم - خاصة 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 ؛
التورنت وإي آي بي-4444؛
شبكة البوابة؛
شبكة البوابة و EIP-4444؛
تخزين واسترجاع الكائنات SSZ في Portal بشكل موزع؛
كيف تزيد من حد الغاز (بارادايم).
ماذا تحتاج أن تفعل بعد، وما الذي يجب موازنته؟
تشمل الأعمال الرئيسية المتبقية بناء وتكامل حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و 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.
سهولة التعامل مع المطورين: لا يحتاج المطورون إلى التحويل إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت متجمدة وغير محدثة في العمل بشكل طبيعي.
ليس من السهل حل المشكلات إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا في أي وقت عند القراءة أو الكتابة)، ووجود حلقة تتنقل عبر الحالة لحذف كائنات حالة تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى متطلبات تخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما أن المطورين يجدون صعوبة في استنتاج الحالات الحدية التي تتضمن قيم التخزين التي يتم إعادة تعيينها أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فهذا من الناحية الفنية يسهل حياة المطورين، لكنه يجعل الأمور الاقتصادية أكثر صعوبة: يجب على المطورين أن يفكروا في كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه هي المشاكل التي كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء المقترحات وركزنا على فئتين من "أفضل الحلول المعروفة الأقل سوءًا":
جزء من حلول انتهاء الحالة
اقتراح انتهاء الحالة بناءً على دورة العنوان.
انتهاء حالة جزئية
بعض المقترحات المتعلقة بالحالة المنتهية تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يقوم الجميع بتخزين "خريطة المستوى الأعلى" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط عندما يتم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد البيانات مخزنة.
الفرق الرئيسي بين هذه الاقتراحات هو: (i) كيف نحدد "الأخير" ،
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 19
أعجبني
19
3
مشاركة
تعليق
0/400
WhaleMinion
· 07-21 10:24
تقليم تقليم فيتاليك بوتيرين ثور批
شاهد النسخة الأصليةرد0
Ser_APY_2000
· 07-21 10:15
فيتاليك بوتيرين محق، يجب أن نتحسن أولاً لنعيش.
شاهد النسخة الأصليةرد0
HodlNerd
· 07-21 10:06
من الناحية الإحصائية، فإن هذه الاستراتيجية للتقليم هي تحفة في نظرية الألعاب... ببساطة رائعة
فيتاليك يشرح رؤية إثيريوم: كيف تحقق التطهير التنمية المستدامة على المدى الطويل
فيتاليك: المستقبل المحتمل لإثيريوم، التطهير
إثيريوم تواجه تحديًا واحدًا وهو أنه بشكل افتراضي، فإن التضخم والتعقيد لأي بروتوكول بلوكتشين يزداد مع مرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب أن يتم تخزين أي صفقة تمت في أي لحظة تاريخية وأي حساب تم إنشاؤه بشكل دائم بواسطة جميع العملاء، ويجب أن يتم تنزيلها بواسطة أي عميل جديد، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.
لكي يتمكن إثيريوم من الاستمرار على المدى الطويل، نحتاج إلى تطبيق ضغط قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على أحد الخصائص الأساسية التي تجعل blockchain عظيمة: الديمومة. يمكنك وضع NFT، رسالة حب في بيانات مكالمة تجارية، أو عقد ذكي يحتوي على 1 مليون دولار على السلسلة، والدخول إلى كهف لمدة عشر سنوات، لتجد أنه لا يزال هناك في انتظارك للقراءة والتفاعل. لكي تتمكن التطبيقات اللامركزية من الذهاب بالكامل إلى اللامركزية بثقة وحذف مفاتيح الترقية، يحتاجون إلى التأكد من أن اعتماداتهم لن تتطور بطريقة تدمرهم - خاصة 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 ؛
التورنت وإي آي بي-4444؛
شبكة البوابة؛
شبكة البوابة و EIP-4444؛
تخزين واسترجاع الكائنات SSZ في Portal بشكل موزع؛
كيف تزيد من حد الغاز (بارادايم).
ماذا تحتاج أن تفعل بعد، وما الذي يجب موازنته؟
تشمل الأعمال الرئيسية المتبقية بناء وتكامل حل موزع محدد لتخزين السجلات التاريخية ------ على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و 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.
سهولة التعامل مع المطورين: لا يحتاج المطورون إلى التحويل إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت متجمدة وغير محدثة في العمل بشكل طبيعي.
ليس من السهل حل المشكلات إذا لم يتم تلبية هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يخزن أيضًا عداد تاريخ انتهاء (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا في أي وقت عند القراءة أو الكتابة)، ووجود حلقة تتنقل عبر الحالة لحذف كائنات حالة تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم حسابات إضافية (حتى متطلبات تخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما أن المطورين يجدون صعوبة في استنتاج الحالات الحدية التي تتضمن قيم التخزين التي يتم إعادة تعيينها أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فهذا من الناحية الفنية يسهل حياة المطورين، لكنه يجعل الأمور الاقتصادية أكثر صعوبة: يجب على المطورين أن يفكروا في كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه هي المشاكل التي كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء المقترحات وركزنا على فئتين من "أفضل الحلول المعروفة الأقل سوءًا":
جزء من حلول انتهاء الحالة اقتراح انتهاء الحالة بناءً على دورة العنوان.
انتهاء حالة جزئية
بعض المقترحات المتعلقة بالحالة المنتهية تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يقوم الجميع بتخزين "خريطة المستوى الأعلى" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط عندما يتم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد البيانات مخزنة.
الفرق الرئيسي بين هذه الاقتراحات هو: (i) كيف نحدد "الأخير" ،