نظرة شاملة على الحوسبة المتوازية في Web3: من التوافق مع EVM إلى اختراق الأداء في Rollup Mesh

نظرة شاملة على مسار الحوسبة المتوازية في Web3: ما هي أفضل حلول التوسع الأصلية؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اعتماد الحالة DAG: آلية جدولة مدفوعة برسم الاعتماد

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

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

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

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

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

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

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

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

تحليل آلية الحساب المتوازية لشبكة Rollup Mesh:

  1. معالجة خط الأنابيب غير المتزامن على مدار دورة الحياة بالكامل (Full Lifecycle Asynchronous Pipelining): تفكك Pharos المراحل المختلفة للمعاملات (مثل التوافق، التنفيذ، التخزين) وتستخدم طريقة معالجة غير متزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل ومتوازي، وبالتالي تحسين كفاءة المعالجة الإجمالية.
  2. تنفيذ متوازي مزدوج للآلة الافتراضية (Dual VM Parallel Execution): تدعم Pharos بيئتين للآلة الافتراضية EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة حسب الحاجة. لا تعمل هذه البنية المزدوجة للآلة الافتراضية على تحسين مرونة النظام فحسب، بل تعزز أيضًا قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
  3. الشبكات المعالجة الخاصة (SPNs): تعتبر SPNs مكونًا رئيسيًا في بنية Pharos، مشابهة للشبكات الفرعية المعيارية، ومخصصة لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص الموارد الديناميكي ومعالجة المهام بشكل متوازي، مما يعزز المزيد من قابلية توسيع النظام وأدائه.
  4. الإجماع القابل للتطوير وآلية إعادة الرهن (Modular Consensus & Restaking): قدمت Pharos آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT و PoS و PoA) وتحقق الشبكة الرئيسية مع SPNs من خلال بروتوكول إعادة الرهن (Restaking).
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 4
  • مشاركة
تعليق
0/400
ShadowStakervip
· منذ 18 س
مه... منشور آخر عن الثلاثية. متى سيدرك الناس أن التنفيذ المتوازي ليس الحل السحري لسرعة المعاملات؟
شاهد النسخة الأصليةرد0
NftPhilanthropistvip
· منذ 18 س
يوم آخر أشرح لماذا المعالجة المتوازية لن تحل القضايا الأساسية للويب 3 بصراحة...
شاهد النسخة الأصليةرد0
AirdropBlackHolevip
· منذ 18 س
من الواضح أنه مشروع يُستغل بغباء.
شاهد النسخة الأصليةرد0
MetaverseLandladyvip
· منذ 18 س
مبتدئ来问下 哪种比较靠谱?
شاهد النسخة الأصليةرد0
  • تثبيت