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

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

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

تشمل حلول توسيع البلوكشين: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدات DA، الهيكلية المعيارية، نظام الممثلين، ضغط 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 بأقل قدر ممكن، وتحقيق التوازي من خلال تأجيل كتابة الحالة، واكتشاف التعارضات ديناميكيًا أثناء التنفيذ، يشبه نسخة الأداء من Ethereum، مع نضوج جيد يسهل تحقيق الانتقال إلى بيئة EVM، وهو مسرع توازي في عالم EVM.

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

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

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

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

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

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

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

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

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

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

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

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