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

أولاً، ثلاث ميزات والحالات الحالية للقيود:

عالية throughput المعاملات, 高吞吐量

تتميز opBNB بمعدل غاز مرتفع للغاية 100MGas/s، ولكن لا تزال قدراتها أقل بكثير مقارنة بخوادم web2، حيث إن 100MGas/s تعادل 650 عملية تبادل uniswap في الثانية أو 3700 تحويل ERC20، بينما يمكن للخوادم الحديثة تنفيذ أكثر من مليون معاملة في الثانية.

قدرة حسابية كبيرة (abundant compute capacity)، قدرة حسابية وفيرة

لا يمكن ترميز التطبيقات المعقدة على السلسلة، والقيود الرئيسية تكون في القدرة الحسابية. إذا استخدمنا تعاقدات EVM لحساب أرقام ن-فيبوناتشي، نحتاج إلى 5.5 مليار Gas، وهذا سيستهلك سرعة حساب 100MGas/s المطلوبة لتشغيل 55 ثانية على سلسلة opbnb بأكملها. أما في الحالة التقليدية، فإن برنامجاً مكتوباً بلغة C يحتاج فقط إلى 30ms. وعلى معالج أحادي النواة، ترتفع السرعة 1833 مرة.

و، بشكل مميّز جداً، أزمنة استجابة بمستوى الملّي ثانية حتى تحت حمل ثقيل. قدرة الاستجابة بمستوى الملّي ثانية تحت التحميل العالي

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

ثانياً: كيف نتجاوز حدود الأداء القصوى

معمارية البلوكشين الحالية (L1)

تتضمن كل سلسلة بلوكشين جزأين أساسيين، بما في ذلك الإجماع والتنفيذ: consensus and execution.

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

لذلك فإن متطلبات تشغيل العقد الكاملة مهمة جداً، لأنها ترتبط بالأمان ومقاومة الرقابة

النموذج/البارادايم الجديد لـ Layer 2

الجوهر في سلاسل بلوكشين L2 هو أنها غير متجانسة بطبيعتها، أي مختلفة بطبيعتها. فالعُقد المختلفة في L2 تكون متخصصة لتنفيذ مهام معينة بكفاءة أكبر.

تذهب megaETH خطوة أبعد، حيث تفصل مهمة تنفيذ المعاملات عن العقدة الكاملة (فك الارتباط). على وجه التحديد، تمتلك megaETH ثلاثة أدوار: sequencers (المُرتِّبات/الترتيب)، provers (المُصدِقون/المُثبتون) وfull nodes (العُقد الكاملة)

العنصر الأساسي الأول هو مُرتِّب مركزي قوي

sequencers: مسؤولة عن ترتيب وتنفيذ المعاملات، لكن لدى megaeth اختلاف؛ ففي أي وقت محدد، يوجد فقط مُرتِّب نشط واحد، وبذلك يتم القضاء على تكلفة الإجماع أثناء التنفيذ الطبيعي. يتلقى معظم العُقد الكاملة فروقات الحالة (state diffs) من هذا المُرتِّب عبر شبكة p2p، ثم تطبق الفروقات مباشرة لتحديث الحالة المحلية، لكنّها لا تعيد تنفيذ المعاملات؛ بل تتحقق من صحة الكتلة بشكل غير مباشر عبر الإثباتات التي يقدمها provers. ما يزال بإمكان المستخدمين المتقدمين (مشغلي الـbridge وصناع السوق) تنفيذ كل معاملة للحصول على الصلاحية النهائية (finality) بأسرع ما يمكن، لكن هذا يتطلب متطلبات عتاد أعلى لمواكبة sequencer. في النهاية، يقوم provers بالتحقق غير المتزامن وغير المرتّب من الكتل عبر مخطط تحقق عديم الحالة (stateless validation scheme).

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

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

إذا اعتمدنا فقط على خوادم قوية، ففي التجارب لا يمكن لـReth سوى الوصول إلى 1000TPS تقريباً، أي حوالي 100MGas/s. والسبب الرئيسي يعود إلى قيود تحديث MPT (بنية البيانات المستخدمة في Ethereum) في كل كتلة، وهذا أعلى بـ10 مرات من كلفة الحساب نفسها لتنفيذ المعاملات.

لذلك ما زالت تواجه حالات معقّدة كثيرة.

ثالثاً: تصميم megaETH

قِسْ ثم ابنِ: أولاً قيّم، وحدد مكان المشكلة، ثم اعرف المشكلة الحقيقية لقيود الأداء، وبعد ذلك صمّم نظاماً جديداً، مع معالجة جميع المشكلات في الوقت نفسه.

努力 تصميم الأنظمة، للوصول إلى حدود العتاد، ولا أحب التصميم التدريجي، بل أحب تصميمات جديدة تقترب من حدود النظرية القصوى.

فيما يلي بعض التحديات والحلول التي واجهتها أثناء عملية التصميم

تنفيذ المعاملات

لنبدأ الحديث عن الـsequencer (الترتيب). يقول كثيرون إن EVM أداءه سيئ على L2s وإن السبب هو انخفاض TPS، لكن هذا غير صحيح. وفق اختبارات megaeth، يمكن لـEVM تحقيق 14000 TPS، وهذا رقم مرتفع جداً بالفعل.

لكن بالنسبة للبلوكشين الفوري، هذا غير كافٍ. فلدى التنفيذ التقليدي لـEVM ثلاث مشكلات من حيث الكفاءة المنخفضة، وهي على التوالي:

تأخر الوصول إلى الحالة مرتفع (high state access latency): الوصول وقراءة حالة البلوكشين بطيئان، لأن الحالة مخزنة على القرص الصلب، وتحتاج إلى قراءات متعددة.

الحل: تزود عقد الـsequencer بكمية كافية من RAM لحفظ الحالة الكاملة للبلوكشين. حالياً تبلغ RAM على Ethereum تقريباً 100GB. يسرّع هذا النهج بشكل ملحوظ عبر إزالة تأخيرات قراءة SSD عند الوصول إلى الحالة.

نقص التنفيذ المتوازي (lack of parallel execution): لأن المعاملات تُنفَّذ بالتسلسل، ولضمان اتساق الحالة ومنع الإنفاق المزدوج، يصبح من الصعب تنفيذها بالتوازي

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

تكلفة المفسّر (interpreter overhead): عند تنفيذ عقود ذكية، توجد تكاليف إضافية يسببها الجهاز الظاهري أو المفسّر.

الحل: إن حصة كبيرة من الأوبكودات (opcodes) تكون أصلاً مكتوبة بلغة Rust الأصلية، لذلك يصعب الاستفادة من تحسينات التجميع (compilation). وحتى الزيادة القصوى قد تكون فقط 2x.

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

مزامنة الحالة

مزامنة الحالة هي العملية التي تجعل العُقد الكاملة تواكب سرعة المُرتّبين (sequenecers)، وهي واحدة من أكثر الجوانب تحدّياً في تصميم سلاسل بلوكشين عالية الأداء.

تحويل الأموال ومعاملات uniswap. إذا تم إرسال 100 ألف عملية في الثانية، فستحتاج كلٌ منها إلى 152.6Mbps و476.1Mbps من عرض النطاق. وهذا يتجاوز بكثير عرض النطاق المتاح للعقد الكاملة البالغ 100Mbps. والأرجح أن هذا الـ100Mbps يكون معدل استخدامه أقل من الثلث. في الواقع، فإن عرض النطاق المستخدم للمزامنة قد يكون فقط 25Mbps، وهذا فارق كبير جداً عن الاحتياج الفعلي.

تحديث جذر الحالة (state root)

المفهوم معقد: ضمن بنية MPT، إذا أردنا تحديث state root، نحتاج إلى قراءة وكتابة عدد كبير من العقد الورقية وعقد الأبناء. باستخدام 100 ألف عملية تحويل للمثال: في حساب مجرد القراءة، نحتاج تقريباً إلى 6 ملايين عملية قراءة من قاعدة بيانات غير مخبأة (non-cached). وحتى إذا افترضنا أن كل قراءة للقاعدة يمكن أن تُعالَج عبر عملية إدخال/إخراج واحدة للقرص، فإن 6 ملايين IOPS تتجاوز بكثير قدرة أي SSD استهلاكي في الوقت الحالي. بل إن هذا الحساب لا يأخذ حتى في الاعتبار عمليات الكتابة.

تتمثل إحدى الاستراتيجيات الشائعة لتقليل عمليات الإدخال/الإخراج على القرص في تجميع عدة عقد trie داخل شجرة فرعية (subtree) وتخزينها معاً ضمن صفحة قرص بحجم 4KB. لكن هذا ما يزال أقل بنحو 6 مرات من ما نحتاجه.

حد الغاز للكتلة

من أجل أمان وموثوقية البلوكشين، يجب أن نضع حدّاً معقولاً لـGas،

البنية التحتية

في النهاية، لا يتفاعل المستخدمون مباشرة مع عقد المُرتِّب، ولا يقوم معظم الناس بتشغيل عقد كاملة في المنزل. بدلاً من ذلك، يقدّم المستخدمون المعاملات إلى عقد RPC تابعة لطرف ثالث، ويعتمدون على dApp أو متصفح بلوكشين، مثل الواجهة الويب في http://etherscan.io/، للتحقق من نتيجة المعاملة.

لذا فإن تجربة المستخدم الفعلية للبلوكشين تعتمد إلى حدّ كبير على ما إذا كان يدعم البنية التحتية، مثل عقد RPC والفهرسة. مهما كانت سرعة تشغيل البلوكشين الفوري، إذا لم تستطع عقد RPC معالجة عدد كبير من طلبات القراءة بكفاءة خلال أوقات الذروة، أو نشر المعاملات بسرعة إلى عقد المُرتّب (الـ sorter)، أو إذا لم تستطع الفهرسة التحديث بالسرعة الكافية لِمجاراة وجهة التطبيق، فسيكون الأمر غير مهم.

توسيع بلوكشين بطريقة ذات مبادئ

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

رابعاً: أنواع التطبيقات المتوقعة

• الألعاب

• بنية تحتية فيزيائية لامركزية للحساب الفوري (dePin)

• محرك عوالم مستقل

• شبكة VPN لامركزية

• المدفوعات عبر الحدود

• استخدام تداول عالي التردد منخفض التأخير جداً (هل هذا مثل باينانس على السلسلة؟)

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