خريطة شاملة لسباق الحسابات المتوازية في Web3: هل هي أفضل حل للتوسع الأصلي؟
1. نظرة عامة على الحوسبة المتوازية في Web3
مثلث "استحالة" blockchain (Blockchain Trilemma) "الأمان"، "اللامركزية"، "القابلية للتوسع" يكشف عن التوازن الجوهري في تصميم أنظمة blockchain، حيث من الصعب على مشاريع blockchain تحقيق "أمان مطلق، مشاركة للجميع، ومعالجة سريعة" في نفس الوقت. فيما يتعلق بموضوع "القابلية للتوسع" هذا، يتم تصنيف الحلول السائدة لتوسيع blockchain في السوق حاليًا وفقًا للنماذج، بما في ذلك:
تنفيذ التوسع المعزز: تعزيز القدرة التنفيذية في المكان، مثل المعالجة المتوازية، GPU، والمعالجة متعددة النواة
توسيع نموذج عزل الحالة: تقسيم الحالة أفقياً / شارد، مثل التقسيم، UTXO، شبكات فرعية متعددة
توسيع نموذج التعهيد خارج السلسلة: نقل التنفيذ إلى خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع نوع فصل الهيكل: هيكلية وحدات، تشغيل متزامن، مثل سلسلة الوحدات، مرتب مشترك، Rollup Mesh
توسيع متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التقسيم، وحدة DA، الهيكلية المودولارية، نظام Actor، ضغط إثبات zk، الهيكلية عديمة الحالة، وغيرها، مما يغطي مجالات متعددة مثل التنفيذ، الحالة، البيانات، الهيكل، وهو نظام توسيع كامل «تعزيز متعدد الطبقات، تجميع الموديلات». بينما تركز هذه المقالة على أسلوب التوسيع الذي يعتمد بشكل رئيسي على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة معمارية، حيث تصبح درجة توازي الجسيمات أدق، وتزداد شدة التوازي، وتزداد تعقيد الجدولة، ويزداد تعقيد البرمجة وصعوبة التنفيذ.
التوازي على مستوى الحساب (Account-level): يمثل مشروع سولانا
التوازي على مستوى الكائن (Object-level): يمثل المشروع Sui
المستوى المعاملاتي المتوازي (Transaction-level): يمثل المشروع Monad، Aptos
مستوى الاستدعاء / مايكرو VM المتوازي (Call-level / MicroVM): يمثل المشروع MegaETH
التوازي على مستوى التعليمات (Instruction-level): يمثل المشروع GatlingX
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثل بنظام الكيانات الذكية (نموذج الوكيل / الكيان)، ينتمي إلى نمط حسابي موازٍ آخر، كنظام رسائل عبر السلاسل / غير متزامن (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل كـ "عملية كيان مستقلة"، ويتبع نمط رسائل غير متزامن مدفوع بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi.
وخطط التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تنتمي إلى آلية التزامن على مستوى النظام، ولا تنتمي إلى الحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الأنواع من خطط التوسع ليست محور المناقشة في هذه المقالة، ولكننا سنستخدمها مع ذلك للمقارنة بين اختلافات مفاهيم الهيكل.
٢. سلسلة EVM المعززة بالمعالجة المتوازية: اختراق حدود الأداء في التوافق
لقد تطور هيكل المعالجة المتسلسلة في إيثريوم حتى الآن، حيث مر بعدة محاولات لتوسيع النطاق بما في ذلك التجزئة، وRollup، والهياكل المودولارية، ولكن لا يزال عنق الزجاجة في مستوى التنفيذ لم يشهد اختراقًا جذريًا. ومع ذلك، لا يزال EVM وSolidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين وإمكانات النظام البيئي لتطوير العقود الذكية الحالية. لذلك، فإن سلسلة تعزيز EVM المتوازية، التي تأخذ في الاعتبار التوافق البيئي وتحسين الأداء التنفيذي، أصبحت اتجاهًا مهمًا في الجولة الجديدة من تطوير التوسع. تعتبر Monad وMegaETH من بين المشاريع الأكثر تمثيلاً في هذا الاتجاه، حيث تبنيان هيكل معالجة EVM المتوازي المستهدف لمشاهد عالية التزامن وعالية الإنتاجية، بدءًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هي سلسلة كتل من الطبقة الأولى عالية الأداء تم إعادة تصميمها لآلة Ethereum الافتراضية (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 ، أو كطبقة تعزيز تنفيذ على Ethereum (Execution Layer) أو مكون قابل للتعديل. الهدف الأساسي من تصميمها هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل ، لتحقيق تنفيذ عالي التزامن واستجابة منخفضة التأخير داخل السلسلة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني دوري غير متجه) يعتمد على الحالة وآلية التزامن القابلة للتعديل ، والتي تبني معًا نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
تقدم MegaETH نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)"، مما يجعل بيئة التنفيذ "مُتعددة الخيوط"، ويقدم وحدة العزل الأدنى لجدولة متوازية. تتواصل هذه الآلات الافتراضية عبر الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ بشكل مستقل والتخزين بشكل مستقل، مما يجعلها متوازية بشكل طبيعي.
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، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
5
إعادة النشر
مشاركة
تعليق
0/400
TestnetNomad
· 08-18 04:03
التوسع ليس أفضل من شراء بطاقات التعدين مباشرة للحصول على قوة الحوسبة المتوازية.
شاهد النسخة الأصليةرد0
MemecoinResearcher
· 08-16 14:30
بالصراحة، التوازي لن يحل المشكلة الأساسية... لكن مهلاً، الأرقام ترتفع عندما نقول "توسيع وحدة معالجة الرسومات" هاها
بانوراما مسار الحوسبة المتوازية Web3: تقود Monad و MegaETH突破 حدود الأداء لـ EVM
خريطة شاملة لسباق الحسابات المتوازية في Web3: هل هي أفضل حل للتوسع الأصلي؟
1. نظرة عامة على الحوسبة المتوازية في Web3
مثلث "استحالة" blockchain (Blockchain Trilemma) "الأمان"، "اللامركزية"، "القابلية للتوسع" يكشف عن التوازن الجوهري في تصميم أنظمة blockchain، حيث من الصعب على مشاريع blockchain تحقيق "أمان مطلق، مشاركة للجميع، ومعالجة سريعة" في نفس الوقت. فيما يتعلق بموضوع "القابلية للتوسع" هذا، يتم تصنيف الحلول السائدة لتوسيع blockchain في السوق حاليًا وفقًا للنماذج، بما في ذلك:
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التقسيم، وحدة DA، الهيكلية المودولارية، نظام Actor، ضغط إثبات zk، الهيكلية عديمة الحالة، وغيرها، مما يغطي مجالات متعددة مثل التنفيذ، الحالة، البيانات، الهيكل، وهو نظام توسيع كامل «تعزيز متعدد الطبقات، تجميع الموديلات». بينما تركز هذه المقالة على أسلوب التوسيع الذي يعتمد بشكل رئيسي على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة معمارية، حيث تصبح درجة توازي الجسيمات أدق، وتزداد شدة التوازي، وتزداد تعقيد الجدولة، ويزداد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثل بنظام الكيانات الذكية (نموذج الوكيل / الكيان)، ينتمي إلى نمط حسابي موازٍ آخر، كنظام رسائل عبر السلاسل / غير متزامن (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل كـ "عملية كيان مستقلة"، ويتبع نمط رسائل غير متزامن مدفوع بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi.
وخطط التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تنتمي إلى آلية التزامن على مستوى النظام، ولا تنتمي إلى الحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الأنواع من خطط التوسع ليست محور المناقشة في هذه المقالة، ولكننا سنستخدمها مع ذلك للمقارنة بين اختلافات مفاهيم الهيكل.
٢. سلسلة EVM المعززة بالمعالجة المتوازية: اختراق حدود الأداء في التوافق
لقد تطور هيكل المعالجة المتسلسلة في إيثريوم حتى الآن، حيث مر بعدة محاولات لتوسيع النطاق بما في ذلك التجزئة، وRollup، والهياكل المودولارية، ولكن لا يزال عنق الزجاجة في مستوى التنفيذ لم يشهد اختراقًا جذريًا. ومع ذلك، لا يزال EVM وSolidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين وإمكانات النظام البيئي لتطوير العقود الذكية الحالية. لذلك، فإن سلسلة تعزيز EVM المتوازية، التي تأخذ في الاعتبار التوافق البيئي وتحسين الأداء التنفيذي، أصبحت اتجاهًا مهمًا في الجولة الجديدة من تطوير التوسع. تعتبر Monad وMegaETH من بين المشاريع الأكثر تمثيلاً في هذا الاتجاه، حيث تبنيان هيكل معالجة EVM المتوازي المستهدف لمشاهد عالية التزامن وعالية الإنتاجية، بدءًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هي سلسلة كتل من الطبقة الأولى عالية الأداء تم إعادة تصميمها لآلة Ethereum الافتراضية (EVM)، تعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم التنفيذ غير المتزامن في طبقة الإجماع (Asynchronous Execution) والتنفيذ المتفائل (Optimistic Parallel Execution) في طبقة التنفيذ. بالإضافة إلى ذلك، في طبقتي الإجماع والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا من النهاية إلى النهاية.
التدفق: آلية التنفيذ المتوازية متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بالتوازي، وتتمثل فكرته الأساسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بالتوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويهدف في النهاية إلى زيادة السعة وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) الوصول إلى التوافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: التوافق - تنفيذ فصل غير متزامن
في السلاسل التقليدية، عادة ما تكون عملية توافق المعاملات والتنفيذ عملية متزامنة، وهذا النموذج المتسلسل يحد بشدة من أداء التوسع. تحقق Monad "التنفيذ غير المتزامن" في طبقة التوافق غير المتزامن، وطبقة التنفيذ غير المتزامنة، والتخزين غير المتزامن. مما يقلل بشكل كبير من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: التنفيذ المتوازي المتفائل
تستخدم الإيثيريوم التقليدية نموذجًا صارمًا للتنفيذ التسلسلي للمعاملات لتجنب تعارض الحالة. بينما تعتمد Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسارًا متوافقًا: أقل تغيير ممكن في قواعد EVM، حيث يتم تحقيق التوازي من خلال تأخير كتابة الحالة والكشف الديناميكي عن الصراعات خلال عملية التنفيذ، مما يجعلها أكثر شبيهة بإيثريوم الأداء، مما يسهل الانتقال إلى نظام EVM البيئي بفضل نضجها، وهي معجل التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad ، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء قابلة للتعديل ومتوافقة مع 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 ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، 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: