في الأسبوع القليلة الماضية ، لم أشارك العديد من التحديثات حول @ethrex_client ، عميل تنفيذ @class_lambda @ethereum L1 ومكدس ZK L2. يرجى اتباع @ethrex_client لمعرفة المزيد حول كل ما نقوم به. في L1 ، نقوم بالفعل بتشغيل شبكات اختبار Ethereum بنجاح وفي L2 نقوم بتشغيل شبكات اختبار للهوية وتطبيقات DeFi التي نبنيها من أجل الشركاء ومع الشركاء. أعتقد بصدق أننا على وشك الحصول على أبسط قاعدة بيانات ومكدس للحفاظ على Ethereum وترقيتها وتعديلها. لم نكن لنتمكن من الوصول إلى هذه النقطة دون التحقق من رمز @NethermindEth و @go_ethereum مع شركائي @rj_aligned ، @fran_aligned من @alignedlayer و @SantiDiPaolo ، @AguuMg من @PolFinance_ ، نحن على وشك إصدار واحدة من أولى الأوراق البيضاء حول RWA L2s التي سيتم تشغيلها بواسطة Ethrex و @alignedlayer. لقد حصلنا على الكثير القادم ولكني متحمس بشكل خاص لهذا لأنه سيربط بين حالة استخدام مثيرة للاهتمام للغاية من TradFi و DeFi. لقد حصلنا كمستشارين وشركاء على بعض أقوى الفرق في الصناعة. أنا حريص على مشاركة المزيد عن هذا المشروع. مستجدات L1 لقد عملنا على العديد من الجبهات. لقد قمنا بتحسين إمكانية الملاحظة باستخدام Grafana ، وإزالة الميزات غير المستخدمة لتبسيط قاعدة التعليمات البرمجية وأضفنا دعما لنقطة النهاية "engine_getBlobsV1". سجل التغيير: feat(l1): نقطة نهاية طلب 'engine_getBlobsV1' (#3636) الأعمال الروتينية (L1): إزالة دعم REDB (# 4103) إعادة بناء الهيكل (L1): إزالة الاستخدامات غير الضرورية من صندوق blockchain (# 4110) Fix(L1): تمت إزالة استنساخ الحالة غير الضروري (#4117) Fix(L1): استخدم صورة Docker المناسبة لتدوير الشبكات المحلية. (#4131) الأعمال الروتينية (L1): إضافة وقت الحظر إلى لوحة معلومات Grafana. (#4112) fix(l1): طرح أوقات قراءة قاعدة البيانات من تنفيذ الكتلة. (#4051) الروتين (L1): تحسينات مترية. (#4118) الأعمال الروتينية (LEVM): تحسين تنظيم عداء اختبار LEVM الجديد (# 3958) L2 تماشيا مع نهجنا البسيط ، قمنا بإزالة قدر كبير من التعليمات البرمجية من قواعد بيانات L2 غير المستخدمة. نواصل تبسيط قاعدة التعليمات البرمجية وإزالة التعليمات البرمجية الميتة. بالإضافة إلى ذلك ، استقر CI بعد إصلاح خطأ متعلق بأسعار الغاز. نحن نقيم L2 على جبهتين: - تكلفة صيانة شبكة L2: نقوم بضبط معلمات L2 من خلال محاكاة سيناريوهات مختلفة مع أحمال عمل مختلفة للمعاملات وتكوينات الشبكة. الهدف هو تحديد التكلفة التقريبية لعمولة الصيانة لكل معاملة يجب على المستخدمين تحملها حتى تحقق الشبكة الاستدامة الذاتية. - إثبات الكتلة المعزول لمعايير إنشاء التنفيذ: باستخدام أداة إعادة تشغيل ethrex ، نثبت الكتل من Hoodi و Sepolia و Mainnet لتحديد الأخطاء المحتملة في قاعدة التعليمات البرمجية وقياس أداء prover لدينا. على جانب إعادة تشغيل العرق ، الأداة مستقرة بدرجة كافية ، ولدينا بنية تحتية تم إعدادها لإعادة تشغيل عمليات تنفيذ الكتل والبراهين للشبكات العامة بشكل دوري. نحن الآن نعالج الأخطاء التي ظهرت خلال هذه الجولات. تنبع بعض الأخطاء من أخطاء منطقية في ethrex ، بينما يرتبط البعض الآخر باستخدام الذاكرة. وقد تم حل الأولى في معظمها، ونحن نحرز تقدما كبيرا في الثانية. لقد بدأنا أيضا في النظر في @ziskvm و @0xLita ZKVMs للتكامل المحتمل على المدى القصير. نحن ندعم بالفعل @RiscZero و @SuccinctLabs. هذا الأسبوع ، قمنا بدمج العلاقات العامة التي تعمل على استقرار إعادة تشغيل ethrex ، مما يمكننا من تحديد وحل اثنين من الأخطاء في ethrex. كما تم دمج هذه الإصلاحات. تضمن الخطأ الأول حالة حافة في الترجمة المسبقة ecrecover ، حيث تسبب إدخال معين في فشل التنفيذ بسبب عدم تطابق الغاز. بعد تحقيق شامل ، تتبعنا المشكلة إلى مكتبة secp256k1 الرسمية المصححة ب SP1. قمنا بحلها عن طريق الترحيل إلى مكتبة k256 المصححة SP1. نشأ الخطأ الثاني من افتراض غير صحيح حول طول بت نوع usize في جزء من قاعدة التعليمات البرمجية. لمنع حدوث مشكلات مماثلة، أجرينا مراجعة شاملة لقاعدة التعليمات البرمجية وقدمنا العديد من العلاقات العامة لتقييد استخدام usize بحالتين محددتين: الفهرسة والسيناريوهات المقيدة بواجهة برمجة التطبيقات أو المكتبة. بالإضافة إلى ذلك، نضيف دعما لتشغيل مجموعات اختبار EF، بما في ذلك اختبارات blockchain والحالة، مع SP1 لتعزيز تغطية الاختبار لدينا وضمان المتانة عبر سيناريوهات التنفيذ المختلفة. مع معالجة هذه الأخطاء ، لم تعد المشكلات تحدث. نحن نعيد بنجاح تشغيل كتل Hoodi و Sepolia الجديدة ، وتحسنت عمليات تنفيذ كتل Mainnet بشكل كبير ، مع ارتفاع معدل نجاح تنفيذ SP1 من 1/10 إلى 6/10. يمهد هذا التقدم الطريق لمعالجة التحديات المتبقية مع إعادات الكتلة الأخيرة: أخطاء نفاد الذاكرة أثناء تنفيذ الكتلة في SP1 zkVM ومشكلات الأداء في التنفيذ والإثبات. لمعالجة هذه ، قمنا بإعداد صندوق الأداة لتنميط الذاكرة باستخدام صندوق Jemalloc. نحن نعمل أيضا على دعم إعادة تشغيل الكتل التاريخية. يوجد MVP لهذه الميزة في مسودة العلاقات العامة ويعمل بشكل جيد مع عملاء ethrex و reth و geth ولكنه يواجه مشكلات مع عملاء nethermind. قبل إصدار الإصدار الأول، نهدف إلى تحسين طلبات RPC لضمان تنزيلات بيانات الكتلة بدقة، حتى عند استخدام موفري RPC المجانيين، لغالبية الكتل. تحسينات DevEx: - لقد أصلحنا تصميماتنا الثنائية لعدم الحاجة إلى CUDA كتبعية افتراضية على أنظمة تشغيل وبنى معينة. يتم تضمين هذا الإصلاح في الإصدار الأخير. - تم تقديم PR لتحديث إصدار ethrex في rex ، مما يضمن التوافق مع أحدث التغييرات في ethrex L2. - لقد بدأنا في تطوير علامة تبويب جديدة لشاشة ethrex L2 في بيئات التطوير. ستعرض علامة التبويب هذه المعلومات ذات الصلة بالمطور، مثل قائمة الحسابات المنسقة وعناوين عقود L1 وL2. سجل التغيير: - إعادة التأهيل (L2): استبدال ثوابت فرق حالة USIZE. - Reature(L1,L2): تم تكوين EthreX-Replay لتنميط الذاكرة. - إعادة الهيكلة (L1): تمت إزالة استخدام USIZE غير الضروري في صندوق blockchain (المتعلق بإصلاح الخطأ). - feature(L1,L2): تمت إضافة أوامر جديدة إلى شاهد التنفيذ. - Fix(LEVM): معالجة المشكلات المتعلقة ببنية 32 بت (المتعلقة بإصلاح الخطأ). - إعادة الهيكل (LEVM): تم تحديث تنفيذ ecRecover لاستخدام K256 بدلا من secp256K1 (يتعلق بإصلاح الخطأ). - CI (L1 ، L2): تصميمات GPU المنفصلة واعتمدت هدف x86-64-v2. اداء واصلنا هذا الأسبوع تركيزنا على استهلاك وحدة المعالجة المركزية والمعايير. فيما يتعلق باستهلاك وحدة المعالجة المركزية ، حددنا حالتين مختلفتين ، واحدة حيث يوجد بناء الكتل والأخرى حيث لا يكون موجودا. نحن نعطي الأولوية لتلك التي لا تحتوي على بناء كتلة نظرا لأنها موجودة دائما وتؤثر على الجهود الأخرى (مثل المزامنة المفاجئة). بقدر ما حققنا في الأمر يتعلق تماما ب p2p. وسنواصل جهودنا على هذه الجبهة فيما يتعلق بالمعايير ، بعد تحسيننا الأسبوع الماضي لأداء modexp ، ركزنا على بعض التحسينات المكتشفة ، مثل نسخ التعليمات البرمجية والعمليات ذات الصلة بالإضافة إلى signextend و mulmod و addmod. سنواصل تركيزنا على كل من استهلاك وحدة المعالجة المركزية وأداء الاختبار الذي حددناه كخطوات تالية للتحسينات المحتملة، مثل عمليات نقل eth ورموز تشغيل levm الأخرى.