مخطط شامل لمجال الحوسبة المتوازية في Web3: ما هي أفضل حل للتوسع الأصلي؟
1. نظرة عامة على الخلفية
يظهر "مثلث الاستحالة" في تقنية البلوكشين "(" "الأمان"، "اللامركزية"، و"القابلية للتوسع" ")" التوازنات الأساسية في تصميم أنظمة البلوكشين، مما يعني أنه من الصعب على مشاريع البلوكشين تحقيق "أقصى درجات الأمان، ومشاركة الجميع، وسرعة المعالجة" في نفس الوقت. وبالنسبة لموضوع "القابلية للتوسع" الدائم، فإن الحلول الرئيسية لتوسيع نطاق البلوكشين المتاحة في السوق مصنفة حسب النماذج، بما في ذلك:
تنفيذ توسيع معزز: تعزيز القدرة التنفيذية في مكانها، مثل المعالجة المتوازية، GPU، متعددة النواة
عزل الحالة لتوسيع القدرة: تقسيم أفقي للحالة / شارد، مثل التجزئة، UTXO، الشبكات الفرعية المتعددة
التوسع الخارجي من نوع التشغيل المأجور: نقل التنفيذ إلى خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع بنية مفككة: هيكلية مُودولية، تشغيل متعاون، مثل سلسلة الوحدات، مُرتّب مشترك، Rollup Mesh
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط الإثبات zk، الهيكلية عديمة الحالة، وغيرها، التي تغطي مستويات متعددة من التنفيذ، الحالة، البيانات، والهياكل، وهي نظام توسيع كامل "بتعاون متعدد الطبقات، وتجميع وحدات". بينما يركز هذا المقال على طريقة التوسيع التي تعتمد بشكل رئيسي على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة هيكلية، حيث تصبح حبيبات التوازي أكثر دقة، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، وكذلك زيادة تعقيد البرمجة وصعوبة التنفيذ.
مستوى حساب متوازي ( مستوى الحساب ): يمثل مشروع سولانا
مستوى الكائن متوازي ( Object-level ): يمثل مشروع Sui
مستوى المعاملات (Transaction-level): يمثل المشروع Monad، Aptos
استدعاء مستوى / ميكرو VM بالتوازي (: يمثل مشروع MegaETH
مستوى التعليمات المتوازي ) Instruction-level (: يمثل مشروع GatlingX
نموذج الازدواج المتزامن غير المتصل بالشبكة ، مع نظام الكائنات الذكية Actor ) نموذج الوكيل / الكائن ( كممثل له ، ينتمي إلى نمط آخر من حسابات المتوازية ، كنظام رسائل عبر السلاسل / غير المتزامن ) نموذج غير تزامني غير قائم على الكتل ( ، كل وكيل يعمل كـ "عملية كائن ذكي" تعمل بشكل مستقل ، بطريقة غير متزامنة للرسائل ، مدفوعة بالأحداث ، دون الحاجة إلى جدولة متزامنة ، من المشاريع الممثلة 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 هو blockchain عالي الأداء من Layer1 مصمم لـ Ethereum Virtual Machine ###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.
![Web3مسار الحسابات المتوازية خريطة شاملة: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) تحليل آلية الحوسبة المتوازية لـ MegaETH
يختلف MegaETH في تحديده عن L1 الخاص بـ Monad، حيث يتم تحديده كطبقة تنفيذ عالية الأداء وقابلة للتعديل متوافقة مع EVM، يمكن أن تعمل كشبكة عامة مستقلة من نوع L1، أو كطبقة تعزيز تنفيذية على الإيثريوم ###Execution Layer( أو كمكون معدّل. الهدف الرئيسي من تصميمه هو فصل منطق الحساب، وبيئة التنفيذ، والحالة، وتحليلها إلى وحدات صغيرة قابلة للجدولة بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي اقترحه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة )الرسوم البيانية المعتمدة على الحالة غير الدائرية( وآلية التزامن المعدلة، التي تبني معًا نظام تنفيذ متوازي يركز على "تعدد الخيوط داخل السلسلة".
مايكرو-VM) آلة افتراضية صغيرة ( الهيكل: الحساب هو الخيط
تم تقديم نموذج التنفيذ "مايكرو-VM لكل حساب)Micro-VM(" في MegaETH، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويقدم وحدة العزل الدنيا لجدولة متوازية. تتواصل هذه VMs فيما بينها من خلال الرسائل غير المتزامنة)Asynchronous Messaging(، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من VMs بالتنفيذ بشكل مستقل، والتخزين بشكل مستقل، مما يجعلها متوازية بشكل طبيعي.
آلية جدولة معتمدة على الرسم البياني للإعتمادية (DAG)
بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يحافظ النظام على رسم بياني عالمي للاعتماد )Dependency Graph( في الوقت الحقيقي، وكل معاملة تعدل أي حسابات، وتقرأ أي حسابات، يتم نمذجتها جميعًا كعلاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي مباشرة، بينما سيتم جدولة المعاملات ذات العلاقات الاعتمادية بطريقة تسلسلية أو متأخرة وفقًا لترتيب التوبولوجيا. يضمن رسم الاعتماد الاتساق في الحالة وعدم الكتابة المتكررة خلال عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
ميغا إيث مبنية على نموذج البرمجة غير المتزامنة، مشابهة لنموذج الممثل في تمرير الرسائل غير المتزامنة، والتي تحل مشكلة الاستدعاءات المتسلسلة في EVM التقليدي. استدعاء العقود غير متزامن ) وتنفيذ غير تكراري (، عند استدعاء العقد A → B → C، يتم تحويل كل استدعاء إلى غير متزامن، دون الحاجة إلى الانتظار في حالة الحظر؛ يتم توسيع مكدس الاستدعاءات إلى رسم بياني للاستدعاءات غير المتزامنة )رسم بياني للاستدعاءات(؛ معالجة المعاملات = استعراض الرسم البياني غير المتزامن + حل التبعيات + جدولة متوازية.
بشكل عام، يقوم MegaETH بكسر نموذج آلة الحالة أحادية الخيط التقليدية EVM، حيث يتم تحقيق تغليف الميكرو VM على أساس الحسابات، من خلال جدول معاملات يعتمد على الرسم البياني للحالة، ويستبدل آلية الرسائل غير المتزامنة بدعوة المكدس المتزامن. إنها منصة حساب متوازٍ تم إعادة تصميمها من "بنية الحسابات → بنية الجدولة → تدفق التنفيذ" على جميع الأبعاد، مما يوفر أفكارًا جديدة على مستوى النمط لبناء أنظمة عالية الأداء من الجيل التالي على السلسلة.
اختارت MegaETH مسار إعادة الهيكلة: تحويل الحسابات والعقود بالكامل إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لإطلاق أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، ولكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ويشبه نظام تشغيل موزع فائق تحت مفهوم إيثيريوم.
![Web3 مسار الحوسبة المتوازية: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
تختلف فلسفة تصميم كل من Monad و MegaETH اختلافًا كبيرًا عن التقسيم )Sharding(: يقسم التقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة )Shards(، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة على مستوى الشبكة؛ بينما يحافظ كل من Monad و MegaETH على تكامل السلسلة الواحدة، مع توسيع أفقي فقط على مستوى التنفيذ، مما يحدث تحسينات في الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH أساسًا على مسارات تحسين الإنتاجية، بهدف أساسي هو رفع TPS داخل السلسلة، من خلال تنفيذ مؤجل )Deferred Execution( وميكرو-آلة افتراضية )Micro-VM( لتحقيق المعالجة المتوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network شبكة بلوكشين من المستوى الأول L1، تعتمد على التوازي الكامل، حيث يتمثل آلية الحوسبة المتوازية الأساسية فيها بـ "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة )SPNs(، كما تدعم بيئات متعددة للآلة الافتراضية )EVM و Wasm(، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية )ZK(، وبيئات التنفيذ الموثوقة )TEE(.
تحليل آلية الحوسبة المتوازية Rollup Mesh:
معالجة الأنابيب غير المتزامنة على مدار دورة الحياة ): تقوم Pharos بفصل مراحل المعاملات ( مثل الإجماع، التنفيذ، التخزين )، وتت采用 طريقة معالجة غير متزامنة، مما يسمح لكل مرحلة أن تتم بشكل مستقل ومتوازي، وبالتالي تحسين كفاءة المعالجة الإجمالية.
تنفيذ مزدوج للآلة الافتراضية المتوازية (Dual VM Parallel Execution): يدعم Pharos بيئتي الآلة الافتراضية EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة حسب الحاجة. لا تعزز هذه الهيكلية المزدوجة للآلة الافتراضية مرونة النظام فحسب، بل تعزز أيضًا من قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
معالجة خاصة للشبكة (SPNs): SPNs هي مكونات رئيسية في بنية Pharos، تشبه الشبكات الفرعية المودولية، مصممة خصيصًا لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بشكل متوازي، مما يعزز من قابلية توسيع النظام وأدائه.
التوافق المعياري وآلية إعادة الرهن ( Modular Consensus & Restaking ): قدمت Pharos آلية توافق مرنة تدعم نماذج توافق متعددة ( مثل PBFT و PoS و PoA )، ومن خلال بروتوكول إعادة الرهن ( Restaking ) تحقق من المشاركة الآمنة والمشاركة في الموارد بين الشبكة الرئيسية و SPNs.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
8
إعادة النشر
مشاركة
تعليق
0/400
LayerHopper
· 08-14 18:01
المحللون المرحون الذين يتنقلون بين كل L2، المتفائلون الذين يحبون قوة الحوسبة
يرجى كتابة تعليق باللغة الصينية بأسلوب الحساب المذكور أعلاه.
شاهد النسخة الأصليةرد0
PanicSeller69
· 08-14 00:41
ههه التضحية باللامركزية لزيادة متطلبات المعاملات في الثانية؟
شاهد النسخة الأصليةرد0
SeeYouInFourYears
· 08-13 17:12
بدأت الطبقة 1 مرة أخرى في المنافسة
شاهد النسخة الأصليةرد0
ChainComedian
· 08-12 17:17
كون متوازي معقد هكذا، من الأفضل استخدام بطاقة الرسوميات لتحسين TPS مباشرة.
شاهد النسخة الأصليةرد0
SchroedingerGas
· 08-12 17:03
L2 فهمت كل شيء، لكن رسوم الغاز لا تزال مرتفعة.
شاهد النسخة الأصليةرد0
OnchainArchaeologist
· 08-12 16:57
هل ما زلتم تتداول في التوازي الأصلي؟ لماذا لا تشتري بطاقة N للتعدين؟
panorama الحسابات المتوازية Web3: اختراق الأداء تحت خمسة أنماط للتوسع
مخطط شامل لمجال الحوسبة المتوازية في Web3: ما هي أفضل حل للتوسع الأصلي؟
1. نظرة عامة على الخلفية
يظهر "مثلث الاستحالة" في تقنية البلوكشين "(" "الأمان"، "اللامركزية"، و"القابلية للتوسع" ")" التوازنات الأساسية في تصميم أنظمة البلوكشين، مما يعني أنه من الصعب على مشاريع البلوكشين تحقيق "أقصى درجات الأمان، ومشاركة الجميع، وسرعة المعالجة" في نفس الوقت. وبالنسبة لموضوع "القابلية للتوسع" الدائم، فإن الحلول الرئيسية لتوسيع نطاق البلوكشين المتاحة في السوق مصنفة حسب النماذج، بما في ذلك:
تشمل حلول توسيع سلسلة الكتل: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط الإثبات zk، الهيكلية عديمة الحالة، وغيرها، التي تغطي مستويات متعددة من التنفيذ، الحالة، البيانات، والهياكل، وهي نظام توسيع كامل "بتعاون متعدد الطبقات، وتجميع وحدات". بينما يركز هذا المقال على طريقة التوسيع التي تعتمد بشكل رئيسي على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة (intra-chain parallelism)، تركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل فئة سعيًا مختلفًا للأداء، ونموذج تطوير، وفلسفة هيكلية، حيث تصبح حبيبات التوازي أكثر دقة، وزيادة شدة التوازي، وزيادة تعقيد الجدولة، وكذلك زيادة تعقيد البرمجة وصعوبة التنفيذ.
نموذج الازدواج المتزامن غير المتصل بالشبكة ، مع نظام الكائنات الذكية Actor ) نموذج الوكيل / الكائن ( كممثل له ، ينتمي إلى نمط آخر من حسابات المتوازية ، كنظام رسائل عبر السلاسل / غير المتزامن ) نموذج غير تزامني غير قائم على الكتل ( ، كل وكيل يعمل كـ "عملية كائن ذكي" تعمل بشكل مستقل ، بطريقة غير متزامنة للرسائل ، مدفوعة بالأحداث ، دون الحاجة إلى جدولة متزامنة ، من المشاريع الممثلة 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 هو blockchain عالي الأداء من Layer1 مصمم لـ Ethereum Virtual Machine ###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.
![Web3مسار الحسابات المتوازية خريطة شاملة: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) تحليل آلية الحوسبة المتوازية لـ MegaETH
يختلف MegaETH في تحديده عن L1 الخاص بـ Monad، حيث يتم تحديده كطبقة تنفيذ عالية الأداء وقابلة للتعديل متوافقة مع EVM، يمكن أن تعمل كشبكة عامة مستقلة من نوع L1، أو كطبقة تعزيز تنفيذية على الإيثريوم ###Execution Layer( أو كمكون معدّل. الهدف الرئيسي من تصميمه هو فصل منطق الحساب، وبيئة التنفيذ، والحالة، وتحليلها إلى وحدات صغيرة قابلة للجدولة بشكل مستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة التأخير. الابتكار الرئيسي الذي اقترحه MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة )الرسوم البيانية المعتمدة على الحالة غير الدائرية( وآلية التزامن المعدلة، التي تبني معًا نظام تنفيذ متوازي يركز على "تعدد الخيوط داخل السلسلة".
مايكرو-VM) آلة افتراضية صغيرة ( الهيكل: الحساب هو الخيط
تم تقديم نموذج التنفيذ "مايكرو-VM لكل حساب)Micro-VM(" في MegaETH، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويقدم وحدة العزل الدنيا لجدولة متوازية. تتواصل هذه VMs فيما بينها من خلال الرسائل غير المتزامنة)Asynchronous Messaging(، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من VMs بالتنفيذ بشكل مستقل، والتخزين بشكل مستقل، مما يجعلها متوازية بشكل طبيعي.
آلية جدولة معتمدة على الرسم البياني للإعتمادية (DAG)
بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يحافظ النظام على رسم بياني عالمي للاعتماد )Dependency Graph( في الوقت الحقيقي، وكل معاملة تعدل أي حسابات، وتقرأ أي حسابات، يتم نمذجتها جميعًا كعلاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي مباشرة، بينما سيتم جدولة المعاملات ذات العلاقات الاعتمادية بطريقة تسلسلية أو متأخرة وفقًا لترتيب التوبولوجيا. يضمن رسم الاعتماد الاتساق في الحالة وعدم الكتابة المتكررة خلال عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
ميغا إيث مبنية على نموذج البرمجة غير المتزامنة، مشابهة لنموذج الممثل في تمرير الرسائل غير المتزامنة، والتي تحل مشكلة الاستدعاءات المتسلسلة في EVM التقليدي. استدعاء العقود غير متزامن ) وتنفيذ غير تكراري (، عند استدعاء العقد A → B → C، يتم تحويل كل استدعاء إلى غير متزامن، دون الحاجة إلى الانتظار في حالة الحظر؛ يتم توسيع مكدس الاستدعاءات إلى رسم بياني للاستدعاءات غير المتزامنة )رسم بياني للاستدعاءات(؛ معالجة المعاملات = استعراض الرسم البياني غير المتزامن + حل التبعيات + جدولة متوازية.
بشكل عام، يقوم MegaETH بكسر نموذج آلة الحالة أحادية الخيط التقليدية EVM، حيث يتم تحقيق تغليف الميكرو VM على أساس الحسابات، من خلال جدول معاملات يعتمد على الرسم البياني للحالة، ويستبدل آلية الرسائل غير المتزامنة بدعوة المكدس المتزامن. إنها منصة حساب متوازٍ تم إعادة تصميمها من "بنية الحسابات → بنية الجدولة → تدفق التنفيذ" على جميع الأبعاد، مما يوفر أفكارًا جديدة على مستوى النمط لبناء أنظمة عالية الأداء من الجيل التالي على السلسلة.
اختارت MegaETH مسار إعادة الهيكلة: تحويل الحسابات والعقود بالكامل إلى VM مستقل، من خلال جدولة التنفيذ غير المتزامن لإطلاق أقصى إمكانيات التوازي. نظريًا، فإن الحد الأقصى للتوازي في MegaETH أعلى، ولكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ويشبه نظام تشغيل موزع فائق تحت مفهوم إيثيريوم.
![Web3 مسار الحوسبة المتوازية: أفضل حل للتوسع الأصلي؟])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
تختلف فلسفة تصميم كل من Monad و MegaETH اختلافًا كبيرًا عن التقسيم )Sharding(: يقسم التقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة )Shards(، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة على مستوى الشبكة؛ بينما يحافظ كل من Monad و MegaETH على تكامل السلسلة الواحدة، مع توسيع أفقي فقط على مستوى التنفيذ، مما يحدث تحسينات في الأداء من خلال التنفيذ المتوازي داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز العمودي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH أساسًا على مسارات تحسين الإنتاجية، بهدف أساسي هو رفع TPS داخل السلسلة، من خلال تنفيذ مؤجل )Deferred Execution( وميكرو-آلة افتراضية )Micro-VM( لتحقيق المعالجة المتوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network شبكة بلوكشين من المستوى الأول L1، تعتمد على التوازي الكامل، حيث يتمثل آلية الحوسبة المتوازية الأساسية فيها بـ "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة )SPNs(، كما تدعم بيئات متعددة للآلة الافتراضية )EVM و Wasm(، وتدمج تقنيات متقدمة مثل الإثباتات الصفرية )ZK(، وبيئات التنفيذ الموثوقة )TEE(.
تحليل آلية الحوسبة المتوازية Rollup Mesh:
يرجى كتابة تعليق باللغة الصينية بأسلوب الحساب المذكور أعلاه.