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

1. الموضوع الأبدي لتوسيع نطاق Blockchain

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

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

تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، 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 أو تقنيات تقسيم السلاسل، فهي تنتمي إلى آليات التوازي على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازٍ"، وليس من خلال زيادة مستوى التوازي داخل كتلة واحدة/آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها لمقارنة أوجه التشابه والاختلاف في مفاهيم الهيكل.

2. سلسلة تعزيز التوازي 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 مستقلة، أو كطبقة تعزيز تنفيذ (Execution Layer) على Ethereum أو كمكون معياري. الهدف الرئيسي من تصميمها هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ عالي التزامن داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: هيكل Micro-VM + DAG اعتماد الحالة (Directed Acyclic Graph) وآلية التزامن المعيارية، التي تبني معًا نظام تنفيذ متوازي موجه نحو "التخييط داخل السلسلة".

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

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

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

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

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

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

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

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

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

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