النص الكامل لاقتراح الطبقة التنفيذية L1 طويل الأجل من Vitalik: استبدال EVM ب RISC-V
المصدر: فيتاليك بوتيرين
تجميع: KarenZ ، Foresight News
في 20 أبريل ، قدم فيتاليك بوتيرين اقتراحا مهما على منصة Ethereum Magicians لطبقة تنفيذ L1 طويلة الأجل ل Ethereum. واقترح استبدال EVM (Ethereum Virtual Machine) الحالي ببنية RISC-V كلغة آلة افتراضية لكتابة العقود الذكية ، بهدف تحسين الكفاءة التشغيلية لطبقة تنفيذ Ethereum بشكل أساسي ، واختراق أحد اختناقات التوسع الرئيسية الحالية ، وتبسيط بساطة طبقة التنفيذ إلى حد كبير.
قامت Foresight News بتجميع النص الكامل للاقتراح لمساعدة القراء على فهم هذه الرؤية التقنية. وفيما يلي تجميع للاقتراح الأصلي:
تقدم هذه الورقة فكرة جذرية حول مستقبل طبقة تنفيذ Ethereum ، لا تقل طموحا عن مبادرات Beam Chain لطبقة الإجماع. يهدف الاقتراح إلى تحسين كفاءة طبقة تنفيذ Ethereum بشكل كبير ، ومعالجة أحد اختناقات التوسع الرئيسية ، وتبسيط طبقة التنفيذ بشكل كبير - في الواقع ، قد تكون هذه هي الطريقة الوحيدة لتحقيق ذلك.
الفكرة الأساسية: استبدال EVM ب RISC-V كلغة آلة افتراضية للعقود الذكية.
ملاحظات مهمة:
-
سيتم الاحتفاظ بمفاهيم مثل نظام الحساب ، والمكالمات عبر العقود ، والتخزين ، وما إلى ذلك ، بالكامل. تعمل هذه التصميمات المجردة بشكل جيد واعتاد المطورون على استخدامها. يتم تحويل رموز التشغيل مثل SLOAD و SSTORE و BALANCE و CALL وما إلى ذلك إلى مكالمات نظام RISC-V.
-
في هذا الوضع ، يمكن كتابة العقود الذكية بلغة Rust ، لكنني أتوقع أن يستمر معظم المطورين في كتابة العقود في Solidity (أو Vyper) ، والتي ستتكيف مع RISC-V كواجهة خلفية جديدة. لأن العقود الذكية المكتوبة في Rust هي في الواقع أقل قابلية للقراءة ، في حين أن Solidity و Vyper أكثر وضوحا وأسهل في القراءة. قد تتأثر تجربة التطوير بالكاد ، وقد لا يلاحظ المطورون التغيير.
-
سيستمر عقد EVM القديم في العمل وهو متوافق تماما ثنائي الاتجاه مع عقد RISC-V الجديد. هناك عدة طرق للقيام بذلك ، والتي سيتم مناقشتها بمزيد من التفصيل لاحقا في هذه المقالة.
لقد وضع Nervos CKB VM سابقة وهو في الأساس تطبيق RISC-V.
لماذا؟
على المدى القصير ، ستعالج EIPs القادمة (على سبيل المثال ، قوائم الوصول على مستوى الكتلة ، والتنفيذ المؤجل ، وتخزين المحفوظات الموزعة ، و EIP-4444) اختناقات التوسع الرئيسية ل Ethereum L1. سيتم حل المزيد من المشاكل على المدى المتوسط مع انعدام الجنسية و ZK-EVM. على المدى الطويل ، ستصبح العوامل المقيدة الرئيسية لتوسيع نطاق Ethereum L1:
-
استقرار توفر البيانات وأخذ العينات وبروتوكولات التخزين التاريخية
-
الحفاظ على الطلب على المنافسة في سوق إنتاج البلوك
-
إثبات ZK-EVM
سأزعم أن استبدال ZK-EVM ب RISC-V يمكن أن يحل الاختناقات الرئيسية في (2) و (3).
يوضح الجدول التالي عدد الدورات المطلوبة لكل خطوة من خطوات طبقة تنفيذ Succinct ZK-EVM Proof 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 مليون تجزئة في الثانية على جهاز كمبيوتر محمول (مقارنة بحوالي 15,000 تجزئة / ثانية ل keccak). بالإضافة إلى Poseidon ، هناك العديد من الخيارات الأخرى. بشكل عام ، هناك مجال كبير لتحسين هذه المكونات. بالإضافة إلى ذلك ، يمكننا القضاء على accrue_logs_bloom عن طريق إزالة الإزهار.
تمثل block_execution المتبقية حوالي نصف دورات prover الحالية. لتحقيق زيادة 100 مرة في كفاءة الإثبات الإجمالية ، يلزم وجود كفاءة إثبات EVM لا تقل عن 50 ضعفا. يتمثل أحد الحلول في إنشاء تطبيق إثبات أكثر كفاءة ل EVM ، والآخر هو ملاحظة أن موفر ZK-EVM الحالي يقوم بالفعل بتجميع EVM إلى RISC-V للإثبات ، مما يمنح مطوري العقود الذكية وصولا مباشرا إلى الجهاز الظاهري RISC-V.
تظهر بعض البيانات أن مكاسب الكفاءة لأكثر من 100 مرة يمكن أن تحدث في مواقف معينة:
من الناحية العملية ، قد يتم شغل وقت prover المتبقي في الغالب من خلال عملية التجميع المسبق الحالية. مع RISC-V باعتباره الجهاز الافتراضي الأساسي ، سيعكس جدول الغاز وقت الإثبات الفعلي ، وسيدفع الضغط الاقتصادي المطورين إلى تقليل استخدام التجميع المسبق عالي التكلفة. وحتى في هذه الحالة، لن تكون المكاسب كبيرة جدا، ولكن لدينا سبب وجيه للاعتقاد بأنها ستكون كبيرة.
(تجدر الإشارة إلى أن الوقت المستغرق ل "عمليات EVM" و "العمليات الأخرى" في التنفيذ العادي ل EVM يقترب أيضا من 50/50 ، لذلك نفترض بشكل حدسي أن إزالة EVM ك "طبقة وسيطة" ستحقق مكاسب كبيرة بنفس القدر.)
تفاصيل التنفيذ
هناك عدة طرق لتنفيذ هذا الاقتراح. الحل الأقل تعطيلا هو دعم كل من الأجهزة الظاهرية والسماح بكتابة العقد في أحدهما. يتمتع كلا النوعين من العقود بإمكانية الوصول إلى نفس الميزات: التخزين المستمر (SLOAD/SSTORE)، والقدرة على الاحتفاظ بأرصدة ETH، وبدء/استقبال المكالمات، والمزيد. يمكن استدعاء عقود EVM و RISC-V لبعضها البعض - من منظور RISC-V ، فإن استدعاء عقد EVM يعادل تنفيذ استدعاء نظام بمعلمات خاصة ؛ سيفسرها عقد EVM الذي يتلقى الرسالة على أنها مكالمة.
يتمثل النهج الأكثر جذرية من منظور البروتوكول في تحويل عقد EVM الحالي إلى استدعاء لعقد مترجم EVM مكتوب بلغة RISC-V لتشغيل رمز EVM الحالي. أي ، إذا كان عقد EVM يحتوي على رمز C وكان مترجم EVM في العنوان X ، استبدال العقد بمنطق المستوى الأعلى الذي ، عند استدعاؤه من الخارج بوسيطة استدعاء D ، يستدعي X ويمر (C ، D) ، ثم ينتظر قيمة الإرجاع وإعادة التوجيه. إذا استدعى مترجم EVM نفسه العقد، ويطلب تشغيل CALL أو SLOAD/SSTORE، فإن العقد ينفذ هذه العمليات.
الحل الوسط هو الخيار الثاني ، ولكن مع دعم صريح لمفهوم "مترجم الآلة الافتراضية" من خلال بروتوكول يتطلب كتابة منطقه بلغة RISC-V. سيكون EVM هو المثيل الأول ، مع دعم لغات أخرى في المستقبل (قد يكون Move مرشحا).
الميزة الأساسية للخيارين الثاني والثالث هي أنهما يبسطان إلى حد كبير مواصفات طبقة التنفيذ. نظرا لصعوبة إزالة التبسيط التدريجي مثل التدمير الذاتي ، قد يكون هذا الخط من التفكير هو المسار الوحيد القابل للتطبيق للتبسيط. تلتزم Tinygrad بالقاعدة الصارمة المتمثلة في "ما لا يزيد عن 10,000 سطر من التعليمات البرمجية" ، ويجب أن تكون blockchain المثلى الأساسية قادرة على تلبية هذا الحد بسهولة وتبسيطه بشكل أكبر. تعد مبادرة Beam Chain بتبسيط طبقة إجماع Ethereum بشكل كبير ، وقد يكون هذا التغيير الجذري هو الطريقة الوحيدة لتحقيق دفعة مماثلة في طبقة التنفيذ.