بدأنا في بناء ريث في عام 2022 لتوفير المرونة لـ Ethereum L1، وحل مشكلة توسيع طبقة التنفيذ على الطبقة 2.

اليوم نحن متحمسون لمشاركة طريقة Reth نحو 1 جيجا غاز في L2 في عام 2024، وخريطة الطريق الطويلة الأجل لدينا للذهاب إلى ما هو أبعد من ذلك.

ندعو النظام البيئي للتعاون معنا بينما ندفع حدود الأداء والمقاييس الصارمة في عالم العملات المشفرة.

هل تم توسيعنا بعد؟

هناك مسار بسيط جدًا للعملات المشفرة للوصول إلى نطاق عالمي والهروب من المضاربة كحالة استخدام سائدة: يجب أن تكون التحويلات رخيصة وسريعة.

كيف تقيس الأداء؟ ماذا يعني الغاز في الثانية؟

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

التوحيد حول الغاز في الثانية كمقياس أداء يسمح بفهم أوضح لقدرة البلوكشين وكفاءته. كما أنه يساعد في تقييم الآثار التكلفة على النظام، مما يحمي ضد هجمات إنكار الخدمة المحتملة التي يمكن أن تستغل قياسات أقل دقة. يساعد هذا المقياس في مقارنة الأداء عبر سلاسل إيثيريوم الافتراضية المتوافقة مختلفة.

نقترح على مجتمع EVM اعتماد الغاز في الثانية كمقياس قياسي، إلى جانب الاستيعابأبعاد أخرى لتسعير الغازلإنشاء معيار أداء شامل.

أين نحن اليوم؟

يتم تحديد الغاز في الثانية عن طريق قسمة استخدام الغاز المستهدف لكل كتلة عن طريق وقت الكتلة. هنا، نعرض الغاز الحالي في الثانية والكفاءة عبر سلاسل EVM L1s و L2s المختلفة (غير شاملة):

نحن نؤكد على الغاز في الثانية لتقييم أداء شبكة EVM بشكل شامل، ملتقطين كل من تكاليف الحساب والتخزين. الشبكات مثل سولانا، سوي، أو أبتوس لا تدخل في الاعتبار بسبب نماذج تكاليفها المتميزة. نشجع الجهود نحو توحيد نماذج التكاليف عبر جميع شبكات البلوكشين لتمكين المقارنات الشاملة والعادلة.

نحن نعمل على مجموعة متكاملة مستمرة لقياس الأداء لـ Reth تقليد العبء العمل الحقيقي، إذا كنت ترغب في التعاون في هذا، يرجى التواصل. نحن بحاجة إلى مؤشر TPCللعقد.

كيف سيصل ريث إلى 1 جيجاغا غاز في الثانية؟ وما بعد ذلك؟

كنا محفزين جزئياً لبناء Reth في عام 2022 بحاجة ملحة لامتلاك غاز مصمم لأغراض العميل للمتداولات على نطاق الويب. نعتقد أن لدينا مساراً واعداً للمستقبل.

يحقق Reth بالفعل 100-200 مليون غاز / ثانية خلال المزامنة الحية (بما في ذلك استعادة المرسلين، تنفيذ المعاملات، وحساب الشجرة في كل كتلة); 10 مرات من هنا يحصل علينا لهدفنا القصير المدى من 1 جيجا غاز / ثانية.

بينما نقوم بتطوير Reth، يجب على خطتنا للتوسيع تحقيق توازن بين القابلية للتطوير والكفاءة:

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

التحسينات التي نستكشفها هنا لا تتضمن حل نمو الدولة, الذي نبحث فيه بشكل منفصل.

ها هي ملخص لكيف نعتزم الوصول إلى هناك:

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

خريطة طريق تحسين القدرة العمودية لـ ريث

هدفنا هنا هو تحقيق أقصى أداء وكفاءة لخادم واحد أو كمبيوتر محمول يعمل بنظام Reth.

EVM في الوقت المناسب وقبل الوقت

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

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

ومع ذلك، يمكن أن يكون JIT عرضة للشفرة الخبيثة المصممة لاستغلال عملية JIT، أو قد تكون بطيئة جدًا لتشغيل العمليات الحية أثناء التنفيذ. سيقوم Reth بتجميع Ahead-of-Time (AOT) للعقود ذات الطلب العالي وتخزينها على القرص، لتجنب محاولة البايتات غير الموثوقة الاستفادة من خطوة تجميع الشفرة الخاصة بنا أثناء التنفيذ الحي.

لقد عملنا على مترجم JIT/AOT لـ Revm، يتم حاليًا دمجه مع Reth. سنقوم بفتح المصدر لهذا في الأسابيع القادمة بمجرد الانتهاء من اختبار الأداء لدينا. يتم قضاء حوالي 50% من وقت التنفيذ في مترجم EVM في المتوسط، لذا يجب أن يوفر هذا تحسينًا في تنفيذ EVM بمقدار ~2x، على الرغم من أنه في بعض الحالات التي تتطلب حسابًا أكثر ثقلًا قد يكون له تأثير أكبر. سنقوم بمشاركة نتائج الاختبارات ودمج مترجمنا الخاص JIT EVM في Reth في الأسابيع القادمة.

موازي EVM

مفهوم آلة تشغيل إثيريوم الموازية (Parallel EVM) يمكنه تمكين معالجة المعاملات المتزامنة، على عكس النموذج التنفيذي التسلسلي التقليدي لآلة تشغيل إثيريوم. لدينا مساران مستقبليان هنا:

1. مزامنة تاريخية: في المزامنة التاريخية، يمكننا حساب أفضل جدولة للتوازن عن طريق تحليل المعاملات السابقة وتحديد جميع تضاربات الحالة التاريخية. انظر محاولتنا الأولى في هذا الشأن في فرع قديم على جيتهاب.
2. مزامنة مباشرة: بالنسبة للمزامنة المباشرة، يمكننا استخدام كتلة STM-مثل تقنيات التنفيذ التكهني دون أي معلومات إضافية مثل قوائم الوصول. هذا الخوارزمية لديه أداء سيء خلال فترات الصراع الحالة الثقيلة، لذا نريد استكشاف التبديل بين التنفيذ التسلسلي والتوازي اعتمادًا على شكل العبء العمل، بالإضافة إلى التنبؤ بشكل ساكن بالفتحات التخزينية التي سيتم الوصول إليها لتحسين جودة التوازي. انظر إلى واحد PoC من قبل فريق ثالثهنا.

بناءً على تحليلنا التاريخي، يتم الوصول إلى حوالي 80٪ من فتحات تخزين الإيثريوم بشكل مستقل، مما يعني أن التوازي يمكن أن يؤدي إلى تحسين يصل إلى 5 مرات في تنفيذ EVM.

تحسين الالتزام الحكومي

نحنكتبت حديثًا عنتأثير جذر الحالة في الأداء والفروقات بين نموذج قاعدة بيانات Reth عن العملاء الآخرين، ولماذا هذا أمر مهم.

في نموذج Reth ، حساب جذر الحالة هو عملية منفصلة عن تنفيذ المعاملات (رؤية أفل رمز)، مما يتيح استخدام متاجر KV القياسية التي لا تحتاج إلى معرفة أي شيء عن الشجرة. يستغرق ذلك حاليًا أكثر من 75٪ من الوقت الكلي لإغلاق كتلة، وهو مجال مثير للتحسين.

نحدد الانتصارات السهلة التالية 2 التي يمكن أن تمنحنا 2-3x في أداء جذر الحالة، بدون أي تغيير في البروتوكول:

1. الجذر الرئيسي موازٍ تمامًا: الآن نقوم فقط بإعادة حساب شجرة التخزين للحسابات المتغيرة بشكل موازٍ، ولكن يمكننا المضي قدمًا وأيضًا حساب شجرة الحسابات بشكل موازٍ أثناء اكتمال وظائف الجذر التخزيني في الخلفية.
2. جذر الحالة المجزأ: اجلب عقد الشجرة الوسيطة من القرص أثناء التنفيذ عن طريق إخطار خدمة جذر الحالة حول فتحات التخزين والحسابات التي تم لمسها.

فوق ذلك، نرى بضعة مسارات متقدمة من خلال التباين عن سلوك جذر الحالة Ethereum L1:

1. جذر الحالة الأقل تكرارًا: بدلاً من حساب جذر الحالة في كل كتلة، احسبه كل T كتلة. يقلل هذا من النسبة الإجمالية للوقت الذي يتم فيه إجراء جذر الحالة في النظام بأكمله ويمكن أن يكون الحل الأسهل والأكثر فاعلية.
2. جذر الحالة المتأخر: بدلاً من الحاجة إلى حساب جذر الحالة في نفس الكتلة، دعه يتخلف بضع كتل. يسمح هذا بتقدم التنفيذ دون عرقلة في حساب جذر الحالة.
3. استبدل مشفر RLP و Keccak256: بدلاً من الترميز بـ RLP، قد يكون أرخص فقط دمج البايتات واستخدام وظيفة تجزئة أسرع مثل Blake3.
4. شجرة أوسع: زيادة عدد الأفرع N في الشجرة، لتقليل تضخيم الإدخال/الإخراج بسبب عمق logN للشجرة.

هناك بعض الأسئلة هنا:

1. ما هي الآثار من الدرجة الثانية للتغييرات أعلاه على العملاء الخفيفين، L2s، الجسور، المعالجات المساعدة والبروتوكولات الأخرى التي تعتمد على البراهين الدائمة والتخزين المتكرر؟
2. هل يمكننا تحسين الالتزام بالحالة لإثبات SNARK وسرعة التنفيذ الأصلية؟
3. ما هو أوسع التزام حكومي يمكننا الحصول عليه باستخدام الأدوات المتاحة لنا؟ ما هي الآثار من الدرجة الثانية المحيطة بحجم الشاهد؟

خريطة طريق توسيع أفقي لريث

سننفذ العديد من النقاط المذكورة أعلاه طوال عام 2024 ونحقق هدفنا المتمثل في 1 جيجاجاز / ثانية.

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

متعدد اللف Reth

تتطلب كوما L2 الحالية تشغيل خدمات متعددة لمتابعة السلسلة: L1 CL، L1 EL، وظيفة الانشقاق L1 -> L2 (التي قد تكون مجمعة مع L2 EL)، و L2 EL. بينما رائع للقابلية للتمدد، يصبح هذا معقدًا عند تشغيل كوما العقدة المتعددة. تخيل أن تكون عليه تشغيل 100 رول أب!

نريد السماح بإطلاق اللفائف في نفس العملية التي تعمل بها Reth وتقليل تكلفة التشغيل لتشغيل آلاف اللفائف إلى الصفر تقريبًا.

نحن بالفعل قيد التنفيذ لهذا مع بوابتنا مشاريع توسيع التنفيذ ([1], [2])، المزيد في الأسابيع القادمة هنا.

Reth السحابية

قد تكون لديها طلب كافٍ على سكة واحدة بحيث تحتاج إلى توسيع نطاقها إلى خارج جهاز واحد. هذا غير ممكن في تنفيذات العقد الأحادية اليوم.

نريد السماح بتشغيل عقد Reth السحابي الأصلي كعمود خدمة يمكنه التوسع التلقائي مع الطلب على الحوسبة واستخدام تخزين الكائنات السحابي غير المحدود للثبات. هذه هي الهندسة المعمارية الشائعة في مشاريع قواعد البيانات الخادمة مثل NeonDB، وCockroachDB أو Amazon Aurora.

انظرأفكار مبكرةمن فريقنا بعض الطرق التي يمكننا اتباعها للتعامل مع هذه المشكلة.

النظرة

نعتزم طرح خارطة الطريق هذه بشكل تدريجي لجميع مستخدمي Reth. مهمتنا هي منح الجميع إمكانية الوصول إلى 1 جيجا / ثانية وما بعدها. سنختبر تحسيناتنا على Reth AlphaNet ، ونأمل أن يقوم الأشخاص ببناء عقد معدلة عالية الأداء باستخدام Reth كSDK.

هناك بعض الأسئلة التي لم نصل إلى إجابات لها بعد.

• كيف يمكن لـ Reth المساعدة في تحسين الأداء عبر النظام البيئي L2؟
• كيف يمكننا قياس سيناريوهات أسوأ بشكل مناسب عندما قد تكون بعض أمثلتنا موجهة نحو الحالة المتوسطة؟
• كيف يمكننا إدارة التوتر بين L1 و L2 الذي قد يتباعد بشكل محتمل؟

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

تنصل:

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