خريطة بانورامية لمسار حسابات Web3 المتوازية: هل هي أفضل حل للتوسع الأصلي؟
1. جوهر توسيع blockchain والحوسبة المتوازية
تُظهر "مثلث المستحيل" في blockchain (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain. فيما يتعلق بموضوع "قابلية التوسع" الذي لا ينتهي، فإن الحلول الرائجة لتوسيع blockchain في السوق الحالية تُصنف حسب النماذج، بما في ذلك:
تنفيذ توسيع محسّن: تعزيز القدرة التنفيذية في المكان، مثل المعالجة المتوازية، وحدة معالجة الرسومات، والمعالجات متعددة النواة
عزل الحالة للتوسع: تقسيم أفقي للحالة / الشظية، مثل التجزئة، UTXO، الشبكات الفرعية المتعددة
التوسع من نوع التعهيد خارج السلسلة: نقل التنفيذ إلى خارج السلسلة، مثل Rollup، Coprocessor، DA
توسعة هيكلية غير مرتبطة: نمذجة الهيكل، التشغيل التعاوني، مثل السلاسل النمطية، المُرتب المشترك، شبكة رول أب
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكيل، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع البلوكتشين: الحوسبة المتوازية داخل السلسلة، Rollup، الشظايا، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل عديم الحالة، وما إلى ذلك، والتي تغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهي نظام توسيع "تعاوني متعدد الطبقات ومركب تفاعلي" كامل. بينما يركز هذا المقال على طريقة التوسع التي تعتمد بشكل رئيسي على الحوسبة المتوازية.
الحوسبة المتوازية داخل السلسلة (التوازي داخل السلسلة )، يركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. بناءً على آلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة مطامح أداء مختلفة، ونماذج تطوير، وفلسفات هيكلية، حيث تصبح حبيبات التوازي أكثر دقة، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، بالإضافة إلى ازدياد تعقيد البرمجة وصعوبة التنفيذ.
التوازي على مستوى الحساب (Account-level): يمثل مشروع سولانا
المستوى العنصري المتوازي (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 عالية الأداء مصممة من جديد لآلة Ethereum الافتراضية (EVM) ، تعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining) ، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) ، ويتم تنفيذ الطبقة التنفيذية بالتوازي المتفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك ، في طبقة التوافق وطبقة التخزين ، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل من البداية إلى النهاية.
أنبوب البيانات: آلية تنفيذ متوازية متعددة المراحل
تعتبر Pipelining الفكرة الأساسية لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الأساسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بشكل متوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يحقق تحسين معدل النقل وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
تنفيذ غير متزامن: فك الارتباط بين التوافق والتنفيذ
في السلسلة التقليدية، يكون توافق المعاملات والتنفيذ عادةً عملية متزامنة، مما يحد بشدة من قابلية الأداء للتوسع. تحقق Monad من خلال "التنفيذ غير المتزامن" توافق الطبقة غير المتزامنة، وتنفيذ الطبقة غير المتزامن، والتخزين غير المتزامن. مما يقلل بشكل ملحوظ من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقود.
يتم تشغيل عملية التنفيذ (طبقة التنفيذ) بشكل غير متزامن بعد اكتمال الإجماع.
بعد الانتهاء من الإجماع، يتم الدخول مباشرة إلى عملية إجماع الكتلة التالية دون الحاجة إلى انتظار الانتهاء من التنفيذ.
تنفيذ متوازي متفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذج تنفيذ صارم تسلسلي لتجنب تعارض الحالة. بينما تعتمد مونايد على استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
ستقوم 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) بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها طبيعية ومتوازية.
مخطط الاعتماد على الحالة: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنت MegaETH نظام جدولة DAG قائم على علاقة الوصول إلى حالة الحساب، حيث يحافظ النظام على رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي، حيث يتم نمذجة جميع التغيرات الناتجة عن المعاملات التي تعدل أي حسابات أو تقرأ حسابات معينة كعلاقات اعتماد. يمكن تنفيذ المعاملات غير المتضاربة بشكل متوازي مباشرة، بينما سيتم جدولة المعاملات التي لها علاقات اعتماد بشكل تسلسلي أو مؤجل وفقًا لترتيب الطوبولوجيا. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المتكررة أثناء عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، قامت MegaETH بكسر نموذج آلة الحالة أحادية الخيط التقليدية EVM، من خلال تحقيق تغليف الميكرو VM على أساس الحسابات، وتنفيذ جدولة المعاملات من خلال رسم الاعتماد على الحالة، واستبدال آلية الاستدعاء المتزامن بمكالمات الرسائل غير المتزامنة. إنها منصة حساب متوازٍ مصممة من جميع الأبعاد "هيكل الحساب → هيكل الجدولة → سير التنفيذ"، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: حيث تم تحويل الحسابات والعقود تمامًا إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لتحرير أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر تعقيدًا في التحكم، ويشبه أكثر نظام التشغيل الموزع الفائق تحت مفهوم الإيثريوم.
تختلف فلسفة تصميم Monad و MegaETH بشكل كبير عن التجزئة (Sharding): حيث تقسم التجزئة blockchain إلى عدة سلاسل فرعية مستقلة (Shards) ، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة ، مما يكسر قيود السلسلة الفردية في توسيع مستوى الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الفردية ، فقط في مستوى التنفيذ يتم توسيعها أفقيًا ، مما يكسر الأداء من خلال تحسين التنفيذ المتوازي الداخلي في السلسلة الفردية. يمثل كلاهما اتجاهين مختلفين في مسار توسيع blockchain ، وهما التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على مسارات تحسين الإنتاجية، مع الهدف الأساسي المتمثل في زيادة TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) و بنية الميكرو VM (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.
علاوة على ذلك، فإن Pharos من خلال شجرة Merkle متعددة النسخ، والترميز التفاضلي (Delta Encoding)، وعنوان النسخ (Versioned Addressing) وتقنية دفع ADS (ADS Pushdown)، أعادت بناء نموذج التنفيذ من أسفل محرك التخزين، وأطلقت محرك تخزين عالي الأداء على السلسلة الأصلية Pharos Store، مما يحقق قدرة معالجة عالية السعة، منخفضة الكمون، وقابلة للتحقق بشكل قوي.
بشكل عام، فإن بنية شبكة Rollup الخاصة بـ Pharos من خلال النموذج
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 10
أعجبني
10
6
إعادة النشر
مشاركة
تعليق
0/400
rekt_but_resilient
· منذ 6 س
لا تتحدث عن الأمور الوهمية، فقط قم بالتركيز على التقنية.
شاهد النسخة الأصليةرد0
NewDAOdreamer
· منذ 13 س
المثلث ينقصه رأس واحد فقط.
شاهد النسخة الأصليةرد0
UnluckyMiner
· 08-10 17:15
البقرة مزدهرة ، تذهب إلى الجنة
شاهد النسخة الأصليةرد0
LiquidityWizard
· 08-10 17:15
التوسع هو الطريق
شاهد النسخة الأصليةرد0
CoconutWaterBoy
· 08-10 17:04
هل يمكن أن تضمن التوسعة الأمان؟ لقد خفت...
شاهد النسخة الأصليةرد0
CountdownToBroke
· 08-10 16:51
مرة أخرى أعمل بجد لتوسيع السعة ولكن لا أستطيع التوسع
بانوراما مسار الحوسبة المتوازية: تحليل 5 مسارات تكنولوجية لاختراق أداء EVM
خريطة بانورامية لمسار حسابات Web3 المتوازية: هل هي أفضل حل للتوسع الأصلي؟
1. جوهر توسيع blockchain والحوسبة المتوازية
تُظهر "مثلث المستحيل" في blockchain (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain. فيما يتعلق بموضوع "قابلية التوسع" الذي لا ينتهي، فإن الحلول الرائجة لتوسيع blockchain في السوق الحالية تُصنف حسب النماذج، بما في ذلك:
تشمل حلول توسيع البلوكتشين: الحوسبة المتوازية داخل السلسلة، Rollup، الشظايا، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل عديم الحالة، وما إلى ذلك، والتي تغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهي نظام توسيع "تعاوني متعدد الطبقات ومركب تفاعلي" كامل. بينما يركز هذا المقال على طريقة التوسع التي تعتمد بشكل رئيسي على الحوسبة المتوازية.
الحوسبة المتوازية داخل السلسلة (التوازي داخل السلسلة )، يركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. بناءً على آلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة مطامح أداء مختلفة، ونماذج تطوير، وفلسفات هيكلية، حيث تصبح حبيبات التوازي أكثر دقة، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، بالإضافة إلى ازدياد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثله نظام الوكيل الذكي (نموذج الوكيل / الممثل)، ينتمي إلى نمط حساب متوازي آخر، كونه نظام رسائل غير متزامن عبر السلاسل (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل ك"عملية ذكية مستقلة"، ويتعامل بأسلوب غير متزامن من خلال الرسائل، مدفوعًا بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة 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 الفكرة الأساسية لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الأساسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بشكل متوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يحقق تحسين معدل النقل وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
تنفيذ غير متزامن: فك الارتباط بين التوافق والتنفيذ
في السلسلة التقليدية، يكون توافق المعاملات والتنفيذ عادةً عملية متزامنة، مما يحد بشدة من قابلية الأداء للتوسع. تحقق Monad من خلال "التنفيذ غير المتزامن" توافق الطبقة غير المتزامنة، وتنفيذ الطبقة غير المتزامن، والتخزين غير المتزامن. مما يقلل بشكل ملحوظ من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
تنفيذ متوازي متفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذج تنفيذ صارم تسلسلي لتجنب تعارض الحالة. بينما تعتمد مونايد على استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسار التوافق: تقليل التغييرات في قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة واكتشاف التعارضات بشكل ديناميكي أثناء التنفيذ، مما يجعلها أقرب إلى نسخة الأداء من إيثيريوم، ناضجة وسهلة لتحقيق انتقال النظام البيئي لـ EVM، وهي مسرع التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء متوازية وقابلة للتكيف مع EVM، ويمكن أن تكون بمثابة سلسلة عامة مستقلة L1 أو كطبقة تعزيز تنفيذ على Ethereum (Execution Layer) أو مكونٍ قابل للتعديل. الهدف الأساسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي قدمته 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): حيث تقسم التجزئة blockchain إلى عدة سلاسل فرعية مستقلة (Shards) ، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة ، مما يكسر قيود السلسلة الفردية في توسيع مستوى الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الفردية ، فقط في مستوى التنفيذ يتم توسيعها أفقيًا ، مما يكسر الأداء من خلال تحسين التنفيذ المتوازي الداخلي في السلسلة الفردية. يمثل كلاهما اتجاهين مختلفين في مسار توسيع blockchain ، وهما التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على مسارات تحسين الإنتاجية، مع الهدف الأساسي المتمثل في زيادة TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) و بنية الميكرو VM (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos شبكة بلوكتشين L1 متوازية وموحدة، يُطلق على آلية الحوسبة المتوازية الأساسية فيها اسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة للآلات الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل إثبات المعرفة الصفرية (ZK) وبيئة التنفيذ الموثوقة (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh:
علاوة على ذلك، فإن Pharos من خلال شجرة Merkle متعددة النسخ، والترميز التفاضلي (Delta Encoding)، وعنوان النسخ (Versioned Addressing) وتقنية دفع ADS (ADS Pushdown)، أعادت بناء نموذج التنفيذ من أسفل محرك التخزين، وأطلقت محرك تخزين عالي الأداء على السلسلة الأصلية Pharos Store، مما يحقق قدرة معالجة عالية السعة، منخفضة الكمون، وقابلة للتحقق بشكل قوي.
بشكل عام، فإن بنية شبكة Rollup الخاصة بـ Pharos من خلال النموذج