شكراً جزيلاً لجاستن دريك، تيم بيكو، مات غارنيت، بيبر ميريام، ماريوس فان دير وايدن، وتوماسز ستانساك على التعليقات والمراجعة.

احد التحديات التي تواجه واجهة إيثيريوم هي أن توسع وتعقيد أي برتوكول كتلة يزيدان مع مرور الوقت بشكل افتراضي. يحدث ذلك في مكانين:

· البيانات القديمة: يجب على جميع العملاء تخزين كل صفقة تم إجراؤها وكل حساب تم إنشاؤه في أي وقت في التاريخ بشكل دائم وتحميلها بواسطة أي عميل جديد، وبالتالي مزامنتها تمامًا مع الشبكة. يؤدي هذا إلى زيادة عبء العميل ووقت المزامنة مع مرور الوقت، حتى لو ظلت سعة السلسلة ثابتة.

· وظيفة البروتوكول: إضافة وظيفة جديدة أسهل بكثير من حذف الوظيفة القديمة، مما يؤدي إلى زيادة تعقيد الشفرة مع مرور الوقت.

لكي يستمر إيثريوم على المدى الطويل ، نحتاج إلى ممارسة ضغوط قوية على هاتين الاتجاهين مع مرور الوقت: الإسقاط التعقيدية والتضخم. ولكن في الوقت نفسه ، نحتاج إلى الحفاظ على واحدة من الخصائص الرئيسية التي تجعل بلوكتشين عظيمًا: الثبات. يمكنك وضع عملة غير قابلة للاستبدال أو رسالة حب في بيانات المكالمات التجارية أو عقد ذكي يحتوي على مليون دولار داخل السلسلة ، والذهاب إلى كهف لمدة عشر سنوات ، واكتشاف أنه لا يزال هناك في انتظار قراءتك والتفاعل معه. لكي يكون DApp مرتاحًا بالكامل ولكي يتمكن من حذف المفتاح السري والترقية ، يحتاجون إلى التأكد من أن تبعياتهم لن تتطور بطريقة تدمرهم - خاصة L1 نفسه.

إذا قررنا بجدية التوازن بين هاتين الاحتياجتين وتقليل أو عكس التدهور والتعقيد والبطء إلى أقصى حد ممكن وفي نفس الوقت الحفاظ على الاستمرارية، فإن ذلك ممكن بالتأكيد. يستطيع الكائن الحي فعل ذلك: على الرغم من أن معظم الكائنات الحية تتقادم مع مرور الوقت، إلا أن هناك قلة قليلة من المحظوظين الذين لا يتقادمون. يمكن أن تكون لدى النظم الاجتماعية أيضًا عمر طويل جدًا. في بعض الحالات، حققت إثيريوم نجاحًا: تلاشى إثبات العمل، واختفى معظم رمز العملية SELFDESTRUCT، وتم تخزين بيانات قديمة تصل إلى ستة أشهر في سلسلة beacon. إيجاد الطريق الصحيح بشكل أكثر عمومية لإثيريوم والانتقال نحو النتيجة النهائية للاستقرار الطويل الأجل هو تحدي إثيريوم النهائي للقابلية للتوسعة والاستدامة التقنية وحتى الأمان.

التطهير: الأهداف الرئيسية.

· متطلبات تخزين العميل عن طريق تقليل أو إلغاء الحاجة إلى تخزين كل السجل بشكل دائم وحتى الحالة النهائية على أساس كل عميل.

· من خلال إزالة الميزات غير الضرورية لتبسيط بروتوكول الأسقاط.

قائمة المحتويات:

· تاريخ الانتهاء (تاريخ انتهاء السجل)

· انتهاء صلاحية الحالة

· تنظيف الميزات

تاريخ انتهاء الصلاحية

حل ما المشكلة؟

حتى وقت كتابة هذا النص ، يتطلب تزامن كامل لعقدة إثيريوم حوالي 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) ببساطة إدخال مكتبة التورنت الحالية، بالإضافة إلى (ii) ما يسمى بحل Portal Network الأصلي لـ إثيريوم. بمجرد إدخال أيًا منهما، يمكننا فتح EIP-4444. EIP-4444 نفسه لا يحتاج إلى fork صلب، لكنه يتطلب بالفعل إصدار بروتوكول شبكة جديد. لذا، فإن تمكينه لجميع العملاء في نفس الوقت يعد أمرًا قيمًا، وإلا فإنه يوجد خطر فشل العميل الذي يتوقع تنزيل سجل تاريخ كامل من العقد الآخر ولكن في الواقع لم يحصل عليه.

التوازن الرئيسي يتعلق بكيفية العمل على توفير البيانات التاريخية ‘القديمة’. أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا والاعتماد على العقد الموجودة ومزودي الخدمات المركزية المختلفة للنسخ. هذا أمر سهل، ولكنه يضعف مكانة شبكة إثيريوم كمكان لتسجيل السجلات الدائمة. النهج الأصعب ولكنه الأكثر أمانًا هو بناء ودمج شبكة تورنت أولاً لتخزين السجلات التاريخية بطريقة موزعة. هنا، ‘كم نحن مجتهدون’ لديها بعدين:

1. كيف نحرص على أن تحتوي أكبر عقدة ممكنة فعلًا على جميع البيانات؟

2. إلى أي مدى تم دمج تخزين السجلات التاريخية في العمق البروتوكول؟

بالنسبة لطريقة الهوس الشديد (1)، ستشمل إثبات الاحتجاز: بشكل فعلي، يُطلب من كل محقق للتخزين تخزين نسبة معينة من السجلات التاريخية وفحصها بانتظام بطريقة التشفير للتحقق مما إذا كانوا يفعلون ذلك. والطريقة الأكثر اعتدالاً هي تعيين معيار طوعي لنسبة السجلات التاريخية المخزنة لكل عميل.

بالنسبة لـ (2)، فإن النسخة الأساسية تنطوي فقط على العمل الذي تم إنجازه اليوم: قامت بوابة بتخزين ملف ERA الذي يحتوي على تاريخ Ethereum بأكمله. وستشمل التنفيذات الأكثر شمولاً ربطها بعملية المزامنة بحيث يمكن لمن يريدون مزامنة عقدة التخزين أو عقدة الأرشيف التاريخي الكامل، حتى إذا لم تكن هناك أي عقدة أرشيف أخرى عبر الإنترنت، يمكنهم تحقيق ذلك من خلال المزامنة المباشرة من شبكة البوابة.

كيف يتفاعل مع أجزاء الخريطة الطريقية الأخرى؟

إذا كنا نريد جعل تشغيل أو بدء تشغيل العقد يصبح سهلاً للغاية، فإن تقليل احتياجات التخزين التاريخية يمكن القول بأنه أكثر أهمية من عدم الحالة: من بين 1.1 تيرابايت المطلوبة للعقد، حوالي 300 جيجابايت هي الحالة، وتبقى حوالي 800 جيجابايت قد أصبحت تاريخية. إن تحقيق عدم الحالة و EIP-4444 هو الوحيد القادر على تحقيق رؤية تشغيل عقد إيثيريوم على ساعة ذكية وضبطها في بضع دقائق فقط.

يجعل تقييد تخزين التاريخ عقدة إيث المحدثة أكثر قابلية للتنفيذ فقط بدعم أحدث إصدار من البروتوكول، مما يجعلها أكثر بساطة. على سبيل المثال، يمكن الآن حذف العديد من الأسطر من الرمز بأمان، حيث تم حذف جميع الفتحات الفارغة التي تم إنشاؤها خلال هجوم DOS في عام 2016. وبما أن الانتقال إلى إثبات التخزين أصبح جزءًا من التاريخ، يمكن للعملاء حذف جميع الرموز المتعلقة بإثبات العمل بأمان.

انتهاء الحالة

حل ما المشكلة؟

حتى بعد إزالة حاجة تخزين سجلات التخزين المؤقت في العميل، ستستمر احتياجات التخزين في العميل في الارتفاع بمقدار حوالي 50 جيجابايت سنويًا، نظرًا للاستمرار في الارتفاع الحالة: رصيد الحساب والأرقام العشوائية ورمز العقد وتخزين العقد. يمكن للمستخدمين دفع رسوم ذات مرة لتوفير عبء دائم لعميل ETH الحالي والمستقبلي.

من الصعب “انتهاء صلاحية” الحالة من التاريخ لأن EVM مصمم بشكل أساسي حول افتراض أنه بمجرد إنشاء كائن الحالة ، سيكون موجودا دائما ويمكن قراءته بواسطة أي معاملة في أي وقت. إذا أدخلنا انعدام الجنسية ، يجادل البعض بأن المشكلة ربما ليست بهذا السوء: فقط فئة منشئ كتلة المتخصصة تحتاج إلى تخزين الحالة فعليا ، في حين أن جميع العقدة الأخرى (حتى بما في ذلك إنشاء القائمة!) ) يمكن تشغيلها بدون حالة. ومع ذلك ، هناك حجة مفادها أننا لا نريد الاعتماد كثيرا على انعدام الجنسية ، وفي النهاية قد نرغب في إنهاء صلاحية الدولة للحفاظ على Ethereum اللامركزية.

ما هو، وكيف يعمل

اليوم، عند إنشاء كائن حالة جديد (يحدث ذلك بأحد الطرق الثلاث التالية: (i) إرسال ETH إلى حساب جديد، (ii) إنشاء حساب جديد باستخدام الشفرة، (iii) تعيين فتحة تخزين غير لمسها سابقًا)، يتم الاحتفاظ بكائن الحالة هذا إلى الأبد. على العكس من ذلك، نريد أن ينتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو تحقيق هذا الهدف بطريقة تلبي الأهداف الثلاثة.

1. الكفاءة: لا حاجة لحسابات إضافية كبيرة لتشغيل عملية الانتهاء.

2. سهولة الاستخدام للمستخدم: إذا قام شخص ما بدخول الكهف لمدة خمس سنوات وعاد، فلا يجب أن يفقد حق الوصول إلى ETH و ERC 20 والعملة غير القابلة للاستبدال وموقف الـ CDP…

3. ودية المطور: لا يحتاج المطورون إلى التبديل إلى نموذج تفكير غير مألوف تمامًا. علاوة على ذلك، يجب أن يتمكن التطبيق الحالي القائم الذي هو صلب وغير محدث من الاستمرار في العمل بشكل طبيعي.

إذا لم تحقق هذه الأهداف ، فمن السهل حل المشكلة. على سبيل المثال ، يمكنك جعل كل كائن حالة يخزن أيضا عداد تاريخ انتهاء الصلاحية (يمكن تمديد تاريخ انتهاء الصلاحية عن طريق حرق ETH ، والذي يمكن أن يحدث تلقائيا في أي وقت للقراءة أو الكتابة) ، ولديك عملية تتكرر عبر الحالة لإزالة تاريخ انتهاء صلاحية كائن الحالة. ومع ذلك ، فإن هذا يقدم حوسبة إضافية (وحتى متطلبات التخزين) ، وهو بالتأكيد لا يفي بمتطلبات سهولة الاستخدام. من الصعب أيضا على المطورين التفكير في حالات الحافة التي تتضمن قيم تخزين تتم إعادة تعيينها أحيانا إلى الصفر. إذا قمت بتعيين مؤقت انتهاء الصلاحية ضمن نطاق العقد ، فإن هذا سيجعل حياة المطور أسهل من الناحية الفنية ، ولكنه سيجعل الاقتصاد أكثر صعوبة: سيتعين على المطور التفكير في كيفية “نقل” تكاليف التخزين المستمرة إلى المستخدم.

هذه كلها قضايا يتصارع معها مجتمع تطوير Ethereum الأساسي منذ سنوات ، بما في ذلك مقترحات مثل “إيجار سلسلة كتلة” و “التجديد”. في النهاية ، قمنا بدمج أفضل أجزاء الاقتراح وركزنا على فئتين من “الحلول الأقل سوءا المعروفة”:

· حلول لحالات الانتهاء الجزئي

· الاقتراحات المستندة إلى العنوان

تاريخ انتهاء الحالة الجزئي

بعض الاقتراحات التي تنتهي حالتها تتبع نفس المبدأ. نقسم الحالة إلى كتل. يحتفظ الجميع بـ ‘التعيين الأعلى’ بشكل دائم ، حيث يكون الكتلة فارغة أو غير فارغة. يتم تخزين بيانات كل كتلة فقط عندما يتم الوصول إليها مؤخرًا. هناك آلية ‘النهوض’ إذا لم يعد هناك تخزين للبيانات.

الاختلاف الرئيسي بين هذه المقترحات هو: (i) كيف نحدد “الأحدث”، و (ii) كيف نحدد “الكتلة”؟ مقترح محدد هو EIP-7736، والذي يعتمد على تصميم “الأوراق الجذرية” المُقدم لشجرة Verkle (على الرغم من كونه متوافقًا مع أي شكل من أشكال الحالة غير القابلة للتحويل، مثل الأشجار الثنائية). في هذا التصميم، يتم تخزين رؤوس الكتل المتجاورة والشفرات وفتحات التخزين في نفس “الجذع”. يمكن للبيانات المخزنة تحت الجذع أن تصل إلى 7،936 بايت (256 * 31) في الحد الأقصى. في كثير من الحالات، سيتم تخزين رأس الحساب والشفرات بأكملها والعديد من فتحات التخزين تحت نفس الجذع. إذا لم يتم قراءة البيانات المخزنة تحت الجذع المعطى أو كتابتها في غضون 6 أشهر، فلن تتم متابعة تخزين هذه البيانات بعد ذلك، بل سيتم تخزين فقط الالتزامات (“الجذور”) البالغة 32 بايتًا لهذه البيانات. سيتطلب المعاملات المستقبلية للوصول إلى هذه البيانات “إحياء” البيانات، وتقديم دليل على الفحص القائم على الجذور.

هناك طرق أخرى لتحقيق أفكار مماثلة. على سبيل المثال، إذا لم يكن تفصيل الحساب كافيًا، يمكننا وضع خطة حيث يتم التحكم في كل جزء 1/2 32 من الشجرة بآلية مماثلة للساق والورق.

يصبح هذا الأمر أكثر تعقيدا بسبب الحوافز: يمكن للمهاجم “تحديث الشجرة” عن طريق وضع كمية كبيرة من البيانات في شجرة فرعية واحدة وإرسال معاملة واحدة كل عام ، مما يجبر العميل على تخزين كمية كبيرة من الحالة بشكل دائم. إذا جعلت تكلفة التجديد متناسبة مع حجم الشجرة (أو تتناسب عكسيا مع مدة التجديد) ، فقد يؤذي شخص ما المستخدمين الآخرين عن طريق وضع الكثير من البيانات في نفس الشجرة الفرعية مثلهم. يمكن للمرء أن يحاول الحد من هاتين المشكلتين عن طريق جعل الدقة ديناميكية بناء على حجم الشجرة الفرعية: على سبيل المثال ، يمكن اعتبار كل كائنات حالة متتالية 2 16 = 65536 “مجموعة”. ومع ذلك ، فإن هذه الأفكار أكثر تعقيدا. النهج القائم على العلوم والتكنولوجيا والهندسة والرياضيات بسيط ، ويمكن تعديل الحوافز ، حيث غالبا ما تكون جميع البيانات الموجودة تحت الجذع ذات صلة بنفس التطبيق أو المستخدم.

مقترح انتهاء الحالة القائم على العنوان

ماذا لو أردنا تجنب أي حالة دائمة تماما ارتفع، حتى كعب 32 بايت؟ هذا لغز بسبب تعارض القيامة: ماذا لو تم حذف كائن حالة واحد وبعد ذلك وضع تنفيذ EVM كائن الحالة الآخر في نفس الموضع بالضبط ، ولكن بعد ذلك يعود الشخص الذي يهتم بكائن الحالة الأصلي ويحاول استعادته؟ عندما تنتهي صلاحية بعض الولايات ، يمنع “كعب الروتين” إنشاء بيانات جديدة. مع انتهاء صلاحية الولاية بالكامل ، لا يمكننا حتى تخزين بذرة.

تصميم الفترة الزمنية هو أحد أشهر الأفكار التي تحل هذه المشكلة. لا نقوم بتخزين الحالة بأكملها باستخدام شجرة حالة واحدة، بل لدينا قائمة من الشجر المتزايدة باستمرار ويتم حفظ أي حالة قراءة أو كتابة في أحدث شجرة حالة. يتم إضافة شجرة حالة فارغة جديدة في كل فترة (على سبيل المثال: سنة واحدة). يتم تجميد الشجرة القديمة تماما. تقوم العقدة الكاملة بتخزين الشجرتين الأحدثين فقط. إذا لم يتم لمس كائن حالة في فترتين متتاليتين، وبالتالي سقوطه في الشجرة المنتهية صلاحيته، فإنه لا يزال بإمكانه قراءته أو كتابته، ولكن يجب على المعاملات إثبات برهان ميركل - بمجرد إثبات ذلك، سيتم حفظ نسخة مرة أخرى في الشجرة الأحدث.

أحد الأفكار الرئيسية لجعل هذا ودودًا للمستخدمين والمطورين هو مفهوم الدورة الزمنية. الدورة الزمنية هي رقم ينتمي إلى جزء من العنوان. القاعدة الرئيسية هي أن العنوان الذي يحتوي على الدورة الزمنية N يمكن قراءته أو كتابته فقط خلال الدورة N أو بعدها (أي عندما يصل طول قائمة شجرة الحالة إلى N). إذا كنت ترغب في حفظ كائن حالة جديد (مثل عقد جديد أو رصيد جديد ل ERC 20) ، يمكنك حفظه على الفور دون الحاجة لتقديم أي دليل على عدم وجود أي شيء من قبل إذا كنت تضمن وضع كائن الحالة في عقد ذي دورة زمنية تساوي N أو N-1. من ناحية أخرى ، يتطلب أي إضافة أو تحرير في دورة العنوان القديمة دليلاً.

هذا التصميم يحتفظ بمعظم الخصائص الحالية لإيثيريوم، دون الحاجة إلى حسابات إضافية، مما يسمح بكتابة التطبيقات تقريبًا كما هي الآن (يجب إعادة كتابة ERC 20 لضمان أن رصيد العنوان بدورة N يتم تخزينه في العقد الفرعي، الذي يحتوي بدوره على دورة N)، مما يحل مشكلة “المستخدم يدخل الكهف لمدة خمس سنوات”. ومع ذلك، لديها مشكلة كبيرة: يجب توسيع العنوان إلى أكثر من 20 بايت ليتماشى مع دورة العنوان.

تمديد مساحة العنوان

واحدة من الاقتراحات هي إدخال تنسيق جديد للعنوان بطول 32 بت، يتضمن رقم الإصدار ورقم الدورة للعنوان والتجزئة الموسعة.

0x01（أحمر）0000（برتقالي）000001（أخضر）57 الأبدية408398 الأبدية7 الأزرق f4552091 الأبدية25 d5dFcb7B8C2659029395bdF（أزرق）。

الأحمر هو رقم الإصدار. يهدف الصفر الأربعة البرتقاليون هنا كمساحة فارغة يمكن أن تحتوي في المستقبل على رقم مشاركة. الأخضر هو رقم الدورة. الأزرق هو قيمة التجزئة بطول 26 بايت.

تحدي التوافق مع الخلف هو التحدي الرئيسي هنا. العقود الحالية مصممة حول عنوان 20 بايت وعادة ما تستخدم تقنية تعبئة البايت الصارمة، مع افتراض واضح أن العنوان هو بالضبط 20 بايت طويل. فكرة لحل هذه المشكلة تشمل تحويل الخريطة، حيث سيشهد العقود القديمة التي تتفاعل مع العنوان الجديد قيمة هاش 20 بايت للعنوان الجديد. ومع ذلك، يوجد تعقيد كبير في ضمان أمانه.

ضيق مساحة العنوان

يمكن اتباع طريقة أخرى بالذهاب في الاتجاه المعاكس: نحظر على الفور بعض النطاقات الفرعية لحجم 2^128 (مثل جميع العناوين التي تبدأ بـ0xffffffff) ثم استخدام هذا النطاق الفرعي لإدخال عناوين ذات دورة و قيمة هاش بطول 14 بايت.

0xffffffff000169125 d5dFcb7B8C2659029395bdF

التضحيات الرئيسية التي تم إدخالها بهذه الطريقة هي تنطوي على مخاطر أمان العناوين الوهمية: عنوان يمتلك الأصول أو الأذونات، ولكن لم يتم نشر رمزه على السلسلة. تتضمن المخاطر أن يقوم شخص ما بإنشاء عنوان يدعي أنه يمتلك جزءًا من الرمز (لم يتم نشره بعد)، ولكن هناك أيضًا جزء آخر من الرمز الصحيح يتجزأ إلى نفس العنوان. يتطلب حساب تصادم مثل هذا النوع اليوم 2^80 تجزئة ؛ ستقلص مساحة العنوان هذا الرقم إلى قيمة تسهل الوصول إليها وهي 2^56 تجزئة.

مجالات المخاطر الرئيسية، أي الأماكن التي ليست لها المحفظة والعنوان المعاكس الذي يملكه المالك الوحيد، هذه الحالة نادرة نسبيًا اليوم، ولكن مع دخولنا عالم L2 المتعدد، قد تصبح أكثر شيوعًا. الحل الوحيد هو قبول هذا النوع من المخاطر ببساطة، ولكن تحديد جميع الحالات الاستخدام الشائعة التي يمكن أن تحدث مشكلة فيها وتقديم حلول فعالة.

ما هي العلاقات الموجودة مع البحوث الحالية؟

مقترح مبكر

كتلة السلسلة النظيفة؛

إعادة التوليد;

نظرية إدارة حجم حالة إيثريوم؛

بعض المسارات المحتملة للحالة اللاحقة وانتهاء الصلاحية؛

بعض الاقتراحات المنتهية صلاحيتها

EIP-7736 ;

العنوان空间扩展文档

المقترح الأصلي؛

استعراض إبسيلون

تعليقات المقالات في المدونة؛

إذا فقدنا المقاومة للاصطدام، ماذا سندمر.

ما الذي يتبقى للقيام به؟ وما الذي يحتاج إلى مراعاته؟

أعتقد أن هناك أربع طرق ممكنة للمستقبل:

· نحن نحقق الحالة اللاحالة، ولا نقوم أبداً بإدخال انتهاء الحالة. الحالة في ارتفاع مستمر (على الرغم ببطء: قد لا نراها تتجاوز 8 تيرابايت في عقود)، ولكن يكفي أن تكون من فئة مستخدمين نسبية: حتى المحققون PoS لا يحتاجون إلى حالة.

واحدة من الوظائف التي تتضمن الوصول إلى جزء من الحالة هي إنشاء القوائم ، ولكن يمكننا إكمال هذه العملية بطريقة متفرقة: يتحمل كل مستخدم مسؤولية الحفاظ على جزء من شجرة الحالة التي تحتوي على حسابه الخاص. عندما يبثون صفقاتهم ، سيبثون الصفقات ويحملون براهين الكائنات الحالية التي تم الوصول إليها أثناء خطوات التحقق (هذا ينطبق على حسابات EOA و ERC-4337). ثم يمكن للمحقق الخالي من الحالة جمع هذه البراهين لتشكيل برهان يحتوي على القائمة بأكملها.

· نقوم بإنهاء جزء من الحالة ونقبل معدل نمو حجم الحالة الدائمة الأقل ولكن لا يزال غير صفر. يمكن القول أن هذا النتيجة مشابهة لكيفية قبول الاقتراحات المنتهية التاريخ المتعلقة بالشبكة المتساوية في العمر لكل عميل يجب عليه تخزين نسبة أقل ولكن ثابتة من البيانات التاريخية بنسبة نمو الأقل ولكن لا تزال غير صفر للتخزين التاريخي الدائم.

· نقوم بتوسيع العنوان لتنتهي صلاحيته. وسينطوي هذا على عملية تستغرق سنوات لضمان أن طرق تحويل العنوان فعالة وآمنة، بما في ذلك التطبيقات الحالية.

نحن نستخدم تقليص الفضاء العنواني للتحكم في انتهاء الحالة. سيتطلب هذا عملية تستغرق عدة سنوات لضمان معالجة جميع المخاطر الأمنية المتعلقة بالعناوين المتعارضة (بما في ذلك الحالات التي تنطوي على تفاعل عبر السلاسل).

النقطة المهمة هي أنه يجب حل مشكلة توسيع وتقليص الفضاء الخاص بالعناوين، سواء تم تنفيذ خطط انتهاء الحالة التي تعتمد على تغيير تنسيق العناوين أم لا. حاليًا، يتطلب توليد تعارضات العناوين حوالي 2^80 قيمة هاش، وهذا العبء الحسابي ممكن للمشاركين الذين يملكون موارد غنية جدًا: يمكن لوحدات معالجة الرسومات أن تنفذ حوالي 2^27 قيمة هاش، لذلك يمكن حساب 2^52 خلال عام واحد، وبالتالي يمكن لحوالي 230 وحدة معالجة الرسومات في العالم حساب تعارض واحد في حوالي 1/4 من العام، ويمكن لوحدات FPGA و ASIC تسريع هذه العملية بشكل أكبر. في المستقبل، ستصبح هذه الهجمات متاحة لأشخاص أكثر فأكثر. لذلك، قد لا يكون تكلفة تنفيذ انتهاء الحالة بالكامل مرتفعة كما يبدو، لأننا بأي حال من الأحوال يجب حل هذه المشكلة الصعبة جدًا في العناوين.

كيف يتفاعل مع أجزاء الخريطة الطريقية الأخرى؟

قد يجعل انتهاء حالة التحول من تنسيق شجرة حالة واحد إلى آخر أكثر سهولة، لأنه لا يلزم عملية التحويل: يمكنك ببساطة البدء في إنشاء شجرة جديدة باستخدام التنسيق الجديد ثم القيام بشوكة صلبة لتحويل الشجرة القديمة. لذلك، على الرغم من أن انتهاء الحالة معقد للغاية، إلا أنه يفيد حقًا في تبسيط جوانب أخرى من خارطة الطريق.

تنظيف الميزات

ما المشكلة التي يحلها؟

إحدى الشروط الأساسية للأمان والوصولية والمحايدية الموثوق بها هي البساطة. إذا كانت البروتوكول جميلة وبسيطة ، فسوف يقلل من احتمال حدوث أخطاء. إنه يزيد من فرصة أي مطور جديد للمشاركة في أي جزء منه. من المرجح أن يكون عادلاً أيضًا وأسهل في التصدي للمصالح الخاصة. للأسف ، يتحول البروتوكول إلى تعقيد متزايد مع مرور الوقت ، تمامًا مثل أي نظام اجتماعي. إذا لم نرغب في أن ينغمس إيثريوم في حفرة تعقيد متزايدة ، فيجب علينا القيام بإحدى الأمور التاليتين: (i) التوقف عن التغيير وجعل البروتوكول جامدًا ، (ii) القدرة على حذف الميزات فعليًا وإسقاط التعقيد. طريقة وسط أيضًا ممكنة ، وهي إجراء تغييرات أقل على البروتوكول والتخلص على الأقل من بعض التعقيد مع مرور الوقت. سيتم مناقشة كيفية تقليل أو القضاء على التعقيد في هذا القسم.

ما هو، وكيف يعمل؟

لا يوجد أي إصلاح كبير واحد يمكن أن يقلل من تعقيد بروتوكول؛ جوهر هذه المشكلة هو وجود العديد من الحلول الصغيرة.

مثال تم إكمال معظمه بالفعل هو حذف كود التشغيل الذاتي SELFDESTRUCT ويمكن استخدامه كمخطط لكيفية التعامل مع أمثلة أخرى. كان كود التشغيل الذاتي SELFDESTRUCT هو الوحيد القادر على تعديل عدد غير محدود من فتحات التخزين في كتلة واحدة، مما يتطلب من العميل تنفيذ تعقيدات أعلى بشكل ملحوظ لتجنب هجمات الـ DoS. كان الهدف الأصلي لهذا الكود هو تحقيق التسوية الاختيارية للحالة، مما يسمح بتقليل حجم الحالة مع مرور الوقت. في الواقع، نادرًا ما استخدمه أي شخص في النهاية. تم تضعيف الكود التشغيلي ليسمح فقط بإنشاء حسابات الحسابات الذاتية التي تم إنشاؤها في نفس المعاملة في الـ Dencun hard fork. وقد حل هذا المشكلة DoS ويمكن أن يبسط بشكل ملحوظ كود العميل. في المستقبل، قد يكون من المعقول حقًا حذف الكود التشغيلي بشكل كامل.

بعض الأمثلة الرئيسية للفرص المبسطة للبروتوكول التي تم تحديدها حتى الآن تشمل ما يلي. أولاً ، بعض الأمثلة خارج EVM ؛ وهذه نسبياً غير تداخلية ، وبالتالي أسهل في التوصل إلى الإجماع وتنفيذه في وقت أقصر.

· تحويل RLP إلى SSZ: في البداية، كانت كائنات Ethereum تُسلسل باستخدام ترميز يُسمى RLP. الـ RLP لا يحتوي على نوع وهو معقد بشكل غير ضروري. اليوم، تستخدم سلسلة beacon SSZ التي تعتبر بمعنى الكلمة أفضل في كثير من الأحوال، بما في ذلك دعم التسلسل وأيضًا دعم التجزئة. في النهاية، نأمل التخلص تمامًا من RLP ونقل جميع أنواع البيانات إلى هيكل SSZ، مما سيجعل عملية الترقية أسهل بكثير. تتضمن EIP الحالية [ 1 ] [ 2 ] [ 3 ].

· حذف أنواع التداول القديمة: هناك الكثير من أنواع التداول الحالية، والعديد منها قد يتم حذفه. بدلاً من الحذف الكامل، يمكن أن يكون بديلاً أكثر لطفًا هو وظيفة التجريد الحسابي، حيث يمكن للحسابات الذكية أن تحتوي على رمز لمعالجة والتحقق من التداولات القديمة (إذا كانوا راغبين في ذلك).

· تحديث السجلات: تم إنشاء فلتر بلوم للسجلات والمنطق الأخرى، مما زاد من تعقيد البروتوكول، ولكن في الواقع لم يتم استخدامها من قبل العميل لأنها بطيئة جدًا. يمكننا حذف هذه الوظائف والعمل بدلاً من ذلك على بدائل مثل استخدام تقنيات حديثة مثل SNARK كأدوات بروتوكول خارجية مركزية لقراءة السجلات.

· الإزالة النهائية لآلية لجنة مزامنة المنارة السلسلة: تم تقديم آلية لجنة المزامنة في الأصل لتمكين التحقق من العميل الخفيف في مربع ETH. ومع ذلك ، فإنه يزيد بشكل كبير من تعقيد بروتوكول. في النهاية ، سنكون قادرين على التحقق من صحة طبقة مقبس ETH الإجماع مباشرة باستخدام SNARKs ، مما سيلغي الحاجة إلى بروتوكول التحقق المخصص للعميل الخفيف. من المحتمل أن يسمح لنا التغيير في الإجماع بإزالة لجنة المزامنة في وقت سابق عن طريق إنشاء عميل “أصلي” أكثر بروتوكولا والذي يتضمن التحقق من صحة التوقيعات من مجموعة فرعية عشوائية من مدققي ETH.

· توحيد تنسيق البيانات: حاليًا ، يتم تخزين حالة التنفيذ في شجرة Merkle Patricia ، ويتم تخزين حالة الإجماع في شجرة SSZ ، ويتم تقديم blob عن طريق KZG التزامًا. في المستقبل ، سيكون لتطوير تنسيق واحد موحد لبيانات الكتل وتنسيق واحد موحد للحالة معنى. ستلبي هذه الأشكال جميع المتطلبات الرئيسية: (i) برهان بسيط للعميل اللاحالة (ii) تسلسل البيانات وترميز الاحتياطي (iii) هيكل البيانات الموحد.

· إزالة لجنة سلسلة beacon: تم تقديم هذا الآلية في البداية لدعم تنفيذ مشاركة معينة. بدلاً من ذلك ، نقوم في النهاية بالمشاركة عبر L2 و blob. لذلك ، اللجنة غير ضرورية ونحن نقوم حاليًا باتخاذ إجراء لإزالة اللجنة.

· إزالة ترتيب البايت المختلط: EVM هو ترتيب البايت الكبير ، بينما طبقة الاتفاق هي ترتيب البايت الصغير. إعادة التنسيق وجعل جميع المحتويات بنوع واحد أو آخر قد يكون له معنى (قد يكون ترتيب البايت الكبير لأن EVM أكثر صعوبة في التغيير)

الآن بعض الأمثلة في EVM:

· تبسيط آلية الغاز: لم تحصل قواعد الغاز الحالية على تحسين جيد حتى الآن، ولا يمكن وضع حد دقيق لكمية الموارد المطلوبة لتحقق كتلة. الأمثلة الرئيسية في هذا الصدد تشمل (i) تكلفة القراءة / الكتابة للتخزين، التي تهدف إلى تقييد عدد مرات القراءة / الكتابة في كتلة ما، ولكنها حالياً متساهلة إلى حدٍ ما، و (ii) قواعد ملء الذاكرة، والتي يصعب حالياً تقدير الاستهلاك الذاكري الأقصى لـ EVM. تشمل الإصلاحات المقترحة تغيير تكلفة الغاز اللاحالة (جعل جميع تكاليف التخزين ذات الصلة موحدة في صيغة بسيطة واحدة) ومقترح التسعير الذاكري.

· إزالة التجهيز المسبق: يمتلك إثيريوم العديد من التجهيزات المسبقة التي غالبًا ما تكون معقدة للغاية وغير مستخدمة بشكل كبير وتشكل جزءًا كبيرًا من فشل الإجماع بشكل تقريبي. هناك طريقتان للتعامل مع هذه المشكلة: (i) إزالة التجهيز المسبق فقط و (ii) استبداله بقطعة من الشفرة EVM ذات المنطق المماثلة (والتي ستكون بالضرورة أكثر تكلفة). يقترح مسودة EIP إجراء الخطوة الأولى لتنفيذ إزالة التجهيز المسبق للهوية. في وقت لاحق، قد تكون RIPEMD 160 و MODEXP و BLAKE مرشحين للإزالة.

· إزالة الغاز قابلية الملاحظة: يجعل تنفيذ EVM غير قادر على رؤية كمية الغاز المتبقية. هذا سيؤدي إلى تعطيل بعض التطبيقات (على سبيل المثال ، المعاملات الممولة) ، ولكنه سيجعل الترقيات أسهل في المستقبل (على سبيل المثال ، إصدارات أكثر تقدمًا للغاز متعدد الأبعاد). تم جعل الغاز غير قابل للملاحظة بالفعل وفقًا لمواصفات EOF ، ولكنه يجب أن يصبح إلزاميًا من أجل تبسيط البروتوكول.

• تحسين الفحص الثابت: يصعب الآن تحليل EVM بشكل ثابت ، خاصةً لأن القفزات قد تكون ديناميكية. يجعل هذا أيضًا تحقيق EVM المحسن (تحويل رمز EVM إلى لغة أخرى محددة مسبقًا) أكثر صعوبة. يمكن حل هذه المشكلة عن طريق إزالة القفزات الديناميكية (أو جعلها أكثر تكلفة ، على سبيل المثال ، يتناسب تكلفة الغاز مع عدد JUMPDEST الموجود في العقد) ، وهذا هو ما تفعله EOF ، على الرغم من أنه يتطلب تنفيذ بروتوكول Vereinfachtes بقوة للاستفادة من الفائدة.

ما هي العلاقات الموجودة مع البحوث الحالية؟

· خطوات التنظيف التالية؛

· التدمير الذاتي

· SSZ تحويل EIPS: [1] [2] [3];

· الغاز ليس له تكلفة ثابتة؛

· تسعير الذاكرة الخطية؛

· إزالة الترميز المُسبق؛

· إزالة فلتر بلوم؛

· طريقة لاسترداد سجلات الأمان بأمان خارج السلسلة باستخدام الحسابات القابلة للتحقق التدريجي (قراءة: STARK المتكرر)؛

ما الذي يتبقى للقيام به؟ وما الذي يحتاج إلى مراعاته؟

المفاضلة الرئيسية لهذا التبسيط الوظيفي هي (i) درجة وسرعة تبسيطنا مقابل (ii) التوافق مع الإصدارات السابقة. تأتي قيمة ETH Square كسلسلة من حقيقة أنها منصة حيث يمكنك نشر تطبيق وتكون واثقا من أنه سيظل يعمل بعد سنوات عديدة. في الوقت نفسه ، قد يذهب هذا المثل الأعلى بعيدا ، على حد تعبير ويليام جينينغز بريان ، “تسمير مربعات ETH على تقاطع التوافق مع الإصدارات السابقة”. إذا كان هناك تطبيقان فقط في ETH Square بالكامل يستخدمان ميزة معينة ، ولم يكن لدى أحد التطبيقات أي مستخدمين لسنوات ، في حين أن التطبيق الآخر غير مستخدم بالكامل تقريبا واكتسب قيمة إجمالية قدرها 57 دولارا ، فيجب علينا إزالة الميزة ودفع 57 دولارا للضحية من جيبه إذا لزم الأمر.

أحد التحديات الأكبر في المجتمع هو خلق قناة موحدة لإجراء تغييرات غير ضرورية للتوافق الخلفي المتضرر. وسيلة لحل هذه المشكلة هي فحص وتوسيع الأسس القائمة بالفعل ، مثل عملية الذاتية التدميرية. يبدو القناة كما يلي:

1. بدء مناقشة وظيفة الحذف X؛

2. قم بتحليل الأمر لتحديد الأثر الناجم عن حذف X على التطبيق، وذلك يعتمد تماما على النتائج: (i) التخلي عن الفكرة، (ii) المضي قدما حسب الخطة، أو (iii) تحديد الطريقة المعدلة الأقل “تدميراً” لحذف X والاستمرار؛

3. وضع EIP الرسمي لإلغاء X. تأكد من أن البنية الأساسية للمستوى الأعلى الشهيرة (مثل لغات البرمجة، المحفظة) تحترم هذه النقطة وتتوقف عن استخدام هذه الوظيفة.

4. في النهاية ، احذف X بشكل فعلي؛

يجب أن يكون هناك أنابيب طويلة بين الخطوة 1 والخطوة 4 تستغرق سنوات عديدة ، وتوضح بوضوح أي مشاريع في أي خطوة. في هذه النقطة ، يجب التوازن بين حيوية وسرعة عملية إزالة الميزات والاستثمار المحافظ وتخصيص المزيد من الموارد لتطوير البروتوكول في المجالات الأخرى ، لكننا لا نزال بعيدين عن الحد الأمثل.

EOF

مجموعة من التغييرات الرئيسية المقدمة لـ EVM هي تنسيق كائن EVM (EOF). يقدم EOF العديد من التغييرات مثل منع غاز المراقبة، رصد الكود (أي بدون CODECOPY)، والسماح فقط بالقفزات الثابتة. الهدف هو السماح لـ EVM بالترقيات بطريقة أكثر قوة مع الحفاظ على التوافق مع الإصدارات السابقة (لأن EVM قبل EOF ما زال موجودًا).

إيجابيات القيام بذلك هي أنه يخلق مسارًا طبيعيًا لإضافة وظائف EVM جديدة ويشجع على الانتقال إلى EVM أكثر صرامة وضمانًا. عيوبه هي أنه يزيد بشكل كبير من تعقيد البروتوكول، ما لم نتمكن من إيجاد طريقة لإلغاء استخدام EVM القديم وحذفه في النهاية. مشكلة رئيسية هي: ما هو دور EOF في اقتراح تبسيط EVM، خاصة إذا كان الهدف هو إسقاط تعقيد EVM بأكمله؟

كيف يتفاعل مع أجزاء الخريطة الطريقية الأخرى؟

العديد من الاقتراحات “للتحسين” في الجزء الآخر من خريطة الطريق هي فرص لتبسيط الوظائف القديمة. قم بتكرار بعض الأمثلة أعلاه:

· التبديل إلى الثبات النهائي لفتحة واحدة يتيح لنا فرصة إلغاء اللجان وإعادة تصميم الاقتصاد وإجراء تبسيطات أخرى ذات الصلة بإثبات التخزين.

· يمكننا أن نحقق تجريد الحساب بالكامل لنحذف الكثير من الخطط المعتمدة حاليًا لمعالجة المعاملات ونقوم بتحويلها إلى ‘الحساب الافتراضي للأكواد الإضافية لـ EVM’ التي يمكن استبدالها بأي EOA.

· إذا قمنا بنقل حالة Ethereum إلى شجرة الفهرسة الثنائية، يمكن أن يتم ذلك بتنسيق متناغم مع الإصدار الجديد من SSZ، بحيث يمكن معالجة جميع هياكل بيانات Ethereum بنفس الطريقة.

طريقة أكثر تطرفًا: تحويل جزء كبير من بروتوكول إلى رمز العقد

استراتيجية بسيطة أكثر تطرفا لـ إثيريوم هي الاحتفاظ بالبروتوكول كما هو، ولكن نقل معظم وظائف البروتوكول إلى شيفرة العقد.

أقصى نسخة هي أن تجعل ETH بلوك L1 “تقنياً” سلسلة Beacon وتقدم آلة افتراضية صغيرة جدًا (مثل RISC-V أو Cairo أو أصغر بكثير مخصصة لنظام البراهين) تسمح للآخرين بإنشاء مجموعاتهم الخاصة. ثم يصبح EVM الأول في هذه المجموعات. من الساخر أن هذا هو بالضبط نتيجة اقتراح بيئة التنفيذ لعام 2019-20، على الرغم من أن SNARK يجعل تنفيذها عمليًا أكثر قابلية.

الطريقة الأكثر اعتدالًا هي الحفاظ على العلاقة بين سلسلة beacon وبيئة تنفيذ ETH الحالية كما هي، ولكن بتبديل EVM في المكان. يمكننا اختيار RISC-V أو Cairo أو غيرها من ال٢٠١٩٢٨٣٧٤٦٥٦٥٧٤٨٣٩٢٠١ VM كـ “VM الرسمية لـ ETH” الجديدة، ثم تحويل جميع عقود EVM بشكل قسري إلى رمز VM جديد يقوم بتفسير الشيفرة الأصلية (عن طريق الترجمة أو التفسير). من النظرية، يمكن أن يتم ذلك حتى من خلال “الجهاز الافتراضي المستهدف” كإصدار من EOF.

رابط المقال الأصلي