jakiro
المصدر: Vitalik Buterin ، Ethereum Magicians ؛ التجميع: Tao Zhu ، رؤية Baitchain
تقدم هذه المقالة فكرة عدوانية لمستقبل طبقة تنفيذ Ethereum ، والتي تعتبر طموحة مثل جهود سلسلة الشعاع نحو طبقة الإجماع.ويهدف إلى زيادة كفاءة طبقة تنفيذ Ethereum بشكل كبير ، وحل واحدة من اختناقات التحجيم الرئيسية ، وكذلك تحسين بساطة طبقة التنفيذ – في الواقع ، ربما تكون هذه هي الطريقة الوحيدة.
الفكرة: استخدم RISC-V كلغة الجهاز الظاهري لكتابة عقود EVM الذكية.
توضيح مهم:
-
ستبقى مفاهيم الحسابات ، والمكالمات عبر العقد ، والتخزين ، وما إلى ذلك. هذه التجريدات تعمل بشكل جيد والتعود على المطورين عليهم. ستصبح Sload و Sstore و Balance و Call و Opcsodes الأخرى مكالمات نظام RISC-V.
-
في عالم مثل هذا ، يمكن كتابة العقود الذكية في الصدأ ، لكنني أتوقع أن يواصل معظم المطورين كتابة العقود الذكية في صلابة (أو Vyper) ، والتي ستتكيف مع إضافة RISC-V كخلف. وذلك لأن العقود الذكية المكتوبة في الصدأ هي في الواقع قبيحة للغاية ، في حين أن الصلابة والفيبر أكثر قابلية للقراءة. ربما يكون التغيير في Devex صغيرًا ، وقد يلاحظ المطورون هذا التغيير.
-
ستظل عقود EVM ذات الطراز القديم صالحة وستكون قابلية للتشغيل في ثنائية الاتجاه تمامًا مع عقود RISC-V الجديدة. هناك عدة طرق للقيام بذلك ، والتي سأغطيها لاحقًا في هذه المقالة.
سابقة واحدة هي Nervos CKB VM ، والتي هي أساسا RISC-V.
لماذا هذا؟
على المدى القريب ، سيتم معالجة الاختناقات الرئيسية في قابلية التوسع Ethereum L1 مع EIPs القادمة مثل قوائم الوصول على مستوى الكتلة ، وتنفيذ الكمون والتخزين التاريخي الموزع ، و EIP-4444. على المدى المتوسط ، سوف نتناول المزيد من القضايا المتعلقة بالإقلاع و ZK-EVM. على المدى الطويل ، فإن العوامل المحددة الرئيسية لتوسع Ethereum Layer1 هي:
-
أخذ عينات من توافر البيانات واستقرار بروتوكولات التخزين التاريخي
-
نأمل في الحفاظ على تنافسية سوق إنتاج الكتلة
-
القدرة على التحقق ZK-EVM
أعتقد أن استبدال ZK-EVM بـ RISC-V يمكنه حل عنق الزجاجة الرئيسي في (2) و (3).
هذا هو عدد الحلقات المستخدمة من قبل ZK-EVM المستجيب لإثبات أجزاء مختلفة من طبقة تنفيذ EVM:
هناك أربعة أجزاء تستغرق الكثير من الوقت: Deserialize_inputs ، و initialize_witness_db ، و state_root_computation ، و block_execution.
ترتبط initialize_witness_db و state_root_computation بأشجار الحالة ، ويشير Deserialize_Inputs إلى عملية تحويل الكتل والشهود إلى تمثيلات داخلية ؛ لذلك ، في الواقع ، أكثر من 50 ٪ يتناسب مع مقياس الشهود.
يمكن تحسين هذه الأجزاء بشكل كبير عن طريق استبدال شجرة Merkle Patricia Keccak الحالية 16 عضوًا بشجرة ثنائية تستخدم وظائف التجزئة الصديقة للثلج. إذا استخدمنا Poseidon ، فيمكننا إثبات ملايين تجزئة في الثانية على جهاز الكمبيوتر المحمول (و Keccak تجزئة حوالي 15000 تجزئة في الثانية). هناك العديد من الخيارات الأخرى إلى جانب بوسيدون. الكل في الكل ، لدينا الفرصة لتقليل هذه المكونات بشكل كبير. كمكافأة ، يمكننا التخلص من accrue_logs_bloom عن طريق التخلص من الإزهار.
الباقي هو block_execution ، الذي يمثل حوالي نصف دورة الإثبات التي تم إنفاقها اليوم. إذا أردنا زيادة كفاءة المثل الإجمالية بمقدار 100 مرة ، فلا يمكننا تجنب حقيقة أننا بحاجة إلى زيادة كفاءة Prover EVM بمقدار 50 مرة على الأقل. شيء واحد يمكننا القيام به هو محاولة إنشاء تطبيقات EVM أكثر كفاءة في دورات الإثبات. شيء آخر يمكننا القيام به هو ملاحظة أن ZK-EVM Prover عمل اليوم من خلال إثبات أن تنفيذ EVM تم تجميعه في RISC-V ويمنح مطوري العقد الذكي الوصول المباشر إلى ذلك RISC-V VM.
تشير بعض البيانات إلى أن هذا يمكن أن يزيد من الكفاءة بأكثر من 100 مرة في الحالات المحدودة:
في الواقع ، أتوقع أن يهيمن على وقت الإثبات المتبقي من قبل الجبال اليوم. إذا استخدمنا RISC-V كآلة افتراضية رئيسية ، فستعكس خطة الغاز وقت الإثبات ، لذلك سيكون هناك ضغط اقتصادي للتوقف عن استخدام أجهزة التجهيزات الأكثر تكلفة ؛ لكن على الرغم من ذلك ، فإن الفوائد لن تكون مثيرة للإعجاب ، لكن لدينا سبب وجيه للاعتقاد بأن الفوائد ستكون مهمة للغاية.
(بالمناسبة ، يظهر تقسيم ما يقرب من 50/50 بين “EVM” و “أشياء أخرى” في تنفيذ EVM العادي ، ونتوقع بشكل حدسي أن فوائد الإزالة من EVM كـ “الوسيط” يجب أن تكون كبيرة بنفس القدر)
تفاصيل التنفيذ
هناك عدة طرق لتنفيذ مثل هذه الاقتراحات. الأسلوب الأقل تمييزًا هو دعم أجهزتين افتراضيتين والسماح لكتابة العقود في أي من الجهاز الظاهري. يمكن أن يستخدم كلا النوعين من العقود نفس النوع من المنشآت: التخزين المستمر (Sload و Sstore) ، والقدرة على الاحتفاظ بأرصدة ETH ، والقدرة على إجراء واستقبال المكالمات ، وما إلى ذلك. من وجهة نظر RISC-V ، يبدو أن استدعاء عقد EVM يقوم بإجراء مكالمة نظام مع بعض المعلمات الخاصة ؛ عقد EVM الذي يتلقى الرسالة يفسرها كمكالمة.
من منظور البروتوكول ، يتمثل نهج أكثر راديكالية في تحويل عقد EVM الحالي إلى عقد يطلق على عقد مترجم EVM مكتوبًا في RISC-V ، والذي يدير رمز EVM الحالي. وهذا هو ، إذا كان عقد EVM يحتوي على رمز C وكان مترجم EVM في العنوان X ، فسيتم استبدال العقد بمنطق المستوى الأعلى ، عند استدعاؤه من الخارج باستخدام معلمة الاتصال D ، X يتم استدعاؤه بـ (C ، D) ، ثم انتظر قيمة الإرجاع وإعادة توجيهه. إذا استدعاء مترجم EVM نفسه العقد ويتطلب تشغيل المكالمة أو Sload/Sstore ، فإن العقد يفعل ذلك.
يتمثل المسار الوسيط في اتخاذ الخيار الثاني ، ولكن إنشاء وظيفة بروتوكول واضحة لها – في الأساس ، يتم أخذ مفهوم “مترجم الجهاز الظاهري” كدليل ويجب كتابة منطقه في RISC -V. سيكون EVM الأول ، ولكن قد يكون هناك آخرون (على سبيل المثال ، قد يكون التحرك مرشحًا).
واحدة من الفوائد الرئيسية للمقترحات الثانية والثالثة هي أنها تبسط مواصفات طبقة التنفيذ بشكل كبير – في الواقع ، قد تكون هذه الفكرة هي النهج الوحيد القابل للحياة ، حتى أن التبسيط التدريجي مثل إزالة التدمير الذاتي أمر صعب للغاية. لدى Tinygrad قاعدة صارمة مفادها أن حجم الكود لا يتجاوز 10،000 سطر ؛ يجب أن تكون أفضل طبقة أساس blockchain قادرة على التكيف بشكل جيد مع هذه الحدود ، حتى أصغر. إن جهود سلسلة الشعاع لها أمل كبير في تبسيط طبقة الإجماع من Ethereum بشكل كبير. ولكن بالنسبة لطبقة التنفيذ ، قد يكون هذا التغيير الجذري هو الطريقة الوحيدة القابلة للحياة للحصول على فوائد مماثلة.
