خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟
المثلث "غير الممكن" في blockchain "الأمان" و"اللامركزية" و"القابلية للتوسع" يكشف عن المقايضات الجوهرية في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة الجميع، معالجة سريعة" في نفس الوقت. فيما يتعلق بموضوع "القابلية للتوسع" الذي لا ينتهي، تشمل الحلول الرائجة لتوسيع blockchain في السوق حاليًا، حسب الأنماط، ما يلي:
تنفيذ التوسع المعزز: تعزيز القدرة التنفيذية في الموقع، مثل التوازي، GPU، والمعالجة متعددة النواة
نموذج توسيع معزول: تقسيم الحالة الأفقية / شارد، مثل الشظايا، UTXO، شبكات فرعية متعددة
التوسع الخارجي الخارجي: تنفيذ العمليات خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع الهيكل المفصول: هيكلية موزعة، تشغيل متعاون، مثل سلسلة الوحدات، جهاز ترتيب مشترك، Rollup Mesh
توسيع متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع البلوكتشين: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدات DA، الهيكلية المعيارية، نظام Actor، ضغط zk، وهيكل Stateless، مما يغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهو نظام توسيع كامل "تعاون متعدد الطبقات، وتكوينات معيارية". تركز هذه المقالة على طريقة التوسع التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير وفلسفة معمارية مختلفة، حيث يصبح حجم التوازي تدريجيًا أدق، وزيادة شدة التوازي، وتزداد أيضًا تعقيد الجدولة، وتزداد تعقيد البرمجة وصعوبة التنفيذ.
مستوى الحساب (: يمثل مشروع سولانا
مستوى الكائن ) Object-level (: يمثل مشروع Sui
مستوى المعاملات )Transaction-level(: يمثل المشروع Monad, Aptos
مستوى الاستدعاء / Micro VM متوازي ) مستوى الاستدعاء / MicroVM (: يمثل مشروع MegaETH
التوازي على مستوى التعليمات ) Instruction-level (: يمثل المشروع GatlingX
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثل نظام الكيانات الذكية Actor )Agent / Actor Model(، ينتمي إلى نمط آخر من الحساب المتوازي، كنظام رسائل عبر السلاسل / غير متزامن )نموذج غير متزامن غير سلسلة (، حيث يعمل كل وكيل كـ "عملية كيان ذكية" مستقلة، بطريقة غير متزامنة مع رسائل، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
بينما تعتبر حلول Rollup أو تقسيم التوسع التي نعرفها جيدًا آليات تزامن على مستوى النظام، ولا تنتمي إلى الحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، لكننا سنستخدمها لمقارنة الاختلافات في مفاهيم الهيكل.
![خريطة مشهد مسار الحوسبة المتوازية Web3: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
٢. سلسلة تعزيز التوازي EVM: لكسر حدود الأداء ضمن التوافق
تطور هيكل المعالجة المتسلسلة في إيثيريوم حتى الآن، حيث مر بعدة جولات من محاولات التوسع بما في ذلك التقسيم، Rollup، والهياكل المعيارية، لكن لا يزال هناك اختناق في الإنتاجية في طبقة التنفيذ دون突破 جذري. ولكن في الوقت نفسه، لا يزال EVM و Solidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين والطاقة البيئية لعقود الذكية الحالية. لذلك، تعتبر سلسلة EVM المعززة بالتوازي كمسار رئيسي يوازن بين توافق البيئة وتحسين أداء التنفيذ، وهي تتجه لتصبح الاتجاه المهم لتطور التوسع الجديد. يُعتبر Monad و MegaETH المشروعين الأكثر تمثيلاً في هذا الاتجاه، حيث يبدآن من تنفيذ التأخير وتفكيك الحالة، ليبنيا هيكل معالجة متسلسلة EVM موجه نحو السيناريوهات ذات التزامن العالي والإنتاجية العالية.
) تحليل آلية الحساب المتوازي لـ Monad
Monad هي سلسلة كتل عالية الأداء من الطبقة 1 مصممة لإعادة تصميم الآلة الافتراضية للإيثيريوم ###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 قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة والكشف الديناميكي عن التداخل أثناء عملية التنفيذ، مما يجعلها تشبه Ethereum المحسنة من حيث الأداء، مع نضوج جيد وسهولة في تحقيق انتقال بيئة EVM، وهي معجل التوازي لعالم EVM.
![خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) تحليل آلية الحساب المتوازي لـ MegaETH
يختلف نظام MegaETH عن نظام Monad في أنه يعتبر طبقة تنفيذ عالية الأداء وقابلة للتطوير ومتوافقة مع 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 ، تكون كل استدعاء غير متزامنة دون منع الانتظار. يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن )Call Graph( ؛ معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يقوم MegaETH بتجاوز نموذج آلة الحالة ذات الخيط الواحد التقليدي EVM، من خلال تحقيق تغليف الميكرو فيرتشوال ماشين على أساس الحسابات، ويقوم بجدولة المعاملات من خلال رسم الاعتماد على الحالة، ويستخدم آلية الرسائل غير المتزامنة بدلاً من مكدس الاستدعاء المتزامن. إنه منصة حسابية متوازية تم إعادة تصميمها من "بنية الحسابات → بنية الجدولة → سير التنفيذ" على مستوى كامل، مما يوفر أفكاراً جديدة من مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة البناء: حيث يتم تجريد الحسابات والعقود إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لتحرير أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ويشبه أكثر نظام التشغيل الموزع الفائق تحت مفهوم الإيثيريوم.
![رسم بياني شامل لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
تصميم Monad و MegaETH يختلف بشكل كبير عن مفهوم التجزئة )Sharding(: حيث تقوم التجزئة بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة )Shards(، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الطبقة الشبكية؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، حيث يقومان بالتوسع أفقيًا فقط في طبقة التنفيذ، مع تحسين التنفيذ المتوازي داخل السلسلة الواحدة لتجاوز الأداء. يمثل الاثنان اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
![Web3 مسار الحوسبة المتوازية: ما هي أفضل الحلول للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-562daa8ae6acba834ef937bf88a742f0.webp(
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على مسارات تحسين الإنتاجية، بهدف رئيسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل )Deferred Execution( وميكرو-آلة افتراضية )Micro-VM( لتحقيق معالجات متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network شبكة بلوكتشين L1 متكاملة وموحدة، يُعرف آلية الحوسبة المتوازية الأساسية فيها باسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة )SPNs(، مما يدعم بيئات متعددة للآلات الافتراضية )EVM و Wasm(، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية المعرفة )ZK( وبيئات التنفيذ الموثوقة )TEE(.
تحليل آلية الحساب المتوازي Rollup Mesh:
معالجة خط الأنابيب غير المتزامن مدى الحياة )Full Lifecycle Asynchronous Pipelining(: يقوم فارو بتفكيك كل مرحلة من مراحل المعاملات ) مثل الإجماع والتنفيذ والتخزين (، ويستخدم طريقة المعالجة غير المتزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل ومتوازي، وبالتالي تحسين كفاءة المعالجة الشاملة.
تنفيذ متوازي لآلتين افتراضيتين )Dual VM Parallel Execution(: تدعم Pharos بيئتين افتراضيتين EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة وفقًا للاحتياجات. لا تعزز هذه البنية المزدوجة VM مرونة النظام فحسب، بل تعزز أيضًا قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
المعالجة الخاصة بالشبكة )SPNs(: SPNs هي مكون رئيسي في بنية Pharos، تشبه الشبكات الفرعية المعيارية، ومخصصة لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز بشكل أكبر قابلية توسيع النظام وأدائه.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 11
أعجبني
11
5
إعادة النشر
مشاركة
تعليق
0/400
NotSatoshi
· 08-13 13:56
حديث كل هذا أفضل من حل مشكلة الغاز العالية أولاً
شاهد النسخة الأصليةرد0
NFTDreamer
· 08-13 13:55
المتفرجون الذين لا يمانعون في الفوضى من rollup
شاهد النسخة الأصليةرد0
MEVHunterX
· 08-13 13:54
مرة أخرى نتحدث عن خارج السلسلة للتوسع، هكذا كان الأمر، دعنا نرى الأداء.
شاهد النسخة الأصليةرد0
DeFiCaffeinator
· 08-13 13:51
لا أهتم بتحسين الأداء، عالم العملات الرقمية يمكن أن يربح المال وينتهي الأمر.
شاهد النسخة الأصليةرد0
SerumSqueezer
· 08-13 13:49
لكن تقليص تقليص تقليص، لا يزال أفضل من الذهاب إلى الشبكة الرئيسية
رسم تخطيطي شامل للحوسبة المتوازية في Web3: مناقشة أفضل الحلول للتوسع الأصلي
خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟
المثلث "غير الممكن" في blockchain "الأمان" و"اللامركزية" و"القابلية للتوسع" يكشف عن المقايضات الجوهرية في تصميم أنظمة blockchain، مما يعني أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة الجميع، معالجة سريعة" في نفس الوقت. فيما يتعلق بموضوع "القابلية للتوسع" الذي لا ينتهي، تشمل الحلول الرائجة لتوسيع blockchain في السوق حاليًا، حسب الأنماط، ما يلي:
تشمل حلول توسيع البلوكتشين: الحساب المتوازي داخل السلسلة، Rollup، تقسيم، وحدات DA، الهيكلية المعيارية، نظام Actor، ضغط zk، وهيكل Stateless، مما يغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهو نظام توسيع كامل "تعاون متعدد الطبقات، وتكوينات معيارية". تركز هذه المقالة على طريقة التوسع التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير وفلسفة معمارية مختلفة، حيث يصبح حجم التوازي تدريجيًا أدق، وزيادة شدة التوازي، وتزداد أيضًا تعقيد الجدولة، وتزداد تعقيد البرمجة وصعوبة التنفيذ.
نموذج التزامن غير المتزامن خارج السلسلة، الذي يمثل نظام الكيانات الذكية Actor )Agent / Actor Model(، ينتمي إلى نمط آخر من الحساب المتوازي، كنظام رسائل عبر السلاسل / غير متزامن )نموذج غير متزامن غير سلسلة (، حيث يعمل كل وكيل كـ "عملية كيان ذكية" مستقلة، بطريقة غير متزامنة مع رسائل، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.
بينما تعتبر حلول Rollup أو تقسيم التوسع التي نعرفها جيدًا آليات تزامن على مستوى النظام، ولا تنتمي إلى الحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل / مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة درجة التوازي داخل كتلة واحدة / آلة افتراضية. هذه الحلول التوسعية ليست محور النقاش في هذه المقالة، لكننا سنستخدمها لمقارنة الاختلافات في مفاهيم الهيكل.
![خريطة مشهد مسار الحوسبة المتوازية Web3: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(
٢. سلسلة تعزيز التوازي EVM: لكسر حدود الأداء ضمن التوافق
تطور هيكل المعالجة المتسلسلة في إيثيريوم حتى الآن، حيث مر بعدة جولات من محاولات التوسع بما في ذلك التقسيم، Rollup، والهياكل المعيارية، لكن لا يزال هناك اختناق في الإنتاجية في طبقة التنفيذ دون突破 جذري. ولكن في الوقت نفسه، لا يزال EVM و Solidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين والطاقة البيئية لعقود الذكية الحالية. لذلك، تعتبر سلسلة EVM المعززة بالتوازي كمسار رئيسي يوازن بين توافق البيئة وتحسين أداء التنفيذ، وهي تتجه لتصبح الاتجاه المهم لتطور التوسع الجديد. يُعتبر Monad و MegaETH المشروعين الأكثر تمثيلاً في هذا الاتجاه، حيث يبدآن من تنفيذ التأخير وتفكيك الحالة، ليبنيا هيكل معالجة متسلسلة EVM موجه نحو السيناريوهات ذات التزامن العالي والإنتاجية العالية.
) تحليل آلية الحساب المتوازي لـ Monad
Monad هي سلسلة كتل عالية الأداء من الطبقة 1 مصممة لإعادة تصميم الآلة الافتراضية للإيثيريوم ###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 قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة والكشف الديناميكي عن التداخل أثناء عملية التنفيذ، مما يجعلها تشبه Ethereum المحسنة من حيث الأداء، مع نضوج جيد وسهولة في تحقيق انتقال بيئة EVM، وهي معجل التوازي لعالم EVM.
![خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) تحليل آلية الحساب المتوازي لـ MegaETH
يختلف نظام MegaETH عن نظام Monad في أنه يعتبر طبقة تنفيذ عالية الأداء وقابلة للتطوير ومتوافقة مع 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 ، تكون كل استدعاء غير متزامنة دون منع الانتظار. يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن )Call Graph( ؛ معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يقوم MegaETH بتجاوز نموذج آلة الحالة ذات الخيط الواحد التقليدي EVM، من خلال تحقيق تغليف الميكرو فيرتشوال ماشين على أساس الحسابات، ويقوم بجدولة المعاملات من خلال رسم الاعتماد على الحالة، ويستخدم آلية الرسائل غير المتزامنة بدلاً من مكدس الاستدعاء المتزامن. إنه منصة حسابية متوازية تم إعادة تصميمها من "بنية الحسابات → بنية الجدولة → سير التنفيذ" على مستوى كامل، مما يوفر أفكاراً جديدة من مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة البناء: حيث يتم تجريد الحسابات والعقود إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لتحرير أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ويشبه أكثر نظام التشغيل الموزع الفائق تحت مفهوم الإيثيريوم.
![رسم بياني شامل لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
تصميم Monad و MegaETH يختلف بشكل كبير عن مفهوم التجزئة )Sharding(: حيث تقوم التجزئة بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة )Shards(، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الطبقة الشبكية؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الواحدة، حيث يقومان بالتوسع أفقيًا فقط في طبقة التنفيذ، مع تحسين التنفيذ المتوازي داخل السلسلة الواحدة لتجاوز الأداء. يمثل الاثنان اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
![Web3 مسار الحوسبة المتوازية: ما هي أفضل الحلول للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-562daa8ae6acba834ef937bf88a742f0.webp(
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على مسارات تحسين الإنتاجية، بهدف رئيسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل )Deferred Execution( وميكرو-آلة افتراضية )Micro-VM( لتحقيق معالجات متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network شبكة بلوكتشين L1 متكاملة وموحدة، يُعرف آلية الحوسبة المتوازية الأساسية فيها باسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة )SPNs(، مما يدعم بيئات متعددة للآلات الافتراضية )EVM و Wasm(، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية المعرفة )ZK( وبيئات التنفيذ الموثوقة )TEE(.
تحليل آلية الحساب المتوازي Rollup Mesh: