خريطة شاملة لمجال الحوسبة المتوازية Web3: ما هي أفضل خطة للتوسع الأصلي؟
تظهر "مثلث blockchain" (مستحيل الثلاثي) "الأمان" و"اللامركزية" و"القابلية للتوسع" التوازن الأساسي في تصميم أنظمة blockchain، مما يعني أن مشاريع blockchain من الصعب أن تحقق في نفس الوقت "أمانًا مطلقًا، مشاركة شاملة، ومعالجة سريعة". بالنسبة لموضوع "القابلية للتوسع"، تتنوع حلول توسيع blockchain السائدة في السوق حاليًا وفقًا للنموذج، بما في ذلك:
تنفيذ توسيع معزز: تحسين القدرة التنفيذية في مكانها، مثل المعالجة المتوازية، GPU، والعديد من النوى
توسيع فصل الحالة: تقسيم أفقي للحالة / شارد، مثل الشظايا، UTXO، الشبكات الفرعية المتعددة
التوسع من نوع التشغيل الخارجي: نقل التنفيذ إلى خارج السلسلة، مثل Rollup، Coprocessor، DA
توسعة بنية مفككة: نمذجة هيكلية، تشغيل متزامن، مثل سلسلة الوحدات، مرتبة مشتركة، شبكة رول أب
توسيع متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع نطاق 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 أو تقسيم السلسلة التي نعرفها جيدًا آليات تزامن على مستوى النظام، إلا أنها لا تندرج ضمن حسابات التوازي داخل السلسلة. فهي تحقق التوسع من خلال "تشغيل سلاسل / مجالات تنفيذ متعددة بالتوازي"، وليس عن طريق تعزيز درجة التوازي داخل كتلة واحدة / آلة افتراضية. على الرغم من أن مثل هذه الحلول للتوسع ليست محور هذا المقال، إلا أننا سنستخدمها لمقارنة أوجه التشابه والاختلاف في مفاهيم الهيكل.
٢. سلسلة تحسين EVM المتوازية:突破 حدود الأداء في التوافق
لقد شهدت بنية المعالجة المتسلسلة للإيثيريوم تطورات حتى الآن، حيث مرت بعدة جولات من محاولات التوسع بما في ذلك التجزئة، وRollup، والهندسة المعمارية المعيارية، ولكن لا يزال هناك حاجز في سعة طبقة التنفيذ لم يتم اختراقه بشكل جذري. ومع ذلك، تظل EVM وSolidity هما المنصتان الأكثر جذبًا للمطورين ولديهما إمكانيات بيئية قوية في مجال العقود الذكية. لذلك، تعتبر سلسلة EVM المعززة بالتوازي كمسار رئيسي يجمع بين توافق البيئة وتحسين أداء التنفيذ، وهي تتحول إلى اتجاه مهم في التطور الجديد للتوسع. يُعتبر Monad وMegaETH من المشاريع الأكثر تمثيلًا في هذا الاتجاه، حيث يبنيان بنية معالجة EVM بالتوازي تستهدف البيئات ذات التحميل العالي وسعة الإنتاج العالية، من خلال التركيز على تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحساب المتوازي لـ Monad
Monad هو سلسلة كتل عالية الأداء من الطبقة 1 تم إعادة تصميمها لـ Ethereum Virtual Machine (EVM) ، بناءً على مفهوم المعالجة المتوازية الأساسي (Pipelining) ، مع تنفيذ غير متزامن على طبقة الإجماع (Asynchronous Execution) وتنفيذ متفائل متوازي (Optimistic Parallel Execution) في طبقة التنفيذ. بالإضافة إلى ذلك ، في طبقات الإجماع والتخزين ، يقدم Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل.
Pipeline: آلية التنفيذ المتوازي متعددة المراحل
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 نموذج تنفيذ "مايكرو-آلة افتراضية لكل حساب"، مما يجعل بيئة التنفيذ "مُعَزَّزة"، لتوفير وحدة العزل الدنيا للتخطيط المتوازي. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous 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، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 20
أعجبني
20
9
إعادة النشر
مشاركة
تعليق
0/400
GweiTooHigh
· 08-18 06:19
لقد وصلت إلى 3.0 ولكن لا يزال هذا tps يسبب لي صداعًا
شاهد النسخة الأصليةرد0
GateUser-9ad11037
· 08-17 19:08
عالم GPU هو Rug Pull
شاهد النسخة الأصليةرد0
OvertimeSquid
· 08-17 03:00
لا يمكن اختيار سوى اثنين من الثلاثة، نريد أن تجري الخيل وفي نفس الوقت لا تأكل العشب.
شاهد النسخة الأصليةرد0
AirdropHunter
· 08-16 13:23
يجب أن تختار جانبًا واحدًا بين الأسود والأبيض، أليس هذا هو التضحية باللامركزية؟
شاهد النسخة الأصليةرد0
PretendingSerious
· 08-15 14:29
لا أحد يمكنه كسر المثلث، هذه المسار يجب أن نرى من سيجري أولاً
شاهد النسخة الأصليةرد0
Ser_APY_2000
· 08-15 14:29
داخل السلسلة tps طوال اليوم ينادون ما الفائدة؟
شاهد النسخة الأصليةرد0
0xOverleveraged
· 08-15 14:10
هناك الكثير من المصطلحات الفنية التي تُخترع يومياً.
شاهد النسخة الأصليةرد0
TokenToaster
· 08-15 14:09
ليس كل شيء يمكن حله بواسطة Rollup، مستثمر التجزئة لا ينبغي أن يفكر كثيراً.
تحليل شامل للحوسبة المتوازية في Web3: من توسيع EVM إلى Rollup Mesh
خريطة شاملة لمجال الحوسبة المتوازية Web3: ما هي أفضل خطة للتوسع الأصلي؟
تظهر "مثلث blockchain" (مستحيل الثلاثي) "الأمان" و"اللامركزية" و"القابلية للتوسع" التوازن الأساسي في تصميم أنظمة 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 هو سلسلة كتل عالية الأداء من الطبقة 1 تم إعادة تصميمها لـ Ethereum Virtual Machine (EVM) ، بناءً على مفهوم المعالجة المتوازية الأساسي (Pipelining) ، مع تنفيذ غير متزامن على طبقة الإجماع (Asynchronous Execution) وتنفيذ متفائل متوازي (Optimistic Parallel Execution) في طبقة التنفيذ. بالإضافة إلى ذلك ، في طبقات الإجماع والتخزين ، يقدم Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين شامل.
Pipeline: آلية التنفيذ المتوازي متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بالتوازي ، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ blockchain إلى عدة مراحل مستقلة ومعالجة هذه المراحل بشكل متوازي ، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد ، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة ، لتحقيق معالجة متزامنة عبر الكتل ، مما يؤدي في النهاية إلى تحسين الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) ، تحقيق التوافق (Consensus) ، تنفيذ المعاملات (Execution) ، وتقديم الكتل (Commit).
التنفيذ غير المتزامن: الإجماع - تنفيذ فك الارتباط غير المتزامن
في السلاسل التقليدية، عادة ما تكون عملية التوافق والتنفيذ متزامنة، وهذا النموذج التسلسلي يحد بشكل كبير من توسعة الأداء. حققت Monad التوافق غير المتزامن من خلال "التنفيذ غير المتزامن"، مما أدى إلى توافق غير متزامن في طبقة التوافق، وتنفيذ غير متزامن في طبقة التنفيذ، وتخزين غير متزامن. هذا يقلل بشكل كبير من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
تنفيذ متوازي متفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذج تنفيذ صارم متسلسل لتجنب تعارض الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسارًا متوافقًا: تقليل تغيير قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة والكشف الديناميكي عن النزاعات خلال عملية التنفيذ لتحقيق التوازي، مما يجعلها أكثر شبهًا بإيثريوم المُحسن من حيث الأداء، مما يسهل انتقال النظام البيئي لـ EVM بسبب نضجه، وهو مُعجّل التوازي لعالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad ، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وموحدة متوافقة مع EVM ، يمكن أن تكون بمثابة سلسلة عامة مستقلة L1 أو كطبقة تعزيز تنفيذ على Ethereum (Execution Layer) أو كمكون معياري. الهدف الأساسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولة كل منها بشكل مستقل ، لتحقيق تنفيذ عالي التزامن واستجابة منخفضة التأخير داخل السلسلة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG اعتماد الحالة (مخطط الاعتماد الموجه غير الدائري) وآلية التزامن المعيارية ، والتي تبني معًا نظام تنفيذ متوازي موجه نحو "تشغيل السلاسل داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
تقدم MegaETH نموذج تنفيذ "مايكرو-آلة افتراضية لكل حساب"، مما يجعل بيئة التنفيذ "مُعَزَّزة"، لتوفير وحدة العزل الدنيا للتخطيط المتوازي. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous 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: