تفسير نموذج CTO: كيف تحقق Reth 1 غيغابايت من الغاز في الثانية

المؤلف: جورجيوس كونستانتوبولوس، شريك أبحاث Paradigm ومدير التكنولوجيا التنفيذي الترجمة: Golden Finance xiaozou

بدأنا في بناء Reth في عام 2022 لتوفير المرونة لـ Ethereum L1 أثناء حل طبقة التنفيذ في سؤال ملحق L2.

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

نحن ندعو النظام البيئي بأكمله للانضمام إلينا في دفع حدود الأداء والمعايير الصارمة في مجال العملات المشفرة.

1. هل حققنا توسعًا واسع النطاق؟

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

1.1 كيف يتم قياس الأداء؟ إلى ماذا يشير الغاز في الثانية؟

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

يمكن أن يوفر ضبط معدل الغاز في الثانية كمقياس للأداء فهمًا أوضح لقدرة وكفاءة blockchain. كما أنه يساعد في تقييم تأثير تكلفة النظام والحماية من هجمات رفض الخدمة (DOS) المحتملة التي قد تستغل طرق قياس أقل تفصيلاً. يساعد هذا المقياس على مقارنة أداء السلاسل المختلفة المتوافقة مع Ethereum Virtual Machine (EVM).

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

1.2 مرحلة التطوير الحالية لدينا

يتم تحديد كمية الغاز في الثانية عن طريق قسمة استخدام الغاز المستهدف لكل كتلة على وقت الكتلة. في الجدول التالي، نعرض إنتاجية الغاز الحالية وزمن الوصول في الثانية لسلاسل EVM المختلفة L1 وL2 (ليست شاملة):

نحن نركز على الغاز في الثانية ونستخدمه لتقييم أداء شبكة EVM بشكل شامل مع التقاط تكاليف الحوسبة والتخزين. لا يتم تضمين شبكات مثل Solana أو Sui أو Aptos نظرًا لنماذج التكلفة الفريدة الخاصة بها. نحن نشجع الجهود المبذولة لمواءمة نماذج التكلفة عبر جميع شبكات blockchain لتمكين إجراء مقارنات شاملة وعادلة.

نحن نعمل على تطوير مجموعة من أدوات قياس الأداء بدون توقف لـ Reth لتكرار أعباء العمل الحقيقية. متطلباتنا للعقد هي الامتثال لمعيار TPC.

2. كيف يصل الريث إلى 1 جيجا غاز في الثانية؟ أو حتى أعلى؟

كان جزءًا من دوافعنا لإنشاء Reth في عام 2022 هو حاجتنا الملحة إلى عميل مصمم خصيصًا لتجميع الويب. ونعتقد أن طريقنا إلى الأمام واعد.

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

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

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

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

التحسينات التي نناقشها هنا لن تتضمن حلول نمو الدولة، والتي سنناقشها بشكل منفصل في مقالات أخرى. وفيما يلي نظرة عامة على خططنا لتحقيق هذا الهدف:

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

2.1 خريطة طريق التوسع الرأسي لـ Reth

هدفنا للتوسع الرأسي هو زيادة أداء وكفاءة الخادم أو الكمبيوتر المحمول الذي يقوم بتشغيل Reth.

(1) EVM حتى (في الوقت المناسب) وEVM قبل الوقت (قبل الوقت)

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

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

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

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

( 2) Parallel EVM

يدعم مفهوم آلة Ethereum الافتراضية الموازية (Parallel EVM) معالجة معاملات متعددة في نفس الوقت، وهو ما يختلف عن نموذج التنفيذ التسلسلي التقليدي لـ EVM. لدينا المسارين التاليين:

• التزامن التاريخي: التزامن التاريخي يسمح لنا بالمرور تحليل المعاملات التاريخية وتحديد جميع تعارضات الحالة التاريخية لحساب أفضل جدول موازي ممكن.

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

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

( 3) تحسين التزام الحالة

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

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

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

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

بالإضافة إلى ذلك، يمكننا أيضًا استكشاف بعض المسارات للأمام من خلال الانحراف عن نشاط جذر حالة Ethereum L1:

• حسابات جذر الحالة الأكثر تكرارًا: لا يتم حساب جذر الحالة على كل كتلة، ولكن يتم حسابه مرة واحدة في كل كتلة T. وهذا يقلل من إجمالي الوقت المستغرق في الاستثمار في جذر الحالة للنظام بأكمله، وهو على الأرجح الحل الأبسط والأكثر فعالية.

• تتبع جذر الحالة: بدلاً من حساب جذر الحالة على نفس الكتلة، دعها تتأخر بضع كتل. وهذا يسمح للتنفيذ بالتقدم دون عرقلة حساب جذر الحالة.

• استبدال برنامج تشفير RLP وKeccak256: قد يكون من الأرخص دمج البايتات مباشرةً واستخدام وظيفة تجزئة أسرع (مثل Blake3) بدلاً من استخدام تشفير RLP.

• محاولة أوسع: قم بزيادة العقد الفرعية N-arity للشجرة لتقليل زيادة الإدخال/الإخراج الناتجة عن عمق logN للمحاولة.

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

< li>

ما هي التأثيرات الثانوية للتغييرات المذكورة أعلاه على العملاء الخفيفين وL2 والجسور والمعالجات المساعدة والبروتوكولات الأخرى التي تعتمد على الحسابات المتكررة وإثباتات التخزين؟

• هل يمكننا تحسين التزامات الدولة لإثباتات SNARK وسرعة التنفيذ الأصلية في نفس الوقت؟

• ما هو أوسع التزام للدولة يمكننا الحصول عليه باستخدام أدواتنا الحالية؟ ما هي التأثيرات الثانوية على حجم الشاهد؟

2.2 خريطة طريق التوسع الأفقي لشركة Reth

سنقوم بتنفيذ العديد مما سبق طوال عام 2024 لتحقيق هدف 1 جيجابايت من الغاز في الثانية.

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

(1) العائد المجمع المتعدد

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

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

إننا نعمل بالفعل على ذلك في مشروعنا الخاص بقياس التنفيذ، وهناك المزيد في المستقبل في الأسابيع المقبلة.

(2) Reth السحابية الأصلية

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

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

3. الآفاق المستقبلية

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

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

• كيف تساعد Reth في تحسين أداء نظام اللغة الثانية بأكمله؟

• كيف يمكننا قياس أسوأ السيناريوهات التي قد تحدث مع بعض التحسينات بشكل عام بشكل صحيح؟

• كيف نتعامل مع الخلافات المحتملة بين L1 وL2؟

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