في 20 أبريل، قدم فيتاليك بوترين اقتراحًا مهمًا حول طبقة التنفيذ L1 طويلة الأجل لإيثيريوم على منصة Ethereum Magicians. اقترح اعتماد بنية RISC-V كبديل للآلة الافتراضية الحالية (EVM) كلغة آلة افتراضية لكتابة العقود الذكية، بهدف تحسين كفاءة تشغيل طبقة التنفيذ في إيثيريوم بشكل جذري، وكسر أحد أبرز اختناقات التوسع الحالية، بينما يبسط بشكل كبير من بساطة طبقة التنفيذ.
قامت Foresight News بترجمة الاقتراح بالكامل، بهدف مساعدة القراء على فهم هذا التصور التكنولوجي. فيما يلي محتوى الترجمة للنص الأصلي للاقتراح:
تقدم هذه المقالة فكرة جذرية حول مستقبل طبقة التنفيذ في إيثيريوم، حيث أن طموحها لا يقل عن خطة Beam Chain الخاصة بطبقة الإجماع. يهدف هذا الاقتراح إلى زيادة كفاءة طبقة التنفيذ في إيثيريوم بشكل كبير، ومعالجة واحدة من أهم اختناقات التوسع، وتبسيط طبقة التنفيذ بشكل ملحوظ - في الواقع، قد تكون هذه هي الطريقة الوحيدة لتحقيق هذا الهدف.
الفكرة الأساسية: استبدال 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 يمكن أن يحل الز bottlenecks الرئيسية في (2) و (3).
يوضح الجدول أدناه عدد الدورات المطلوبة لكل مرحلة من مراحل تنفيذ EVM في Succinct ZK-EVM.
شرح الرسم البياني: أربع مراحل رئيسية تستغرق وقتًا هي deserialize_inputs و initialize_witness_db و state_root_computation و block_execution
حيث ترتبط initialize_witness_db و state_root_computation بشجرة الحالة ، ويتضمن إلغاء التسلسل \ _inputs عملية تحويل بيانات الكتلة والشاهد إلى تمثيلات داخلية - أكثر من 50٪ منها يتناسب فعليا مع حجم بيانات الشهود.
من خلال استبدال شجرة Merkle Patricia 16-ary الحالية باستخدام شجرة ثنائية تستخدم دوال هاش سهلة الإثبات، يمكن تحسين هذه الأجزاء بشكل كبير. إذا استخدمنا Poseidon، يمكننا إثبات 2 مليون قيمة هاش في الثانية على اللابتوب (بينما keccak حوالي 15,000 hash/sec). بالإضافة إلى Poseidon، هناك العديد من الخيارات الأخرى. بشكل عام، هناك مساحة كبيرة لتحسين هذه المكونات. علاوة على ذلك، يمكننا القضاء على accrue_logs_bloom من خلال إزالة bloom.
تُشكل block_execution المتبقية حوالي نصف دورة الإثبات الحالية (دورات المُثبت). لتحقيق زيادة بمقدار 100 مرة في كفاءة الإثبات الإجمالية، يجب أن ترتفع كفاءة إثبات EVM بمقدار 50 مرة على الأقل. أحد الحلول هو إنشاء تنفيذ إثبات أكثر كفاءة لـ EVM، بينما الحل الآخر هو ملاحظة أن مُثبت ZK-EVM الحالي يقوم فعليًا بالإثبات من خلال تحويل EVM إلى RISC-V، مما يسمح مباشرة لمطوري العقود الذكية بالوصول إلى تلك الآلة الافتراضية RISC-V.
تشير بعض البيانات إلى أن تحسين الكفاءة قد يتجاوز 100 مرة في ظروف معينة:
في التطبيقات العملية، قد يتم احتلال الوقت المتبقي للـ prover بشكل رئيسي من قبل عمليات الـ precompiles الحالية. إذا تم استخدام RISC-V كآلة افتراضية رئيسية، فإن جدول Gas سيعكس الوقت الفعلي للإثبات، وسيؤدي الضغط الاقتصادي إلى دفع المطورين لتقليل استخدام الـ precompiles ذات التكلفة العالية. حتى مع ذلك، لن تكون المكاسب ملحوظة بشكل كبير، لكن لدينا أسباب كافية للاعتقاد بأن هذه المكاسب ستكون كبيرة جداً.
(من الجدير بالذكر أن نسبة الوقت المستغرق في "عمليات EVM" و "عمليات أخرى" في تنفيذ EVM العادي تقترب أيضًا من 50/50، لذلك نعتقد بشكل بديهي أن إزالة 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. ستكون EVM هي المثال الأول، وفي المستقبل يمكن دعم لغات أخرى (قد تكون Move خياراً مرشحاً).
الميزة الأساسية للخيارين الثاني والثالث هي أنهما يبسطان إلى حد كبير مواصفات طبقة التنفيذ. نظرا لصعوبة إزالة التبسيط التدريجي مثل التدمير الذاتي ، قد يكون هذا الخط من التفكير هو المسار الوحيد القابل للتطبيق للتبسيط. تلتزم Tinygrad بالقاعدة الصارمة والسريعة المتمثلة في "ما لا يزيد عن 10000 سطر من التعليمات البرمجية" ، ويجب أن تكون blockchain الأساسية المثلى قادرة على تلبية هذا الحد بسهولة وزيادة تبسيطها. تعد مبادرة Beam Chain بتبسيط طبقة إجماع Ethereum بشكل كبير ، وقد يكون هذا التغيير الجذري هو الطريقة الوحيدة لتحقيق دفعة مماثلة في طبقة التنفيذ.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
النص الكامل للاقتراح طويل الأمد من فيتاليك لطبقة التنفيذ L1: استبدال EVM بـ RISC-V
المصدر: فيتاليك بوتيرين
ترجمة: كارين زد، أخبار فورسايت
في 20 أبريل، قدم فيتاليك بوترين اقتراحًا مهمًا حول طبقة التنفيذ L1 طويلة الأجل لإيثيريوم على منصة Ethereum Magicians. اقترح اعتماد بنية RISC-V كبديل للآلة الافتراضية الحالية (EVM) كلغة آلة افتراضية لكتابة العقود الذكية، بهدف تحسين كفاءة تشغيل طبقة التنفيذ في إيثيريوم بشكل جذري، وكسر أحد أبرز اختناقات التوسع الحالية، بينما يبسط بشكل كبير من بساطة طبقة التنفيذ.
قامت Foresight News بترجمة الاقتراح بالكامل، بهدف مساعدة القراء على فهم هذا التصور التكنولوجي. فيما يلي محتوى الترجمة للنص الأصلي للاقتراح:
تقدم هذه المقالة فكرة جذرية حول مستقبل طبقة التنفيذ في إيثيريوم، حيث أن طموحها لا يقل عن خطة Beam Chain الخاصة بطبقة الإجماع. يهدف هذا الاقتراح إلى زيادة كفاءة طبقة التنفيذ في إيثيريوم بشكل كبير، ومعالجة واحدة من أهم اختناقات التوسع، وتبسيط طبقة التنفيذ بشكل ملحوظ - في الواقع، قد تكون هذه هي الطريقة الوحيدة لتحقيق هذا الهدف.
الفكرة الأساسية: استبدال 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 يمكن أن يحل الز bottlenecks الرئيسية في (2) و (3).
يوضح الجدول أدناه عدد الدورات المطلوبة لكل مرحلة من مراحل تنفيذ EVM في Succinct ZK-EVM.
شرح الرسم البياني: أربع مراحل رئيسية تستغرق وقتًا هي deserialize_inputs و initialize_witness_db و state_root_computation و block_execution
حيث ترتبط initialize_witness_db و state_root_computation بشجرة الحالة ، ويتضمن إلغاء التسلسل \ _inputs عملية تحويل بيانات الكتلة والشاهد إلى تمثيلات داخلية - أكثر من 50٪ منها يتناسب فعليا مع حجم بيانات الشهود.
من خلال استبدال شجرة Merkle Patricia 16-ary الحالية باستخدام شجرة ثنائية تستخدم دوال هاش سهلة الإثبات، يمكن تحسين هذه الأجزاء بشكل كبير. إذا استخدمنا Poseidon، يمكننا إثبات 2 مليون قيمة هاش في الثانية على اللابتوب (بينما keccak حوالي 15,000 hash/sec). بالإضافة إلى Poseidon، هناك العديد من الخيارات الأخرى. بشكل عام، هناك مساحة كبيرة لتحسين هذه المكونات. علاوة على ذلك، يمكننا القضاء على accrue_logs_bloom من خلال إزالة bloom.
تُشكل block_execution المتبقية حوالي نصف دورة الإثبات الحالية (دورات المُثبت). لتحقيق زيادة بمقدار 100 مرة في كفاءة الإثبات الإجمالية، يجب أن ترتفع كفاءة إثبات EVM بمقدار 50 مرة على الأقل. أحد الحلول هو إنشاء تنفيذ إثبات أكثر كفاءة لـ EVM، بينما الحل الآخر هو ملاحظة أن مُثبت ZK-EVM الحالي يقوم فعليًا بالإثبات من خلال تحويل EVM إلى RISC-V، مما يسمح مباشرة لمطوري العقود الذكية بالوصول إلى تلك الآلة الافتراضية RISC-V.
تشير بعض البيانات إلى أن تحسين الكفاءة قد يتجاوز 100 مرة في ظروف معينة:
في التطبيقات العملية، قد يتم احتلال الوقت المتبقي للـ prover بشكل رئيسي من قبل عمليات الـ precompiles الحالية. إذا تم استخدام RISC-V كآلة افتراضية رئيسية، فإن جدول Gas سيعكس الوقت الفعلي للإثبات، وسيؤدي الضغط الاقتصادي إلى دفع المطورين لتقليل استخدام الـ precompiles ذات التكلفة العالية. حتى مع ذلك، لن تكون المكاسب ملحوظة بشكل كبير، لكن لدينا أسباب كافية للاعتقاد بأن هذه المكاسب ستكون كبيرة جداً.
(من الجدير بالذكر أن نسبة الوقت المستغرق في "عمليات EVM" و "عمليات أخرى" في تنفيذ EVM العادي تقترب أيضًا من 50/50، لذلك نعتقد بشكل بديهي أن إزالة 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. ستكون EVM هي المثال الأول، وفي المستقبل يمكن دعم لغات أخرى (قد تكون Move خياراً مرشحاً).
الميزة الأساسية للخيارين الثاني والثالث هي أنهما يبسطان إلى حد كبير مواصفات طبقة التنفيذ. نظرا لصعوبة إزالة التبسيط التدريجي مثل التدمير الذاتي ، قد يكون هذا الخط من التفكير هو المسار الوحيد القابل للتطبيق للتبسيط. تلتزم Tinygrad بالقاعدة الصارمة والسريعة المتمثلة في "ما لا يزيد عن 10000 سطر من التعليمات البرمجية" ، ويجب أن تكون blockchain الأساسية المثلى قادرة على تلبية هذا الحد بسهولة وزيادة تبسيطها. تعد مبادرة Beam Chain بتبسيط طبقة إجماع Ethereum بشكل كبير ، وقد يكون هذا التغيير الجذري هو الطريقة الوحيدة لتحقيق دفعة مماثلة في طبقة التنفيذ.