فيتاليك: الهدف الرئيسي لمرحلة التطهير في إيثريوم

المؤلف: فيتاليك، مؤسس إيثريوم؛ المترجم: دينج تونج، جولدن فاينانس

ملاحظة: هذه المقالة هي الخامسة في سلسلة من المقالات حول "التطور المستقبلي لبروتوكول إيثريوم" التي نشرتها مؤخرًا فيتاليك، مؤسس إيثريوم الجزء "العقود المستقبلية المحتملة لبروتوكول إيثريوم، الجزء 5: التطهير"، للجزء الرابع، راجع "Vitalik: Ethereum مستقبل ورشة العمل The Verge". يمكن العثور على الجزء الثالث في "Vitalik: الأهداف الرئيسية لمرحلة البلاء في Ethereum"، ويمكن العثور على الجزء الثاني يمكن العثور عليها في "فيتاليك: كيف يجب أن يتطور بروتوكول إيثريوم أثناء الطفرة"، راجع الجزء الأول في "< a href="https:// www.jinse.cn/blockchain/3699549.html">ما الذي يمكن تحسينه أيضًا في Ethereum PoS". فيما يلي النص الكامل للجزء الخامس:

شكر خاص لجوستين دريك، وتيم بيكو، ومات جارنيت، وبيبر ميريام، وماريوس فان دير فيدن، وتوماس ستانزاك على تعليقاتهم وتعليقاتهم.

أحد التحديات التي تواجه Ethereum هو أنه افتراضيًا، سيزداد تضخم وتعقيد أي بروتوكول blockchain بمرور الوقت. يحدث هذا بطريقتين:

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

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

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

التطهير، خارطة طريق 2023.

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

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

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

• تقليل تعقيد البروتوكول عن طريق التخلص من الوظائف غير الضرورية

  < /li>

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

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

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

ما هذا؟ كيف يعمل؟

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

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

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

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

ما هي الأبحاث المتوفرة؟

EIP-4444: https://eips.ethereum.org/EIPS/eip-4444

السيول و EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788

شبكة البوابة الإلكترونية: https://ethereum.org/en/developers/docs/networking-layer/portal-network/

شبكة البوابة الإلكترونية وEIP-4444 : https://github.com/ethereum/portal-network-specs/issues/308

التخزين الموزع واسترجاع كائنات SSZ في البوابة: https://ethresear.ch/t/distributed-storage-and-cryptographically- Secured -retrieval-of-ssz-objects-for-portal-network/19575

كيفية زيادة حد الغاز (نموذج): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

ماذا يجب أن أفعل بعد ذلك، وما هي المقايضات؟

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

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

• مدى الجدية التي يجب أن نعمل بها للتأكد من أن الحد الأقصى لعدد العقد يقوم بالفعل بتخزين كافة البيانات؟

• ما مدى عمق دمج تخزين السجل في البروتوكول؟

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

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

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

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

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

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

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

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

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

ما هذا؟ كيف يعمل؟

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

• < p>< strong>الكفاءة: لا يلزم إجراء حسابات إضافية واسعة النطاق لتشغيل عملية انتهاء الصلاحية.

• سهولة الاستخدام: إذا ذهب شخص ما إلى كهف وعاد بعد خمس سنوات، فلا ينبغي أن يفقد السيطرة على ETH وERC20 وNFT الخاص به. ، الوصول إلى مواقع CDP…

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

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

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

• حل انتهاء صلاحية الحالة الجزئية.

• مقترح انتهاء الصلاحية بناءً على فترة العنوان.

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

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

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

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

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

اقتراح انتهاء صلاحية الحالة المستندة إلى فترة العنوان

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

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

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

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

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

يتمثل الاقتراح في تقديم تنسيق جديد لعنوان 32 بايت يتضمن رقم الإصدار ورقم فترة العنوان وقيمة تجزئة الامتداد.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

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

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

تقلص مساحة العنوان

هناك طريقة أخرى معاكسة: فنحن نمنع على الفور بعض النطاقات الفرعية من العناوين بحجم 2128 (على سبيل المثال، جميع العناوين التي تبدأ بـ 0xffffffff)، ثم نستخدم هذا النطاق لتقديم النطاق توجد فترة عنوان وقيمة تجزئة تبلغ 14 بايت للعنوان.

0xffffffff000169125d5dFcb7B8C2659029395bdF

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

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

ما هي الأبحاث المتوفرة؟

الاقتراح المبكر

رسوم استئجار Blockchain: https://github.com/ethereum/EIPs/issues/35< /p >

التجديد:https :/ /ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582

نظرية إدارة حجم حالة الإيثريوم: https:/ /hackmd. io/@vbuterin/state_size_management

العديد من المسارات المحتملة لانعدام الجنسية وانتهاء صلاحية الولاية: https://hackmd.io/@vbuterin/state_expiry_paths

< strong>انتهت الحالة الجزئية الاقتراح

EIP-7736: https://eips.ethereum.org/EIPS/eip-7736

وثائق توسيع مساحة العنوان

الاقتراح الأصلي: https: //ethereum-magicians .org/t/increasing-address-size-from-20-to-32-bytes/5485

تعليقات إبسيلون : https:/ /notes.ethereum.org/@ipsilon/address-space-extension-exploration

تعليقات منشورات المدونة: https://medium.com/@chaisomsri96/stateness-series-part2-ase-address-space-extension-60626544b8e6

ماذا سيحدث إذا فقدنا مقاومة الاصطدام: https://ethresear.ch/t/what-would-break -if-we- Lose-address-collision-resistance/11356

ما الذي بقي ليفعله؟ ما هي المقايضات؟

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

• < p> نحن عديمو الجنسية ولا نقدم أبدًا انتهاء صلاحية الحالة. تنمو الحالة (وإن كان ذلك بطيئًا: ربما لن نراها تتجاوز 8 تيرابايت لعقود من الزمن)، ولكنها تحتاج فقط إلى الاحتفاظ بها من قبل فئة متخصصة نسبيًا من المستخدمين: حتى أدوات التحقق من صحة إثبات الحصة (PoS) لا تحتاج إلى حالة.

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

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

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

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

هناك نقطة مهمة وهي ما إذا كان التنفيذ يعتمد على تنسيق العنوان أم لا التغييرات يجب أن يحل نظام انتهاء صلاحية الحالة في النهاية مشكلة توسيع مساحة العنوان وانكماشها. اليوم، يلزم ما يقرب من 2^80 تجزئة لإنتاج تضارب عنوان، وهذا التحميل الحسابي ممكن بالفعل للجهات الفاعلة الغنية بالموارد للغاية: يمكن لوحدات معالجة الرسوميات إجراء ما يقرب من 2^27 تجزئة، لذلك يتم تشغيلها لمدة عام يمكنها حساب 2^52، لذلك يمكن لجميع وحدات معالجة الرسوميات ~2^30 في العالم حساب الاصطدامات في حوالي 1/4 عام، ويمكن لـ FPGAs وASICs تسريع هذه العملية بشكل أكبر. وفي المستقبل، ستكون مثل هذه الهجمات مفتوحة أمام المزيد والمزيد من الناس. ولذلك، فإن التكلفة الفعلية لتنفيذ انتهاء صلاحية الحالة الكاملة قد لا تكون عالية كما تبدو، حيث يتعين علينا حل مشكلة العنوان الصعبة للغاية هذه على أي حال.

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

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

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

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

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

ما هذا؟ كيف يعمل؟

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

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

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

• RLP → تحويل SSZ: في البداية، كائنات Ethereum يتم تسلسلها باستخدام ترميز يسمى RLP. اليوم، تستخدم سلسلة المنارات SSZ، وهو أفضل بكثير من نواحٍ عديدة، بما في ذلك دعم ليس فقط التسلسل ولكن أيضًا التجزئة. في النهاية، نأمل في التخلص من RLP تمامًا ونقل جميع أنواع البيانات إلى هياكل SSZ، مما يؤدي بدوره إلى تسهيل عمليات الترقيات. تتضمن خطط EIP المقترحة حاليًا لهذا الأمر [1] [2] [3].

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

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

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

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

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

• إزالة endianness المختلط:EVM هو endian كبير وطبقة الإجماع هي endian صغيرة. قد يكون من المنطقي إعادة ترتيب كل شيء وجعله كبيرًا (ربما يكون كبيرًا نظرًا لأنه من الصعب تغيير EVM).

الآن، بعض الأمثلة من داخل EVM:

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

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

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

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

ما هي الأبحاث المتوفرة؟

الخطوات التالية للتطهير: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA

الهيكل الذاتي: https://hackmd.io/@vbuterin/selfdestruct

SSZ-ification EIPS: [1] [2] [3]

تغيرات تكلفة الغاز عديمة الحالة: https://eips.ethereum org /EIPS/eip-4762

تسعير الذاكرة الخطية: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw

تم حذف التجميع المسبق:< a href="https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg" _src="https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg">https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg< /p >

إزالة مرشح بلوم: https://eips.ethereum.org/EIPS/eip-7668

طريقة للتوقف - استرجاع السجل الآمن للسلسلة باستخدام حساب تزايدي يمكن التحقق منه (اقرأ: STARK العودي): https ://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

ما الذي يجب فعله أيضًا وما هي المقايضات؟

إن المفاضلة الرئيسية في تبسيط هذه الميزة هي (1) مدى التبسيط وسرعته مقابل (2) التوافق مع الإصدارات السابقة. تتمثل قيمة Ethereum كسلسلة في أنها منصة يمكنك من خلالها نشر تطبيق وتكون واثقًا من أنه سيظل يعمل بعد سنوات. وفي الوقت نفسه، من الممكن أن نأخذ هذا المثل الأعلى بعيدًا جدًا، وعلى حد تعبير ويليام جينينغز بريان، "صلب الإيثيريوم على صليب التوافق العكسي". إذا كان هناك تطبيقان فقط في إجمالي Ethereum يستخدمان إحدى الميزات، ولم يكن لأحدهما أي مستخدمين لسنوات والآخر ليس له أي استخدام تقريبًا على الإطلاق، وتم اكتساب قيمة إجمالية بقيمة 57 دولارًا، فإننا يجب إزالة الميزة، إذا لزم الأمر، يتم دفع 57 دولارًا من جيبك للضحية.

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

• الخطوة 1: قوي>ابدأ المناقشة حول إزالة الميزة X.

• الخطوة 2: قم بإجراء تحليل لتحديد مدى الضرر الذي تحدثه عملية الإزالة ) كما هو مخطط لها، أو (3) تحديد الطريقة المعدلة "الأقل تدميراً" إزالة X والمضي قدما.

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

• الخطوة 4:أخيرًا، احذف X.

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

EOF

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

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

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

تمثل العديد من مقترحات "التحسين" الواردة في بقية خريطة الطريق أيضًا فرصًا لتبسيط الميزات القديمة. تكرار بعض الأمثلة المذكورة أعلاه:

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

• يسمح لنا التنفيذ الكامل لتجريد الحساب بإزالة الكثير من منطق معالجة المعاملات الحالي عن طريق نقله إلى جزء من "رمز EVM للحساب الافتراضي" الذي يمكن لجميع EOAs استبداله بـ .

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

نهج أكثر جذرية: تحويل معظم البروتوكول إلى كود عقد

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

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

أسلوب ألطف هو الحفاظ على العلاقة بين سلسلة المنارات وبيئة تنفيذ Ethereum الحالية دون تغيير، ولكن لتبادل EVM في مكانه. يمكننا اختيار RISC-V، أو كايرو، أو جهاز افتراضي آخر باعتباره "جهاز Ethereum VM الرسمي" الجديد ثم فرض جميع عقود EVM على كود VM جديد (إما من خلال التجميع أو التفسير) الذي يفسر منطق الكود الأصلي. من الناحية النظرية، يمكن القيام بذلك باستخدام "VM الهدف" كإصدار EOF.