تواجه إثيريوم تحديًا يتمثل في أن التوسع والتعقيد لأي بروتوكول بلوكتشين سيزيد مع مرور الوقت بشكل افتراضي. يحدث ذلك في جانبين:
البيانات التاريخية: يجب تخزين أي صفقة تمت في أي وقت في التاريخ وأي حساب تم إنشاؤه من قبل جميع العملاء بشكل دائم، ويجب أن يتم تنزيلها من قبل أي عميل جديد، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة حمل العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد التعليمات البرمجية بمرور الوقت.
لضمان استمرار إثيريوم على المدى الطويل، نحتاج إلى تطبيق ضغط قوي على هاتين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على واحدة من الخصائص الأساسية التي تجعل البلوكتشين عظيمة: الديمومة. يمكنك وضع 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 الذي يحتوي على تاريخ إثيريوم بالكامل. سيتضمن التنفيذ الأكثر شمولاً ربطه فعليًا بعملية المزامنة، بحيث إذا أراد أي شخص مزامنة عقدة تخزين السجل الكامل أو عقدة الأرشيف، حتى لو لم تكن هناك عقد أرشيف أخرى متاحة على الإنترنت، يمكنه تحقيق ذلك من خلال المزامنة المباشرة مع شبكة البوابة.
كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
إذا كنا نريد أن تكون عملية تشغيل أو بدء العقدة سهلة للغاية، فإن تقليل متطلبات التخزين التاريخية يمكن أن يُعتبر أكثر أهمية من اللاstate: من بين 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي الحالة، والباقي حوالي 800 جيجابايت أصبح تاريخيًا. فقط من خلال تحقيق اللاstate و EIP-4444 يمكن تحقيق الرؤية لتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في غضون بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن أكثر لعملاء إثيريوم الجدد، حيث يدعمون فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الكود بأمان، حيث تم حذف جميع فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الأكواد المتعلقة بإثبات العمل بأمان.
انتهاء صلاحية الدولة
ماذا تحل؟
حتى لو قمنا بإزالة الحاجة إلى تخزين تاريخ العميل، فإن متطلبات التخزين للعميل ستستمر في النمو، بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، وكود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما سيؤدي إلى تحميل العملاء الحاليين والمستقبليين لإثيريوم.
الحالة أصعب من التاريخ "منتهية"، لأن EVM مصممة أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة قراءته في أي وقت. إذا قدمنا حالة غير محددة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة بناة الكتل المتخصصة تحتاج إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى (حتى تلك التي تتضمن إنشاء القوائم!) أن تعمل بدون حالة. ومع ذلك، هناك رأي مفاده أننا لا نريد الاعتماد بشكل مفرط على الحالة غير المحددة، وفي النهاية قد نرغب في جعل الحالة "منتهية" للحفاظ على اللامركزية في إثيريوم.
ما هو؟ كيف يعمل؟
اليوم، عندما تقوم بإنشاء كائن حالة جديد (يمكن أن يحدث ذلك بأحد الطرق الثلاث التالية: (i) إرسال ETH إلى حساب جديد، (ii) إنشاء حساب جديد باستخدام كود، (iii) إعداد فتحة تخزين لم تُستخدم من قبل)، فإن كائن الحالة يظل في تلك الحالة إلى الأبد. على العكس، ما نريد هو أن تنتهي صلاحية الكائن تلقائيًا بمرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا تحتاج إلى حسابات إضافية كبيرة لتشغيل عملية الانتهاء.
سهولة الاستخدام: إذا دخل شخص ما إلى الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
سهولة الاستخدام للمطورين: لا يحتاج المطورون إلى التحول إلى نماذج تفكير غير مألوفة تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل حل المشكلة إذا لم يتم تحقيق هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ايثر، وقد يحدث هذا تلقائيًا عند القراءة أو الكتابة في أي وقت)، ووجود عملية لتكرار الحالة لحذف كائنات الحالة بتاريخ انتهاء صلاحية منتهٍ. ومع ذلك، فإن هذا يقدم حوسبة إضافية (حتى متطلبات التخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج حالات الحافة التي تتضمن إعادة تعيين قيم التخزين أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية ضمن نطاق العقد، فإن ذلك سيجعل حياة المطورين أسهل من الناحية التقنية، لكنه سيجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يأخذوا في اعتبارهم كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه كلها مشاكل كانت مجتمع مطوري إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء المقترحات وركزنا على فئتين من "أفضل الحلول المعروفة الأقل سوءًا":
حلول انتهاء صلاحية الحالة الجزئية
اقتراح انتهاء حالة مستند إلى فترة عنوان.
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يقوم الجميع بتخزين "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
4
إعادة النشر
مشاركة
تعليق
0/400
HodlBeliever
· 08-10 09:55
ركضت لمدة خمس سنوات بعقد ، تكلفة 14 دولارًا ، لا يزال بالإمكان المشاهدة
شاهد النسخة الأصليةرد0
GasWaster
· 08-10 02:27
استخرج النقي من الخشن، لقد بدأت في الطريق الصحيح
شاهد النسخة الأصليةرد0
ChainSherlockGirl
· 08-10 02:23
أسرع في فقدان الوزن V神 منزلك داخل السلسلة مكدس تقريبًا حتى التصفية القسرية
فيتاليك يقدم رؤية إثيريوم The Purge: اسقاط التعقيد لتحقيق التنمية المستدامة على المدى الطويل
فيتاليك: مستقبل إثيريوم المحتمل، The Purge
تواجه إثيريوم تحديًا يتمثل في أن التوسع والتعقيد لأي بروتوكول بلوكتشين سيزيد مع مرور الوقت بشكل افتراضي. يحدث ذلك في جانبين:
البيانات التاريخية: يجب تخزين أي صفقة تمت في أي وقت في التاريخ وأي حساب تم إنشاؤه من قبل جميع العملاء بشكل دائم، ويجب أن يتم تنزيلها من قبل أي عميل جديد، مما يؤدي إلى مزامنة كاملة مع الشبكة. سيؤدي ذلك إلى زيادة حمل العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: من الأسهل بكثير إضافة ميزات جديدة من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد التعليمات البرمجية بمرور الوقت.
لضمان استمرار إثيريوم على المدى الطويل، نحتاج إلى تطبيق ضغط قوي على هاتين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الحفاظ على واحدة من الخصائص الأساسية التي تجعل البلوكتشين عظيمة: الديمومة. يمكنك وضع 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 الذي يحتوي على تاريخ إثيريوم بالكامل. سيتضمن التنفيذ الأكثر شمولاً ربطه فعليًا بعملية المزامنة، بحيث إذا أراد أي شخص مزامنة عقدة تخزين السجل الكامل أو عقدة الأرشيف، حتى لو لم تكن هناك عقد أرشيف أخرى متاحة على الإنترنت، يمكنه تحقيق ذلك من خلال المزامنة المباشرة مع شبكة البوابة.
كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
إذا كنا نريد أن تكون عملية تشغيل أو بدء العقدة سهلة للغاية، فإن تقليل متطلبات التخزين التاريخية يمكن أن يُعتبر أكثر أهمية من اللاstate: من بين 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي الحالة، والباقي حوالي 800 جيجابايت أصبح تاريخيًا. فقط من خلال تحقيق اللاstate و EIP-4444 يمكن تحقيق الرؤية لتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في غضون بضع دقائق.
تقييد التخزين التاريخي يجعل من الممكن أكثر لعملاء إثيريوم الجدد، حيث يدعمون فقط أحدث إصدار من البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الكود بأمان، حيث تم حذف جميع فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DoS في عام 2016. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الأكواد المتعلقة بإثبات العمل بأمان.
انتهاء صلاحية الدولة
ماذا تحل؟
حتى لو قمنا بإزالة الحاجة إلى تخزين تاريخ العميل، فإن متطلبات التخزين للعميل ستستمر في النمو، بمعدل حوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، وكود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما سيؤدي إلى تحميل العملاء الحاليين والمستقبليين لإثيريوم.
الحالة أصعب من التاريخ "منتهية"، لأن EVM مصممة أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة قراءته في أي وقت. إذا قدمنا حالة غير محددة، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة بناة الكتل المتخصصة تحتاج إلى تخزين الحالة فعليًا، بينما يمكن لجميع العقد الأخرى (حتى تلك التي تتضمن إنشاء القوائم!) أن تعمل بدون حالة. ومع ذلك، هناك رأي مفاده أننا لا نريد الاعتماد بشكل مفرط على الحالة غير المحددة، وفي النهاية قد نرغب في جعل الحالة "منتهية" للحفاظ على اللامركزية في إثيريوم.
ما هو؟ كيف يعمل؟
اليوم، عندما تقوم بإنشاء كائن حالة جديد (يمكن أن يحدث ذلك بأحد الطرق الثلاث التالية: (i) إرسال ETH إلى حساب جديد، (ii) إنشاء حساب جديد باستخدام كود، (iii) إعداد فتحة تخزين لم تُستخدم من قبل)، فإن كائن الحالة يظل في تلك الحالة إلى الأبد. على العكس، ما نريد هو أن تنتهي صلاحية الكائن تلقائيًا بمرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا تحتاج إلى حسابات إضافية كبيرة لتشغيل عملية الانتهاء.
سهولة الاستخدام: إذا دخل شخص ما إلى الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
سهولة الاستخدام للمطورين: لا يحتاج المطورون إلى التحول إلى نماذج تفكير غير مألوفة تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل حل المشكلة إذا لم يتم تحقيق هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ايثر، وقد يحدث هذا تلقائيًا عند القراءة أو الكتابة في أي وقت)، ووجود عملية لتكرار الحالة لحذف كائنات الحالة بتاريخ انتهاء صلاحية منتهٍ. ومع ذلك، فإن هذا يقدم حوسبة إضافية (حتى متطلبات التخزين)، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في استنتاج حالات الحافة التي تتضمن إعادة تعيين قيم التخزين أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية ضمن نطاق العقد، فإن ذلك سيجعل حياة المطورين أسهل من الناحية التقنية، لكنه سيجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يأخذوا في اعتبارهم كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه كلها مشاكل كانت مجتمع مطوري إثيريوم الأساسي يعمل على حلها لسنوات، بما في ذلك مقترحات مثل "إيجار البلوكشين" و"التجديد". في النهاية، جمعنا أفضل أجزاء المقترحات وركزنا على فئتين من "أفضل الحلول المعروفة الأقل سوءًا":
انتهاء حالة جزئية
بعض مقترحات انتهاء الحالة تتبع نفس المبادئ. نقوم بتقسيم الحالة إلى كتل. يقوم الجميع بتخزين "الخريطة العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط إذا تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم تعد مخزنة.
![فيتاليك: مستقبل إثيريوم المحتمل، التطهير](https://