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

1. الحوسبة المتوازية: المسار الرئيسي لتوسيع نطاق blockchain

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

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

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

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

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

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

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

![صورة شاملة لمجال الحوسبة المتوازية Web3: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

٢- سلسلة تعزيز التوازي 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.

![صورة شاملة لمجال الحوسبة المتوازية في Web3: هل هي أفضل خطة للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(

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

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

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

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

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

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

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

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

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

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

![خريطة شاملة لمسار الحوسبة المتوازية في Web3: ما هو أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

تختلف فلسفة تصميم 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. معالجة الأنابيب غير المتزامنة طوال دورة الحياة ): يقوم 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 )، بإعادة بناء نموذج التنفيذ من أسفل محرك التخزين، وأطلقت محرك التخزين عالي الأداء Pharos Store الخاص بسلسلة الكتل الأصلية، مما يحقق قدرة معالجة عالية السعة، وانخفاض في التأخير، وقوة قابلة للتحقق على السلسلة.

![