خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هو أفضل حل للتوسع الأصلي؟
1. خلفية وتحديات الحوسبة المتوازية في البلوكتشين
يظهر "مثلث عدم الإمكانية" في تقنية البلوكشين (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة البلوكشين، مما يعني أن مشاريع البلوكشين تواجه صعوبة في تحقيق "أقصى درجات الأمان، ومشاركة الجميع، ومعالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع"، فإن الحلول السائدة لتوسيع البلوكشين في السوق الحالية تصنف وفقًا للنموذج، بما في ذلك:
تنفيذ التوسع المعزز: تحسين القدرة التنفيذية في الموقع، مثل المعالجة المتوازية، GPU، تعدد النواة
توسيع فاصل الحالة: تقسيم أفقي للحالة / شارد، مثل الشظايا، UTXO، شبكات فرعية متعددة
توسيع نوع التعاقد الخارجي: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع غير متصل بالهيكل: نمذجة معمارية، تشغيل متعاون، مثل سلسلة الوحدات، المرتب المشترك، Rollup Mesh
توسيع متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل غير الحالة، وما إلى ذلك، تغطي عدة مستويات من التنفيذ، الحالة، البيانات، والهيكل، وهي نظام كامل لتوسيع "التعاون متعدد المستويات، وتكوين المكونات". بينما تركز هذه المقالة على طريقة التوسيع التي تعتمد بشكل رئيسي على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تصنيف طرق التوسع إلى خمسة فئات، تمثل كل فئة طموحات أداء مختلفة، ونماذج تطوير وفلسفات معمارية مختلفة، حيث يصبح حجم التوازي أكثر دقة، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، كما تزداد تعقيد البرمجة وصعوبة التنفيذ.
مستوى الحساب المتوازي (Account-level): يمثل مشروع سولانا
التوازي على مستوى الكائن (Object-level): يمثل مشروع Sui
المعاملات المتوازية (Transaction-level): تمثل المشروع Monad، Aptos
مستوى الاستدعاء / MicroVM المتوازي (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 هو المفهوم الأساسي لتنفيذ Monad بالتوازي، حيث يتمثل جوهر الفكرة في تقسيم عملية تنفيذ blockchain إلى عدة مراحل مستقلة، ومعالجة هذه المراحل بشكل متوازٍ، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويصل في النهاية إلى زيادة القدرة على المعالجة وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: التوافق - تنفيذ فك الارتباط غير المتزامن
في السلاسل التقليدية، فإن توافق المعاملات والتنفيذ غالباً ما يكون عملية متزامنة، وهذا النموذج التسلسلي يحد بشكل كبير من قدرة الأداء. قامت Monad بتحقيق تنفيذ غير متزامن على مستوى التوافق، وتنفيذ غير متزامن على مستوى التنفيذ، وتخزين غير متزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقد.
عملية التنفيذ (طبقة التنفيذ) تُ triggered بشكل غير متزامن بعد اكتمال الإجماع.
بعد إتمام الإجماع، يتم الدخول مباشرة في عملية إجماع الكتلة التالية دون الحاجة إلى انتظار تنفيذ العملية.
تستخدم الإيثيريوم التقليدية نموذجًا صارمًا للتسلسل في تنفيذ المعاملات لتجنب تضارب الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
Monad ستقوم بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، على افتراض أن معظم المعاملات لا تحتوي على صراعات حالة.
تشغيل "كاشف التعارضات (Conflict Detector))" لمراقبة ما إذا كانت المعاملات تصل إلى نفس الحالة (مثل تعارضات القراءة / الكتابة).
إذا تم الكشف عن تعارض، فسيتم تسلسل إعادة تنفيذ المعاملة المتعارضة للتأكد من صحة الحالة.
اختارت Monad مسارًا متوافقًا: تقليل التعديلات على قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة، واكتشاف التعارضات ديناميكيًا لتحقيق التوازي، مما يجعلها أشبه بإيثيريوم عالي الأداء، مع مستوى نضج يسهل تحقيق انتقال النظام البيئي لـ EVM، إنها معجل التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لـ MegaETH
بالإضافة إلى تحديد L1 الذي يختلف عن Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء متوازية ومتوافقة مع EVM، والتي يمكن أن تعمل كشبكة عامة مستقلة من L1، أو كطبقة تنفيذ معززة على Ethereum، أو كمكون معياري. الهدف الرئيسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ عالي التزامن واستجابة منخفضة التأخير داخل السلسلة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني موجه غير دوري يعتمد على الحالة) وآلية مزامنة معيارية، لبناء نظام تنفيذ متوازي يركز على "تعدد الخيوط داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
ميغا إيث (MegaETH) قدمت نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)"، مما يجعل بيئة التنفيذ "مُجزأة"، وتوفر الحد الأدنى من وحدات العزل لجدولة متوازية. تتواصل هذه الآلات الافتراضية عبر الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها طبيعية ومتوازية.
آلية جدولة مدفوعة بالرسم البياني التبادلي للاعتماد: DAG
بنيت 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 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
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 9
أعجبني
9
4
مشاركة
تعليق
0/400
NotAFinancialAdvice
· منذ 1 س
لقد مرت سنوات عديدة ولا يزال هناك هذه الأسئلة الثلاثة فقط، حتى أن فيتاليك لم يتمكن من حلها.
شاهد النسخة الأصليةرد0
GasGuzzler
· 07-17 13:58
من قال إن المثلث يجب أن يختار اثنين فقط؟ لنضف بعض الابتكارات الجذرية~
مشهد سباق الحوسبة المتوازية في Web3: كيف يمكن لسلاسل EVM المتوافقة أن تتجاوز حدود الأداء
خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هو أفضل حل للتوسع الأصلي؟
1. خلفية وتحديات الحوسبة المتوازية في البلوكتشين
يظهر "مثلث عدم الإمكانية" في تقنية البلوكشين (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة البلوكشين، مما يعني أن مشاريع البلوكشين تواجه صعوبة في تحقيق "أقصى درجات الأمان، ومشاركة الجميع، ومعالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع"، فإن الحلول السائدة لتوسيع البلوكشين في السوق الحالية تصنف وفقًا للنموذج، بما في ذلك:
تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل غير الحالة، وما إلى ذلك، تغطي عدة مستويات من التنفيذ، الحالة، البيانات، والهيكل، وهي نظام كامل لتوسيع "التعاون متعدد المستويات، وتكوين المكونات". بينما تركز هذه المقالة على طريقة التوسيع التي تعتمد بشكل رئيسي على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (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 هو المفهوم الأساسي لتنفيذ Monad بالتوازي، حيث يتمثل جوهر الفكرة في تقسيم عملية تنفيذ blockchain إلى عدة مراحل مستقلة، ومعالجة هذه المراحل بشكل متوازٍ، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويصل في النهاية إلى زيادة القدرة على المعالجة وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: التوافق - تنفيذ فك الارتباط غير المتزامن
في السلاسل التقليدية، فإن توافق المعاملات والتنفيذ غالباً ما يكون عملية متزامنة، وهذا النموذج التسلسلي يحد بشكل كبير من قدرة الأداء. قامت Monad بتحقيق تنفيذ غير متزامن على مستوى التوافق، وتنفيذ غير متزامن على مستوى التنفيذ، وتخزين غير متزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
التنفيذ الموازي المتفائل: التنفيذ المتوازي المتفائل
تستخدم الإيثيريوم التقليدية نموذجًا صارمًا للتسلسل في تنفيذ المعاملات لتجنب تضارب الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسارًا متوافقًا: تقليل التعديلات على قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة، واكتشاف التعارضات ديناميكيًا لتحقيق التوازي، مما يجعلها أشبه بإيثيريوم عالي الأداء، مع مستوى نضج يسهل تحقيق انتقال النظام البيئي لـ EVM، إنها معجل التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لـ MegaETH
بالإضافة إلى تحديد L1 الذي يختلف عن Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء متوازية ومتوافقة مع EVM، والتي يمكن أن تعمل كشبكة عامة مستقلة من L1، أو كطبقة تنفيذ معززة على Ethereum، أو كمكون معياري. الهدف الرئيسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ عالي التزامن واستجابة منخفضة التأخير داخل السلسلة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني موجه غير دوري يعتمد على الحالة) وآلية مزامنة معيارية، لبناء نظام تنفيذ متوازي يركز على "تعدد الخيوط داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
ميغا إيث (MegaETH) قدمت نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)"، مما يجعل بيئة التنفيذ "مُجزأة"، وتوفر الحد الأدنى من وحدات العزل لجدولة متوازية. تتواصل هذه الآلات الافتراضية عبر الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها طبيعية ومتوازية.
آلية جدولة مدفوعة بالرسم البياني التبادلي للاعتماد: DAG
بنيت 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 Network شبكة بلوكتشين من الطبقة الأولى (L1) متوازية، شاملة، وآلية الحوسبة المتوازية الأساسية فيها تُعرف باسم "Rollup Mesh". تدعم هذه البنية العمل المشترك بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، كما تدعم بيئات متعددة للآلة الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل إثبات المعرفة الصفرية (ZK) وبيئة التنفيذ الموثوقة (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh: