اقتراح فيتاليك الجديد: استبدال EVM الحالي بـ RISC-V

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

فكرة: استبدال EVM بلغة الآلة الخاصة بالعقود الذكية باستخدام RISC-V (ملاحظة المترجم: RISC-V تشير إلى بنية مجموعة التعليمات المفتوحة التي تم إنشاؤها بناءً على مبادئ RISC للحوسبة ذات مجموعة التعليمات المختصرة، حيث يشير V إلى الجيل الخامس من RISC).

توضيح مهم:

• ستبقى مفاهيم مثل الحسابات والمكالمات عبر العقود والتخزين وما إلى ذلك كما هي تماما. تعمل هذه التجريدات بشكل جيد للغاية ، ويعتاد المطورون عليها. تصبح رموز التشغيل مثل SLOAD و SSTORE و BALANCE و CALL مكالمات نظام RISC-V.
• في مثل هذا العالم، يمكن كتابة العقود الذكية باستخدام Rust، لكنني أتوقع أن يواصل معظم المطورين كتابة العقود الذكية باستخدام Solidity (أو Vyper) مما سيتناسب مع إضافة RISC-V كخلفية. وذلك لأن العقود الذكية المكتوبة بلغة Rust تبدو في الواقع قبيحة إلى حد ما، بينما فإن قابلية قراءة Solidity و Vyper أعلى بكثير. ربما تكون التغييرات في devex طفيفة، وقد لا يلاحظ المطورون هذا التغيير تقريبًا.
• ستظل عقود EVM القديمة فعالة وستكون قابلة للتشغيل المتبادل ثنائي الاتجاه بالكامل مع عقود RISC-V الجديدة. هناك عدة طرق لتحقيق ذلك، سأقوم بشرحها في وقت لاحق من هذه المقالة.

من الأمثلة هو Nervos CKB VM، التي هي أساسًا RISC-V.

لماذا نفعل ذلك؟

على المدى القصير، ستُحلّ العوائق الرئيسية في قابلية توسيع إثيريوم L1 من خلال EIP القادم، مثل قوائم الوصول على مستوى الكتلة، التنفيذ المتأخر والتخزين التاريخي الموزع بالإضافة إلى EIP-4444. على المدى المتوسط، سنعالج المزيد من القضايا المتعلقة بالحالة الفارغة و ZK-EVM. على المدى الطويل، فإن العوامل الرئيسية التي تحد من توسيع Layer1 لإثيريوم هي:

• استقرار بروتوكولات عينة توفر البيانات والتخزين التاريخي
• نأمل في الحفاظ على تنافسية سوق إنتاج الكتل
• قدرة التحقق ZK-EVM

أعتقد أن استبدال RISC-V بـ ZK-EVM يمكن أن يحل أحد الاختناقات الرئيسية في (2) و (3).

هذا هو جدول عدد دورات الأجزاء المختلفة من طبقة تنفيذ EVM باستخدام Succinct ZK-EVM:

! nsRqhscTyRR2vPvAOgUE58HVgFHuLUgGxTescWwT.jpeg

هناك أربعة أجزاء تستغرق الكثير من الوقت: إلغاء التسلسل \ _inputs ، تهيئة \ _witness \ _db ، الحالة \ _root \ _computation ، و block \ _execution.

initialize_witness_db و state_root_computation كلاهما يتعلقان بشجرة الحالة، deserialize_inputs تشير إلى العملية التي يتم من خلالها تحويل الكتلة وبيانات الشهادة إلى تمثيل داخلي؛ وبالتالي، في الواقع، أكثر من 50% يتناسب مع حجم الشهادة.

يمكن تحسين هذه الأجزاء بشكل كبير من خلال استبدال شجرة ميركل باتريشيا ذات 16 عنصر keccak الحالية بشجرة ثنائية تستخدم دالة هاش صديقة للمدققين. إذا استخدمنا Poseidon، يمكننا إثبات 2 مليون قيمة هاش في الثانية على اللابتوب (بينما keccak يحقق حوالي 15,000 قيمة هاش في الثانية). بالإضافة إلى Poseidon، هناك العديد من الخيارات الأخرى. بوجه عام، لدينا فرصة لتقليل هذه المكونات بشكل كبير. كمكافأة، يمكننا التخلص من accrue_logs_bloom من خلال التخلي عن bloom.

بقي فقط block_execution، والذي يمثل حوالي نصف دورة الإثبات التي تم إنفاقها اليوم. إذا أردنا زيادة كفاءة الإثبات الإجمالية بمقدار 100 مرة، فلن نتمكن من تجنب حقيقة أنه يجب علينا على الأقل زيادة كفاءة إثبات EVM بمقدار 50 مرة. يمكننا القيام بشيء واحد وهو محاولة إنشاء تنفيذ EVM أكثر كفاءة من حيث دورة الإثبات. يمكننا القيام بشيء آخر وهو ملاحظة أن إثبات ZK-EVM يعمل اليوم من خلال إثبات تم ترجمته إلى تنفيذ EVM على RISC-V، وفتح الوصول لمطوري العقود الذكية مباشرة إلى تلك الذاكرة الافتراضية RISC-V.

تشير بعض البيانات إلى أنه في حالات محدودة، يمكن أن يزيد هذا الكفاءة أكثر من 100 مرة:

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

(بالمناسبة، يظهر تقسيم حوالي 50/50 بين “EVM” و"أشياء أخرى" أيضًا في تنفيذ EVM العادي، ونتوقع بشكل بديهي أن تكون العوائد التي يجب إزالتها من EVM ك"وسيط" كبيرة بنفس القدر)

تفاصيل التنفيذ

هناك طرق متعددة لتحقيق هذه الاقتراحات. الطريقة الأقل تدميراً هي دعم جهازين افتراضيين، والسماح بكتابة العقود في أي من الجهازين الافتراضيين. يمكن استخدام نوعي العقود مع نفس نوع المرافق: التخزين الدائم (SLOAD و SSTORE)، القدرة على الاحتفاظ برصيد ETH، القدرة على إجراء واستقبال المكالمات، وما إلى ذلك. يمكن للعقود EVM و RISC-V استدعاء بعضها البعض بحرية؛ من منظور RISC-V، يبدو أن استدعاء عقود EVM هو إجراء مكالمة نظام مع بعض المعلمات الخاصة؛ ستقوم عقد EVM التي تتلقى الرسالة بتفسيرها على أنها CALL.

من وجهة نظر البروتوكول، فإن الطريقة الأكثر جذرية هي تحويل العقود الحالية الخاصة بـ EVM إلى عقود تستدعي عقد مفسر EVM المكتوب بلغة RISC-V، والذي يقوم بتشغيل كود EVM الحالي الخاص به. بمعنى آخر، إذا كان لدى عقد EVM كود C، وكان مفسر EVM موجودًا في العنوان X، فإن هذا العقد سيتم استبداله بالمنطق العلوي، وعند استدعائه من الخارج باستخدام معلمات الاستدعاء D، سيتم استخدام (C، D) لاستدعاء X، ثم الانتظار لقيمة الإرجاع وإعادة توجيهها. إذا قام مفسر EVM نفسه باستدعاء عقد، مطالبًا بتشغيل CALL أو SLOAD/SSTORE، فسوف يقوم العقد بذلك.

المسار الأوسط هو اعتماد الخيار الثاني، ولكن لإنشاء وظيفة بروتوكول واضحة له - بشكل أساسي، تكريس مفهوم “مفسر الآلة الافتراضية” كمرجع، وطلب منطقها أن يُكتب باستخدام RISC-V. ستكون EVM هي الأولى، ولكن قد يكون هناك أيضًا أخرى (على سبيل المثال، قد تكون Move مرشحًا).

تتمثل إحدى الفوائد الرئيسية للاقتراحين الثاني والثالث في أنهما يبسطان بشكل كبير مواصفات طبقة التنفيذ - في الواقع، قد تكون هذه الفكرة هي الطريقة الوحيدة القابلة للتطبيق، لأنه حتى تقليل التعقيد بشكل تدريجي مثل حذف SELFDESTRUCT يعد أمرًا صعبًا للغاية. لدى Tinygrad قاعدة صارمة مفادها أن كمية التعليمات البرمجية لا تتجاوز 10,000 سطر؛ يجب أن تكون أفضل طبقة أساسية للبلوكشين قادرة على التكيف بشكل جيد مع هذه الحدود، بل وأصغر. تأمل جهود سلسلة Beam في تبسيط طبقة الإجماع في إثيريوم بشكل كبير. ولكن بالنسبة لطبقة التنفيذ، قد تكون هذه التغييرات الجذرية هي الطريقة الوحيدة لتحقيق فوائد مماثلة.