اقتراح فيتاليك الجديد: RISC-V كلغة آلة افتراضية لعقود EVM الذكية

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

الفكرة: استخدام RISC-V كلغة الآلة الافتراضية لكتابة عقود EVM الذكية.

توضيح مهم:

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

إحدى السوابق هي Nervos CKB VM، وهي في الأساس عبارة عن RISC-V.

لماذا تفعل هذا؟

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

• أخذ عينات من توفر البيانات واستقرار بروتوكولات تخزين التاريخ

• الرغبة في الحفاظ على سوق إنتاج كتل تنافسية

• إمكانيات التحقق من ZK-EVM

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

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

هناك أربعة أجزاء تستغرق الكثير من الوقت: deserialize_inputs، وinitialize_witness_db، وstate_root_computation، وblock_execution.

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

يمكن تحسين هذه الأجزاء بشكل كبير عن طريق استبدال شجرة keccak 16-ary Merkle patricia الحالية بشجرة ثنائية تستخدم دالة تجزئة صديقة للمثبت. إذا استخدمنا Poseidon، فيمكننا إثبات 2 مليون تجزئة في الثانية على الكمبيوتر المحمول (مقارنة بحوالي 15000 تجزئة في الثانية لـ Keccak). هناك العديد من الخيارات الأخرى إلى جانب بوسيدون. وفي المجمل، لدينا الفرصة لتقليص هذه المكونات بشكل كبير. كمكافأة، يمكننا التخلص من accrue_logs_bloom عن طريق التخلص من bloom.

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

تشير بعض البيانات إلى أنه في حالات محدودة، قد يؤدي هذا إلى تحسينات في الكفاءة بأكثر من 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، يستدعي X باستخدام (C, D) ثم ينتظر قيمة الإرجاع ويعيد توجيهها. إذا قام مترجم EVM بنفسه بالاتصال بالعقد، وطلب منه تشغيل CALL أو SLOAD/SSTORE، فسوف يقوم العقد بذلك.

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

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