خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل الحلول للتوسع الأصلي؟
1. المقدمة: الموضوع الأبدي لتوسيع نطاق blockchain
تُظهر "مثلث blockchain" (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أن من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة الجميع، ومعالجة سريعة" في الوقت نفسه. بالنسبة للموضوع الأبدي "لقابلية التوسع"، فإن حلول توسيع blockchain الرائجة في السوق تُصنف وفقًا للأنماط، بما في ذلك:
تنفيذ تحسينات في التوسع: تحسين القدرة التنفيذية في المكان، مثل التشغيل المتوازي، وحدة معالجة الرسومات، المعالجات المتعددة
توسيع من نوع العزل الحالة: تقسيم أفقي للحالة / شارد، مثل الشظايا، UTXO، شبكات فرعية متعددة
توسيع نمط الاستعانة بمصادر خارجية خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع هيكل تفكيك الهيكل: هيكلية معيارية، تشغيل متعاون، مثل سلسلة الوحدات، موحد المشاركة، Rollup Mesh
توسيع متزامن غير متزامن: نموذج Actor، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلاسل غير متزامنة متعددة الخيوط
تشمل حلول توسيع blockchain: الحوسبة المتوازية داخل السلسلة، 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
موناد هو سلسلة كتل Layer1 عالية الأداء تم إعادة تصميمها لآلة الإيثريوم الافتراضية (EVM)، استنادًا إلى مفهوم المعالجة المتوازية الأساسية (Pipelining)، في تنفيذ غير متزامن على مستوى الإجماع (Asynchronous Execution) وتنفيذ متوازي متفائل (Optimistic Parallel Execution) على مستوى التنفيذ. بالإضافة إلى ذلك، في طبقة الإجماع والتخزين، قدمت موناد بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا من الطرف إلى الطرف.
خط الأنابيب: آلية تنفيذ متوازية متعددة المراحل
تعتبر Pipelining الفكرة الأساسية لتنفيذ Monad بالتوازي، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ سلسلة الكتل إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بالتوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة في خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويؤدي في النهاية إلى زيادة السعة وتقليل التأخير. تشمل هذه المراحل: اقتراح الصفقة (Propose) ، الوصول إلى توافق (Consensus) ، تنفيذ الصفقة (Execution) ، وتقديم الكتلة (Commit).
تنفيذ غير متزامن：فصل الإجماع والتنفيذ بشكل غير متزامن
في السلاسل التقليدية، يتكون توافق المعاملات والتنفيذ عادةً من عملية متزامنة، حيث يحد هذا النموذج التسلسلي بشدة من أداء التوسع. حققت Monad "التنفيذ غير المتزامن" من خلال جعل طبقة التوافق غير متزامنة، وطبقة التنفيذ غير متزامنة، والتخزين غير متزامن. مما يقلل بشكل كبير من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقود.
عملية التنفيذ (طبقة التنفيذ) يتم تنشيطها بشكل غير متزامن بعد اكتمال الإجماع.
بعد إتمام الإجماع، يتم الدخول مباشرة في عملية إجماع الكتلة التالية دون الحاجة إلى انتظار الانتهاء من التنفيذ.
يعتمد الإيثريوم التقليدي على نموذج تنفيذ صارم متسلسل لتجنب تعارضات الحالة. بينما يتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
ستقوم Monad بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، بافتراض أن معظم المعاملات لا تتعارض مع بعضها البعض.
تشغيل "كاشف التعارض (Conflict Detector))" في نفس الوقت لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة (مثل تعارض القراءة/الكتابة).
إذا تم الكشف عن تعارض، فسيتم تسلسل إعادة تنفيذ المعاملات المتعارضة لضمان صحة الحالة.
اختارت Monad مسار التوافق: تقليل التغييرات في قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات خلال عملية التنفيذ، مما يجعلها تشبه نسخة الأداء من Ethereum، حيث أن النضج يسهل نقل نظام EVM البيئي، وهي مسرع التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لمجايث
بخلاف تحديد L1 في Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء متوازية ومتوافقة مع EVM، يمكن أن تعمل كشبكة L1 عامة مستقلة، أو كطبقة تعزيز تنفيذ على الإيثيريوم، أو كعنصر معياري. الهدف الأساسي من تصميمها هو فصل منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات الحد الأدنى القابلة للتخطيط بشكل مستقل، لتحقيق قدرة تنفيذ عالية المتزامنة واستجابة منخفضة التأخير داخل الشبكة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة (الرسم البياني المعتمد على الحالة الموجه غير الدوري) وآلية التزامن المعيارية، مما يبني معًا نظام تنفيذ متوازي موجه نحو "التخييط داخل السلسلة".
بنية Micro-VM (آلة افتراضية صغيرة): الحساب هو الخيط
أدخلت MegaETH نموذج تنفيذ "آلة افتراضية صغيرة (Micro-VM) لكل حساب"، مما يجعل بيئة التنفيذ "متعددة الخيوط"، مما يوفر وحدة عزل أصغر لجدولة متوازية. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (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
معالجة الأنابيب غير المتزامنة طوال دورة الحياة (Full Lifecycle Asynchronous Pipelining): تقوم Pharos بفصل مراحل المعاملة المختلفة (مثل الإجماع، التنفيذ، التخزين) وتستخدم طريقة معالجة غير متزامنة، مما يسمح لكل مرحلة بالعمل بشكل مستقل ومتوازي، وبالتالي زيادة كفاءة المعالجة الشاملة.
تنفيذ مزدوج للآلة الافتراضية بالتوازي (Dual VM Parallel Execution): يدعم Pharos بيئتي الآلة الافتراضية EVM وWASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة بناءً على احتياجاتهم. لا تعمل بنية VM المزدوجة على تحسين مرونة النظام فحسب، بل تعزز أيضًا قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
الشبكات المعالجة الخاصة (SPNs): تعتبر SPNs مكونًا رئيسيًا في بنية Pharos، تشبه الشبكات الفرعية المعيارية، والمخصصة لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص الموارد الديناميكي ومعالجة المهام بالتوازي، مما يعزز المزيد من قابلية التوسع والأداء للنظام.
التوافق المعياري وآلية إعادة التStake (Modular Consensus & Restaking): قدمت Pharos آلية توافق مرنة تدعم نماذج توافق متعددة (مثل PBFT و PoS و PoA)، ومن خلال بروتوكول إعادة التStake (Restaking) تحقق مشاركة آمنة للموارد وتكاملها بين الشبكة الرئيسية و SPNs.
علاوة على ذلك، يستخدم Pharos شجرة ميركل متعددة النسخ، والترميز التفاضلي (Delta Encoding)، والإصدارات
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
5
مشاركة
تعليق
0/400
MevHunter
· منذ 14 س
لنبدأ بالتعدين باستخدام GPU، ماذا نناقش بعد؟
شاهد النسخة الأصليةرد0
TrustMeBro
· منذ 17 س
又搞个新概念 يُستغل بغباء؟
شاهد النسخة الأصليةرد0
SelfMadeRuggee
· منذ 17 س
لا جدوى من المشاركة في هذا النقاش. إذا كان لديهم حقًا ما يكفي من المعلومات، لكانوا قد أصبحوا أغنياء بالفعل.
شاهد النسخة الأصليةرد0
LiquidationWatcher
· منذ 17 س
يا إلهي، حل تحجيم آخر... أليس لدينا خبرة سابقة في هذا الفيلم؟ ذكريات مؤلمة من 2022 لا تزال تؤثر بشدة بصراحة.
شاهد النسخة الأصليةرد0
MidnightGenesis
· منذ 17 س
الشفرة لا تكذب أبداً... بيانات داخل السلسلة هي الحقيقة. النشر السري في الساعة الثانية ليلاً دائماً ما يكون مشبوهًا. من الذي يتلاعب بالسوق؟
نظرة شاملة على مجال الحوسبة المتوازية في Web3: من التوافق مع EVM إلى اختراق الأداء في التنفيذ غير المتزامن
خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل الحلول للتوسع الأصلي؟
1. المقدمة: الموضوع الأبدي لتوسيع نطاق blockchain
تُظهر "مثلث blockchain" (Blockchain Trilemma) "الأمان" و"اللامركزية" و"قابلية التوسع" التوازن الجوهري في تصميم أنظمة blockchain، مما يعني أن من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة الجميع، ومعالجة سريعة" في الوقت نفسه. بالنسبة للموضوع الأبدي "لقابلية التوسع"، فإن حلول توسيع blockchain الرائجة في السوق تُصنف وفقًا للأنماط، بما في ذلك:
تشمل حلول توسيع blockchain: الحوسبة المتوازية داخل السلسلة، Rollup، القطع، وحدة DA، الهيكل المعياري، نظام Actor، ضغط إثبات zk، الهيكل عديم الحالة، وغيرها، تغطي عدة مستويات من التنفيذ، الحالة، البيانات، الهيكل، وهي "نظام توسيع كامل بالتعاون المتعدد الطبقات، وتكوينات معيارية". تركز هذه المقالة على طريقة التوسيع التي تعتمد على الحوسبة المتوازية.
الحساب المتوازي داخل السلسلة ( التوازي داخل السلسلة )، يركز على التنفيذ المتوازي للمعاملات/التعليمات داخل الكتلة. حسب آلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، كل فئة تمثل سعيًا مختلفًا نحو الأداء، ونموذج تطوير، وفلسفة هيكلية، بحيث تتناقص حبيبات التوازي تدريجيًا، وتزداد شدة التوازي، وتزداد تعقيدات الجدولة، كما تزداد تعقيدات البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، الذي يتم تمثيله بنظام الوكلاء (نموذج الوكيل / الممثل)، ينتمي إلى نمط حسابي متوازي آخر، كونه نظام رسائل عبر السلاسل / غير متزامن (نموذج غير متزامن للكتل)، كل وكيل يعمل ك"عملية وكيل مستقلة"، بأسلوب متوازي رسائل غير متزامنة، مدفوعة بالأحداث، دون حاجة لتزامن الجدولة، المشاريع الممثلة تشمل AO و ICP و Cartesi وغيرها.
وخطط التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تنتمي إلى آلية التوازي على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة مستوى التوازي داخل كتلة واحدة/آلة افتراضية. هذه الأنواع من خطط التوسع ليست محور النقاش في هذه المقالة، لكننا سنستخدمها لمقارنة أوجه الشبه والاختلاف في مفاهيم الهيكل.
٢- سلسلة تعزيز التوازي EVM: الاختراق في حدود الأداء في التوافق
تطورت بنية المعالجة المتسلسلة لإيثريوم حتى اليوم، بعد أن مرت بعدة جولات من محاولات التوسع مثل التجزئة، وRollup، والبنية المعمارية المودولارية، ولكن لا يزال عنق الزجاجة في قابلية تنفيذ الطبقة التنفيذية لم يحصل على突破 جذري. ولكن في الوقت نفسه، لا تزال EVM وSolidity هما المنصتان الأكثر جذبًا للمطورين ولديهما إمكانية بيئية كبيرة. لذلك، فإن سلسلة التعزيز المتوازية من EVM كمسار رئيسي يجمع بين توافق النظام البيئي وتحسين أداء التنفيذ، أصبحت تتجه لتكون اتجاهًا مهمًا في التطور الجديد للتوسع. يعتبر Monad وMegaETH من المشاريع الأكثر تمثيلًا في هذا الاتجاه، حيث يقومان ببناء بنية معالجة متوازية لـ EVM مع التركيز على تنفيذ التأخيرات وتفكيك الحالة، موجهة نحو السيناريوهات ذات التزامن العالي وقابلية الإرسال العالية.
تحليل آلية الحساب المتوازي لـ Monad
موناد هو سلسلة كتل Layer1 عالية الأداء تم إعادة تصميمها لآلة الإيثريوم الافتراضية (EVM)، استنادًا إلى مفهوم المعالجة المتوازية الأساسية (Pipelining)، في تنفيذ غير متزامن على مستوى الإجماع (Asynchronous Execution) وتنفيذ متوازي متفائل (Optimistic Parallel Execution) على مستوى التنفيذ. بالإضافة إلى ذلك، في طبقة الإجماع والتخزين، قدمت موناد بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا من الطرف إلى الطرف.
خط الأنابيب: آلية تنفيذ متوازية متعددة المراحل
تعتبر Pipelining الفكرة الأساسية لتنفيذ Monad بالتوازي، حيث تتمثل الفكرة الرئيسية في تقسيم عملية تنفيذ سلسلة الكتل إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بالتوازي، مما يشكل هيكل خط أنابيب ثلاثي الأبعاد، حيث تعمل كل مرحلة في خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويؤدي في النهاية إلى زيادة السعة وتقليل التأخير. تشمل هذه المراحل: اقتراح الصفقة (Propose) ، الوصول إلى توافق (Consensus) ، تنفيذ الصفقة (Execution) ، وتقديم الكتلة (Commit).
تنفيذ غير متزامن：فصل الإجماع والتنفيذ بشكل غير متزامن
في السلاسل التقليدية، يتكون توافق المعاملات والتنفيذ عادةً من عملية متزامنة، حيث يحد هذا النموذج التسلسلي بشدة من أداء التوسع. حققت Monad "التنفيذ غير المتزامن" من خلال جعل طبقة التوافق غير متزامنة، وطبقة التنفيذ غير متزامنة، والتخزين غير متزامن. مما يقلل بشكل كبير من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: التنفيذ المتوازي المتفائل
يعتمد الإيثريوم التقليدي على نموذج تنفيذ صارم متسلسل لتجنب تعارضات الحالة. بينما يتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسار التوافق: تقليل التغييرات في قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات خلال عملية التنفيذ، مما يجعلها تشبه نسخة الأداء من Ethereum، حيث أن النضج يسهل نقل نظام EVM البيئي، وهي مسرع التوازي في عالم EVM.
تحليل آلية الحوسبة المتوازية لمجايث
بخلاف تحديد L1 في Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء متوازية ومتوافقة مع EVM، يمكن أن تعمل كشبكة L1 عامة مستقلة، أو كطبقة تعزيز تنفيذ على الإيثيريوم، أو كعنصر معياري. الهدف الأساسي من تصميمها هو فصل منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات الحد الأدنى القابلة للتخطيط بشكل مستقل، لتحقيق قدرة تنفيذ عالية المتزامنة واستجابة منخفضة التأخير داخل الشبكة. الابتكار الرئيسي الذي تقدمه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة (الرسم البياني المعتمد على الحالة الموجه غير الدوري) وآلية التزامن المعيارية، مما يبني معًا نظام تنفيذ متوازي موجه نحو "التخييط داخل السلسلة".
بنية Micro-VM (آلة افتراضية صغيرة): الحساب هو الخيط
أدخلت MegaETH نموذج تنفيذ "آلة افتراضية صغيرة (Micro-VM) لكل حساب"، مما يجعل بيئة التنفيذ "متعددة الخيوط"، مما يوفر وحدة عزل أصغر لجدولة متوازية. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (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
علاوة على ذلك، يستخدم Pharos شجرة ميركل متعددة النسخ، والترميز التفاضلي (Delta Encoding)، والإصدارات