صورة شاملة لمجال الحوسبة المتوازية في Web3: هل هي أفضل حل للتوسع الأصلي؟
1. الخلفية التقنية والدوافع لتقنية الحوسبة المتوازية
تظهر "مثلث الاستحالة" في تقنية blockchain "الأمان" و"اللامركزية" و"قابلية التوسع" التوازنات الجوهرية في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة شاملة، ومعالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "قابلية التوسع" الذي لا يزال موضوعًا دائمًا، يتم تصنيف حلول توسيع blockchain السائدة في السوق حاليًا وفقًا للنماذج، بما في ذلك:
تنفيذ التوسع المعزز: تحسين قدرة التنفيذ في المكان، مثل المعالجة المتوازية، GPU، والأنوية المتعددة
توسيع العزل بالحالة: تقسيم أفقي للحالة / شارد، مثل الشظايا، UTXO، الشبكات الفرعية المتعددة
توسيع نموذج التعهيد خارج السلسلة: نقل التنفيذ إلى خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع هيكل فك الارتباط: هيكل معياري، تشغيل متزامن، مثل سلسلة الوحدات، مرتبة مشتركة، Rollup Mesh
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل غير القائم على الحالة، وغيرها، والتي تغطي مستويات متعددة من التنفيذ، الحالة، البيانات، والهيكل، مما يشكل نظام توسيع كامل "تعاون متعدد الطبقات، تجميع وحدات". وتركز هذه المقالة على أسلوب التوسع المعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، حيث تمثل كل فئة سعيًا مختلفًا نحو الأداء، و نموذج تطوير وفلسفة معمارية مختلفة، تتناقص تدريجيًا في حجم التوازي، وتزداد قوة التوازي، وتزداد تعقيد الجدولة، كما تزداد تعقيد البرمجة وصعوبة التنفيذ.
التوازي على مستوى الحساب (Account-level): يمثل المشروع Solana
المستوى الكائن المتوازي (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: آلية تنفيذ متوازية متعددة المراحل
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) أو كمكون قابل للتعديل. الهدف الأساسي من تصميمها هو فصل منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات صغيرة قابلة للجدولة بشكل مستقل، لتحقيق تنفيذ عالي التزامن داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي قدمه MegaETH هو: بنية Micro-VM + DAG (الرسم البياني المعتمد ذو الاتجاهات) التابع للحالة وآلية التزامن القابلة للتعديل، التي تبني معًا نظام تنفيذ متوازي يركز على "تعدد خيوط السلسلة".
بنية Micro-VM (آلة افتراضية صغيرة): الحساب هو الخيط
تقدم MegaETH نموذج تنفيذ «مايكرو-آلة افتراضية لكل حساب» (Micro-VM) ، مما يجعل بيئة التنفيذ «خيوطية» ، ويوفر الحد الأدنى من وحدة العزل لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ بشكل مستقل وتخزين مستقل، وبالتالي تكون متوازية بشكل طبيعي.
أنشأت 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:
معالجة الأنابيب غير المتزامنة على مدار دورة الحياة الكاملة: تقوم Pharos بفصل مراحل المعاملة المختلفة (مثل الإجماع، التنفيذ، التخزين) وتستخدم طريقة المعالجة غير المتزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل ومتوازي، وبالتالي زيادة كفاءة المعالجة الكلية.
التنفيذ الموازٍ لآلتين افتراضيتين (Dual VM Parallel Execution): تدعم Pharos بيئتين افتراضيتين EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة حسب الحاجة. هذه البنية المزدوجة للآلات الافتراضية لا تعزز فقط مرونة النظام، بل تعزز أيضاً قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
الشبكات ذات المعالجة الخاصة (SPNs): تعتبر SPNs مكونًا رئيسيًا في بنية Pharos، تشبه الشبكات الفرعية المودولارية، وتخصص لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق توزيع ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز قابلية توسيع النظام وأدائه.
الإجماع القابل للتعديل وآلية إعادة الرهن (Modular Consensus & Restaking): قدمت Pharos آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT، PoS، PoA
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مشهد سباق الحوسبة المتوازية في Web3: من تعزيز EVM إلى Rollup Mesh
صورة شاملة لمجال الحوسبة المتوازية في Web3: هل هي أفضل حل للتوسع الأصلي؟
1. الخلفية التقنية والدوافع لتقنية الحوسبة المتوازية
تظهر "مثلث الاستحالة" في تقنية blockchain "الأمان" و"اللامركزية" و"قابلية التوسع" التوازنات الجوهرية في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة شاملة، ومعالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "قابلية التوسع" الذي لا يزال موضوعًا دائمًا، يتم تصنيف حلول توسيع blockchain السائدة في السوق حاليًا وفقًا للنماذج، بما في ذلك:
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل غير القائم على الحالة، وغيرها، والتي تغطي مستويات متعددة من التنفيذ، الحالة، البيانات، والهيكل، مما يشكل نظام توسيع كامل "تعاون متعدد الطبقات، تجميع وحدات". وتركز هذه المقالة على أسلوب التوسع المعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، حيث تمثل كل فئة سعيًا مختلفًا نحو الأداء، و نموذج تطوير وفلسفة معمارية مختلفة، تتناقص تدريجيًا في حجم التوازي، وتزداد قوة التوازي، وتزداد تعقيد الجدولة، كما تزداد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، مع نظام الكيانات الذكية (نموذج الوكيل / الكيان) كنموذج رئيسي، حيث ينتمي إلى نوع آخر من أنماط الحوسبة المتوازية، كنظام رسائل غير متزامنة عبر السلاسل (نموذج غير متزامن للكتل)، حيث يعتبر كل وكيل بمثابة "عملية كيان مستقلة"، ويعمل بطريقة غير متزامنة مع الرسائل والأحداث، دون الحاجة إلى جدولة متزامنة، والمشاريع الممثلة تشمل 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: آلية تنفيذ متوازية متعددة المراحل
Pipelining هي الفكرة الأساسية لتنفيذ Monad بشكل متوازي، والفكرة الرئيسية هي تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يصل إلى زيادة السعة وتقليل الكمون. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) والتزام الكتل (Commit).
التنفيذ غير المتزامن: الإجماع - تنفيذ فصل غير متزامن
في السلاسل التقليدية، يعد توافق المعاملات والتنفيذ عادةً عملية متزامنة، وهذا النموذج المتسلسل يحد بشكل كبير من قابلية التوسع في الأداء. من خلال "التنفيذ غير المتزامن"، حقق Monad توافق الطبقة بشكل غير متزامن، والتنفيذ بشكل غير متزامن والتخزين بشكل غير متزامن. مما يقلل بشكل ملحوظ من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: التنفيذ المتوازي المتفائل
تعتمد إيثيريوم التقليدية على نموذج تسلسلي صارم لتنفيذ المعاملات، لتجنب تعارض الحالة. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسار التوافق: تقليل تغييرات قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة، واكتشاف التضارب ديناميكيًا لتحقيق التوازي، مما يجعلها أشبه بإيثريوم المعزز من حيث الأداء، والنضج الجيد يسهل نقل النظام البيئي لـ EVM، وهي معجل التوازي لعالم EVM.
تحليل آلية الحوسبة المتوازية لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومتوازية قابلة للتعديل ومتوافقة مع EVM، يمكن أن تعمل كشبكة عامة مستقلة L1، أو كطبقة تعزيز تنفيذ على إيثيريوم (Execution Layer) أو كمكون قابل للتعديل. الهدف الأساسي من تصميمها هو فصل منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات صغيرة قابلة للجدولة بشكل مستقل، لتحقيق تنفيذ عالي التزامن داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي قدمه MegaETH هو: بنية Micro-VM + DAG (الرسم البياني المعتمد ذو الاتجاهات) التابع للحالة وآلية التزامن القابلة للتعديل، التي تبني معًا نظام تنفيذ متوازي يركز على "تعدد خيوط السلسلة".
بنية Micro-VM (آلة افتراضية صغيرة): الحساب هو الخيط
تقدم MegaETH نموذج تنفيذ «مايكرو-آلة افتراضية لكل حساب» (Micro-VM) ، مما يجعل بيئة التنفيذ «خيوطية» ، ويوفر الحد الأدنى من وحدة العزل لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ بشكل مستقل وتخزين مستقل، وبالتالي تكون متوازية بشكل طبيعي.
الاعتمادية على الرسم البياني الموجه للدالة: آلية جدولة مدفوعة بالرسم البياني
أنشأت 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: