خريطة شاملة لمجال الحوسبة المتوازية Web3: هل هي أفضل خطة للتوسع الأصلي؟
1. خلفية تطوير الحوسبة المتوازية في بلوكتشين
مثلث "المستحيل" في blockchain (الأمان، اللامركزية، القابلية للتوسع) يكشف عن التوازن الأساسي في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain أن تحقق "أقصى أمان، مشاركة للجميع، معالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "القابلية للتوسع"، فإن الحلول الرئيسية لتوسيع blockchain المتاحة في السوق حاليًا تُصنف حسب النمط، بما في ذلك:
تنفيذ التوسع المعزز: تحسين القدرة التنفيذية في المكان، مثل المعالجة المتوازية، GPU، والأنوية المتعددة
عزل الحالة للتوسع: تقسيم أفقي للحالة / شارد، مثل الشظايا، UTXO، متعدد الشبكات الفرعية
توسيع من نوع التعهيد خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع نموذج فك الهيكل: هيكل نمطي، تشغيل متزامن، مثل سلسلة الوحدات، مرتبة مشتركة، Rollup Mesh
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، محرك الرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع نطاق blockchain: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكلية بدون حالة، وغيرها، مما يغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهو نظام توسيع كامل "تعاون متعدد الطبقات، وتجميع وحدات". وستركز هذه المقالة على طريقة التوسع الرئيسية المتمثلة في الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة ( الازدواجية داخل السلسلة )، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة هيكلية، حيث يصبح حجم التوازي أدق، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، وزيادة تعقيد البرمجة وصعوبة التنفيذ.
التوازي على مستوى الحساب (Account-level): يمثل مشروع سولانا
التوازي على مستوى الكائن (Object-level): يمثل مشروع Sui
المستوى المعاملاتي المتوازي (Transaction-level): يمثل المشروع Monad, Aptos
مستوى الاتصال/المايكرو VM المتوازي (Call-level / MicroVM): يمثل مشروع MegaETH
التنفيذ المتوازي على مستوى التعليمات (Instruction-level): يمثل مشروع GatlingX
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثل نظام الوكلاء (Agent / Actor Model)، ينتمي إلى نمط حسابي متوازي آخر، كنظام رسائل عبر السلاسل / غير متزامن (نموذج عدم تزامن الكتل)، حيث يعمل كل وكيل ك"عملية ذكية مستقلة"، بأسلوب غير متزامن في الرسائل المدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
إن خطط التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تُعتبر آليات تزامنية على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/نطاقات تنفيذ في وقت واحد"، وليس من خلال تعزيز مستوى التوازي داخل كتلة واحدة/آلة افتراضية. هذه الخطط التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها لمقارنة أوجه الاختلاف في مفاهيم الهيكلة.
٢، سلسلة التعزيز المتوازية EVM: كسر حدود الأداء من خلال التوافق
لقد شهدت بنية سلسلة معالجة Ethereum تطورات حتى الآن، حيث مرت بجولات متعددة من محاولات التوسع مثل التجزئة، وRollup، والهندسة المعمارية المودولارية، لكن لا يزال هناك نقص أساسي في تخفيف الاختناق في طبقة التنفيذ. ومع ذلك، لا يزال EVM وSolidity هما الأكثر قوة من حيث قاعدة المطورين وإمكانات النظام البيئي بين منصات العقود الذكية الحالية. لذلك، تعتبر سلسلة تعزيز EVM المتوازية كمسار رئيسي يوازن بين ملاءمة النظام البيئي وتحسين أداء التنفيذ، وهي تتحول إلى اتجاه مهم في التطورات المستقبلية للتوسع. تعتبر Monad وMegaETH من أكثر المشاريع تمثيلاً في هذا الاتجاه، حيث تبنيان بنية معالجة EVM المتوازية الموجهة نحو السيناريوهات ذات التوازي العالي والإنتاجية العالية من خلال تأخير التنفيذ وتفكيك الحالة.
تحليل آلية الحساب المتوازي Monad
Monad هي سلسلة كتل من الطبقة 1 عالية الأداء تم إعادة تصميمها لآلة افتراضية إيثيريوم (EVM)، تعتمد على مفهوم المعالجة المتوازية الأساسي (Pipelining)، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) بينما يتم تنفيذ الطبقة التنفيذية باستخدام التوازي المتفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي التوافق والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) لتحقيق تحسين من طرف إلى طرف.
تسلسل الأنابيب: آلية تنفيذ متوازية متعددة المراحل
Pipelining هو المفهوم الأساسي للتنفيذ المتوازي للـ Monad ، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بشكل متوازي ، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد. تعمل كل مرحلة على خيوط أو نوى مستقلة ، مما يحقق معالجة متزامنة عبر الكتل ، وفي النهاية يصل إلى تحسين السعة وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) ، تحقيق الإجماع (Consensus) ، تنفيذ المعاملات (Execution) ، وتقديم الكتل (Commit).
التنفيذ غير المتزامن: فك الارتباط بين الإجماع والتنفيذ
في السلاسل التقليدية، عادة ما تكون عملية التوافق والتنفيذ متزامنة، مما يحد بشدة من توسيع الأداء. تحقق Monad "التنفيذ غير المتزامن"، مما يجعل طبقة التوافق غير متزامنة، وطبقة التنفيذ غير متزامنة، والتخزين غير متزامن. مما يقلل بشكل كبير من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعمليات المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقد.
عملية التنفيذ (طبقة التنفيذ) يتم تفعيلها بشكل غير متزامن بعد اكتمال الاجماع.
بعد اكتمال الإجماع، يتم الانتقال مباشرة إلى عملية إجماع الكتلة التالية، دون الحاجة إلى انتظار الانتهاء من التنفيذ.
تستخدم الإيثيريوم التقليدية نموذج تنفيذ صارم متسلسل لتجنب تعارض الحالة. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
سيقوم Monad بتنفيذ جميع المعاملات بشكل متوازي بشكل متفائل، مفترضًا أن معظم المعاملات لا تحتوي على تعارضات حالة.
تشغيل "كاشف تضارب (Conflict Detector)" لمراقبة ما إذا كانت المعاملات تصل إلى نفس الحالة (مثل تضارب القراءة/الكتابة).
إذا تم اكتشاف تعارض، فسيتم تسلسل إعادة تنفيذ المعاملات المتعارضة لضمان صحة الحالة.
اختارت Monad مساراً متوافقاً: تقليل تغييرات قواعد EVM قدر الإمكان، وتحقيق التوازي خلال عملية التنفيذ من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات، مما يجعلها أشبه بإيثريوم النسخة المحسنة من حيث الأداء، حيث أن النضج يجعل من السهل تحقيق انتقال النظام البيئي لـ EVM، وهي مسرع التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لـ MegaETH
بخلاف تحديد L1 لـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء متوازية وقابلة للتعديل متوافقة مع EVM، يمكن أن تعمل كشبكة L1 عامة مستقلة، أو كطبقة تعزيز تنفيذ على Ethereum أو كمكون متكامل. الهدف الأساسي من تصميمها هو تفكيك منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات أصغر يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي قدمته MegaETH هو: بنية Micro-VM + DAG (رسم بياني موجه بدون حلقات) من الاعتماد على الحالة وآلية التزامن القابلة للتعديل، مما يبني نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".
بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط
تم تقديم نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)" في MegaETH، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويوفر الحد الأدنى من وحدات العزل لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (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 شبكة بلوكتشين من الطبقة الأولى (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): قدمت فارووس آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT و PoS و PoA)، ومن خلال بروتوكول إعادة الرهن (Restaking) تحقق المشاركة الآمنة والتكامل بين الشبكة الرئيسية وSPNs.
علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من خلال تقنيات مثل شجرة Merkle متعددة الإصدارات، والترميز التفاضلي (Delta Encoding)، والعنوانة المعتمدة على الإصدارات (Versioned Addressing)، ودفع ADS (ADS Pushdown) من أسفل محرك التخزين، مما أطلق محرك التخزين عالي الأداء على السلسلة الأصلية Pharos Store، لتحقيق قدرة معالجة عالية الإنتاجية، وانخفاض في زمن الاستجابة، وقوة قابلة للتحقق على السلسلة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 20
أعجبني
20
6
مشاركة
تعليق
0/400
NftDataDetective
· 07-24 20:18
همم نقاش قابلية التوسع مرة أخرى... لقد رأيت هذا الفيلم من قبل بصراحة. مجموعات تبدو مغرية جداً
شاهد النسخة الأصليةرد0
LayoffMiner
· 07-23 18:18
نباتات الثوم يجب خداع الناس لتحقيق الربح، والخداع ينهي الأمر.
شاهد النسخة الأصليةرد0
MEVSupportGroup
· 07-23 09:10
ماذا نفعل إذا لم نستطع الفوز على المركزية في هذا TPS؟
شاهد النسخة الأصليةرد0
LidoStakeAddict
· 07-23 09:00
من يفهم tps الحقيقي داخل السلسلة؟ الأرقام الورقية كلها ثور.
شاهد النسخة الأصليةرد0
GhostAddressMiner
· 07-23 08:56
هذه الحلول التوسعية ذات التعبئة الجميلة... ليست سوى أدوات جديدة لخداع حمقى رأس المال. لقد تتبعت عددًا من محافظ المؤسسات، وهم جميعًا يقومون بتخزين عملة L2 في السر.
شاهد النسخة الأصليةرد0
shadowy_supercoder
· 07-23 08:49
مرة أخرى يتحدثون عن التوسع، من لم يقم بعد بعمل بعض rollups؟
مشهد الحوسبة المتوازية في Web3: مقارنة بين حلول توسيع السلسلة واتجاهات التطوير
خريطة شاملة لمجال الحوسبة المتوازية Web3: هل هي أفضل خطة للتوسع الأصلي؟
1. خلفية تطوير الحوسبة المتوازية في بلوكتشين
مثلث "المستحيل" في blockchain (الأمان، اللامركزية، القابلية للتوسع) يكشف عن التوازن الأساسي في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain أن تحقق "أقصى أمان، مشاركة للجميع، معالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "القابلية للتوسع"، فإن الحلول الرئيسية لتوسيع blockchain المتاحة في السوق حاليًا تُصنف حسب النمط، بما في ذلك:
تشمل حلول توسيع نطاق blockchain: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكلية بدون حالة، وغيرها، مما يغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهو نظام توسيع كامل "تعاون متعدد الطبقات، وتجميع وحدات". وستركز هذه المقالة على طريقة التوسع الرئيسية المتمثلة في الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة ( الازدواجية داخل السلسلة )، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة هيكلية، حيث يصبح حجم التوازي أدق، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، وزيادة تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثل نظام الوكلاء (Agent / Actor Model)، ينتمي إلى نمط حسابي متوازي آخر، كنظام رسائل عبر السلاسل / غير متزامن (نموذج عدم تزامن الكتل)، حيث يعمل كل وكيل ك"عملية ذكية مستقلة"، بأسلوب غير متزامن في الرسائل المدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
إن خطط التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تُعتبر آليات تزامنية على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/نطاقات تنفيذ في وقت واحد"، وليس من خلال تعزيز مستوى التوازي داخل كتلة واحدة/آلة افتراضية. هذه الخطط التوسعية ليست محور النقاش في هذه المقالة، ولكننا سنستخدمها لمقارنة أوجه الاختلاف في مفاهيم الهيكلة.
٢، سلسلة التعزيز المتوازية EVM: كسر حدود الأداء من خلال التوافق
لقد شهدت بنية سلسلة معالجة Ethereum تطورات حتى الآن، حيث مرت بجولات متعددة من محاولات التوسع مثل التجزئة، وRollup، والهندسة المعمارية المودولارية، لكن لا يزال هناك نقص أساسي في تخفيف الاختناق في طبقة التنفيذ. ومع ذلك، لا يزال EVM وSolidity هما الأكثر قوة من حيث قاعدة المطورين وإمكانات النظام البيئي بين منصات العقود الذكية الحالية. لذلك، تعتبر سلسلة تعزيز EVM المتوازية كمسار رئيسي يوازن بين ملاءمة النظام البيئي وتحسين أداء التنفيذ، وهي تتحول إلى اتجاه مهم في التطورات المستقبلية للتوسع. تعتبر Monad وMegaETH من أكثر المشاريع تمثيلاً في هذا الاتجاه، حيث تبنيان بنية معالجة EVM المتوازية الموجهة نحو السيناريوهات ذات التوازي العالي والإنتاجية العالية من خلال تأخير التنفيذ وتفكيك الحالة.
تحليل آلية الحساب المتوازي Monad
Monad هي سلسلة كتل من الطبقة 1 عالية الأداء تم إعادة تصميمها لآلة افتراضية إيثيريوم (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 (الآلة الافتراضية الصغيرة): الحساب هو الخيط
تم تقديم نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)" في MegaETH، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويوفر الحد الأدنى من وحدات العزل لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (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 شبكة بلوكتشين من الطبقة الأولى (L1) متوازية، وذات بنية قابلة للتعديل بالكامل، يُشار إلى آلية الحوسبة المتوازية الأساسية فيها باسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة للآلة الافتراضية (EVM وWasm)، وتدمج تقنيات متقدمة مثل إثبات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEE).
تحليل آلية الحساب المتوازي Rollup Mesh:
علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من خلال تقنيات مثل شجرة Merkle متعددة الإصدارات، والترميز التفاضلي (Delta Encoding)، والعنوانة المعتمدة على الإصدارات (Versioned Addressing)، ودفع ADS (ADS Pushdown) من أسفل محرك التخزين، مما أطلق محرك التخزين عالي الأداء على السلسلة الأصلية Pharos Store، لتحقيق قدرة معالجة عالية الإنتاجية، وانخفاض في زمن الاستجابة، وقوة قابلة للتحقق على السلسلة.