خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟
"ثلاثية مستحيلة" في البلوكشين (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" تكشف عن التوازن الأساسي في تصميم أنظمة البلوكشين، أي أنه من الصعب على مشاريع البلوكشين تحقيق "أمان مطلق، مشاركة للجميع، ومعالجة سريعة" في نفس الوقت. فيما يتعلق بموضوع "قابلية التوسع"، فإن حلول توسيع البلوكشين السائدة في السوق حاليًا تُصنف حسب الأنماط، بما في ذلك:
تنفيذ توسيع معزز: تحسين القدرة التنفيذية في الموقع، مثل المعالجة المتوازية، GPU، متعددة النوى
نوع التوسع المعزول عن الحالة: تقسيم أفقي للحالة / شارد، مثل التجزئة، UTXO، شبكة فرعية متعددة
توسيع نوع الاستعانة بمصادر خارجية خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع هيكل تفكيكي: نمذجة معمارية، تشغيل متزامن، مثل سلسلة الوحدات، مرتّب مشترك، شبكة Rollup
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع 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: اختراق حدود الأداء في التوافق
لقد شهدت بنية معالجة الإيثريوم المتسلسلة حتى اليوم العديد من محاولات التوسع بما في ذلك تقسيم البيانات، والتجميع، والهندسة المعمارية المودولارية، لكن لا تزال هناك اختناقات في القدرة على تنفيذ الطبقة. ومع ذلك، لا يزال EVM و Solidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين والطاقة البيئية الحالية لعقود الذكاء. لذلك، فإن سلسلة EVM المعززة بالتوازي تُعتبر المسار الرئيسي الذي يوازن بين توافق البيئة وتحسين أداء التنفيذ، وهي تتجه لتصبح اتجاهًا مهمًا في الجولة الجديدة من التطوير. تعتبر Monad و MegaETH من أبرز المشاريع في هذا الاتجاه، حيث تبنيان هيكل معالجة EVM بالتوازي الموجه نحو السيناريوهات عالية التزامن وعالية القدرة على التنفيذ من خلال تنفيذ متأخر وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل Layer1 عالية الأداء تم إعادة تصميمها لآلة Ethereum الافتراضية (EVM) ، تستند إلى مفهوم المعالجة المتوازية الأساسية (Pipelining) ، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) ، بينما يتم تنفيذ طبقة التنفيذ بشكل متزامن متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك ، في طبقة التوافق وطبقة التخزين ، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل.
Pipelining: آلية التنفيذ المتوازي عبر خطوط أنابيب متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ blockchain إلى عدة مراحل مستقلة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يصل إلى تحقيق زيادة في معدل النطاق وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) والتقديم إلى الكتلة (Commit).
التنفيذ غير المتزامن: الإجماع - تنفيذ فك الارتباط غير المتزامن
في السلاسل التقليدية، عادةً ما تكون عملية التوافق والتنفيذ متزامنة، مما يحد بشكل كبير من قدرة الأداء. حققت Monad توافقًا غير متزامن في طبقة التوافق، وتنفيذًا غير متزامن في طبقة التنفيذ، وتخزينًا غير متزامن. مما أدى إلى تقليل كبير في زمن الكتل (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وكفاءة استخدام الموارد أعلى.
التصميم الأساسي:
عملية التوافق (طبقة التوافق) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقود.
عملية التنفيذ (طبقة التنفيذ) يتم تفعيلها بشكل غير متزامن بعد اكتمال الإجماع.
بعد إكمال الإجماع، يتم الدخول مباشرة في عملية إجماع الكتلة التالية دون الحاجة إلى انتظار الانتهاء من التنفيذ.
التنفيذ المتوازي المتفائل: تنفيذ متوازي متفائل
يستخدم Ethereum التقليدي نموذج تسلسلي صارم لتنفيذ المعاملات لتجنب تعارض الحالة. بينما تتبنى Monad استراتيجية «التنفيذ المتوازي المتفائل»، مما يعزز بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
Monad ستقوم بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، مع افتراض أن معظم المعاملات لا تتعارض مع بعضها البعض.
تشغيل "كاشف التضارب (Conflict Detector))" لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة (مثل تضارب القراءة / الكتابة).
إذا تم الكشف عن تعارض، فسيتم تسلسل إعادة تنفيذ المعاملات المتعارضة لضمان صحة الحالة.
اختار الموناد مسار متوافق: تقليل تغيير قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة، واكتشاف الصراعات ديناميكياً لتحقيق التوازي، مما يجعله أكثر شبهاً بإيثريوم النسخة السريعة، مع نضج جيد يسهل تنفيذ انتقال النظام البيئي لـ EVM، وهو مسرع التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومتوازية وقابلة للتعديل متوافقة مع EVM، يمكن أن تعمل ككتلة عامة مستقلة L1، أو كطبقة تعزيز تنفيذ على إيثيريوم (Execution Layer) أو كمكون قابل للتعديل. الهدف الأساسي من تصميمها هو تفكيك منطق الحسابات وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ عالي التزامن داخل السلسلة واستجابة ذات تأخير منخفض. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة (Directed Acyclic Graph) وآلية التزامن القابلة للتعديل، والتي تبني معًا نظام تنفيذ متوازي موجه نحو "التخييط داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
أدخلت MegaETH نموذج تنفيذ "مايكرو-آلة افتراضية لكل حساب"، مما يجعل بيئة التنفيذ "خيطية"، ويقدم وحدة العزل الأدنى لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها من خلال الرسائل غير المتزامنة، بدلاً من الاستدعاءات المتزامنة، حيث يمكن للعديد من الآلات الافتراضية التنفيذ بشكل مستقل وتخزين مستقل، مما يتيح التوازي الطبيعي.
اعتماد الدولة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي. كل عملية تداول تعدل أي حسابات، وتقرأ أي حسابات، يتم نمذجتها بالكامل كعلاقات اعتماد. يمكن تنفيذ العمليات التجارية التي لا تتعارض مباشرة بشكل متوازي، بينما سيتم جدولة العمليات التجارية التي لها علاقات اعتماد وفقًا لترتيب طوبولوجي بشكل تسلسلي أو مؤجل. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المكررة أثناء عملية التنفيذ المتوازي.
تنفيذ غير متزامن وآلية الاسترجاع
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يقوم MegaETH بتجاوز نموذج آلة الحالة ذات الخيط الواحد التقليدي لـ EVM، حيث يحقق تغليفًا صغيرًا للآلة الافتراضية على مستوى الحسابات، ويقوم بجدولة المعاملات من خلال رسم الاعتماد على الحالة، ويستبدل آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنه منصة حساب متوازٍ تم إعادة تصميمها من "هيكل الحساب → هيكل الجدولة → سير التنفيذ" على جميع الأبعاد، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: حيث يتم تجريد الحسابات والعقود إلى VM مستقل، مما يحرر الإمكانيات القصوى للتوازي من خلال جدولة التنفيذ غير المتزامن. من الناحية النظرية، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في السيطرة على التعقيد، ويشبه إلى حد كبير نظام التشغيل الموزع الفائق تحت فكرة الإيثيريوم.
تختلف فلسفة تصميم Monad و MegaETH بشكل كبير عن التجزئة (Sharding): تقوم التجزئة بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة (التجزئة Shards)، حيث تتولى كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، مع التوسع الأفقي فقط في طبقة التنفيذ، مما يحقق تحسينات في الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على تحسين مسار الإنتاجية، بهدف أساسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وعمارة ميكرو-آلة افتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network شبكة بلوكشين من المستوى الأول (L1) متوازية، كاملة المكونات، وآلية الحوسبة المتوازية الأساسية لها تُعرف باسم "Rollup Mesh". تدعم هذه البنية العمل المشترك بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة الآلات الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية المعرفة (ZK) وبيئات التنفيذ الموثوقة (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh:
معالجة الأنابيب غير المتزامنة على مدى الحياة (Full Lifecycle Asynchronous Pipelining): يقوم Pharos بفصل المراحل المختلفة للمعاملات (مثل التوافق والتنفيذ والتخزين) ويستخدم طريقة معالجة غير متزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل ومتوازي، مما يزيد من كفاءة المعالجة الكلية.
التنفيذ المتوازي لآلتين افتراضيتين (Dual VM Parallel Execution): تدعم Pharos بيئتين افتراضيتين EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة وفقًا للاحتياجات. هذه البنية التحتية الثنائية للآلة الافتراضية لا تعزز فقط مرونة النظام، بل تعزز أيضًا قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
الشبكات المعالجة الخاصة (SPNs): تعتبر SPNs مكونًا رئيسيًا في بنية Pharos، تشبه الشبكات الفرعية المعيارية، ومخصصة لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص موارد ديناميكي ومعالجة مهام متوازية، مما يعزز بشكل أكبر قابلية توسيع النظام وأدائه.
الإجماع المعياري وآلية إعادة الرهن (Modular Consensus & Restaking): قدمت Pharos آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT، PoS، PoA)، ومن خلال بروتوكول إعادة الرهن (
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
بانوراما مسار الحوسبة المتوازية في Web3: 5 آليات متوازية من مستوى الحساب إلى مستوى التعليمات
خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟
"ثلاثية مستحيلة" في البلوكشين (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" تكشف عن التوازن الأساسي في تصميم أنظمة البلوكشين، أي أنه من الصعب على مشاريع البلوكشين تحقيق "أمان مطلق، مشاركة للجميع، ومعالجة سريعة" في نفس الوقت. فيما يتعلق بموضوع "قابلية التوسع"، فإن حلول توسيع البلوكشين السائدة في السوق حاليًا تُصنف حسب الأنماط، بما في ذلك:
تشمل حلول توسيع blockchain: الحوسبة المتوازية داخل السلسلة، Rollup، التقسيم، وحدة DA، الهيكلية المودولية، نظام Actor، ضغط zk، الهيكل غير الحالة، وغيرها، والتي تغطي عدة مستويات من التنفيذ، الحالة، البيانات، والبنية، وهي نظام توسيع كامل "تعاون متعدد المستويات، تجميع مودولي". بينما تركز هذه المقالة على طريقة التوسيع التي تعتمد بشكل أساسي على الحوسبة المتوازية.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة طموحات أداء مختلفة، ونماذج تطوير، وفلسفات معمارية، حيث تصبح درجة التوازي بشكل متزايد أكثر دقة، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، كما تزداد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، ممثلاً بنظام الكائنات الذكية (نموذج الوكيل / الكائن) والذي ينتمي إلى نمط آخر من الحساب المتوازي، كنظام رسائل غير متزامن عبر سلسلة (نموذج غير متزامن لكتل البيانات)، حيث يعمل كل وكيل كـ "عملية كائن ذكي" مستقلة، مع رسائل غير متزامنة بطريقة متوازية، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
إن خطط التوسع المعروفة لدينا مثل Rollup أو تقسيم الشرايين، تنتمي إلى آلية التزامن على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بالتوازي"، بدلاً من زيادة مستوى التوازي داخل كتلة واحدة / آلة افتراضية. هذه الخطط التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها لمقارنة أوجه الاختلاف في مفاهيم الهيكل.
٢. سلسلة التعزيز المتوازية EVM: اختراق حدود الأداء في التوافق
لقد شهدت بنية معالجة الإيثريوم المتسلسلة حتى اليوم العديد من محاولات التوسع بما في ذلك تقسيم البيانات، والتجميع، والهندسة المعمارية المودولارية، لكن لا تزال هناك اختناقات في القدرة على تنفيذ الطبقة. ومع ذلك، لا يزال EVM و Solidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين والطاقة البيئية الحالية لعقود الذكاء. لذلك، فإن سلسلة EVM المعززة بالتوازي تُعتبر المسار الرئيسي الذي يوازن بين توافق البيئة وتحسين أداء التنفيذ، وهي تتجه لتصبح اتجاهًا مهمًا في الجولة الجديدة من التطوير. تعتبر Monad و MegaETH من أبرز المشاريع في هذا الاتجاه، حيث تبنيان هيكل معالجة EVM بالتوازي الموجه نحو السيناريوهات عالية التزامن وعالية القدرة على التنفيذ من خلال تنفيذ متأخر وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل Layer1 عالية الأداء تم إعادة تصميمها لآلة Ethereum الافتراضية (EVM) ، تستند إلى مفهوم المعالجة المتوازية الأساسية (Pipelining) ، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) ، بينما يتم تنفيذ طبقة التنفيذ بشكل متزامن متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك ، في طبقة التوافق وطبقة التخزين ، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل.
Pipelining: آلية التنفيذ المتوازي عبر خطوط أنابيب متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ blockchain إلى عدة مراحل مستقلة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يصل إلى تحقيق زيادة في معدل النطاق وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) والتقديم إلى الكتلة (Commit).
التنفيذ غير المتزامن: الإجماع - تنفيذ فك الارتباط غير المتزامن
في السلاسل التقليدية، عادةً ما تكون عملية التوافق والتنفيذ متزامنة، مما يحد بشكل كبير من قدرة الأداء. حققت Monad توافقًا غير متزامن في طبقة التوافق، وتنفيذًا غير متزامن في طبقة التنفيذ، وتخزينًا غير متزامن. مما أدى إلى تقليل كبير في زمن الكتل (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وكفاءة استخدام الموارد أعلى.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: تنفيذ متوازي متفائل
يستخدم Ethereum التقليدي نموذج تسلسلي صارم لتنفيذ المعاملات لتجنب تعارض الحالة. بينما تتبنى Monad استراتيجية «التنفيذ المتوازي المتفائل»، مما يعزز بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
اختار الموناد مسار متوافق: تقليل تغيير قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة، واكتشاف الصراعات ديناميكياً لتحقيق التوازي، مما يجعله أكثر شبهاً بإيثريوم النسخة السريعة، مع نضج جيد يسهل تنفيذ انتقال النظام البيئي لـ EVM، وهو مسرع التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومتوازية وقابلة للتعديل متوافقة مع EVM، يمكن أن تعمل ككتلة عامة مستقلة L1، أو كطبقة تعزيز تنفيذ على إيثيريوم (Execution Layer) أو كمكون قابل للتعديل. الهدف الأساسي من تصميمها هو تفكيك منطق الحسابات وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ عالي التزامن داخل السلسلة واستجابة ذات تأخير منخفض. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة (Directed Acyclic Graph) وآلية التزامن القابلة للتعديل، والتي تبني معًا نظام تنفيذ متوازي موجه نحو "التخييط داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
أدخلت MegaETH نموذج تنفيذ "مايكرو-آلة افتراضية لكل حساب"، مما يجعل بيئة التنفيذ "خيطية"، ويقدم وحدة العزل الأدنى لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها من خلال الرسائل غير المتزامنة، بدلاً من الاستدعاءات المتزامنة، حيث يمكن للعديد من الآلات الافتراضية التنفيذ بشكل مستقل وتخزين مستقل، مما يتيح التوازي الطبيعي.
اعتماد الدولة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي. كل عملية تداول تعدل أي حسابات، وتقرأ أي حسابات، يتم نمذجتها بالكامل كعلاقات اعتماد. يمكن تنفيذ العمليات التجارية التي لا تتعارض مباشرة بشكل متوازي، بينما سيتم جدولة العمليات التجارية التي لها علاقات اعتماد وفقًا لترتيب طوبولوجي بشكل تسلسلي أو مؤجل. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المكررة أثناء عملية التنفيذ المتوازي.
تنفيذ غير متزامن وآلية الاسترجاع
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يقوم MegaETH بتجاوز نموذج آلة الحالة ذات الخيط الواحد التقليدي لـ EVM، حيث يحقق تغليفًا صغيرًا للآلة الافتراضية على مستوى الحسابات، ويقوم بجدولة المعاملات من خلال رسم الاعتماد على الحالة، ويستبدل آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنه منصة حساب متوازٍ تم إعادة تصميمها من "هيكل الحساب → هيكل الجدولة → سير التنفيذ" على جميع الأبعاد، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: حيث يتم تجريد الحسابات والعقود إلى VM مستقل، مما يحرر الإمكانيات القصوى للتوازي من خلال جدولة التنفيذ غير المتزامن. من الناحية النظرية، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في السيطرة على التعقيد، ويشبه إلى حد كبير نظام التشغيل الموزع الفائق تحت فكرة الإيثيريوم.
تختلف فلسفة تصميم Monad و MegaETH بشكل كبير عن التجزئة (Sharding): تقوم التجزئة بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة (التجزئة Shards)، حيث تتولى كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، مع التوسع الأفقي فقط في طبقة التنفيذ، مما يحقق تحسينات في الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على تحسين مسار الإنتاجية، بهدف أساسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وعمارة ميكرو-آلة افتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network شبكة بلوكشين من المستوى الأول (L1) متوازية، كاملة المكونات، وآلية الحوسبة المتوازية الأساسية لها تُعرف باسم "Rollup Mesh". تدعم هذه البنية العمل المشترك بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة الآلات الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية المعرفة (ZK) وبيئات التنفيذ الموثوقة (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh: