خريطة شاملة لمجال الحوسبة المتوازية في Web3: هل هي أفضل حل للتوسع الأصلي؟
1. لمحة عامة عن سباق الحوسبة المتوازية
تظهر "مثلث عدم الإمكانية" في تقنية البلوكشين "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة البلوكشين، أي أنه من الصعب على مشاريع البلوكشين تحقيق "أمان تام، مشاركة شاملة، ومعالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "قابلية التوسع"، هناك حلول توسيع رئيسية في السوق حاليًا مصنفة حسب النماذج، بما في ذلك:
تنفيذ التوسع المحسن: تعزيز القدرة التنفيذية في نفس المكان، مثل المعالجة المتوازية، GPU، والأنوية المتعددة
توسيع معزول عن الحالة: تقسيم أفقي للحالة، مثل الشظايا، UTXO، والشبكات الفرعية المتعددة
توسيع من نوع التفويض خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع الهيكل المفكك: هيكلية معيارية، تشغيل متزامن، مثل سلسلة الوحدات، مرتب المشاركة، Rollup Mesh
توسيع متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع سلسلة الكتل: الحوسبة المتوازية داخل السلسلة، 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 أو التقسيم، ينتمي إلى آلية التوازي على مستوى النظام، ولا ينتمي إلى الحساب المتوازي داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة/آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، لكننا سنستخدمها لمقارنة أوجه التشابه والاختلاف في المفاهيم المعمارية.
٢. سلسلة تحسين متوازية EVM:突破 حدود الأداء في التوافق
لقد تطور هيكل المعالجة المتسلسلة للإيثريوم حتى الآن، حيث شهد عدة جولات من محاولات التوسع مثل تقسيم الشحنات (sharding) وRollup والهياكل المودولية، لكن لا تزال هناك عوائق في سعة طبقة التنفيذ. ومع ذلك، تظل EVM وSolidity هما المنصتان الأكثر استنادًا إلى المطورين ولديهما طاقة بيئية كبيرة في عالم العقود الذكية. لذلك، فإن سلسلة EVM المعززة بالتوازي، التي توازن بين التوافق البيئي وتحسين أداء التنفيذ، أصبحت الاتجاه المهم في الجولة الجديدة من التطور في التوسع. يعتبر مشروع Monad وMegaETH من بين المشاريع الأكثر تمثيلاً في هذا الاتجاه، حيث يقومان ببناء هيكل معالجة متسلسل EVM موجه نحو السيناريوهات ذات التزامن العالي وسعة النقل العالية، انطلاقًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل من الطبقة الأولى عالية الأداء مصممة من جديد لآلة Ethereum الافتراضية (EVM)، تعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) والتنفيذ بشكل متوازي متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقة التوافق والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين متكامل.
Pipelining: آلية تنفيذ متوازٍ متعددة المراحل
تعد Pipelining الفكرة الأساسية لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الجوهرية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خط أنابيب ثلاثية الأبعاد. تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يتم الوصول إلى تحسين الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (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 (رسم بياني يعتمد على حالة موجهة وغير دائرية) وآلية مزامنة قابلة للتعديل، التي تُشكل معًا نظام تنفيذ متوازي يركز على "التخييط في السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
أدخلت MegaETH نموذج تنفيذ "مايكرو-VM لكل حساب"، مما يتيح "تخيط" بيئة التنفيذ، ويقدم أصغر وحدة عزل لتخطيط متوازي. تتواصل هذه الـ VMs فيما بينها من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الـ VMs بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
قام MegaETH ببناء نظام جدولة DAG يعتمد على علاقة الوصول إلى حالة الحساب، حيث يقوم النظام بالحفاظ على رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الفعلي، حيث يتم نمذجة جميع المعاملات التي تعدل أي حسابات أو تقرأ أي حسابات على أنها علاقات اعتماد. يمكن تنفيذ المعاملات التي لا تتعارض بشكل مباشر بالتوازي، بينما سيتم جدولة المعاملات التي لها علاقات اعتماد بشكل متسلسل أو مؤجل وفقًا لترتيب الطوبولوجيا. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المتكررة أثناء عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
باختصار، كسر MegaETH نموذج آلة الحالة ذات الخيط الواحد التقليدي لـ EVM، حيث يحقق تغليف الميكرو VM على مستوى الحساب، من خلال جدولة المعاملات باستخدام رسم اعتماد الحالة، ويستبدل آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنه منصة حساب متوازٍ تم إعادة تصميمها بشكل شامل من "هيكل الحساب → هيكل الجدولة → عملية التنفيذ"، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: حيث تم تجريد الحسابات والعقود إلى VM مستقل، مما يتيح تحرير أقصى إمكانيات التوازي من خلال جدولة التنفيذ غير المتزامن. نظريًا، الحد الأقصى للتوازي في MegaETH أعلى، ولكنه أيضًا أكثر صعوبة في التحكم في التعقيد، مما يجعله أشبه بنظام تشغيل موزع فائق تحت فكرة Ethereum.
تختلف فلسفات التصميم لكل من Monad و MegaETH بشكل كبير عن تقسيم المناطق (Sharding): حيث يقوم تقسيم المناطق بتقسيم سلسلة الكتل أفقياً إلى عدة سلاسل فرعية مستقلة (شاردز)، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما ي破破 قيود السلسلة الواحدة في توسيع مستوى الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، حيث يوسعون أفقياً فقط على مستوى التنفيذ، مما يحقق تحسينات الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على تحسين مسار الإنتاجية بهدف رفع معدل المعاملات في الثانية على السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وهندسة مايكرو-آلة افتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos شبكة بلوكتشين من الطبقة الأولى (L1) ذات هيكلية متوازية كاملة ومرنة، وتسمى آلية الحوسبة المتوازية الأساسية فيها "Rollup Mesh". تدعم هذه الهيكلية من خلال التعاون بين الشبكة الرئيسية والشبكات المعالجة الخاصة (SPNs) بيئات متعددة للآلة الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية (ZK) والبيئات التنفيذية الموثوقة (TEE).
تحليل آلية الحساب المتوازي لشبكة Rollup.
معالجة الأنابيب غير المتزامنة لكامل دورة الحياة: يقوم Pharos بفصل مراحل المعاملة المختلفة (مثل الإجماع والتنفيذ والتخزين) ويستخدم طريقة معالجة غير متزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل ومتوازي، وبالتالي زيادة كفاءة المعالجة الكلية.
تنفيذ مزدوج للآلة الافتراضية بالتوازي (Dual VM Parallel Execution): تدعم Pharos بيئتين للأجهزة الافتراضية EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة وفقًا للاحتياجات. لا تعزز بنية VM المزدوجة مرونة النظام فحسب، بل تعزز أيضًا من قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
الشبكات المعالجة الخاصة (SPNs): تعتبر SPNs مكونًا رئيسيًا في بنية Pharos، مشابهةً لشبكات فرعية معيارية، مصممة خصيصًا لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز بشكل أكبر قابلية توسيع النظام وأدائه.
التوافق القابل للتجزئة وآلية إعادة الرهن (Modular Consensus & Restaking): قدمت Pharos آلية توافق مرنة تدعم نماذج توافق متعددة (مثل PBFT و PoS و PoA)، وتحقق من خلال بروتوكول إعادة الرهن (Restaking) الربط بين الشبكة الرئيسية و SPN.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 21
أعجبني
21
5
مشاركة
تعليق
0/400
MEVVictimAlliance
· 07-14 17:28
في النهاية سنستخرج MEV حتى جفافه!
شاهد النسخة الأصليةرد0
RiddleMaster
· 07-13 20:26
مرة أخرى نتحدث عن التوازي ~ متى سنبدأ في استخدام السلسلة الحقيقية؟
شاهد النسخة الأصليةرد0
MeaninglessGwei
· 07-12 05:27
توسيع السعة حتى النهاية البعيدة
شاهد النسخة الأصليةرد0
LeekCutter
· 07-12 05:17
لم يتم العثور على أفضل حل لـ L2؟ لا يزال يتخبط ببطء.
مشهد سباق الحوسبة المتوازية في Web3: من توسيع EVM إلى Rollup Mesh
خريطة شاملة لمجال الحوسبة المتوازية في Web3: هل هي أفضل حل للتوسع الأصلي؟
1. لمحة عامة عن سباق الحوسبة المتوازية
تظهر "مثلث عدم الإمكانية" في تقنية البلوكشين "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة البلوكشين، أي أنه من الصعب على مشاريع البلوكشين تحقيق "أمان تام، مشاركة شاملة، ومعالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "قابلية التوسع"، هناك حلول توسيع رئيسية في السوق حاليًا مصنفة حسب النماذج، بما في ذلك:
تشمل حلول توسيع سلسلة الكتل: الحوسبة المتوازية داخل السلسلة، Rollup، التجزئة، وحدات DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكل غير الحالى، وغيرها، مما يغطي مستويات متعددة من التنفيذ، الحالة، البيانات، الهيكل، وهو نظام توسيع كامل "متعدد الطبقات، وتكوينات معيارية". يركز هذا المقال على طريقة التوسيع التي تعتمد بشكل رئيسي على الحوسبة المتوازية.
الحساب المتوازي داخل السلسلة (intra-chain parallelism)، يركز على التنفيذ المتوازي للمعاملات/التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تصنيف طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة هيكلية، حيث يصبح حجم التوازي أدق، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، كما تزداد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، والذي يمثله نظام الكائنات الذكية (نموذج الوكيل / الكائن)، ينتمي إلى نمط حساب متوازي آخر. كنظام رسائل عبر السلاسل / غير متزامن (نموذج عدم تزامن الكتل)، كل وكيل يعمل كـ "عملية ذكية مستقلة"، حيث يتم تبادل الرسائل بطريقة غير متزامنة وبأسلوب يعتمد على الأحداث، دون الحاجة إلى جدولة متزامنة. المشاريع الممثلة تشمل AO و ICP و Cartesi وغيرها.
إن ما نعرفه جيداً من حلول توسيع Rollup أو التقسيم، ينتمي إلى آلية التوازي على مستوى النظام، ولا ينتمي إلى الحساب المتوازي داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة/آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، لكننا سنستخدمها لمقارنة أوجه التشابه والاختلاف في المفاهيم المعمارية.
٢. سلسلة تحسين متوازية EVM:突破 حدود الأداء في التوافق
لقد تطور هيكل المعالجة المتسلسلة للإيثريوم حتى الآن، حيث شهد عدة جولات من محاولات التوسع مثل تقسيم الشحنات (sharding) وRollup والهياكل المودولية، لكن لا تزال هناك عوائق في سعة طبقة التنفيذ. ومع ذلك، تظل EVM وSolidity هما المنصتان الأكثر استنادًا إلى المطورين ولديهما طاقة بيئية كبيرة في عالم العقود الذكية. لذلك، فإن سلسلة EVM المعززة بالتوازي، التي توازن بين التوافق البيئي وتحسين أداء التنفيذ، أصبحت الاتجاه المهم في الجولة الجديدة من التطور في التوسع. يعتبر مشروع Monad وMegaETH من بين المشاريع الأكثر تمثيلاً في هذا الاتجاه، حيث يقومان ببناء هيكل معالجة متسلسل EVM موجه نحو السيناريوهات ذات التزامن العالي وسعة النقل العالية، انطلاقًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل من الطبقة الأولى عالية الأداء مصممة من جديد لآلة Ethereum الافتراضية (EVM)، تعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) والتنفيذ بشكل متوازي متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقة التوافق والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين متكامل.
Pipelining: آلية تنفيذ متوازٍ متعددة المراحل
تعد Pipelining الفكرة الأساسية لتنفيذ Monad بشكل متوازي، حيث تتمثل الفكرة الجوهرية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خط أنابيب ثلاثية الأبعاد. تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يتم الوصول إلى تحسين الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتلة (Commit).
التنفيذ غير المتزامن: الإجماع - تنفيذ فصل غير متزامن
في السلسلة التقليدية، غالبًا ما تكون عملية التوافق وتنفيذ المعاملات متزامنة، وهذا النموذج التسلسلي يقيد بشكل كبير من أداء التوسع. قامت Monad بتحقيق التوافق غير المتزامن في طبقة التوافق، والتنفيذ غير المتزامن في طبقة التنفيذ، والتخزين غير المتزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلًا، واستخدام الموارد أكثر كفاءة.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: تنفيذ متوازي متفائل
تستخدم الإيثيريوم التقليدية نموذج تسلسل صارم لتنفيذ المعاملات لتجنب تعارض الحالات. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسار التوافق: تقليل التغييرات على قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة والكشف الديناميكي عن التعارضات خلال عملية التنفيذ، مما يجعلها أشبه بإيثريوم ذات الأداء العالي، مما يسهل نقل النظام البيئي لـ EVM بسبب نضجها، وهي مسرع التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وقابلة للتعديل ومتوافقة مع EVM، يمكن أن تعمل كشبكة عامة L1 مستقلة، أو كطبقة تعزيز تنفيذ على إيثريوم (Execution Layer) أو كمكون قابل للتعديل. الهدف الأساسي من التصميم هو فصل المنطق الحسابي، وبيئة التنفيذ، والحالة إلى وحدات مستقلة يمكن جدولتها بشكل منفصل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG (رسم بياني يعتمد على حالة موجهة وغير دائرية) وآلية مزامنة قابلة للتعديل، التي تُشكل معًا نظام تنفيذ متوازي يركز على "التخييط في السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
أدخلت MegaETH نموذج تنفيذ "مايكرو-VM لكل حساب"، مما يتيح "تخيط" بيئة التنفيذ، ويقدم أصغر وحدة عزل لتخطيط متوازي. تتواصل هذه الـ VMs فيما بينها من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الـ VMs بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
مخطط الاعتماد للدولة: آلية جدولة مدفوعة بالرسم البياني للاعتماد
قام MegaETH ببناء نظام جدولة DAG يعتمد على علاقة الوصول إلى حالة الحساب، حيث يقوم النظام بالحفاظ على رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الفعلي، حيث يتم نمذجة جميع المعاملات التي تعدل أي حسابات أو تقرأ أي حسابات على أنها علاقات اعتماد. يمكن تنفيذ المعاملات التي لا تتعارض بشكل مباشر بالتوازي، بينما سيتم جدولة المعاملات التي لها علاقات اعتماد بشكل متسلسل أو مؤجل وفقًا لترتيب الطوبولوجيا. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المتكررة أثناء عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
باختصار، كسر MegaETH نموذج آلة الحالة ذات الخيط الواحد التقليدي لـ EVM، حيث يحقق تغليف الميكرو VM على مستوى الحساب، من خلال جدولة المعاملات باستخدام رسم اعتماد الحالة، ويستبدل آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنه منصة حساب متوازٍ تم إعادة تصميمها بشكل شامل من "هيكل الحساب → هيكل الجدولة → عملية التنفيذ"، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: حيث تم تجريد الحسابات والعقود إلى VM مستقل، مما يتيح تحرير أقصى إمكانيات التوازي من خلال جدولة التنفيذ غير المتزامن. نظريًا، الحد الأقصى للتوازي في MegaETH أعلى، ولكنه أيضًا أكثر صعوبة في التحكم في التعقيد، مما يجعله أشبه بنظام تشغيل موزع فائق تحت فكرة Ethereum.
تختلف فلسفات التصميم لكل من Monad و MegaETH بشكل كبير عن تقسيم المناطق (Sharding): حيث يقوم تقسيم المناطق بتقسيم سلسلة الكتل أفقياً إلى عدة سلاسل فرعية مستقلة (شاردز)، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما ي破破 قيود السلسلة الواحدة في توسيع مستوى الشبكة؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، حيث يوسعون أفقياً فقط على مستوى التنفيذ، مما يحقق تحسينات الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على تحسين مسار الإنتاجية بهدف رفع معدل المعاملات في الثانية على السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وهندسة مايكرو-آلة افتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos شبكة بلوكتشين من الطبقة الأولى (L1) ذات هيكلية متوازية كاملة ومرنة، وتسمى آلية الحوسبة المتوازية الأساسية فيها "Rollup Mesh". تدعم هذه الهيكلية من خلال التعاون بين الشبكة الرئيسية والشبكات المعالجة الخاصة (SPNs) بيئات متعددة للآلة الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية (ZK) والبيئات التنفيذية الموثوقة (TEE).
تحليل آلية الحساب المتوازي لشبكة Rollup.