خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هو أفضل حل للتوسع الأصلي؟
1. الخلفية: الموضوع الدائم لتوسيع نطاق البلوكشين
"مثلث" عدم الإمكانية في blockchain (Blockchain Trilemma) "الأمان"، "اللامركزية"، و"قابلية التوسع" يكشف عن التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أن مشاريع blockchain من الصعب تحقيق "أقصى أمان، مشاركة للجميع، معالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع"، هناك حاليًا حلول توسيع blockchain السائدة في السوق مصنفة وفقًا للنموذج، بما في ذلك:
تنفيذ التوسع المعزز: تحسين القدرة التنفيذية في المكان، مثل المعالجة المتوازية، GPU، والأنوية المتعددة
توسيع العزل الحالة: تقسيم أفقي للحالة / شارد، مثل التقسيم، UTXO، والشبكات الفرعية المتعددة
توسيع نوع التعهيد خارج السلسلة: تنفيذ العمليات خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع بنية مفككة: نمذجة معمارية، تشغيل متزامن، مثل سلسلة الوحدات، مرتب مشترك، Rollup Mesh
التوسيع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، وسلاسل غير متزامنة متعددة الخيوط
تشمل حلول توسيع نطاق blockchain: الحوسبة المتوازية داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل عديم الحالة، وغيرها، مما يغطي مستويات متعددة مثل التنفيذ، الحالة، البيانات، والبنية، وهو نظام توسيع "تعاوني متعدد الطبقات، وتجميع وحدات" كامل. بينما تركز هذه المقالة على طريقة التوسع السائدة التي تعتمد على الحوسبة المتوازية.
الحساب المتوازي داخل السلسلة (intra-chain parallelism)، يركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، حيث تمثل كل فئة طموحات أداء مختلفة، ونماذج تطوير وفلسفات معمارية مختلفة، مع تزايد درجة توازي الجسيمات، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، وزيادة تعقيد البرمجة وصعوبة التنفيذ.
التوازي على مستوى الحساب (Account-level): يمثل مشروع سولانا
التوازي على مستوى الكائن (Object-level): يمثل مشروع سوي
مستوى المعاملات (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 عالية الأداء تم إعادة تصميمها لآلة 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 الخاص بـ MegaETH عن Monad، حيث يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وقابلة للتعديل ومتوافقة مع EVM، يمكن أن تعمل ككتلة عامة مستقلة L1 أو كطبقة تعزيز تنفيذ على إيثريوم أو كمكونات قابلة للتعديل. الهدف الأساسي من تصميمها هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني يعتمد على الحالة بدون دائرة) وآلية تزامن قابلة للتعديل، وكلها تشكل نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".
معمارية Micro-VM (الميكرو آلة الافتراضية): الحساب هو الخيط
أدخل MegaETH نموذج التنفيذ "مايكرو-آلة افتراضية واحدة لكل حساب"، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويقدم أدنى وحدة عزل لتوفير جدولة متوازية. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (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 شبكة بلوكتشين من الطبقة الأولى (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
3
مشاركة
تعليق
0/400
AirdropHunterZhang
· منذ 23 س
تكاليف الكهرباء مرتفعة، الجميع مشارك عالم العملات الرقمية أفضل من فتح تعدين الكود.
شاهد النسخة الأصليةرد0
MidnightSeller
· منذ 23 س
شربت بضع زجاجات من البيرة وأشعر أن rollup يمكنه أيضًا إنقاذ العالم.
Web3 الحوسبة المتوازية: تحليل خمسة مسارات تقنية و突破 الأداء
خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هو أفضل حل للتوسع الأصلي؟
1. الخلفية: الموضوع الدائم لتوسيع نطاق البلوكشين
"مثلث" عدم الإمكانية في blockchain (Blockchain Trilemma) "الأمان"، "اللامركزية"، و"قابلية التوسع" يكشف عن التوازن الجوهري في تصميم أنظمة 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 عالية الأداء تم إعادة تصميمها لآلة 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 الخاص بـ MegaETH عن Monad، حيث يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وقابلة للتعديل ومتوافقة مع EVM، يمكن أن تعمل ككتلة عامة مستقلة L1 أو كطبقة تعزيز تنفيذ على إيثريوم أو كمكونات قابلة للتعديل. الهدف الأساسي من تصميمها هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني يعتمد على الحالة بدون دائرة) وآلية تزامن قابلة للتعديل، وكلها تشكل نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".
معمارية Micro-VM (الميكرو آلة الافتراضية): الحساب هو الخيط
أدخل MegaETH نموذج التنفيذ "مايكرو-آلة افتراضية واحدة لكل حساب"، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويقدم أدنى وحدة عزل لتوفير جدولة متوازية. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (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 شبكة بلوكتشين من الطبقة الأولى (L1) متوازية بالكامل، تُعرف آلية الحوسبة المتوازية الأساسية فيها باسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة للآلة الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات ذات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh: