المؤلف: دراغان راكيتا، الترجمة النموذجية: شان أوبا، Golden Finance
EOF (تنسيق كائن EVM)
EOF (تنسيق كائن EVM) عبارة عن مجموعة من EIPs الصغيرة المصممة لتحسين EVM. يقدم تنسيقًا جديدًا للرمز الثانوي الذي يعد EVM للمستقبل.
مزايا EOF
من الصعب شرح قيمة EOF لأنها ليست شيء واحد، ويصبح التفسير أكثر تعقيدًا بسبب التأخيرات المتعددة في الشوكات وتطور الإصدارات المختلفة على مدار سنوات عديدة من التطوير والبحث.
الغرض من هذا المقال هو تلخيص هذه المزايا وشرحها في جملة واحدة:
المزايا:< /h3>يسمح EOF بتغييرات أسعار الغاز لأكواد التشغيل< /p>
إزالة إمكانية ملاحظة الغاز
< ul class= " list-paddingleft-2">يعني هذا إزالة كود تشغيل GAS وقيود الغاز في CALL/DELEGATECALL/STATICCALL.
يسمح للـ L2 بتغيير الغاز بناءً على حالة استخدامه
< /li> تقليل حجم الرمز الثانوي واستخدام الغاز
li>< ul class=" list-paddingleft-2">تظهر البيانات المبكرة انخفاضًا في حجم الكود/رمز التهيئة واستخدام الغاز:
< /li>< li>يؤدي نشر Uniswap-v3 إلى تقليل رمز التهيئة ورمز النشر بنسبة 6.5%.
يستخدم نشر UniswapV3Factory غازًا أقل بنسبة 14% تقريبًا، كما يستخدم استدعاء runTest غازًا أقل بنسبة 9% تقريبًا.
يقلل نشر ENS DNSRegistrar حوالي 6% من رمز التهيئة وحوالي 1.5% من رمز النشر.
ENS يستدعي proAndClaim: يستخدم غازًا أقل بنسبة 10% تقريبًا.
يسمح بتحويل الرمز الثانوي وقابلية الترقية
li>تعني إزالة إمكانية ملاحظة التعليمات البرمجية إزالة أكواد تشغيل الكمبيوتر الشخصي وCREATE/CREATE2 وEXTCODEHASH وEXTCODESIZE وEXTCODECOPY وCODESIZE وCODECOPY.
إذا تم تغيير الكود، فلن يتم تشغيل العقود التقليدية.
سيسمح لنا هذا بإجراء أي تعديلات على كود EOF الثانوي عند تقديم verkle في المستقبل.
يتيح EOF القيمة الفورية لكود التشغيل
< ul class=" list-paddingleft-2">تفعيل إمكانية أكواد التشغيل SWAPN وDUPN وEXCHANGE.
يوفر هذا لـ Solidity مزيدًا من الحرية في حجم المكدس ويحل مشكلة عمق المكدس المفرط في Solidity.
إزالة تحليل هدف القفز المكلف
في Reth، يتم حفظ نتائج التحليل باستخدام الرمز الثانوي، ولكن هذا يختلف بالنسبة للعملاء الآخرين. تؤدي إزالة تحليل هدف القفز قبل تنفيذ العقد إلى تحسين السرعة.
مع إزالة التحليل، يمكننا زيادة الحد الأقصى لحجم الرمز الثانوي في المستقبل.
أصبح التحليل الثابت أسهل
< ul class =" list-paddingleft-2">تفرض الإجراءات الفرعية تدفق تحكم أكثر تنظيمًا، مما يجعل اختبار الضبابية أكثر كفاءة ويتيح التحليل الثابت للوقت الخطي.
يتم فصل البيانات والرموز، مما يجعل التفكير أسهل.
يمكن تجميع كود EOF الثانوي في كود بايت أسرع p>
EVM مقاوم للمستقبل
امتداد مساحة العنوان
التكامل مع EVM الحالي
هناك مشكلة مهمة للمطورين وهي الجهد المطلوب لتنفيذ التغييرات، وتكلفة الاختبار، وتكلفة صيانة أكواد التشغيل هذه.
لن تتعارض أكواد التشغيل الجديدة مع أكواد التشغيل التقليدية، ولن يمس التحقق من EOF أكواد التشغيل المهملة.
يمكن تشويش تشفير وفك تشفير EOF. يعد التحقق من الصحة أمرًا جديدًا ويتكون من حوالي 500 سطر من التعليمات البرمجية في Revm، ولكن هناك الكثير من حالات الحافة التي يجب تغطيتها والتركيز على الحصول عليها بشكل صحيح في التطبيقات الفردية.
قم بإنشاء معاملة لاستخدامها كحامل لرمز EOF الثانوي، على غرار EOFCREATE ولكنها تتطلب التحقق قبل التنفيذ.
معظم رموز التشغيل بسيطة جدًا:
مكالمة خارجية (0xf8)، مكالمة EXTDELEGATECALL (0xf9)، مكالمة EXTSTATICCALL (0xfb)
له نفس مخطط الاستدعاء المهمل، ولكنه يزيل حقول إخراج الحد من الغاز والذاكرة.
قبل تقديم RETURNDATALOAD (في مفترق مبكر جدًا)، كان لا بد من تنفيذ إخراج الذاكرة لكود تشغيل CALL قبل عملية الاتصال يتم ضبطها قبل الرمز. هذا لا يسمح بالإخراج الديناميكي.
إنشاء EOFC وعقد الإرجاع
تبادل (0xe8)، SWAPN (0xe7)، DUPN (0xe6)، نسخ البيانات (0xd3) ، DATASIZE (0xd2)، DATALOADN (0xd1)، DATALOAD (0xd0)، RJUMP (0xe0)، RJUMPI (0xe1)، RJUMPV (0xe2)، RETURNDATALOAD
CALLF (0xe3) وRETF (0xe4) وJUMPF (0xe5)
يتطلب طفلًا يتطلب تعقيد مكدس البرنامج والتحقق من المكدس حوالي 20-30 سطرًا من التعليمات البرمجية.
يستغرق الأمر من المطور حوالي 2-3 أشهر. بدأت أعمال الاختبار. يوجد حاليًا ما يقرب من 2000 اختبار تحقق مكتوب بخط اليد، كما أن أعمال اختبار الحالة جارية أيضًا.
تتركز التغييرات في EVM، لذا فإن التكامل مع بقية العميل يعتمد على بنية الجهاز العميل وكيفية حفظه موقع الرمز الثانوي.
يحتاج EXTCODESIZE وEXTCODEHASH إلى معرفة ما إذا كان الحساب هو EOF وإرجاع قيمة محددة مسبقًا (الحجم والتجزئة 0xEF00)، مما قد يغير طريقة تكامل العميل قليلاً. تتمثل إحدى الأفكار في حفظ علامة is_eof في جدول حساب عادي لتخطي تحميل الرمز الثانوي عند استدعاء أي كود تشغيل من النوع EXTCODE.
التأثير على L2
السؤال الكبير هو لماذا لا ينفذ L2 هذه التغييرات؟ هل يجب أن نوقف تحسينات EVM على Ethereum L1؟
الحقيقة هي أن L2 ليست جاهزة بعد، وليس ذلك فحسب، ليس لديهم منصة للمساعدة في دمج هذه الابتكارات. تساعد إصدارات Bytecode في بناء منصة يمكن أن يستخدمها L2، وتساعد إزالة إمكانية ملاحظة التعليمات البرمجية على تخفيف مشكلات قابلية الترقية، وتساعد تغييرات الغاز ZK L2 على التخلص من ناقلات DDoS للقنابل الغازية (على سبيل المثال، التجزئة في zk ذات قيمة باهظة الثمن للغاية).
الأهم من ذلك، أن EOF ليس مجرد تنسيق، بل يتطلب أيضًا دعم اللغة (Solidity/Vyper/Huff) ويمكن استخدام دعم سلسلة الأدوات. فهو يتطلب نظامًا بيئيًا لاستخدامه، وهذا التنسيق يمنح L2 مزيدًا من الاستقرار للابتكار فوقه.
العيوب: لا يزال الرمز الثانوي التقليدي موجودًا
هذه مشكلة شائعة. الكود الثانوي التقليدي موجود ليبقى، وإذا لم نقدم بديلاً، فسنواجه مشكلة. يتيح لنا وجود تنسيقات بديلة للرمز الثانوي نقل الرمز الثانوي القديم وإزالته في المستقبل عند انتهاء صلاحية الحالة.
الملخص
EOF ليس الشيء اللامع التالي، بل هو إصلاح للإرث من الإصدار الأولي EVM مشاكل في صيانة EIP، ولا توجد طريقة أخرى لإصلاحها سوى تدميرها. إنه ضروري لمزيد من التطوير والتدقيق المستقبلي لـ EVM. ص>