صورة شاملة لمسار الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟
"مثلث Blockchain" (Blockchain Trilemma) يوضح "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أمان مطلق، مشاركة شاملة، ومعالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع"، تتنوع الحلول الشائعة لتوسيع blockchain في السوق الحالية وفقًا للأنماط، بما في ذلك:
تنفيذ تحسين التوسع: تحسين القدرة التنفيذية في المكان، مثل المعالجة المتوازية، GPU، متعدد النواة
تجزئة حالة العزل: تقسيم أفقي للحالة / شارد، مثل التجزئة، UTXO، العديد من الشبكات الفرعية
توسع خارجي من نوع التعاقد الخارجي: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع بنية مفككة: نمذجة هيكلية، تشغيل متزامن، مثل سلسلة وحدات، جهاز ترتيب مشترك، رول أب مESH
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكل المعياري، نظام Actor، ضغط zk proof، الهيكل عديم الحالة، وغيرها، مما يغطي عدة مستويات من التنفيذ، الحالة، البيانات، والهيكل، وهو نظام توسيع كامل "تعاون متعدد الطبقات، وتركيبات معيارية". بينما يركز هذا المقال على طريقة التوسيع الرئيسية التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، حيث تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير وفلسفة معمارية مختلفة، تزداد درجة التوازي تدريجيًا، وتزداد شدة التوازي، كما تزداد تعقيد الجدولة، وتزداد تعقيد البرمجة وصعوبة التنفيذ.
المستوى الحسابي المتوازي (Account-level): يمثل مشروع سولانا
التوازي على مستوى الكائن (Object-level): يمثل مشروع Sui
المستوى المعاملات المتوازي (Transaction-level): يمثل المشروع Monad، Aptos
مستوى الاستدعاء / مايكرو VM المتوازي (Call-level / MicroVM): يمثل مشروع MegaETH
التوازي على مستوى التعليمات (Instruction-level): يمثل مشروع GatlingX
نموذج التوازي غير المتزامن خارج السلسلة، الذي تمثله نظام الذكاء الاصطناعي (نموذج الوكيل / النموذج الممثل) ، ينتمي إلى نمط آخر من حساب التوازي، كنظام رسائل غير متزامنة عبر السلاسل (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل كـ "عملية ذكية مستقلة"، ويتم توجيه الرسائل بطريقة غير متزامنة، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
إن الحلول المعروفة لنا مثل Rollup أو تقسيم التوسع، هي آليات تزامن على مستوى النظام، ولا تتعلق بالحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بالتوازي"، وليس من خلال تحسين درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها لمقارنة الاختلافات في مفاهيم الهندسة.
2. سلسلة تعزيز التوازي EVM: اختراق حدود الأداء في التوافق
تطور هيكل المعالجة المتسلسلة لإيثريوم حتى اليوم، حيث مر بعدة محاولات للتوسع مثل تقسيم الشريحة، وRollup، والهياكل المودولية، ولكن لا تزال هناك عقبة في سعة طبقة التنفيذ لم تُحل بشكل جذري. ومع ذلك، لا يزال EVM وSolidity هما المنصات الأكثر قوة من حيث قاعدة المطورين والقدرات البيئية للذكاء الاصطناعي. لذلك، تعتبر سلسلة EVM المعززة بشكل متوازي كمسار رئيسي يجمع بين التوافق البيئي وتحسين أداء التنفيذ، وهي تتجه لتصبح اتجاهًا مهمًا في دورة جديدة من التوسع. يُعتبر كل من Monad وMegaETH من المشاريع الأكثر تمثيلاً في هذا الاتجاه، حيث يبنيان هيكل معالجة EVM المتوازي المستهدف لمشاهد عالية التزامن وسعة عالية، بدءًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتلة عالية الأداء مصممة من جديد لآلة Ethereum الافتراضية (EVM)، تعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، في طبقة الإجماع التنفيذ غير المتزامن (Asynchronous Execution)، وفي طبقة التنفيذ التنفيذ المتوازي المتفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي الإجماع والتخزين، يقدم Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل من البداية إلى النهاية.
Pipelining: آلية تنفيذ متعددة المراحل بالتوازي
Pipelining هو المفهوم الأساسي لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ سلسلة الكتل إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بشكل متوازٍ، مما يشكل هيكلية خط أنابيب ثلاثية الأبعاد، حيث تعمل كل مرحلة في خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية الوصول إلى تحسين القدرة الاستيعابية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (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 تبعية الحالة (Directed Acyclic Graph) وآلية التزامن القابلة للتعديل، التي تبني معًا نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة."
هيكل Micro-VM (مايكرو-آلة افتراضية): الحساب هو الخيط
قدمت MegaETH نموذج تنفيذ "آلة افتراضية صغيرة (Micro-VM) لكل حساب"، مما يتيح "تعدد خيوط" بيئة التنفيذ، ويقدم وحدة عزل أصغر لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يحقق التوازي بشكل طبيعي.
بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للتبعية (Dependency Graph) في الوقت الحقيقي. كل معاملة تعدل أي حسابات وتقرا أي حسابات، يتم نمذجتها بالكامل كعلاقات تبعية. يمكن تنفيذ المعاملات غير المتضاربة بشكل متوازي مباشرة، بينما يتم جدولة المعاملات التي لها علاقات تبعية وفقًا لترتيب الطوبولوجيا بشكل تسلسلي أو مع تأخير. يضمن رسم التبعية اتساق الحالة وعدم الكتابة المكررة أثناء عملية التنفيذ المتوازية.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بإيجاز، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدي لـ EVM، حيث يتم تنفيذ تغليف الميكرو VM على مستوى الحساب، من خلال جدول زمني للمعاملات يعتمد على رسم الحالة، ويستخدم آلية الرسائل غير المتزامنة بدلاً من مكدس الاستدعاء المتزامن. إنه منصة حوسبة متوازية أعيد تصميمها بشكل كامل من "هيكل الحساب → هيكل الجدولة → سير التنفيذ"، مما يوفر فكرة جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة البناء: حيث يتم تجريد الحسابات والعقود إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لإطلاق أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، ولكنه أيضًا أصعب في التحكم في التعقيد، مما يجعله أشبه بنظام تشغيل موزع فائق تحت فكرة الإيثيريوم.
تختلف فلسفة تصميم Monad و MegaETH بشكل كبير عن تقسيم الشبكة (Sharding): حيث يقوم تقسيم الشبكة بتقسيم سلسلة الكتل أفقياً إلى عدة سلاسل فرعية مستقلة (Shards)، حيث تكون كل سلسلة فرعية مسؤولة عن جزء من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الطبقة الشبكية؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، مع توسيع أفقي فقط في طبقة التنفيذ، مما يتيح تنفيذاً متوازياً داخلياً على أقصى مستوى لتحسين الأداء. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل، أحدهما تعزيز عمودي والآخر توسيع أفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على تحسين مسار الإنتاجية، مع الهدف الأساسي المتمثل في زيادة TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وهندسة الميكرو آلة الافتراضية (Micro-VM) لتحقيق المعالجة المتوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos شبكة بلوكتشين من المستوى الأول (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 تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز قابلية التوسع والأداء للنظام.
توافق معياري وإعادة
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
7
مشاركة
تعليق
0/400
GasSavingMaster
· منذ 4 س
الجميع يتحدث عن توسيع السعة، لكن هل يمكننا أولاً خفض الغاز؟
شاهد النسخة الأصليةرد0
ForkPrince
· منذ 6 س
ثلاثي مستحيل؟ L2yyds!
شاهد النسخة الأصليةرد0
MetaverseLandlady
· منذ 7 س
هذا الـ Rollup حقاً يصبح أكثر تنافسية.
شاهد النسخة الأصليةرد0
GateUser-44a00d6c
· منذ 7 س
ألف مرة رأيت هذا، إنه كلاسيكي جداً
شاهد النسخة الأصليةرد0
GhostAddressMiner
· منذ 7 س
أه، لقد تم فتح المفتاح السري الذي لا يمكن كسره بواسطة خطوط الكم، فما الجدوى من التوسع في هذا المثالية؟ لقد رأيت حيلكم.
شاهد النسخة الأصليةرد0
GamefiEscapeArtist
· منذ 7 س
علقنا L2 لمدة عام وما زلنا نروي القصص.. لا تتحدثوا طوال اليوم عن التوسع.
شاهد النسخة الأصليةرد0
LightningLady
· منذ 7 س
هذا الاقتراح يجعلني أشعر بالارتباك، لقد تم العبث به داخل السلسلة وخارج السلسلة.
Web3 الحوسبة المتوازية: اختراقات وابتكارات حلول توسيع سلسلة EVM
صورة شاملة لمسار الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟
"مثلث Blockchain" (Blockchain Trilemma) يوضح "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أمان مطلق، مشاركة شاملة، ومعالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع"، تتنوع الحلول الشائعة لتوسيع blockchain في السوق الحالية وفقًا للأنماط، بما في ذلك:
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكل المعياري، نظام Actor، ضغط zk proof، الهيكل عديم الحالة، وغيرها، مما يغطي عدة مستويات من التنفيذ، الحالة، البيانات، والهيكل، وهو نظام توسيع كامل "تعاون متعدد الطبقات، وتركيبات معيارية". بينما يركز هذا المقال على طريقة التوسيع الرئيسية التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، حيث تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير وفلسفة معمارية مختلفة، تزداد درجة التوازي تدريجيًا، وتزداد شدة التوازي، كما تزداد تعقيد الجدولة، وتزداد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التوازي غير المتزامن خارج السلسلة، الذي تمثله نظام الذكاء الاصطناعي (نموذج الوكيل / النموذج الممثل) ، ينتمي إلى نمط آخر من حساب التوازي، كنظام رسائل غير متزامنة عبر السلاسل (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل كـ "عملية ذكية مستقلة"، ويتم توجيه الرسائل بطريقة غير متزامنة، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
إن الحلول المعروفة لنا مثل Rollup أو تقسيم التوسع، هي آليات تزامن على مستوى النظام، ولا تتعلق بالحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بالتوازي"، وليس من خلال تحسين درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها لمقارنة الاختلافات في مفاهيم الهندسة.
2. سلسلة تعزيز التوازي EVM: اختراق حدود الأداء في التوافق
تطور هيكل المعالجة المتسلسلة لإيثريوم حتى اليوم، حيث مر بعدة محاولات للتوسع مثل تقسيم الشريحة، وRollup، والهياكل المودولية، ولكن لا تزال هناك عقبة في سعة طبقة التنفيذ لم تُحل بشكل جذري. ومع ذلك، لا يزال EVM وSolidity هما المنصات الأكثر قوة من حيث قاعدة المطورين والقدرات البيئية للذكاء الاصطناعي. لذلك، تعتبر سلسلة EVM المعززة بشكل متوازي كمسار رئيسي يجمع بين التوافق البيئي وتحسين أداء التنفيذ، وهي تتجه لتصبح اتجاهًا مهمًا في دورة جديدة من التوسع. يُعتبر كل من Monad وMegaETH من المشاريع الأكثر تمثيلاً في هذا الاتجاه، حيث يبنيان هيكل معالجة EVM المتوازي المستهدف لمشاهد عالية التزامن وسعة عالية، بدءًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتلة عالية الأداء مصممة من جديد لآلة Ethereum الافتراضية (EVM)، تعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، في طبقة الإجماع التنفيذ غير المتزامن (Asynchronous Execution)، وفي طبقة التنفيذ التنفيذ المتوازي المتفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي الإجماع والتخزين، يقدم Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل من البداية إلى النهاية.
Pipelining: آلية تنفيذ متعددة المراحل بالتوازي
Pipelining هو المفهوم الأساسي لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ سلسلة الكتل إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بشكل متوازٍ، مما يشكل هيكلية خط أنابيب ثلاثية الأبعاد، حيث تعمل كل مرحلة في خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية الوصول إلى تحسين القدرة الاستيعابية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: الإجماع - تنفيذ فك الارتباط غير المتزامن
في السلسلة التقليدية، فإن توافق المعاملات والتنفيذ عادة ما يكونان عملية متزامنة، وهذا النموذج المتسلسل يحد بشدة من توسيع الأداء. حققت Monad "التنفيذ غير المتزامن" للتوافق غير المتزامن، والتنفيذ غير المتزامن، والتخزين غير المتزامن. مما يقلل بشكل كبير من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، ويقسم عملية المعالجة بشكل أفضل، ويزيد من كفاءة استخدام الموارد.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: التنفيذ المتوازي المتفائل
تستخدم الإيثيريوم التقليدية نموذج تنفيذ صارم متسلسل لتجنب تعارض الحالة. بينما تعتمد Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسارًا متوافقًا: الحد الأدنى من التلاعب بقواعد EVM، من خلال تأخير كتابة الحالة، والكشف الديناميكي عن التعارضات لتحقيق التوازي أثناء التنفيذ، مما يجعلها أشبه بإيثريوم للأداء، مع نضوج يسهل تحقيق انتقال إيكولوجيا EVM، وهي مسرع التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وقابلة للتعديل ومتوافقة مع EVM، يمكن أن تعمل كشبكة عامة مستقلة من L1، أو كطبقة تعزيز تنفيذ على إيثيريوم (Execution Layer) أو كعنصر قابل للتعديل. الهدف الأساسي من تصميمها هو تفكيك منطق الحساب، وبيئة التنفيذ، والحالة لعزلها كأصغر وحدة يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ عالي التزامن واستجابة منخفضة التأخير داخل السلسلة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG تبعية الحالة (Directed Acyclic Graph) وآلية التزامن القابلة للتعديل، التي تبني معًا نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة."
هيكل Micro-VM (مايكرو-آلة افتراضية): الحساب هو الخيط
قدمت MegaETH نموذج تنفيذ "آلة افتراضية صغيرة (Micro-VM) لكل حساب"، مما يتيح "تعدد خيوط" بيئة التنفيذ، ويقدم وحدة عزل أصغر لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يحقق التوازي بشكل طبيعي.
مخطط الاعتماد للدولة: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للتبعية (Dependency Graph) في الوقت الحقيقي. كل معاملة تعدل أي حسابات وتقرا أي حسابات، يتم نمذجتها بالكامل كعلاقات تبعية. يمكن تنفيذ المعاملات غير المتضاربة بشكل متوازي مباشرة، بينما يتم جدولة المعاملات التي لها علاقات تبعية وفقًا لترتيب الطوبولوجيا بشكل تسلسلي أو مع تأخير. يضمن رسم التبعية اتساق الحالة وعدم الكتابة المكررة أثناء عملية التنفيذ المتوازية.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بإيجاز، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدي لـ EVM، حيث يتم تنفيذ تغليف الميكرو VM على مستوى الحساب، من خلال جدول زمني للمعاملات يعتمد على رسم الحالة، ويستخدم آلية الرسائل غير المتزامنة بدلاً من مكدس الاستدعاء المتزامن. إنه منصة حوسبة متوازية أعيد تصميمها بشكل كامل من "هيكل الحساب → هيكل الجدولة → سير التنفيذ"، مما يوفر فكرة جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة البناء: حيث يتم تجريد الحسابات والعقود إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لإطلاق أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، ولكنه أيضًا أصعب في التحكم في التعقيد، مما يجعله أشبه بنظام تشغيل موزع فائق تحت فكرة الإيثيريوم.
تختلف فلسفة تصميم Monad و MegaETH بشكل كبير عن تقسيم الشبكة (Sharding): حيث يقوم تقسيم الشبكة بتقسيم سلسلة الكتل أفقياً إلى عدة سلاسل فرعية مستقلة (Shards)، حيث تكون كل سلسلة فرعية مسؤولة عن جزء من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الطبقة الشبكية؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، مع توسيع أفقي فقط في طبقة التنفيذ، مما يتيح تنفيذاً متوازياً داخلياً على أقصى مستوى لتحسين الأداء. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل، أحدهما تعزيز عمودي والآخر توسيع أفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على تحسين مسار الإنتاجية، مع الهدف الأساسي المتمثل في زيادة TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وهندسة الميكرو آلة الافتراضية (Micro-VM) لتحقيق المعالجة المتوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos شبكة بلوكتشين من المستوى الأول (L1) موازية ومتعددة الطبقات، يُعرف آلية الحوسبة المتوازية الأساسية بها باسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة للآلات الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات ذات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh: