إثيريوم تواجه تحديًا يتمثل في أن التضخم وتعقيد أي بروتوكول blockchain سيزداد مع مرور الوقت بشكل افتراضي. يحدث هذا في جانبين:
البيانات التاريخية: يجب تخزين جميع المعاملات والحسابات التي تم إنشاؤها في أي لحظة تاريخية بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها بالكامل لمزامنتها مع الشبكة. وهذا يؤدي إلى زيادة الحمل على العميل ووقت المزامنة باستمرار، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: إضافة ميزات جديدة أسهل بكثير من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
للحفاظ على إثيريوم على المدى الطويل، نحتاج إلى فرض ضغط قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. في الوقت نفسه، نحتاج إلى الاحتفاظ بإحدى الخصائص الرئيسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع NFT، أو رسائل الحب في سجلات المعاملات، أو عقود ذكية تحتوي على 1000000 دولار على السلسلة، وبعد 10 سنوات ستظل هناك في انتظارك لقراءتها والتفاعل معها. لكي تتمكن DApp من اللامركزية الكاملة بأمان وحذف مفاتيح الترقية، يحتاجون إلى التأكد من أن الاعتماد الخاص بهم لن يتم ترقيته بطريقة تضر بهم - وخاصة L1 نفسها.
إذا كنا عازمين على تحقيق التوازن بين هذين الطلبين، وتقليل أو عكس التضخم والتعقيد والانحدار مع الحفاظ على الاستمرارية، فهذا ممكن بالتأكيد. يمكن للكائنات الحية القيام بذلك: بينما تتقدم معظم الكائنات الحية في العمر مع الوقت، فإن القلة المحظوظة لا تفعل ذلك. حتى الأنظمة الاجتماعية يمكن أن تتمتع بعمر طويل جدًا. في بعض الحالات، حقق إثيريوم نجاحًا: اختفى إثبات العمل، واختفى معظم رمز التشغيل SELFDESTRUCT، وقد خزّن عقد سلسلة الإشارات بيانات قديمة تصل إلى ستة أشهر. إن العثور على هذا الطريق لإيثريوم بطريقة أكثر عمومية، والسير نحو نتيجة نهائية مستقرة على المدى الطويل، هو التحدي النهائي لقابلية توسع إيثريوم على المدى الطويل، واستدامتها التكنولوجية، وحتى أمانها.
الهدف الرئيسي من The Purge:
تقليل متطلبات تخزين العميل عن طريق تقليل أو القضاء على الحاجة إلى تخزين جميع السجلات التاريخية أو حتى الحالة النهائية بشكل دائم لكل عقدة.
تقليل تعقيد البروتوكول من خلال إزالة الميزات غير الضرورية
انتهاء التاريخ
ماذا يحل؟
حتى وقت كتابة هذا المقال، تحتاج العقدة المتزامنة بالكامل لإثيريوم إلى حوالي 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) ببساطة إدخال مكتبة التورنت الحالية، بالإضافة إلى (ii) الحل الأصلي لإيثريوم المعروف باسم شبكة Portal. بمجرد إدخال أي من هذين، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه تقسيمًا صارمًا، ولكنه يحتاج إلى إصدار جديد من بروتوكول الشبكة. ولذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا سيكون هناك خطر فشل العملاء بسبب توقع الاتصال بالعقد الأخرى لتحميل السجلات التاريخية الكاملة ولكنهم لن يحصلوا عليها في الواقع.
تشمل الموازنة الرئيسية كيف نسعى لتوفير بيانات التاريخ "القديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الحالية ومجموعة متنوعة من مقدمي الخدمات المركزية للنسخ. هذا سهل، لكنه يضعف من مكانة إثيريوم كمكان لسجل دائم. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي أولاً بناء وتكامل شبكة تورنت، لتخزين التاريخ بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نعمل جاهدين لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما عمق الدمج الذي سنقوم به لتخزين التاريخ في البروتوكول؟
طريقة متطرفة للغاية للتعامل مع ( ستتضمن إثبات الحفظ: تطلب فعليًا من كل مدقق إثبات حقوق أن يخزن نسبة معينة من السجل التاريخي، وأن يتحقق بانتظام بشكل مشفر مما إذا كانوا يقومون بذلك. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ )2(، فإن التنفيذ الأساسي ينطوي فقط على العمل الذي تم إنجازه اليوم: لقد قام البوابة بتخزين ملف ERA الذي يحتوي على التاريخ الكامل لإثيريوم. سيتطلب التنفيذ الأكثر شمولاً ربطه فعليًا بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة العقدة الكاملة لتاريخ التخزين أو العقدة الأرشيفية، حتى لو لم تكن هناك عقد أرشيفية أخرى متصلة على الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة مع شبكة البوابة.
) كيف تتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
إذا كنا نرغب في جعل تشغيل أو بدء العقدة سهلاً للغاية، فيمكن القول إن تقليل متطلبات تخزين التاريخ أهم من الحالة غير المتصلة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي حالة، والباقي حوالي 800 جيجابايت أصبح تاريخًا. فقط من خلال تحقيق الحالة غير المتصلة وEIP-4444، يمكن تحقيق الرؤية لتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في دقائق قليلة.
تحديد التخزين التاريخي يجعل من الممكن بشكل أكبر تنفيذ عقد إثيريوم الأحدث، حيث تدعم فقط أحدث إصدارات البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي أنشئت خلال هجوم DoS في عام 2016 قد تم حذفها بالكامل. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
حتى لو أزلنا الحاجة إلى تخزين تاريخ العميل، فإن حاجة العميل للتخزين ستستمر في الزيادة، بحوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، كود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يفرض عبئًا على عملاء إثيريوم الحاليين والمستقبليين.
تكون الحالة أكثر صعوبة من التاريخ "منتهية الصلاحية"، لأن EVM مصممة أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة قراءته في أي وقت. إذا قمنا بإدخال الحالة غير المتصل، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة بنائي الكتل المتخصصة تحتاج إلى تخزين الحالة فعليًا، في حين يمكن لجميع العقد الأخرى ### حتى تلك التي تحتوي على قائمة توليد! ( العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إننا لا نريد الاعتماد بشكل مفرط على الحالة غير المتصلة، وفي النهاية قد نرغب في جعل الحالة تنتهي صلاحيتها للحفاظ على لامركزية إيثريوم.
) ما هو؟ كيف يعمل؟
اليوم، عندما تقوم بإنشاء كائن حالة جديد، يمكن أن يحدث ### بأحد الطرق الثلاث التالية: ( i ( إرسال ETH إلى حساب جديد، ) ii ( إنشاء حساب جديد باستخدام الشيفرة، ) iii ( إعداد فتحة تخزين لم يتم لمسها من قبل )، يبقى هذا الكائن في تلك الحالة إلى الأبد. على العكس، ما نريد هو أن ينتهي الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا تحتاج إلى حسابات إضافية كبيرة لتشغيل عملية الانتهاء.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
صداقة المطورين: لا يحتاج المطورون إلى التحول إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل جداً حل المشكلات إذا لم يتم استيفاء هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية ) يمكن أن يتم تمديد تاريخ انتهاء الصلاحية عن طريق حرق ETH، وقد يحدث هذا تلقائيًا في أي وقت للقراءة أو الكتابة (، مع وجود عملية للتكرار عبر الحالة لإزالة كائنات الحالة ذات تواريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية ) إضافية حتى متطلبات التخزين (، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في الاستدلال على الحالات الحافة التي تتضمن قيم التخزين التي يتم إعادة تعيينها أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية داخل نطاق العقد، فإن ذلك يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يأخذوا في الاعتبار كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه هي المشاكل التي كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار blockchain" و"إعادة الإنتاج". في النهاية، قمنا بدمج أفضل أجزاء المقترحات وتركيزنا على نوعين من "أقل الحلول سوءًا المعروفة":
حلول انتهاء بعض الحالات
اقتراح انتهاء الحالة بناءً على فترة عنوان
) انتهاء حالة جزئية
بعض حالات انتهاء الاقتراحات تتبع نفس المبادئ. نحن نقسم الحالة إلى كتل. يقوم الجميع بتخزين "الخرائط العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط عندما يتم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم يعد يتم تخزينها.
الفرق الرئيسي بين هذه الاقتراحات هو: ###i( كيف نعرّف "الأخيرة"، و )ii( كيف نعرّف "الكتلة"؟ أحد الاقتراحات المحددة هو EIP-7736، الذي يبني على تصميم "الأغصان" الذي تم تقديمه لشجرة Verkle ) على الرغم من أنه يتوافق مع أي شكل من أشكال الحالة غير الحالة، مثل الشجرة الثنائية (. في هذا التصميم، يتم تخزين الرؤوس والرموز وفتحات التخزين المجاورة لبعضها البعض تحت نفس "الجذع". يمكن أن تصل البيانات المخزنة تحت جذع واحد إلى 256 * 31 = 7,936 بايت. في العديد من الحالات، سيتم تخزين الرأس والرمز الكاملين للحساب والعديد من فتحات التخزين المفاتيح تحت نفس الجذع. إذا لم يتم قراءة أو كتابة البيانات الموجودة تحت الجذع المعطى خلال 6 أشهر، فلن يتم تخزين هذه البيانات بعد الآن، ولكن سيتم تخزين 32 بايت فقط من تلك البيانات.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
6
مشاركة
تعليق
0/400
LadderToolGuy
· 08-01 17:23
تجرؤ على حذف البيانات التاريخية
شاهد النسخة الأصليةرد0
Ser_APY_2000
· 08-01 13:46
فيتاليك بوتيرين حقًا يعرف كيف يفعل الأمور
شاهد النسخة الأصليةرد0
TrustlessMaximalist
· 07-29 18:30
Vitalik Buterin يتحدث بطريقة قوية.
شاهد النسخة الأصليةرد0
ConfusedWhale
· 07-29 18:27
لا يزال حديث فيت شين عميقاً هكذا
شاهد النسخة الأصليةرد0
hodl_therapist
· 07-29 18:17
لا يوجد خطأ فيما قاله العجوز V
شاهد النسخة الأصليةرد0
MetaverseLandlord
· 07-29 18:06
مساحة التخزين مكلفة للغاية، من الأفضل تنظيفها بدلاً من الاحتفاظ بها.
إثيريوم The Purge: اسقاط تاريخ التخزين تبسيط البروتوكول تعزيز الاستدامة
إثيريوم المستقبل المحتمل: The Purge
المؤلف: فيتاليك بوتيرين
إثيريوم تواجه تحديًا يتمثل في أن التضخم وتعقيد أي بروتوكول blockchain سيزداد مع مرور الوقت بشكل افتراضي. يحدث هذا في جانبين:
البيانات التاريخية: يجب تخزين جميع المعاملات والحسابات التي تم إنشاؤها في أي لحظة تاريخية بشكل دائم من قبل جميع العملاء، ويجب على أي عميل جديد تنزيلها بالكامل لمزامنتها مع الشبكة. وهذا يؤدي إلى زيادة الحمل على العميل ووقت المزامنة باستمرار، حتى لو ظلت سعة السلسلة ثابتة.
وظيفة البروتوكول: إضافة ميزات جديدة أسهل بكثير من حذف الميزات القديمة، مما يؤدي إلى زيادة تعقيد الشيفرة مع مرور الوقت.
للحفاظ على إثيريوم على المدى الطويل، نحتاج إلى فرض ضغط قوي على هذين الاتجاهين، وتقليل التعقيد والتضخم مع مرور الوقت. في الوقت نفسه، نحتاج إلى الاحتفاظ بإحدى الخصائص الرئيسية التي تجعل البلوكشين عظيمة: الديمومة. يمكنك وضع NFT، أو رسائل الحب في سجلات المعاملات، أو عقود ذكية تحتوي على 1000000 دولار على السلسلة، وبعد 10 سنوات ستظل هناك في انتظارك لقراءتها والتفاعل معها. لكي تتمكن DApp من اللامركزية الكاملة بأمان وحذف مفاتيح الترقية، يحتاجون إلى التأكد من أن الاعتماد الخاص بهم لن يتم ترقيته بطريقة تضر بهم - وخاصة L1 نفسها.
إذا كنا عازمين على تحقيق التوازن بين هذين الطلبين، وتقليل أو عكس التضخم والتعقيد والانحدار مع الحفاظ على الاستمرارية، فهذا ممكن بالتأكيد. يمكن للكائنات الحية القيام بذلك: بينما تتقدم معظم الكائنات الحية في العمر مع الوقت، فإن القلة المحظوظة لا تفعل ذلك. حتى الأنظمة الاجتماعية يمكن أن تتمتع بعمر طويل جدًا. في بعض الحالات، حقق إثيريوم نجاحًا: اختفى إثبات العمل، واختفى معظم رمز التشغيل SELFDESTRUCT، وقد خزّن عقد سلسلة الإشارات بيانات قديمة تصل إلى ستة أشهر. إن العثور على هذا الطريق لإيثريوم بطريقة أكثر عمومية، والسير نحو نتيجة نهائية مستقرة على المدى الطويل، هو التحدي النهائي لقابلية توسع إيثريوم على المدى الطويل، واستدامتها التكنولوجية، وحتى أمانها.
الهدف الرئيسي من The Purge:
انتهاء التاريخ
ماذا يحل؟
حتى وقت كتابة هذا المقال، تحتاج العقدة المتزامنة بالكامل لإثيريوم إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى مئات الجيجابايت من مساحة القرص لعميل الإجماع. الغالبية العظمى من ذلك هي بيانات تاريخية: بيانات حول الكتل التاريخية والمعاملات والإيصالات، معظمها يعود لسنوات عديدة. وهذا يعني أنه حتى لو لم تزد قيود الغاز على الإطلاق، فإن حجم العقدة سيستمر في الزيادة بمئات الجيجابايت كل عام.
ما هو؟ كيف يعمل؟
تتمثل إحدى السمات الرئيسية المبسطة لمشكلة التخزين التاريخي في أنه نظرًا لأن كل كتلة مرتبطة بالكتلة السابقة عبر التجزئة ( وهياكل أخرى )، فإن التوصل إلى توافق في الآراء الحالي يكفي للتوصل إلى توافق في الآراء التاريخي. طالما أن الشبكة تتوصل إلى توافق في الآراء بشأن الكتلة الأخيرة، يمكن لأي مشارك فردي تقديم أي كتلة تاريخية أو معاملة أو حالة ( أو رصيد حساب، أو عدد عشوائي، أو رمز، أو تخزين )، وتسمح هذه الإثباتات لأي شخص آخر بالتحقق من صحتها. التوافق هو نموذج ثقة N/2 من N، بينما التاريخ هو نموذج ثقة N من N.
هذا يوفر لنا العديد من الخيارات حول كيفية تخزين السجلات التاريخية. الخيار الطبيعي هو شبكة حيث يخزن كل عقدة جزءًا صغيرًا فقط من البيانات. هذه هي الطريقة التي عملت بها شبكات البذور لعقود من الزمن: بينما تخزن الشبكة وتوزع ملايين الملفات، يخزن كل مشارك ويوزع فقط عددًا قليلاً منها. ربما على عكس الحدس، فإن هذه الطريقة لا تقلل بالضرورة من صلابة البيانات. إذا كان بإمكاننا بناء شبكة تضم 100,000 عقدة حيث تخزن كل عقدة 10% عشوائية من السجلات التاريخية، فإن كل بيانات ستنسخ 10,000 مرة - تمامًا مثل عامل النسخ لشبكة مكونة من 10,000 عقدة، حيث تخزن كل عقدة كل المحتوى.
الآن، بدأت إثيريوم في التخلص من نموذج تخزين جميع التاريخ بشكل دائم من قبل جميع العقد. الكتلة التوافقية ( المرتبطة بجزء التوافق القائم على إثبات الحصة ) تخزن حوالي 6 أشهر فقط. يتم تخزين Blob لمدة حوالي 18 يومًا. تهدف EIP-4444 إلى إدخال فترة تخزين لمدة عام للكتل التاريخية والإيصالات. الهدف على المدى الطويل هو إنشاء فترة موحدة ( قد تكون حوالي 18 يومًا )، وخلال هذه الفترة تتحمل كل عقدة مسؤولية تخزين كل المحتوى، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم لتخزين البيانات القديمة بطريقة موزعة.
يمكن استخدام رموز المسح لتحسين المتانة مع الحفاظ على عامل النسخ كما هو. في الواقع، تم تطبيق رمز المسح على Blob لدعم عينة توفر البيانات. الحل الأبسط على الأرجح هو إعادة استخدام هذه الرموز، ووضع بيانات التنفيذ والكتل المتفقة أيضًا في blob.
مع الأبحاث الحالية ما هي العلاقة؟
ماذا يتعين القيام به بعد ذلك، وما الذي يجب مراعاته؟
تشمل الأعمال الرئيسية المتبقية بناء وتكامل حل موزع محدد لتخزين السجلات التاريخية - على الأقل سجلات التنفيذ، ولكن في النهاية تشمل أيضًا الإجماع و blob. الحل الأبسط هو (i) ببساطة إدخال مكتبة التورنت الحالية، بالإضافة إلى (ii) الحل الأصلي لإيثريوم المعروف باسم شبكة Portal. بمجرد إدخال أي من هذين، يمكننا فتح EIP-4444. لا يتطلب EIP-4444 نفسه تقسيمًا صارمًا، ولكنه يحتاج إلى إصدار جديد من بروتوكول الشبكة. ولذلك، من المفيد تمكينه لجميع العملاء في نفس الوقت، وإلا سيكون هناك خطر فشل العملاء بسبب توقع الاتصال بالعقد الأخرى لتحميل السجلات التاريخية الكاملة ولكنهم لن يحصلوا عليها في الواقع.
تشمل الموازنة الرئيسية كيف نسعى لتوفير بيانات التاريخ "القديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الحالية ومجموعة متنوعة من مقدمي الخدمات المركزية للنسخ. هذا سهل، لكنه يضعف من مكانة إثيريوم كمكان لسجل دائم. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي أولاً بناء وتكامل شبكة تورنت، لتخزين التاريخ بطريقة موزعة. هنا، "مدى جهدنا" له بعدان:
كيف نعمل جاهدين لضمان أن مجموعة العقد الأكبر تخزن جميع البيانات بالفعل؟
ما عمق الدمج الذي سنقوم به لتخزين التاريخ في البروتوكول؟
طريقة متطرفة للغاية للتعامل مع ( ستتضمن إثبات الحفظ: تطلب فعليًا من كل مدقق إثبات حقوق أن يخزن نسبة معينة من السجل التاريخي، وأن يتحقق بانتظام بشكل مشفر مما إذا كانوا يقومون بذلك. الطريقة الأكثر اعتدالًا هي وضع معيار طوعي لنسبة التاريخ المخزنة لكل عميل.
بالنسبة لـ )2(، فإن التنفيذ الأساسي ينطوي فقط على العمل الذي تم إنجازه اليوم: لقد قام البوابة بتخزين ملف ERA الذي يحتوي على التاريخ الكامل لإثيريوم. سيتطلب التنفيذ الأكثر شمولاً ربطه فعليًا بعملية المزامنة، بحيث إذا أراد شخص ما مزامنة العقدة الكاملة لتاريخ التخزين أو العقدة الأرشيفية، حتى لو لم تكن هناك عقد أرشيفية أخرى متصلة على الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة مع شبكة البوابة.
) كيف تتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
إذا كنا نرغب في جعل تشغيل أو بدء العقدة سهلاً للغاية، فيمكن القول إن تقليل متطلبات تخزين التاريخ أهم من الحالة غير المتصلة: من 1.1 تيرابايت المطلوبة للعقدة، حوالي 300 جيجابايت هي حالة، والباقي حوالي 800 جيجابايت أصبح تاريخًا. فقط من خلال تحقيق الحالة غير المتصلة وEIP-4444، يمكن تحقيق الرؤية لتشغيل عقدة إثيريوم على ساعة ذكية وإعدادها في دقائق قليلة.
تحديد التخزين التاريخي يجعل من الممكن بشكل أكبر تنفيذ عقد إثيريوم الأحدث، حيث تدعم فقط أحدث إصدارات البروتوكول، مما يجعلها أبسط. على سبيل المثال، يمكن الآن حذف العديد من أسطر الشيفرة بأمان، لأن فتحات التخزين الفارغة التي أنشئت خلال هجوم DoS في عام 2016 قد تم حذفها بالكامل. الآن بعد أن أصبح الانتقال إلى إثبات الحصة جزءًا من التاريخ، يمكن للعملاء حذف جميع الشيفرات المتعلقة بإثبات العمل بأمان.
![فيتاليك: مستقبل إثيريوم المحتمل، التطهير]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
انتهاء حالة
) ماذا يحل؟
حتى لو أزلنا الحاجة إلى تخزين تاريخ العميل، فإن حاجة العميل للتخزين ستستمر في الزيادة، بحوالي 50 جيجابايت سنويًا، لأن الحالة تستمر في النمو: أرصدة الحسابات والأرقام العشوائية، كود العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم لمرة واحدة، مما يفرض عبئًا على عملاء إثيريوم الحاليين والمستقبليين.
تكون الحالة أكثر صعوبة من التاريخ "منتهية الصلاحية"، لأن EVM مصممة أساسًا حول فرضية واحدة: بمجرد إنشاء كائن الحالة، فإنه سيظل موجودًا دائمًا، ويمكن لأي معاملة قراءته في أي وقت. إذا قمنا بإدخال الحالة غير المتصل، يعتقد البعض أن هذه المشكلة قد لا تكون سيئة للغاية: فقط فئة بنائي الكتل المتخصصة تحتاج إلى تخزين الحالة فعليًا، في حين يمكن لجميع العقد الأخرى ### حتى تلك التي تحتوي على قائمة توليد! ( العمل بدون حالة. ومع ذلك، هناك وجهة نظر تقول إننا لا نريد الاعتماد بشكل مفرط على الحالة غير المتصلة، وفي النهاية قد نرغب في جعل الحالة تنتهي صلاحيتها للحفاظ على لامركزية إيثريوم.
) ما هو؟ كيف يعمل؟
اليوم، عندما تقوم بإنشاء كائن حالة جديد، يمكن أن يحدث ### بأحد الطرق الثلاث التالية: ( i ( إرسال ETH إلى حساب جديد، ) ii ( إنشاء حساب جديد باستخدام الشيفرة، ) iii ( إعداد فتحة تخزين لم يتم لمسها من قبل )، يبقى هذا الكائن في تلك الحالة إلى الأبد. على العكس، ما نريد هو أن ينتهي الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الأهداف الثلاثة:
الكفاءة: لا تحتاج إلى حسابات إضافية كبيرة لتشغيل عملية الانتهاء.
سهولة الاستخدام: إذا دخل شخص ما الكهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد الوصول إلى ETH و ERC20 و NFT و CDP.
صداقة المطورين: لا يحتاج المطورون إلى التحول إلى نموذج تفكير غير مألوف تمامًا. بالإضافة إلى ذلك، يجب أن تستمر التطبيقات التي أصبحت جامدة وغير محدثة في العمل بشكل طبيعي.
من السهل جداً حل المشكلات إذا لم يتم استيفاء هذه الأهداف. على سبيل المثال، يمكنك جعل كل كائن حالة يحتفظ أيضًا بعداد تاريخ انتهاء صلاحية ) يمكن أن يتم تمديد تاريخ انتهاء الصلاحية عن طريق حرق ETH، وقد يحدث هذا تلقائيًا في أي وقت للقراءة أو الكتابة (، مع وجود عملية للتكرار عبر الحالة لإزالة كائنات الحالة ذات تواريخ انتهاء الصلاحية. ومع ذلك، فإن هذا يقدم متطلبات حسابية ) إضافية حتى متطلبات التخزين (، ومن المؤكد أنه لا يمكن أن يلبي متطلبات سهولة الاستخدام. كما يجد المطورون صعوبة في الاستدلال على الحالات الحافة التي تتضمن قيم التخزين التي يتم إعادة تعيينها أحيانًا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية داخل نطاق العقد، فإن ذلك يجعل حياة المطورين أسهل من الناحية الفنية، لكنه يجعل الأمور الاقتصادية أكثر تعقيدًا: يجب على المطورين أن يأخذوا في الاعتبار كيفية "نقل" تكاليف التخزين المستمرة إلى المستخدمين.
هذه هي المشاكل التي كانت مجتمع تطوير إثيريوم الأساسي يعمل على حلها لسنوات عديدة، بما في ذلك مقترحات مثل "إيجار blockchain" و"إعادة الإنتاج". في النهاية، قمنا بدمج أفضل أجزاء المقترحات وتركيزنا على نوعين من "أقل الحلول سوءًا المعروفة":
) انتهاء حالة جزئية
بعض حالات انتهاء الاقتراحات تتبع نفس المبادئ. نحن نقسم الحالة إلى كتل. يقوم الجميع بتخزين "الخرائط العليا" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. يتم تخزين البيانات في كل كتلة فقط عندما يتم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إحياء"، إذا لم يعد يتم تخزينها.
الفرق الرئيسي بين هذه الاقتراحات هو: ###i( كيف نعرّف "الأخيرة"، و )ii( كيف نعرّف "الكتلة"؟ أحد الاقتراحات المحددة هو EIP-7736، الذي يبني على تصميم "الأغصان" الذي تم تقديمه لشجرة Verkle ) على الرغم من أنه يتوافق مع أي شكل من أشكال الحالة غير الحالة، مثل الشجرة الثنائية (. في هذا التصميم، يتم تخزين الرؤوس والرموز وفتحات التخزين المجاورة لبعضها البعض تحت نفس "الجذع". يمكن أن تصل البيانات المخزنة تحت جذع واحد إلى 256 * 31 = 7,936 بايت. في العديد من الحالات، سيتم تخزين الرأس والرمز الكاملين للحساب والعديد من فتحات التخزين المفاتيح تحت نفس الجذع. إذا لم يتم قراءة أو كتابة البيانات الموجودة تحت الجذع المعطى خلال 6 أشهر، فلن يتم تخزين هذه البيانات بعد الآن، ولكن سيتم تخزين 32 بايت فقط من تلك البيانات.