يدحض المطورون فيتاليك: الافتراضات خاطئة ، و RISC-V ليس الخيار الأفضل

هذه المقالة من: تجميع مطور Ethereum levochka.eth

| Odaily Planet Daily (@OdailyChina) ؛ @azuma_eth ملاحظة المحرر

:

بالأمس ، أصدر فيتاليك ، المؤسس المشارك ل Ethereum ، مقالا جذريا حول ترقية طبقة تنفيذ Ethereum (انظر "مقالة Vitalik's Radical الجديدة: Execution Layer Scaling" لا تنكسر ، لا تقف "، يجب تكرار EVM في المستقبل) ، مشيرا إلى أنه يأمل في استبدالها ب RISC-V EVM كلغة آلة افتراضية للعقود الذكية.

بمجرد ظهور هذه المقالة ، تسببت على الفور في ضجة في مجتمع مطوري Ethereum ، وأعرب العديد من الشخصيات الفنية البارزة عن وجهات نظر مختلفة حول الخطة. بعد فترة وجيزة من نشر المقال ، كتب مطور Tier-1 Ethereum levochka.eth مقالا مطولا أسفل المقالة الأصلية يدحض حجة Vitalik بأن Vitalik قد وضع افتراضات خاطئة حول نظام الإثبات وأدائه ، وأن RISC-V قد لا يكون الخيار الأفضل لأنه لا يمكنه تحقيق التوازن بين "قابلية التوسع" و "قابلية الصيانة".

فيما يلي المقال الأصلي على levochka.eth ، الذي جمعته صحيفة Odaily اليومية.

من فضلك لا تفعل هذا.

هذه الخطة غير منطقية ، لأنك تضع افتراضات خاطئة حول إثبات النظام وأدائه.

فرضية التحقق

كما أفهمها ، فإن الحجج الرئيسية لهذا المخطط هي "قابلية التوسع" و "قابلية الصيانة".

أولا ، أريد أن أتحدث عن قابلية الصيانة.

في الواقع، تتطلب جميع أجهزة RISC-V zk-VMs "تجميعات مسبقة" للتعامل مع العمليات كثيفة الحوسبة. يمكن العثور على القائمة المجمعة مسبقا ل SP 1 في وثائق Summary ، وستجد أنها تغطي تقريبا جميع أكواد التشغيل "الحسابية" المهمة في EVM.

نتيجة لذلك ، تتطلب جميع التعديلات على أساسيات تشفير الطبقة الأساسية كتابة "دوائر" جديدة وتدقيقها لهذه المجموعات المسبقة ، وهو ما يمثل قيدا خطيرا.

في الواقع ، إذا كان الأداء جيدا بما فيه الكفاية ، فقد يكون من السهل نسبيا أداء قابلية الخدمة للجزء "غير EVM" من العميل. لست متأكدا مما إذا كان جيدا بما فيه الكفاية ، لكنني أقل ثقة في هذا الجزء للأسباب التالية:

• يمكن بالفعل تسريع "حساب شجرة الحالة" بشكل كبير من خلال التجميع المسبق الودي مثل Poseidon.

• ومع ذلك ، ليس من الواضح ما إذا كان يمكن التعامل مع "إلغاء السلسلة" بطريقة أنيقة وقابلة للصيانة.
  

• بالإضافة إلى ذلك ، هناك بعض التفاصيل الصعبة (مثل قياس الغاز والفحوصات المختلفة) التي قد تندرج تحت "وقت تقييم الكتلة" ولكن يجب تصنيفها في الواقع على أنها أجزاء "غير EVM" ، والتي تميل إلى أن تكون أكثر عرضة لضغط الصيانة.

ثانيا ، الجزء المتعلق بقابلية التوسع.

أحتاج إلى التأكيد على أنه من المستحيل على RISC-V التعامل مع أحمال EVM دون استخدام التجميع المسبق ، بالتأكيد لا.

لذا ، فإن البيان الوارد في النص الأصلي بأن "وقت الإثبات النهائي ستهيمن عليه عملية التحويل المسبق الحالية" صحيح من الناحية الفنية ، لكنه مفرط في التفاؤل - فهو يفترض أنه لن يكون هناك تجميع مسبق في المستقبل ، في حين أن التجميع المسبق في الواقع (في هذا السيناريو المستقبلي) سيظل موجودا ، وهو بالضبط نفس رموز التشغيل المكثفة حسابيا في EVM (مثل التوقيعات والتجزئة وربما نظائرها الكبيرة).

من الصعب الحكم على مثال فيبوناتشي دون الخوض في التفاصيل الأكثر دقة ، لكن المزايا تأتي جزئيا على الأقل:

• الفرق بين التفسير والتنفيذ النفقات العامة.

• الفك الدوري (تقليل "تدفق التحكم" ل RISC-V ، من غير المؤكد ما إذا كان يمكن تنفيذ Solidity ، ولكن حتى رمز تشغيل واحد لا يزال بإمكانه إنشاء عدد كبير من الوصول إلى تدفق التحكم / الذاكرة بسبب النفقات العامة للتفسير) ؛

• استخدام أنواع بيانات أصغر.

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

هنا تأتي المشكلة

، لذلك ، هناك بعض المشاكل هنا.

• لتحسين قابلية الصيانة ، تحتاج إلى RISC-V (مع التجميع المسبق) الذي يقوم بتجميع EVM - هذا كل شيء إلى حد كبير.

• لتحسين قابلية التوسع ، هناك حاجة إلى شيء مختلف تماما - بنية جديدة قد تكون مشابهة ل RISC-V تفهم مفهوم "العقود" ، ومتوافقة مع قيود وقت تشغيل Ethereum ، ويمكنها تنفيذ رمز العقد مباشرة (بدون "النفقات العامة للتفسير").

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

كبديل ،

يمكننا تجميع الرمز الثانوي من رمز تشغيل EVM عالي المستوى. المترجم مسؤول عن ضمان بقاء المنشئ ثابتا ، مثل عدم مواجهة "تجاوز سعة المكدس". أود أن أرى هذا يظهر في EVM عادي. يمكن تزويد SNARKs المجمعة بشكل صحيح بتعليمات نشر العقد.

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

بالطبع ، الخيار الأسهل هو عض الرصاصة والقيام ......

بناء الحد الأدنى من MMU "المتسلسل"

، والذي قد تعبر عنه ضمنيا في المقالة ، ولكن اسمحوا لي أن أحذر من أنه إذا كنت ترغب في التخلص من النفقات العامة للمحاكاة الافتراضية ، فيجب عليك تنفيذ الكود المترجم مباشرة - مما يعني أنك بحاجة إلى منع العقد (القابل للتنفيذ الآن) بطريقة ما من الكتابة إلى ذاكرة kernel (وليس تنفيذ EVM).

لذلك ، نحتاج إلى نوع من "وحدة إدارة الذاكرة" (MMU). قد لا تكون آلية الترحيل لأجهزة الكمبيوتر التقليدية ضرورية لأن مساحة الذاكرة "المادية" لا نهائية تقريبا. يجب أن تكون MMU هذه هزيلة قدر الإمكان (لأنها في نفس مستوى التجريد مثل الهندسة المعمارية نفسها) ، ولكن يمكن نقل بعض الميزات مثل ذرية المعاملات إلى هذه الطبقة.

في هذه المرحلة ، يصبح EVM الذي يمكن إثباته هو برنامج kernel الذي يعمل على هذه البنية.

المثير للاهتمام ، في كل هذه الظروف ، أن أفضل "بنية مجموعة التعليمات" (ISA) لهذه المهمة قد لا تكون RISC-V ، ولكنها شيء مشابه ل EOF-EVM للأسباب التالية:

• تؤدي رموز التشغيل "الصغيرة" في الواقع إلى الكثير من الوصول إلى الذاكرة ، وهو أمر يصعب على طرق التصديق الحالية التعامل معه بكفاءة.

• لتقليل النفقات العامة المتفرعة ، أظهرنا كيفية إثبات كود "القفزات الثابتة" (EOF) مع الأداء على مستوى الترجمة البرمجية المسبقة في ورقتنا البحثية الأخيرة ، Morgana.

اقتراحي هو بناء بنية جديدة صديقة للإثبات مع الحد الأدنى من MMU التي تسمح للعقد بالعمل كملف تنفيذي منفصل. لا أعتقد أنه من المفترض أن يكون RISC-V ، بل ISA جديد محسن لقيود بروتوكول SNARK ، وحتى ISA الذي يرث جزئيا مجموعة فرعية من رموز تشغيل EVM قد يكون أفضل - كما نعلم ، فإن التجميع المسبق موجود ليبقى ، سواء أحببنا ذلك أم لا ، لذلك لا يجلب RISC-V أي تبسيط هنا.