صورة شاملة لمسار الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟

1. الحوسبة المتوازية: نموذج جديد لتوسيع نطاق blockchain

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

• تنفيذ تحسين السعة المعززة: رفع القدرة التنفيذية في الموقع، مثل المعالجة المتوازية، GPU، متعددة النوى
• توسيع معزول عن الحالة: تقسيم أفقي للحالة / شارد، مثل الشظايا، UTXO، شبكات فرعية متعددة
• توسيع من نوع الاستعانة بمصادر خارجية خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup و Coprocessor و DA
• توسيع هيكلية مفككة: نمط معماري معياري، تشغيل متزامن، مثل سلسلة الموديولات، منظم مشترك، Rollup Mesh
• التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط

تشمل حلول توسيع سلسلة الكتل: الحوسبة المتوازية داخل السلسلة، Rollup، التقسيم، وحدة DA، الهيكلية المودولارية، نظام Actor، ضغط إثبات zk، الهيكل عديم الحالة، وغيرها، والتي تغطي مستويات متعددة مثل التنفيذ، الحالة، البيانات، والهيكل، وهي نظام توسيع كامل "تعاون متعدد الطبقات، وتركيب وحدات". بينما تركز هذه المقالة على أسلوب التوسيع الذي يعتمد بشكل رئيسي على الحوسبة المتوازية.

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

• مستوى الحساب ( مستوى الحساب ): يمثل مشروع سولانا
• المستوى الكائن المتوازي ( Object-level ): يمثل مشروع Sui
• مستوى المعاملات(Transaction-level): يمثل المشروع Monad, Aptos
• استدعاء المستوى / ميكرو VM بالتوازي ( استدعاء المستوى / ميكرو VM ): يمثل مشروع MegaETH
• التوازي على مستوى التعليمات ( Instruction-level ): يمثل مشروع GatlingX

نموذج المزامنة غير المتزامنة خارج السلسلة، يتم تمثيله بنظام الكائنات الذكية Actor (Agent / Actor Model)، والذي ينتمي إلى نمط حسابي متوازي آخر، كنظام رسائل عبر السلاسل/غير المتزامن (نموذج غير المتزامن للكتل)، حيث يعمل كل وكيل ك"عملية كائن ذكي" تعمل بشكل مستقل، مع رسائل غير متزامنة، مدفوعة بالأحداث، دون حاجة لجدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.

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

2- سلسلة تعزيز EVM المتوازية: كسر حدود الأداء ضمن التوافق

تطور هيكل المعالجة المتسلسل لإيثريوم حتى اليوم، حيث مر بعدد من محاولات التوسع مثل تقسيم الشبكة، Rollup، والهياكل المودولية، ولكن لا يزال عنق الزجاجة في قدرة التنفيذ دون突破 جذري. وفي الوقت نفسه، لا يزال EVM و Solidity هما المنصتان الأكثر تفضيلاً من قبل المطورين ولديهما قدرة بيئية قوية على التكيف. لذلك، فإن سلسلة EVM المعززة بالتوازي، التي توازن بين التوافق البيئي وتحسين أداء التنفيذ، أصبحت تمثل مسارًا رئيسيًا نحو التوسع الجديد. تعتبر Monad و MegaETH أبرز المشاريع في هذا الاتجاه، حيث تقوم ببناء هيكل معالجة EVM متوازي يستهدف السيناريوهات ذات التزامن العالي وقدرة الإنتاج العالي، انطلاقًا من التنفيذ المتأخر وتفكيك الحالة.

تحليل آلية الحساب المتوازي لـ Monad

Monad هي سلسلة كتل Layer1 عالية الأداء تم إعادة تصميمها لـ Ethereum Virtual Machine (EVM)، تستند إلى مفهوم المعالجة المتداخلة (Pipelining)، حيث يتم تنفيذ العمليات بشكل غير متزامن في طبقة الإجماع (Asynchronous Execution)، وتنفيذ متزامن متفائل في طبقة التنفيذ (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقات الإجماع والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا شاملاً.

تدفق البيانات: آلية تنفيذ متوازية متعددة المراحل

Pipelining هو المفهوم الأساسي لتنفيذ Monad بشكل متوازي، وتتمثل فكرته الأساسية في تقسيم عملية التنفيذ على blockchain إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خط أنابيب ثلاثية الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يحقق زيادة في السعة وتقليل في التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).

التنفيذ غير المتزامن: الإجماع - تنفيذ فك الارتباط غير المتزامن

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

التصميم الأساسي:

• عملية الإجماع ( طبقة الإجماع ) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقد.
• عملية التنفيذ ( طبقة التنفيذ ) يتم تشغيلها بشكل غير متزامن بعد اكتمال الإجماع.
• بعد اكتمال الإجماع، يدخل على الفور في عملية إجماع الكتلة التالية، دون الحاجة إلى انتظار الانتهاء من التنفيذ.

تنفيذ متوازي متفائل:

تستخدم الإيثيريوم التقليدية نموذج تسلسل صارم لتنفيذ المعاملات لتجنب تعارض الحالة. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من سرعة معالجة المعاملات.

آلية التنفيذ:

• Monad ستنفذ جميع المعاملات بشكل متوازي بتفاؤل، على افتراض أن معظم المعاملات لا تتعارض في الحالة.
• تشغيل "(Conflict Detector)" في نفس الوقت لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة ( مثل تعارض القراءة / الكتابة ).
• إذا تم اكتشاف تعارض، فسيتم تسلسل تنفيذ المعاملات المتعارضة مرة أخرى لضمان صحة الحالة.

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

تحليل آلية الحساب المتوازي لـ MegaETH

بخلاف تحديد L1 لوحدة Monad ، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء قابلة للتوسع ومتوافقة مع EVM ، ويمكن أن تعمل كشبكة عامة مستقلة من L1 أو كطبقة تعزيز تنفيذ على Ethereum (Execution Layer) أو مكون قابل للتوسع. الهدف الأساسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل ، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة ( رسم بياني موجه بدون حلقة للاعتماد على الحالة ) وآلية المزامنة القابلة للتوسع ، التي تبني معًا نظام تنفيذ متوازي موجه نحو "التسلسلات داخل السلسلة".

Micro-VM( الماكينة الافتراضية الصغيرة) الهيكل: الحساب هو الخيط

يقدم MegaETH نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)"، مما يجعل بيئة التنفيذ "مُتعددة الخيوط"، ويوفر أصغر وحدة عزل للتخطيط المتوازي. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، حيث يمكن تنفيذ عدد كبير من الآلات الافتراضية بشكل مستقل وتخزينها بشكل مستقل، مما يجعلها متوازية بشكل طبيعي.

رسم بياني يعتمد على الدولة: آلية جدولة مدفوعة بالرسم البياني للاعتماد

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

التنفيذ غير المتزامن وآلية الاستدعاء

تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة ( ) التنفيذ غير المتكرر ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل استدعاء غير متزامنة دون منع الانتظار. يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن (Call Graph) ؛ معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.

بإيجاز، يقوم MegaETH بكسر نموذج الآلة الحالة أحادية الخيط التقليدي لـ EVM، من خلال تحقيق تغليف الميكرو-آلة الافتراضية على أساس الحسابات، وإجراء جدولة المعاملات من خلال رسم الاعتماد على الحالة، واستبدال آلية الاستدعاء المتزامنة بآلية الرسائل غير المتزامنة. إنها منصة حساب متوازٍ تم إعادة تصميمها بشكل شامل من "هيكل الحسابات → هيكل الجدولة → سير التنفيذ"، مما يوفر أفكاراً جديدة على مستوى النماذج لبناء أنظمة سلسلة عالية الأداء من الجيل القادم.

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

إن مفهوم تصميم Monad و MegaETH يختلف بشكل كبير عن مفهوم التقسيم (Sharding): حيث يقوم التقسيم بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة (شظايا Shards)، بحيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة على مستوى الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، حيث يتم التوسع أفقيًا فقط على مستوى تنفيذ المعاملات، مما يؤدي إلى تحسين الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل، وهما التعزيز العمودي والتوسع الأفقي.

تركز مشاريع الحساب المتوازي مثل Monad و MegaETH بشكل رئيسي على مسارات تحسين الإنتاجية، بهدف تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) و ميكرو-VM (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تُعتبر شبكة Pharos Network شبكة بلوكتشين L1 متوازية بالكامل ومودولية، يُطلق على آلية الحساب المتوازي الأساسية فيها "Rollup Mesh". يدعم هذا الهيكل العمل المتزامن بين الشبكة الرئيسية و شبكة المعالجة الخاصة (SPNs)، ويدعم بيئات متعددة للآلات الافتراضية (EVM و Wasm)، ويجمع تقنيات متقدمة مثل الإثباتات صفرية المعرفة (ZK) وبيئات التنفيذ الموثوقة (TEE).

تحليل آلية الحساب المتوازي Rollup Mesh:

1. معالجة خطوط الأنابيب غير المتزامنة على مدار دورة الحياة (Full Lifecycle Asynchronous Pipelining): تقوم Pharos بفصل مراحل المعاملات المختلفة ( مثل التوافق والتنفيذ والتخزين )، وتستخدم أسلوب المعالجة غير المتزامن، مما يسمح لكل مرحلة بالعمل بشكل مستقل ومتوازٍ، وبالتالي تحسين كفاءة المعالجة العامة.
2. تنفيذ متوازي لآلتين افتراضيتين (Dual VM Parallel Execution): تدعم Pharos بيئتي الآلة الافتراضية EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة وفقًا لاحتياجاتهم. لا تعزز هذه البنية المزدوجة للآلة الافتراضية مرونة النظام فحسب، بل تعزز أيضًا قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
3. معالجة خاصة للشبكة (SPNs): SPNs هي مكونات رئيسية في بنية Pharos، تشبه الشبكات الفرعية المودولية، وتخصصت في معالجة أنواع محددة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز بشكل أكبر من قابلية توسيع النظام وأدائه.
4. التوافق المعياري وآلية إعادة الرهن (Modular Consensus & Restaking): قدمت Pharos توافقًا مرنًا