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

الفكرة: استبدال EVM ب RISC-V كلغة لغة الجهاز الظاهري التي يتم كتابة العقود الذكية بها.

توضيحات مهمة:

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

أحد الأسبقيات لهذا هو Nervos CKB VM، الذي يكون أساسيا RISC-V.

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

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

1. استقرار عينات توفر البيانات وبروتوكولات تخزين التاريخ
2. رغبة في الحفاظ على إنتاج الكتل سوق تنافسية
3. قدرات إثبات ZK-EVM

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

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

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

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

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

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

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

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

(وبالمناسبة، تقريبًا تقسيم 50/50 بين 'EVM' و'أشياء أخرى'يظهر أيضًا في تنفيذ EVM العادي, ونتوقع بشكل بديهي أن الفوائد من إزالة 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 قد يكون مرشحًا).

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

تنصل:

1. تم نقل هذه المقالة من [ السحرة الإثيرية]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [فيتاليك بوتيرين]. إذا كانت هناك اعتراضات على هذا النقل، يرجى التواصل مع بوابة تعلمالفريق، وسيتولون بالأمر على الفور.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذا المقال هي فقط تلك للمؤلف ولا تشكل أي نصيحة استثمارية.
3. يقوم فريق Gate Learn بترجمة المقالات إلى لغات أخرى. يُمنع نسخ أو توزيع أو ارتكاب الانتحال للمقالات المترجمة ما لم يُذكر.