خريطة شاملة لمسار الحوسبة المتوازية في Web3: ما هي أفضل خطة للتوسع الأصلي؟
مثلث "مستحيل" blockchain ( Blockchain Trilemma ) "الأمان"، "اللامركزية"، و"قابلية التوسع" تكشف عن التوازن الجوهري في تصميم أنظمة blockchain، حيث من الصعب على مشاريع blockchain تحقيق "أمان مطلق، مشاركة عالمية، ومعالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع" هذا، فإن الحلول السائدة لتوسيع blockchain في السوق الحالية تصنف وفقًا للأنماط، بما في ذلك:
تنفيذ توسيع محسن: تحسين القدرة على التنفيذ في الموقع، مثل المعالجة المتوازية، GPU، والأنوية المتعددة
نوع التوسع المعزول عن الحالة: تقسيم أفقي للحالة / شارد، مثل التقسيم، UTXO، شبكات فرعية متعددة
توسيع نوع الاستعانة بمصادر خارجية خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
هيكل فك الارتباط للتوسع: نمذجة الهيكل، التشغيل المتعاون، مثل سلسلة الوحدات، مرتب المشاركة، Rollup Mesh
توسيع متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط zk، الهيكلية عديمة الحالة، وما إلى ذلك، تغطي عدة مستويات من التنفيذ والحالة والبيانات والهياكل، وهي نظام توسيع كامل "تعاوني متعدد المستويات، وتجميع وحدات". بينما يركز هذا النص على طريقة التوسيع التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة ( intra-chain parallelism )، تركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة طموحات أداء مختلفة، ونماذج تطوير، وفلسفات معمارية، حيث تصبح درجة التوازي بشكل متزايد أكثر دقة، وتزداد شدة التوازي، كما تزداد تعقيد جدولة المهام، وتزداد أيضًا تعقيد البرمجة وصعوبة التنفيذ.
مستوى الحساب المتوازي ( مستوى الحساب ): يمثل مشروع سولانا
مستوى الكائن ( Object-level ): يمثل مشروع Sui
مستوى المعاملات(Transaction-level): يمثل المشروع Monad، Aptos
استدعاء المستوى / MicroVM بالتوازي (Call-level / MicroVM): تمثل مشروع MegaETH
التوازي على مستوى التعليمات ( Instruction-level ): يمثل المشروع GatlingX
نموذج التزامن غير المتزامن خارج السلسلة، مع نظام الوكلاء الذكيين (Agent / Actor Model) كممثل، ينتمي إلى نمط آخر من الحوسبة المتوازية، كنموذج رسائل عبر السلسلة / غير متزامن (نموذج غير المتزامن )، حيث يعمل كل وكيل ك"عملية ذكية مستقلة"، بطريقة غير متزامنة، مع رسائل معتمدة على الأحداث، دون الحاجة إلى جدولة متزامنة، والمشاريع الممثلة تشمل AO و ICP و Cartesi وغيرها.
ومخططات التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تنتمي إلى آلية التوازي على مستوى النظام، ولا تنتمي إلى الحساب المتوازي داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة/آلة افتراضية. لم تكن هذه الأنواع من مخططات التوسع هي محور النقاش في هذه المقالة، لكننا سنستخدمها مع ذلك لمقارنة أوجه التشابه والاختلاف في المفاهيم المعمارية.
الثاني، سلسلة تعزيز الموازاة لنظام EVM: اختراق حدود الأداء في التوافق
لقد شهدت بنية المعالجة المتسلسلة للإيثريوم تطورات حتى الآن، حيث مرت بعدة جولات من محاولات التوسع مثل التقسيم، وRollup، والهندسة المعمارية المودولية، ولكن لا يزال هناك اختناق في قدرة التنفيذ. ومع ذلك، لا يزال EVM وSolidity هما منصات العقود الذكية الأكثر شيوعًا من حيث قاعدة المطورين وقوة النظام البيئي الحالية. لذلك، تعتبر سلسلة EVM المعززة بشكل متوازي كمسار رئيسي يجمع بين التوافق البيئي وتحسين أداء التنفيذ، وهي تتحول إلى اتجاه مهم في تطور التوسع الجديد. يعتبر مشروع Monad وMegaETH من بين أكثر المشاريع تمثيلاً في هذا الاتجاه، حيث يبنيان بنية معالجة EVM المتوازية الموجهة نحو مشاهد عالية التزامن وارتفاع القدرة على المعالجة، من خلال تأخير التنفيذ وتفكيك الحالة على التوالي.
تحليل آلية الحوسبة المتوازية لـ Monad
Monad هو سلسلة كتلة Layer1 عالية الأداء أعيد تصميمها لـ Ethereum Virtual Machine (EVM)، بناءً على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الإجماع بشكل غير متزامن (Asynchronous Execution)، وفي طبقة التنفيذ يتم تنفيذ متوازي متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي الإجماع والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا من النهاية إلى النهاية.
Pipeline: آلية التنفيذ المتوازي متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بالتوازي، حيث يتمحور الفكر حول تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بالتوازي، مما يشكل هيكل أنابيب ثلاثي الأبعاد، وتعمل كل مرحلة في خيوط أو نوى مستقلة، لتحقيق معالجة متزامنة عبر الكتل، وفي النهاية الوصول إلى تحسين السعة وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) تحقيق الإجماع (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: فصل التوافق والتنفيذ بشكل غير متزامن
في السلاسل التقليدية، يكون توافق المعاملات والتنفيذ عادةً عملية متزامنة، وهذا النموذج المتسلسل يقيد بشكل كبير قابلية الأداء للتوسع. حققت Monad "التنفيذ غير المتزامن" لتوافق الطبقة غير المتزامن، وتنفيذ الطبقة غير المتزامن والتخزين غير المتزامن. مما يقلل بشكل كبير من وقت الكتلة ( وقت الكتلة ) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، واستخدام الموارد أعلى.
التصميم الأساسي:
عملية الإجماع ( طبقة الإجماع ) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقود.
عملية التنفيذ ( مستوى التنفيذ ) يتم تفعيله بشكل غير متزامن بعد اكتمال الإجماع.
بعد الانتهاء من الإجماع، انتقل مباشرة إلى عملية إجماع الكتلة التالية دون الحاجة إلى الانتظار لإكمال التنفيذ.
تنفيذ متوازي متفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذج تسلسل صارم لتنفيذ المعاملات لتجنب تضارب الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
يقوم Monad بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، على افتراض أن معظم المعاملات لا تحتوي على تعارضات حالة.
تشغيل "(Conflict Detector)" في نفس الوقت لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة ( مثل تصادمات القراءة/الكتابة ).
إذا تم اكتشاف تعارض، فسيتم تسلسل تنفيذ المعاملات المتعارضة مرة أخرى، لضمان صحة الحالة.
اختارت Monad مسار التوافق: تقليل التعديلات على قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات خلال عملية التنفيذ، مما يجعلها تشبه نسخة الأداء من الإيثيريوم، مع نضج جيد يسهل انتقال نظام EVM البيئي، وهي مسرع التوازي لعالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وموازية متوافقة مع EVM، يمكن أن تعمل كشبكة L1 مستقلة، أو كطبقة تعزيز تنفيذ على إيثريوم (Execution Layer) أو كمكونات معيارية. الهدف الرئيسي من تصميمه هو تفكيك منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي اقترحته MegaETH هو: بنية Micro-VM + DAG اعتماد الحالة (مخطط الاعتماد غير الدوري للحالة) وآلية التزامن المعيارية، معًا لبناء نظام تنفيذ متوازي يركز على "التخييط داخل السلسلة".
Micro-VM( مايكرو آلة افتراضية ) الهيكل: الحساب هو خيط
يقدم MegaETH نموذج التنفيذ "ماكينة افتراضية ميكرو واحدة لكل حساب (Micro-VM)"، ويعمل على "تسلسل" بيئة التنفيذ، مما يوفر وحدة العزل الدنيا للتخطيط المتوازي. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
اعتماد الحالة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنيت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي، حيث يتم نمذجة جميع المعاملات التي تعدل أي حسابات، وتقرأ أي حسابات، على أنها علاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي مباشرة، بينما سيتم جدولة المعاملات ذات العلاقات اعتماد وفقًا لترتيب الطوبولوجيا أو تأجيلها. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المتكررة أثناء عملية التنفيذ المتوازي.
تنفيذ غير متزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة ( ) التنفيذ غير المتكرر ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل استدعاء غير متزامنة دون منع الانتظار. يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن (Call Graph) ؛ معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
باختصار، يقوم 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 )، ومن خلال بروتوكول إعادة الرهن ( Restaking ) تحقق المشاركة الآمنة للموارد بين الشبكة الرئيسية وSPNs.
علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من خلال تقنيات شجرة Merkle متعددة النسخ، والترميز التفاضلي (Delta Encoding)، والعنوان النسخي (Versioned Addressing) وADS Pushdown(، من محرك التخزين الأساسي، مما أدى إلى إطلاق محرك تخزين عالي الأداء من blockchain الأصلي Pharos Store، مما يحقق إنتاجية عالية، وزمن انتقال منخفض، وقابلية تحقق قوية.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
5
مشاركة
تعليق
0/400
ZkSnarker
· 07-23 20:13
حسناً، من الناحية الفنية، فإن الثلاثية تشبه أكثر اقتراحاً بصراحة...
شاهد النسخة الأصليةرد0
OnchainDetective
· 07-23 15:07
أزرق نحيف حتى التوسع لا يمكن حله من قال إن عدة ولادات ليست مرضاً
شاهد النسخة الأصليةرد0
IfIWereOnChain
· 07-21 13:51
يقول البعض إن zk ليس له فائدة، وفي النهاية يجب العودة إلى tps.
بانوراما مجال الحوسبة المتوازية Web3: طريق توسعة EVM لـ Monad و MegaETH
خريطة شاملة لمسار الحوسبة المتوازية في Web3: ما هي أفضل خطة للتوسع الأصلي؟
مثلث "مستحيل" blockchain ( Blockchain Trilemma ) "الأمان"، "اللامركزية"، و"قابلية التوسع" تكشف عن التوازن الجوهري في تصميم أنظمة blockchain، حيث من الصعب على مشاريع blockchain تحقيق "أمان مطلق، مشاركة عالمية، ومعالجة سريعة" في نفس الوقت. بالنسبة لموضوع "قابلية التوسع" هذا، فإن الحلول السائدة لتوسيع blockchain في السوق الحالية تصنف وفقًا للأنماط، بما في ذلك:
تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط zk، الهيكلية عديمة الحالة، وما إلى ذلك، تغطي عدة مستويات من التنفيذ والحالة والبيانات والهياكل، وهي نظام توسيع كامل "تعاوني متعدد المستويات، وتجميع وحدات". بينما يركز هذا النص على طريقة التوسيع التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة ( intra-chain parallelism )، تركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة طموحات أداء مختلفة، ونماذج تطوير، وفلسفات معمارية، حيث تصبح درجة التوازي بشكل متزايد أكثر دقة، وتزداد شدة التوازي، كما تزداد تعقيد جدولة المهام، وتزداد أيضًا تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، مع نظام الوكلاء الذكيين (Agent / Actor Model) كممثل، ينتمي إلى نمط آخر من الحوسبة المتوازية، كنموذج رسائل عبر السلسلة / غير متزامن (نموذج غير المتزامن )، حيث يعمل كل وكيل ك"عملية ذكية مستقلة"، بطريقة غير متزامنة، مع رسائل معتمدة على الأحداث، دون الحاجة إلى جدولة متزامنة، والمشاريع الممثلة تشمل AO و ICP و Cartesi وغيرها.
ومخططات التوسع المعروفة لدينا مثل Rollup أو تقسيم الشريحة، تنتمي إلى آلية التوازي على مستوى النظام، ولا تنتمي إلى الحساب المتوازي داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة/آلة افتراضية. لم تكن هذه الأنواع من مخططات التوسع هي محور النقاش في هذه المقالة، لكننا سنستخدمها مع ذلك لمقارنة أوجه التشابه والاختلاف في المفاهيم المعمارية.
الثاني، سلسلة تعزيز الموازاة لنظام EVM: اختراق حدود الأداء في التوافق
لقد شهدت بنية المعالجة المتسلسلة للإيثريوم تطورات حتى الآن، حيث مرت بعدة جولات من محاولات التوسع مثل التقسيم، وRollup، والهندسة المعمارية المودولية، ولكن لا يزال هناك اختناق في قدرة التنفيذ. ومع ذلك، لا يزال EVM وSolidity هما منصات العقود الذكية الأكثر شيوعًا من حيث قاعدة المطورين وقوة النظام البيئي الحالية. لذلك، تعتبر سلسلة EVM المعززة بشكل متوازي كمسار رئيسي يجمع بين التوافق البيئي وتحسين أداء التنفيذ، وهي تتحول إلى اتجاه مهم في تطور التوسع الجديد. يعتبر مشروع Monad وMegaETH من بين أكثر المشاريع تمثيلاً في هذا الاتجاه، حيث يبنيان بنية معالجة EVM المتوازية الموجهة نحو مشاهد عالية التزامن وارتفاع القدرة على المعالجة، من خلال تأخير التنفيذ وتفكيك الحالة على التوالي.
تحليل آلية الحوسبة المتوازية لـ Monad
Monad هو سلسلة كتلة Layer1 عالية الأداء أعيد تصميمها لـ Ethereum Virtual Machine (EVM)، بناءً على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الإجماع بشكل غير متزامن (Asynchronous Execution)، وفي طبقة التنفيذ يتم تنفيذ متوازي متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي الإجماع والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، مما يحقق تحسينًا من النهاية إلى النهاية.
Pipeline: آلية التنفيذ المتوازي متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بالتوازي، حيث يتمحور الفكر حول تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بالتوازي، مما يشكل هيكل أنابيب ثلاثي الأبعاد، وتعمل كل مرحلة في خيوط أو نوى مستقلة، لتحقيق معالجة متزامنة عبر الكتل، وفي النهاية الوصول إلى تحسين السعة وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) تحقيق الإجماع (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: فصل التوافق والتنفيذ بشكل غير متزامن
في السلاسل التقليدية، يكون توافق المعاملات والتنفيذ عادةً عملية متزامنة، وهذا النموذج المتسلسل يقيد بشكل كبير قابلية الأداء للتوسع. حققت Monad "التنفيذ غير المتزامن" لتوافق الطبقة غير المتزامن، وتنفيذ الطبقة غير المتزامن والتخزين غير المتزامن. مما يقلل بشكل كبير من وقت الكتلة ( وقت الكتلة ) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، واستخدام الموارد أعلى.
التصميم الأساسي:
تنفيذ متوازي متفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذج تسلسل صارم لتنفيذ المعاملات لتجنب تضارب الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسار التوافق: تقليل التعديلات على قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات خلال عملية التنفيذ، مما يجعلها تشبه نسخة الأداء من الإيثيريوم، مع نضج جيد يسهل انتقال نظام EVM البيئي، وهي مسرع التوازي لعالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 الخاص بـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء وموازية متوافقة مع EVM، يمكن أن تعمل كشبكة L1 مستقلة، أو كطبقة تعزيز تنفيذ على إيثريوم (Execution Layer) أو كمكونات معيارية. الهدف الرئيسي من تصميمه هو تفكيك منطق الحساب، وبيئة التنفيذ، والحالة إلى وحدات صغيرة يمكن جدولتها بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة منخفضة التأخير. الابتكار الرئيسي الذي اقترحته MegaETH هو: بنية Micro-VM + DAG اعتماد الحالة (مخطط الاعتماد غير الدوري للحالة) وآلية التزامن المعيارية، معًا لبناء نظام تنفيذ متوازي يركز على "التخييط داخل السلسلة".
Micro-VM( مايكرو آلة افتراضية ) الهيكل: الحساب هو خيط
يقدم MegaETH نموذج التنفيذ "ماكينة افتراضية ميكرو واحدة لكل حساب (Micro-VM)"، ويعمل على "تسلسل" بيئة التنفيذ، مما يوفر وحدة العزل الدنيا للتخطيط المتوازي. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح لعدد كبير من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
اعتماد الحالة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنيت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي، حيث يتم نمذجة جميع المعاملات التي تعدل أي حسابات، وتقرأ أي حسابات، على أنها علاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي مباشرة، بينما سيتم جدولة المعاملات ذات العلاقات اعتماد وفقًا لترتيب الطوبولوجيا أو تأجيلها. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المتكررة أثناء عملية التنفيذ المتوازي.
تنفيذ غير متزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة ( ) التنفيذ غير المتكرر ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل استدعاء غير متزامنة دون منع الانتظار. يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن (Call Graph) ؛ معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
باختصار، يقوم 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:
علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من خلال تقنيات شجرة Merkle متعددة النسخ، والترميز التفاضلي (Delta Encoding)، والعنوان النسخي (Versioned Addressing) وADS Pushdown(، من محرك التخزين الأساسي، مما أدى إلى إطلاق محرك تخزين عالي الأداء من blockchain الأصلي Pharos Store، مما يحقق إنتاجية عالية، وزمن انتقال منخفض، وقابلية تحقق قوية.