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

١. مكانة وقيمة تقنيات الحوسبة المتوازية في توسيع نطاق blockchain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تركز مشاريع الحوسبة المتوازية مثل Monad وMegaETH بشكل رئيسي على تحسين مسارات الإنتاجية، بهدف أساسي هو زيادة TPS داخل السلسلة، من خلال تنفيذ التأخير (Deferred Execution) وهيكل الميكرو آلة الافتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos شبكة بلوكتشين من الطبقة الأولى (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 آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT، PoS، PoA)، ومن خلال بروتوكول إعادة الرهن (Restaking) تحقق المشاركة الآمنة للموارد بين الشبكة الرئيسية وSPNs.

علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من أسفل محرك التخزين من خلال تقنيات متعددة الطبقات من شجرة Merkle، والترميز التفاضلي (Delta Encoding)، والعنوان المميز (Versioned Addressing)، ودفع ADS (ADS Pushdown)، مما أطلق محرك التخزين عالي الأداء الأصلي للبلوكشين Phar.