إحدى التحديات التي تواجه إثيريوم هي أنه، بشكل افتراضي، فإن تضخم وتعقيد أي بروتوكول بلوكشين سيزداد بمرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب تخزين جميع المعاملات التي تمت في أي وقت من التاريخ وأي حساب تم إنشاؤه بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
لجعل إثيريوم قادرًا على البقاء على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على الاتجاهين المذكورين، مع تقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على إحدى الخصائص الرئيسية التي تجعل البلوكشين رائعًا: الديمومة. يمكنك وضع 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( إدخال مكتبة torrent الموجودة، بالإضافة إلى )ii( المعروفة باسم حل إيثريوم الأصلي لشبكة Portal. بمجرد إدخال أي واحد من هذه، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقساماً صلباً، لكنه يحتاج إلى إصدار جديد من بروتوكول الشبكة. لذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا هناك خطر من حدوث أعطال للعملاء بسبب توقع الاتصال بعقد أخرى لتحميل السجل الكامل ولكن لم يتم الحصول عليه فعلياً.
تتضمن الموازنة الرئيسية كيفية جهودنا لتقديم بيانات التاريخ "القديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الحالية ومجموعة متنوعة من مقدمي الخدمة المركزية للنسخ. هذا سهل، لكنه يضعف مكانة إثيريوم كمكان للسجلات الدائمة. الطريق الأكثر صعوبة ولكنه أكثر أمانًا هو بناء وتكامل شبكة التورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهودنا" له بعدان:
كيف نعمل على ضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما مدى عمق تكامل تخزين التاريخ في البروتوكول؟
طريقة متطرفة متشددة لـ ) ستتضمن إثبات الحفظ: تطلب فعليًا من كل مدقق إثبات ملكية تخزين نسبة معينة من السجل التاريخي، والتحقق منها بانتظام بطريقة مشفرة. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة السجل التاريخي المخزنة لكل عميل.
بالنسبة لـ (، فإن التنفيذ الأساسي يتضمن فقط العمل الذي تم إكماله اليوم: لقد خزّن البوابة ملف ERA الذي يحتوي على تاريخ إثيريوم بالكامل. سيتضمن التنفيذ الأكثر شمولاً ربطه فعليًا بعملية المزامنة، بحيث إذا أراد أي شخص مزامنة عقدة تخزين السجل الكامل للتاريخ أو عقدة الأرشفة، حتى لو لم تكن هناك عقد أرشيف أخرى متاحة على الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة مع شبكة البوابة.
)# كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟
إذا أردنا جعل تشغيل أو بدء العقدة سهلاً للغاية، فيمكن القول إن تقليل متطلبات تخزين التاريخ أكثر أهمية من عدم الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي الحالة، والباقي حوالي 800 جيجابايت أصبح تاريخاً. لا يمكن تحقيق الرؤية المتمثلة في تشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في بضع دقائق إلا من خلال تحقيق عدم الحالة و EIP-4444.
تقييد التخزين التاريخي يجعل من الممكن تنفيذ عقد إثيريوم الأحدث بشكل أفضل، حيث تدعم فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016 قد تم حذفها بالكامل. الآن بعد أن أصبح التحول إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
( انتهاء الحالة
)# ما المشكلة التي يتم حلها؟
حتى لو ألغينا الحاجة إلى تخزين السجلات التاريخية على العميل، فإن احتياجات التخزين للعميل ستستمر في النمو، بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، كود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أكثر صعوبة من التاريخ "منتهية الصلاحية"، لأن EVM مصمم أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة قراءته في أي وقت. إذا قمنا بإدخال عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: تحتاج فقط فئة بناء الكتل المتخصصة إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى ### وحتى تلك التي تحتوي على قوائم توليد! ### العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إننا لا نريد الاعتماد بشكل مفرط على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة منتهية الصلاحية للحفاظ على لامركزية إيثيريوم.
اليوم، عند إنشاء كائن حالة جديدة، يمكن أن يحدث ( من خلال واحدة من الطرق الثلاث التالية: ) i ### إرسال ETH إلى حساب جديد، ( ii ( استخدام الكود لإنشاء حساب جديد، ) iii ( تعيين فتحة تخزين لم يتم الوصول إليها من قبل )، حيث يظل كائن الحالة في تلك الحالة إلى الأبد. بدلاً من ذلك، ما نريده هو أن يتجاوز الكائن بشكل تلقائي مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة.
الكفاءة: لا حاجة إلى الكثير من الحسابات الإضافية لتشغيل عملية الاستحقاق.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا يجب أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
سهولة استخدام المطورين: لا يتعين على المطورين الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تتمكن التطبيقات التي أصبحت جامدة وغير محدثة من الاستمرار في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم استيفاء هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية. يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا في أي وقت يتم فيه القراءة أو الكتابة، وهناك عملية للتكرار عبر الحالة لإزالة كائنات الحالة ذات تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية إضافية وحتى متطلبات تخزين. ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج الحالات الحدية التي تتضمن تخزين القيم أحيانًا تعود إلى الصفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فهذا يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين التفكير في كيفية "تحويل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه هي المشاكل التي عملت عليها مجتمع تطوير إثيريوم الأساسي لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، قمنا بدمج أفضل الأجزاء من المقترحات، وركزنا على فئتين من "أقل الحلول السيئة المعروفة":
حلول انتهاء حالة جزئية
اقتراح انتهاء حالة بناءً على دورة العنوان.
)# انتهاء جزء من الحالة
تتبع بعض مقترحات انتهاء الحالة نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يخزن الجميع "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. فقط عندما تكون الأكثر
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 24
أعجبني
24
5
مشاركة
تعليق
0/400
0xSherlock
· 07-28 16:14
صعب جداً! من يستطيع الفهم يرفع يده.
شاهد النسخة الأصليةرد0
WalletDetective
· 07-25 22:52
هذه أيضًا مشكلة كبيرة ها~
شاهد النسخة الأصليةرد0
DeFiGrayling
· 07-25 22:51
البلوكتشين يترتفع أسرع من سعر العملة
شاهد النسخة الأصليةرد0
0xLuckbox
· 07-25 22:51
التسوية أسهل من الابتكار
شاهد النسخة الأصليةرد0
CryptoFortuneTeller
· 07-25 22:50
دي دي المزامنة الأولى تشبه treadmill حقًا لا تنتهي
رؤية المستقبل لإثيريوم: كيف ستعيد عملية التطهير تشكيل بيئة البلوكتشين
إثيريوم المستقبل المحتمل: The Purge
إحدى التحديات التي تواجه إثيريوم هي أنه، بشكل افتراضي، فإن تضخم وتعقيد أي بروتوكول بلوكشين سيزداد بمرور الوقت. يحدث هذا في مكانين:
البيانات التاريخية: يجب تخزين جميع المعاملات التي تمت في أي وقت من التاريخ وأي حساب تم إنشاؤه بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة تحميل العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
لجعل إثيريوم قادرًا على البقاء على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على الاتجاهين المذكورين، مع تقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على إحدى الخصائص الرئيسية التي تجعل البلوكشين رائعًا: الديمومة. يمكنك وضع 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( إدخال مكتبة torrent الموجودة، بالإضافة إلى )ii( المعروفة باسم حل إيثريوم الأصلي لشبكة Portal. بمجرد إدخال أي واحد من هذه، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه انقساماً صلباً، لكنه يحتاج إلى إصدار جديد من بروتوكول الشبكة. لذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا هناك خطر من حدوث أعطال للعملاء بسبب توقع الاتصال بعقد أخرى لتحميل السجل الكامل ولكن لم يتم الحصول عليه فعلياً.
تتضمن الموازنة الرئيسية كيفية جهودنا لتقديم بيانات التاريخ "القديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الحالية ومجموعة متنوعة من مقدمي الخدمة المركزية للنسخ. هذا سهل، لكنه يضعف مكانة إثيريوم كمكان للسجلات الدائمة. الطريق الأكثر صعوبة ولكنه أكثر أمانًا هو بناء وتكامل شبكة التورنت أولاً، لتخزين السجلات بطريقة موزعة. هنا، "مدى جهودنا" له بعدان:
كيف نعمل على ضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما مدى عمق تكامل تخزين التاريخ في البروتوكول؟
طريقة متطرفة متشددة لـ ) ستتضمن إثبات الحفظ: تطلب فعليًا من كل مدقق إثبات ملكية تخزين نسبة معينة من السجل التاريخي، والتحقق منها بانتظام بطريقة مشفرة. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة السجل التاريخي المخزنة لكل عميل.
بالنسبة لـ (، فإن التنفيذ الأساسي يتضمن فقط العمل الذي تم إكماله اليوم: لقد خزّن البوابة ملف ERA الذي يحتوي على تاريخ إثيريوم بالكامل. سيتضمن التنفيذ الأكثر شمولاً ربطه فعليًا بعملية المزامنة، بحيث إذا أراد أي شخص مزامنة عقدة تخزين السجل الكامل للتاريخ أو عقدة الأرشفة، حتى لو لم تكن هناك عقد أرشيف أخرى متاحة على الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة مع شبكة البوابة.
)# كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟
إذا أردنا جعل تشغيل أو بدء العقدة سهلاً للغاية، فيمكن القول إن تقليل متطلبات تخزين التاريخ أكثر أهمية من عدم الحالة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي الحالة، والباقي حوالي 800 جيجابايت أصبح تاريخاً. لا يمكن تحقيق الرؤية المتمثلة في تشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في بضع دقائق إلا من خلال تحقيق عدم الحالة و EIP-4444.
تقييد التخزين التاريخي يجعل من الممكن تنفيذ عقد إثيريوم الأحدث بشكل أفضل، حيث تدعم فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016 قد تم حذفها بالكامل. الآن بعد أن أصبح التحول إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
( انتهاء الحالة
)# ما المشكلة التي يتم حلها؟
حتى لو ألغينا الحاجة إلى تخزين السجلات التاريخية على العميل، فإن احتياجات التخزين للعميل ستستمر في النمو، بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، كود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يثقل كاهل عملاء إثيريوم الحاليين والمستقبليين إلى الأبد.
الحالة أكثر صعوبة من التاريخ "منتهية الصلاحية"، لأن EVM مصمم أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة قراءته في أي وقت. إذا قمنا بإدخال عدم الحالة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: تحتاج فقط فئة بناء الكتل المتخصصة إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى ### وحتى تلك التي تحتوي على قوائم توليد! ### العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إننا لا نريد الاعتماد بشكل مفرط على عدم الحالة، وفي النهاية قد نرغب في جعل الحالة منتهية الصلاحية للحفاظ على لامركزية إيثيريوم.
![فيتاليك: مستقبل إثيريوم المحتمل، التطهير]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(
)# ماذا هو، كيف يعمل
اليوم، عند إنشاء كائن حالة جديدة، يمكن أن يحدث ( من خلال واحدة من الطرق الثلاث التالية: ) i ### إرسال ETH إلى حساب جديد، ( ii ( استخدام الكود لإنشاء حساب جديد، ) iii ( تعيين فتحة تخزين لم يتم الوصول إليها من قبل )، حيث يظل كائن الحالة في تلك الحالة إلى الأبد. بدلاً من ذلك، ما نريده هو أن يتجاوز الكائن بشكل تلقائي مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة.
الكفاءة: لا حاجة إلى الكثير من الحسابات الإضافية لتشغيل عملية الاستحقاق.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا يجب أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
سهولة استخدام المطورين: لا يتعين على المطورين الانتقال إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تتمكن التطبيقات التي أصبحت جامدة وغير محدثة من الاستمرار في العمل بشكل طبيعي.
من السهل حل المشكلات إذا لم يتم استيفاء هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية. يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ايثر، وهذا قد يحدث تلقائيًا في أي وقت يتم فيه القراءة أو الكتابة، وهناك عملية للتكرار عبر الحالة لإزالة كائنات الحالة ذات تاريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية إضافية وحتى متطلبات تخزين. ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج الحالات الحدية التي تتضمن تخزين القيم أحيانًا تعود إلى الصفر. إذا قمت بتعيين مؤقت انتهاء داخل نطاق العقد، فهذا يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين التفكير في كيفية "تحويل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه هي المشاكل التي عملت عليها مجتمع تطوير إثيريوم الأساسي لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، قمنا بدمج أفضل الأجزاء من المقترحات، وركزنا على فئتين من "أقل الحلول السيئة المعروفة":
)# انتهاء جزء من الحالة
تتبع بعض مقترحات انتهاء الحالة نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يخزن الجميع "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. فقط عندما تكون الأكثر