مشهد الحوسبة المتوازية في Web3: ابتكارات في خطط التوسع وانفراجات في الأداء

خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟

مقدمة

"مثلث" عدم إمكانية Blockchain (Blockchain Trilemma) "الأمان"، "اللامركزية"، "القابلية للتوسع" يكشف عن التوازن الجوهري في تصميم أنظمة Blockchain، أي أن مشاريع Blockchain من الصعب تحقيق "أقصى أمان، مشاركة للجميع، معالجة سريعة" في نفس الوقت. بالنسبة للموضوع الدائم "القابلية للتوسع"، فإن الحلول الرئيسية لتوسيع Blockchain المتاحة في السوق حالياً مصنفة وفقًا للنموذج، بما في ذلك:

  • تنفيذ تحسين التوسع: تعزيز القدرة التنفيذية في الموقع، مثل المعالجة المتوازية، GPU، متعددة النواة
  • توسيع العزل الحاوي: تقسيم الحالة أفقياً / شظية، مثل الشظايا، UTXO، شبكات فرعية متعددة
  • توسيع خارجي من نوع الإسناد: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
  • توسيع هيكلية غير مترابطة: نمذجة الهيكل، تشغيل متعاون، مثل سلسلة الوحدات، منظم مشترك، Rollup Mesh
  • توسيع سعة متزامن غير متزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط

تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكل المعياري، نظام Actor، ضغط zk برهان، الهيكل عديم الحالة، إلخ، والتي تغطي مستويات متعددة من التنفيذ والحالة والبيانات والهياكل، وهي نظام توسيع كامل "تعاون متعدد الطبقات، وتجميع الوحدات". بينما تركز هذه المقالة على طريقة التوسيع التي تعتمد على الحساب المتوازي.

الحساب المتوازي داخل السلسلة (intra-chain parallelism)، يركز على التنفيذ المتوازي للمعاملات / التعليمات داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، كل فئة تمثل أهداف أداء مختلفة، نماذج تطوير وفلسفات معمارية، حيث تتناقص تدريجيًا حجم التوازي، وتزداد شدة التوازي، وتزداد أيضًا تعقيد الجدولة، وتعقيد البرمجة وصعوبة التنفيذ.

  • التوازي على مستوى الحساب (Account-level): يمثل مشروع سولانا
  • التوازي على مستوى الكائن (Object-level): يمثل مشروع Sui
  • المعالجة المتوازية على مستوى المعاملات (Transaction-level): تمثل المشروع Monad، Aptos
  • مستوى الاستدعاء / ميكرو VM المتوازي (Call-level / MicroVM): يمثل مشروع ميغا ETH
  • التوازي على مستوى التعليمات (Instruction-level): يمثل مشروع GatlingX

نموذج التزامن غير المتزامن خارج السلسلة، ممثلاً بنظام الكائنات الذكية (نموذج الوكيل / الكائن)، وهو ينتمي إلى نوع آخر من نماذج الحوسبة المتوازية، كنظام رسائل عبر السلاسل / غير متزامن (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل كـ "عملية كائن ذكية" تعمل بشكل مستقل، مع رسائل غير متزامنة بأسلوب متوازي، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن المشاريع الممثلة AO و ICP و Cartesi وغيرها.

وخطط توسيع النطاق المعروفة لدينا مثل Rollup أو التجزئة، تنتمي إلى آلية التوازي على مستوى النظام، ولا تتعلق بالحساب المتوازي داخل السلسلة. إنهم يحققون التوسع من خلال "تشغيل سلاسل متعددة / مجالات تنفيذ بالتوازي"، بدلاً من زيادة مستوى التوازي داخل كتلة واحدة / آلة افتراضية. هذه الأنواع من خطط التوسع ليست محور الحديث في هذه المقالة، لكننا سنستخدمها لمقارنة الاختلافات في مفاهيم الهيكل.

Web3 مساحة المنافسة للتوازي: أفضل حل للتوسع الأصلي؟

ثانياً، سلسلة تعزيز التوازي EVM: كسر حدود الأداء في التوافق

تطورت بنية المعالجة المتسلسلة للإيثريوم حتى الآن، حيث مرت بعدة محاولات توسعة مثل التجزئة، والتجميع، والهندسة المعمارية المعيارية، ولكن لا يزال هناك عنق زجاجة في قدرة التنفيذ. ومع ذلك، لا يزال EVM وSolidity هما المنصتان الأكثر قوة من حيث قاعدة المطورين وإمكانات النظام البيئي. لذلك، فإن سلسلة EVM المعززة بالمعالجة المتوازية، التي تأخذ في الاعتبار التوافق البيئي وتحسين أداء التنفيذ، أصبحت الاتجاه الرئيسي في التطور الجديد للتوسع. يعتبر مشروع Monad وMegaETH من أكثر المشاريع تمثيلاً في هذا الاتجاه، حيث يعمل كل منهما على بناء بنية معالجة متوازية لـ EVM تستهدف سيناريوهات ذات تزامن عالٍ وقدرة معالجة عالية، من خلال تنفيذ متأخر وتفكيك الحالة.

تحليل آلية الحساب المتوازي لـ Monad

Monad هي سلسلة كتل Layer1 عالية الأداء تم إعادة تصميمها لآلة Ethereum الافتراضية (EVM) ، استنادًا إلى مفهوم المعالجة المتوازية الأساسية المعروف باسم المعالجة المتسلسلة (Pipelining) ، حيث يتم تنفيذ توافق الطبقة بشكل غير متزامن (Asynchronous Execution) ، وفي طبقة التنفيذ يتم تنفيذ التوازي المتفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك ، في طبقتي التوافق والتخزين ، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) ، مما يحقق تحسيناً شاملاً من البداية إلى النهاية.

التسلسل: آلية التنفيذ المتوازية متعددة المراحل

تعتبر Pipelining الفكرة الأساسية لتنفيذ Monad بالتوازي، حيث تكمن الفكرة الأساسية في تقسيم عملية تنفيذ سلسلة الكتل إلى عدة مراحل مستقلة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل هيكلًا ثلاثي الأبعاد لخط الأنابيب، تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متزامنة عبر الكتل، وفي النهاية يحقق زيادة في معدل النقل وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) ، التوصل إلى توافق (Consensus) ، تنفيذ المعاملات (Execution) وتقديم الكتلة (Commit).

التنفيذ غير المتزامن: الإجماع - تنفيذ فصل غير متزامن

في السلسلة التقليدية، فإن توافق المعاملات وتنفيذها عادة ما يكون عملية متزامنة، وهذا النموذج المتسلسل يحد بشدة من توسيع الأداء. قامت Monad بتحقيق توافق层 غير متزامن، وتنفيذ层 غير متزامن، وتخزين غير متزامن من خلال "التنفيذ غير المتزامن". مما يقلل بشكل ملحوظ من وقت الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، ويقسم عملية المعالجة بشكل أكبر، ويزيد من كفاءة استخدام الموارد.

التصميم الأساسي:

  • عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقد.
  • عملية التنفيذ (طبقة التنفيذ) يتم ت triggering بشكل غير متزامن بعد اكتمال الإجماع.
  • بعد الانتهاء من التوافق، سيتم الدخول على الفور إلى عملية توافق الكتلة التالية دون الحاجة إلى انتظار انتهاء التنفيذ.

تنفيذ متوازي متفائل: تنفيذ متوازي متفائل

تستخدم الإيثيريوم التقليدية نموذج تنفيذ صارم تسلسلي لتجنب تعارض الحالة. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يعزز بشكل كبير من معدل معالجة المعاملات.

آلية التنفيذ:

  • Monad ستقوم بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، على افتراض أن معظم المعاملات لا تحتوي على تضارب في الحالة.
  • تشغيل "كاشف التعارضات (Conflict Detector)" لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة (مثل تعارضات القراءة / الكتابة).
  • إذا تم الكشف عن تعارض، سيتم تنفيذ المعاملات المتعارضة بشكل متسلسل لضمان صحة الحالة.

اختارت Monad مسارًا متوافقًا: تقليل التغييرات على قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة واكتشاف التعارضات ديناميكيًا لتحقيق التوازي، مما يجعلها أشبه بإيثريوم النسخة عالية الأداء، مما يسهل نقل النظام البيئي لـ EVM بفضل نضجها، وهي مسرع التوازي لعالم EVM.

خريطة منظر كامل لمجال الحوسبة المتوازية Web3: هل هي الحل الأفضل للتوسع الأصلي؟

تحليل آلية الحوسبة المتوازية لـ MegaETH

بخلاف تحديد L1 الخاص بـ Monad، تم تحديد MegaETH كطبقة تنفيذ عالية الأداء وقابلة للتعديل ومتوافقة مع EVM، يمكن أن تعمل كشبكة L1 مستقلة أو كطبقة تعزيز تنفيذ (Execution Layer) أو مكون تعديل على Ethereum. الهدف الرئيسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات أصغر يمكن جدولة كل منها بشكل مستقل، لتحقيق تنفيذ عالي التزامن واستجابة منخفضة التأخير داخل السلسلة. الابتكار الرئيسي الذي تقدمه MegaETH هو: هيكل Micro-VM + DAG (رسم بياني للدالة المعتمدة على الحالة) وآلية التزامن القابلة للتعديل، والتي تشكل معًا نظام تنفيذ متوازي موجه نحو "تعدد الخيوط داخل السلسلة".

بنية Micro-VM (الآلة الافتراضية الصغيرة): الحساب هو الخيط

تقدم MegaETH نموذج تنفيذ "مايكرو-آلة افتراضية (Micro-VM) لكل حساب"، مما يجعل بيئة التنفيذ "متعددة الخيوط"، ويقدم وحدة العزل الدنيا للتخطيط المتوازي. تتواصل هذه الآلات الافتراضية (VM) مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous Messaging) بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ بشكل مستقل وتخزين مستقل، مما يحقق التوازي بشكل طبيعي.

مخطط الاعتماد للدولة: آلية الجدولة المدفوعة بالرسم البياني للاعتماد

بنت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يحافظ النظام في الوقت الحقيقي على رسم بياني عالمي للاعتماد (Dependency Graph). كل معاملة تقوم بتعديل أي حسابات أو قراءة أي حسابات يتم نمذجتها جميعًا كعلاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي، في حين سيتم جدولة المعاملات التي لها علاقات اعتماد بالتسلسل أو التأخير وفقًا لترتيب Topological. يضمن رسم الاعتماد اتساق الحالة وعدم الكتابة المتكررة أثناء عملية التنفيذ المتوازي.

التنفيذ غير المتزامن وآلية الاستدعاء

تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.

بشكل عام، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدي لـ EVM، حيث يحقق تغليف الميكرو VM على مستوى الحسابات، وينظم المعاملات من خلال رسم الاعتماد على الحالة، ويستبدل آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنها منصة حساب متوازٍ تم إعادة تصميمها من "هيكل الحساب → هيكل الجدولة → عملية التنفيذ" على جميع الأبعاد، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة عالية الأداء من الجيل التالي على السلسلة.

اختارت MegaETH مسار إعادة البناء: من خلال تجريد الحسابات والعقود إلى VM مستقل، وتحرير أقصى إمكانيات التوازي من خلال جدولة التنفيذ غير المتزامن. نظريًا، الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ويشبه إلى حد كبير نظام التشغيل الموزع الفائق تحت فكرة Ethereum.

خريطة شاملة لمجال الحوسبة المتوازية في Web3: ما هي أفضل الحلول للتوسع الأصلي؟

Monad و MegaETH كلاهما لديهما مفاهيم تصميم تختلف بشكل كبير عن التقسيم (Sharding): حيث يقوم التقسيم بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة (شاردز Shards)، كل سلسلة فرعية مسؤولة عن جزء من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة في توسيع الطبقة الشبكية؛ بينما يحتفظ كل من Monad و MegaETH بسلامة السلسلة الفردية، حيث يتم التوسع أفقيًا فقط في طبقة التنفيذ، مما يحقق تحسينات في الأداء من خلال التنفيذ المتوازي في حدود السلسلة الفردية. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: تعزيز عمودي وتوسع أفقي.

تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH أساسًا على تحسين مسارات الإنتاجية، مع هدف رئيسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وهندسة ميكرو-آلة افتراضية (Micro-VM) لتحقيق المعالجة المتوازية على مستوى المعاملات أو الحسابات. بينما تُعتبر شبكة Pharos شبكة بلوكشين L1 معيارية وشاملة، تُعرف آلية الحوسبة المتوازية الأساسية فيها باسم "Rollup Mesh". تدعم هذه الهندسة العمل المتناغم بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتوفر بيئات متعددة للآلة الافتراضية (EVM و Wasm)، وتدمج تقنيات متقدمة مثل الإثباتات ذات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEE).

تحليل آلية الحساب المتوازي للشبكة المجمعة:

  1. معالجة الأنابيب غير المتزامنة طوال دورة الحياة (Full Lifecycle Asynchronous Pipelining): تقوم Pharos بفصل مراحل المعاملة المختلفة (مثل الإجماع، التنفيذ، التخزين) وتستخدم طريقة المعالجة غير المتزامنة، مما يسمح لكل مرحلة بالعمل بشكل مستقل ومتوازٍ، وبالتالي زيادة كفاءة المعالجة الإجمالية.
  2. تنفيذ مزدوج للآلة الافتراضية بالتوازي (Dual VM Parallel Execution): تدعم Pharos بيئتين للآلة الافتراضية هما EVM و WASM، مما يسمح للمطورين باختيار البيئة التنفيذية المناسبة بناءً على احتياجاتهم. لا تعزز هذه البنية المزدوجة للآلة الافتراضية مرونة النظام فحسب، بل تزيد أيضًا من قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
  3. الشبكات ذات المعالجة الخاصة (SPNs): SPNs هي مكونات رئيسية في هيكل فهارس، تشبه الشبكات الفرعية المعيارية، وتستخدم خصيصًا لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لفهارس تحقيق توزيع ديناميكي للموارد ومعالجة المهام بالتوازي، مما يعزز أكثر من ذلك قابلية توسيع النظام وأدائه.
  4. الإجماع القابل للتعديل وآلية إعادة الرهن (Modular Consensus & Restaking): قدمت Pharos آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT و PoS و PoA) و من خلال إعادة
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 9
  • مشاركة
تعليق
0/400
SandwichTradervip
· 07-20 16:09
البلوكتشين؟ أليس لا يزال لا يعمل؟
شاهد النسخة الأصليةرد0
WagmiWarriorvip
· 07-20 15:22
مرة أخرى أبحث في توسيع السعة hh
شاهد النسخة الأصليةرد0
MeaninglessApevip
· 07-20 06:35
لا فائدة من الكلام الكثير، من الأفضل أن تقوم بتثبيت وتجربة بنفسك.
شاهد النسخة الأصليةرد0
SchrodingerPrivateKeyvip
· 07-17 17:31
مرة أخرى تم تنظيم مجموعة من خطط التوسع المعقدة.
شاهد النسخة الأصليةرد0
StealthMoonvip
· 07-17 17:26
تتداول جميع الخطط لكن لا يمكن التغلب على المتلاعب بالسوق
شاهد النسخة الأصليةرد0
InscriptionGrillervip
· 07-17 17:22
هذه المجموعة من فريق المشروع تتحدث طوال اليوم عن التوسع، إنها مجرد خداع الحمقى، لقد رأينا الكثير! مهما كان التوسع، لماذا لا نرى أي تطبيق فعلي؟
شاهد النسخة الأصليةرد0
MetaverseLandlordvip
· 07-17 17:21
آه؟ هل هذه المقالة مخصصة للاحترافي؟
شاهد النسخة الأصليةرد0
BridgeJumpervip
· 07-17 17:11
تاي كو لا هو حقًا أداة للنجاح في السوق
شاهد النسخة الأصليةرد0
GasFeeCrybabyvip
· 07-17 17:02
لا يزال L2 جيداً، رسوم الغاز رخيصة
شاهد النسخة الأصليةرد0
عرض المزيد
  • تثبيت