صورة شاملة لميدان الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟
تُظهر "مثلث عدم الإمكانية" في blockchain (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، ومشاركة للجميع، ومعالجة سريعة" في آن واحد. في ما يتعلق بموضوع "قابلية التوسع"، يتم تصنيف الحلول الرئيسية لتوسيع blockchain المتاحة في السوق حاليًا وفقًا للنموذج، بما في ذلك:
تنفيذ التوسع المعزز: رفع القدرة التنفيذية في الموقع، مثل التوازي، GPU، والأنوية المتعددة
نوع التوسيع المعزول عن الحالة: تقسيم أفقي للحالة / شارد، مثل التقسيم، UTXO، العديد من الشبكات الفرعية
التوسع الخارجي من نوع التعهيد: تنفيذ العمليات خارج السلسلة، مثل Rollup، Coprocessor، DA
توسع هيكلية مفككة: نمذجة معمارية، تشغيل متزامن، مثل سلسلة الوحدات، مرتب مشترك، شبكة رول أب
توسيع متزامن غير متزامن: نموذج Actor، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع سلسلة الكتل: الحوسبة المتوازية داخل السلسلة، 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 أو التقسيم التي نعرفها جيدًا آليات تزامن على مستوى النظام، فهي لا تتعلق بالحساب المتوازي داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها مع ذلك لمقارنة الاختلافات في مفاهيم الهيكل.
2. سلسلة التحسين المتوازي EVM: اختراق حدود الأداء في التوافق
على مدى تطور بنية المعالجة المتسلسلة للإيثريوم، شهدت محاولات توسيع متعددة مثل التقسيم، Rollup، والبنية المعمارية المودولية، لكن لا يزال اختناق قدرة التنفيذ يمثل تحديًا رئيسيًا لم يتم التغلب عليه بشكل جذري. ومع ذلك، لا يزال EVM و Solidity هما المنصتان الأكثر شعبية من حيث قاعدة المطورين وإمكانات النظام البيئي لعقود الذكاء. لذلك، فإن سلسلة تعزيزي EVM المتوازية، التي توازن بين توافق النظام البيئي وتحسين أداء التنفيذ، أصبحت اتجاهًا مهمًا في الجولة الجديدة من التطوير. ويعد كل من Monad و MegaETH من المشاريع الأكثر تمثيلًا في هذا الاتجاه، حيث يبنيان بنية المعالجة المتوازية لـ EVM مع التركيز على التنفيذ المؤجل وتفكيك الحالة بهدف دعم السيناريوهات عالية التزامن وعالية القدرة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل عالية الأداء من الطبقة الأولى مصممة من جديد لآلة الإيثيريوم الافتراضية (EVM)، تستند إلى مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الاجماع بشكل غير متزامن (Asynchronous Execution) في طبقة الاجماع، وتنفيذ متوازي متفائل (Optimistic Parallel Execution) في طبقة التنفيذ. بالإضافة إلى ذلك، في طبقة الاجماع والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا شاملاً من النهاية إلى النهاية.
Pipelining: آلية التنفيذ المتوازي عبر خطوط أنابيب متعددة المراحل
Pipelining هو الفكرة الأساسية لتنفيذ الموناد بالتوازي، وتتمثل الفكرة الأساسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بشكل متوازي، مما يخلق هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يصل إلى تحسين الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) ، التوصل إلى توافق (Consensus) ، تنفيذ المعاملات (Execution) ، وتقديم الكتل (Commit).
التنفيذ غير المتزامن: التوافق - تنفيذ فصل غير متزامن
في السلاسل التقليدية، عادة ما تكون عملية توافق المعاملات والتنفيذ عملية متزامنة، وهذا النموذج التسلسلي يحد بشكل كبير من قابلية التوسع في الأداء. من خلال "التنفيذ غير المتزامن"، تحقق Monad توافق الطبقة العلوية بشكل غير متزامن، وتنفيذ الطبقة العلوية بشكل غير متزامن، والتخزين بشكل غير متزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وكفاءة استخدام الموارد أعلى.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقود.
عملية التنفيذ (طبقة التنفيذ) يتم تفعيلها بشكل غير متزامن بعد اكتمال الإجماع.
بعد الانتهاء من التوافق، يتم الدخول مباشرة في عملية توافق الكتلة التالية دون الحاجة إلى انتظار الانتهاء من التنفيذ.
التنفيذ المتوازي المتفائل
تستخدم الإثريوم التقليدية نموذجًا صارمًا للتنفيذ التسلسلي للمعاملات لتجنب تعارض الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
Monad ستقوم بالتنفيذ المتوازي المتفائل لجميع المعاملات، على افتراض أنه لا يوجد تعارض بين معظم المعاملات.
تشغيل "كاشف التعارضات (Conflict Detector))" في نفس الوقت لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة (مثل تعارضات القراءة / الكتابة).
إذا تم اكتشاف تعارض، فسيتم تسلسل إعادة تنفيذ المعاملات المتعارضة لضمان صحة الحالة.
موناد اختار مسار متوافق: تقليل التغييرات في قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة واكتشاف التعارضات بشكل ديناميكي خلال عملية التنفيذ لتحقيق التوازي، مما يجعله أشبه بإيثريوم النسخة عالية الأداء، النضج الجيد يسهل انتقال نظام EVM البيئي، وهو مسرع التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لـ MegaETH
يختلف تحديد L1 الخاص بـ MegaETH عن Monad ، حيث يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومواءمة EVM يمكن أن تعمل كشبكة عامة L1 مستقلة أو كطبقة تعزيز تنفيذ على Ethereum أو مكون معياري. الهدف الرئيسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل ، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني معتمد على الحالة) وآلية تزامن معيارية ، التي تشكل معًا نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".
بنية 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 تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز المزيد من قابلية التوسع والأداء للنظام.
إجماع معياري وآلية إعادة الرهانات (Modular Consensus & Restaking): قدم Pharos آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT و PoS و PoA) وتحقق من خلال بروتوكول إعادة الرهانات (Restaking) الاتصال بين الشبكة الرئيسية و SPNs.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
5
إعادة النشر
مشاركة
تعليق
0/400
0xOverleveraged
· منذ 16 س
مثلث حقاً غير ممكن، إذا تم تحسين الأساس، أليس هذا هو الحل؟
شاهد النسخة الأصليةرد0
TokenomicsTrapper
· منذ 22 س
مجرد كتاب مدرسي آخر عن قابلية التوسع l2 بصراحة... لقد أطلقت على هذا النمط بالضبط قبل عدة أشهر
شاهد النسخة الأصليةرد0
BridgeNomad
· منذ 22 س
*sigh* حل تحجيم آخر يحتاج إلى الجسور عبر السلسلة... ما زلت أعاني من اضطراب ما بعد الصدمة من وورم هول للتو
شاهد النسخة الأصليةرد0
just_another_fish
· منذ 22 س
مرة أخرى يأتي لاعب محترف L2
شاهد النسخة الأصليةرد0
ImpermanentPhilosopher
· منذ 22 س
قابلية التوسع هي موضوع متكرر، كلما زاد عدد المستخدمين، حتى أفضل سلسلة ستضطر للركوع.
مشهد الحساب المتوازي في Web3: من توسيع EVM إلى بنية Rollup Mesh
صورة شاملة لميدان الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟
تُظهر "مثلث عدم الإمكانية" في blockchain (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، ومشاركة للجميع، ومعالجة سريعة" في آن واحد. في ما يتعلق بموضوع "قابلية التوسع"، يتم تصنيف الحلول الرئيسية لتوسيع blockchain المتاحة في السوق حاليًا وفقًا للنموذج، بما في ذلك:
تشمل حلول توسيع سلسلة الكتل: الحوسبة المتوازية داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكل المعياري، نظام Actor، ضغط zk، الهيكل بدون حالة، وغيرها، مما يغطي عدة مستويات مثل التنفيذ، الحالة، البيانات، والبنية، وهو نظام توسيع كامل يتكون من "تعاون متعدد المستويات وتركيبات معيارية". تركز هذه المقالة على طرق التوسع الرئيسية التي تعتمد على الحوسبة المتوازية.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة منها طموحات أداء مختلفة، ونماذج تطوير وفلسفات معمارية مختلفة، مع تزايد دقة التوازي وزيادة شدة التوازي، وكذلك زيادة تعقيد الجدولة، وزيادة تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، والذي يتم تمثيله بنظام الكائنات الذكية (نموذج الوكيل / الكائن)، ينتمي إلى نمط آخر من الحساب المتوازي، كنظام رسائل عبر السلاسل / غير متزامن (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل كـ "عملية كائن ذكي" مستقلة، ويقوم بإرسال الرسائل بطريقة غير متزامنة، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
بينما تعتبر حلول Rollup أو التقسيم التي نعرفها جيدًا آليات تزامن على مستوى النظام، فهي لا تتعلق بالحساب المتوازي داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها مع ذلك لمقارنة الاختلافات في مفاهيم الهيكل.
2. سلسلة التحسين المتوازي EVM: اختراق حدود الأداء في التوافق
على مدى تطور بنية المعالجة المتسلسلة للإيثريوم، شهدت محاولات توسيع متعددة مثل التقسيم، Rollup، والبنية المعمارية المودولية، لكن لا يزال اختناق قدرة التنفيذ يمثل تحديًا رئيسيًا لم يتم التغلب عليه بشكل جذري. ومع ذلك، لا يزال EVM و Solidity هما المنصتان الأكثر شعبية من حيث قاعدة المطورين وإمكانات النظام البيئي لعقود الذكاء. لذلك، فإن سلسلة تعزيزي EVM المتوازية، التي توازن بين توافق النظام البيئي وتحسين أداء التنفيذ، أصبحت اتجاهًا مهمًا في الجولة الجديدة من التطوير. ويعد كل من Monad و MegaETH من المشاريع الأكثر تمثيلًا في هذا الاتجاه، حيث يبنيان بنية المعالجة المتوازية لـ EVM مع التركيز على التنفيذ المؤجل وتفكيك الحالة بهدف دعم السيناريوهات عالية التزامن وعالية القدرة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل عالية الأداء من الطبقة الأولى مصممة من جديد لآلة الإيثيريوم الافتراضية (EVM)، تستند إلى مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الاجماع بشكل غير متزامن (Asynchronous Execution) في طبقة الاجماع، وتنفيذ متوازي متفائل (Optimistic Parallel Execution) في طبقة التنفيذ. بالإضافة إلى ذلك، في طبقة الاجماع والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا شاملاً من النهاية إلى النهاية.
Pipelining: آلية التنفيذ المتوازي عبر خطوط أنابيب متعددة المراحل
Pipelining هو الفكرة الأساسية لتنفيذ الموناد بالتوازي، وتتمثل الفكرة الأساسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بشكل متوازي، مما يخلق هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يصل إلى تحسين الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) ، التوصل إلى توافق (Consensus) ، تنفيذ المعاملات (Execution) ، وتقديم الكتل (Commit).
التنفيذ غير المتزامن: التوافق - تنفيذ فصل غير متزامن
في السلاسل التقليدية، عادة ما تكون عملية توافق المعاملات والتنفيذ عملية متزامنة، وهذا النموذج التسلسلي يحد بشكل كبير من قابلية التوسع في الأداء. من خلال "التنفيذ غير المتزامن"، تحقق Monad توافق الطبقة العلوية بشكل غير متزامن، وتنفيذ الطبقة العلوية بشكل غير متزامن، والتخزين بشكل غير متزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وكفاءة استخدام الموارد أعلى.
التصميم الأساسي:
التنفيذ المتوازي المتفائل
تستخدم الإثريوم التقليدية نموذجًا صارمًا للتنفيذ التسلسلي للمعاملات لتجنب تعارض الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
موناد اختار مسار متوافق: تقليل التغييرات في قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة واكتشاف التعارضات بشكل ديناميكي خلال عملية التنفيذ لتحقيق التوازي، مما يجعله أشبه بإيثريوم النسخة عالية الأداء، النضج الجيد يسهل انتقال نظام EVM البيئي، وهو مسرع التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لـ MegaETH
يختلف تحديد L1 الخاص بـ MegaETH عن Monad ، حيث يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومواءمة EVM يمكن أن تعمل كشبكة عامة L1 مستقلة أو كطبقة تعزيز تنفيذ على Ethereum أو مكون معياري. الهدف الرئيسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل ، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني معتمد على الحالة) وآلية تزامن معيارية ، التي تشكل معًا نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".
بنية 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: