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

المؤلف: Georgios Konstantopoulos

بدأنا في بناء RETH في عام 2022 لتزويد Ethereum L1 بمرونة مع حل توسع طبقة التنفيذ على L2.

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

ندعو النظام الإيكولوجي بأكمله إلى جانبنا للترويج بشكل مشترك بين الأداء المتطور واختبار القياس الصارم في حقل التشفير.

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

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

1.1 كيفية قياس الأداء؟ما هي كمية الغاز في الثانية؟

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

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

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

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

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

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

نقوم بتطوير مجموعة من أدوات اختبار الأساس غير المنقطعة لـ RETH لنسخ عبء العمل الحقيقي.تتماشى متطلباتنا للعقد مع معيار TPC.

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

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

خلال المزامنة في الوقت الفعلي ، وصل RETH إلى 100-200 ميغابايت (بما في ذلك استرداد المرسل ، و trie من المعاملة وحساب كل كتلة) ؛ توسع بمقدار 10 مرات.

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

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

إن التحسين الذي نوقشناه هنا لن ينطوي على حلول نمو الحالة.فيما يلي نظرة عامة على خطتنا لتحقيق هذا الهدف:

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

2.1 خريطة طريق التمديد العمودي

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

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

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

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

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

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

(2) EVM متوازي

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

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

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

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

في نموذج RETH ، يعد حساب جذر الحالة عملية مستقلة عن المعاملات ، مما يتيح استخدام تخزين KV القياسي الذي لا يحتاج إلى الحصول على معلومات تري.هذا يتطلب حاليًا و 75 ٪

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

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

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

حساب جذور حالة التردد السفلية: لا يتم حساب جذور الحالة على كل كتلة ، ولكن تم حسابها بمجرد كل كتلة t.هذا يقلل من إجمالي نسبة الوقت من جذور الحالة في النظام بأكمله ، والذي قد يكون الحل أبسط وأكثر فعالية.
تتبع جذور الحالة: بدلاً من حساب جذر الحالة على نفس الكتلة ، من الأفضل أن تتخلف عن عدة كتل.وبهذه الطريقة ، يمكن تطوير التنفيذ دون منع حساب الجذر للحالة.
استبدال RLP Encoder & amp ؛
أوسع تري: أضف أشجار N-RATE Sub-NODES لتقليل IO الموسع بسبب عمق Logn Trie.

هناك العديد من الأسئلة هنا:

ما هي التغييرات المذكورة أعلاه على عملاء الضوء ، L2 ، الجسر ، المتعاونون ، والتأثيرات الثانوية الأخرى للبروتوكولات التي تعتمد على الحسابات المتكررة وشهادات التخزين؟
هل يمكننا في الوقت نفسه تحسين التزام حالة Snark Proof وسرعة التنفيذ الأصلية؟
من خلال أدواتنا الحالية ، ما هو وعد الدولة الأكثر واسعة التي يمكننا الحصول عليها؟ما هي الآثار الثانوية على الشاهد؟

2.2 خريطة طريق التوسع الأفقي من ريث

سنقوم بإجراء العناصر المتعددة المذكورة أعلاه خلال عام 2024 لتحقيق هدف غاز 1 جيجابايت في الثانية.

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

(1) Rollup Multi Rollup

يحتاج L2 Stack اليوم إلى تشغيل خدمات متعددة لتتبع السلاسل: L1 CL ، L1 EL ، L1 -& GT ؛على الرغم من أن هذا أمر جيد جدًا للتعديل ، إلا أن الموقف سيصبح أكثر تعقيدًا عند تشغيل مداخن عقدة متعددة.تخيل ماذا لو كان عليك تشغيل 100 رولوب!

نأمل أن نسمح لـ Rollup في وقت واحد أثناء تطوير Reth ، وتقليل تكلفة تشغيل الآلاف من Rollup إلى الصفر تقريبًا.

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

(2) يونيوان ريث

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

نأمل أن نتمكن من دعم العقد السحابية قيد التشغيل ، ونشرها كمكدس خدمة ، وتوسيعها تلقائيًا وفقًا لمتطلبات الحساب ، واستخدام تخزين كائن السحابة غير المحدود على ما يبدو لتحقيق التخزين الدائم.هذا بنية شائعة في مشروع قاعدة بيانات الخادم (مثل Neondb أو Cockrochdb أو Amazon Aurora).

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

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

لم نجد الجواب.