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

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

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

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

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

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

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

  • التوازي على مستوى الحساب (Account-level): يمثل المشروع Solana
  • التوازي على مستوى الكائن (Object-level): يمثل مشروع Sui
  • مستوى المعاملات (Transaction-level): يمثل المشروع Monad، Aptos
  • مستوى الاستدعاء / MicroVM المتوازي (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 الفكرة الأساسية لتنفيذ Monad بشكل متوازي، حيث تكمن الفكرة الرئيسية في تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خط أنابيب ثلاثية الأبعاد، تعمل كل مرحلة على خيوط أو نوى مستقلة، لتحقيق معالجة متزامنة عبر الكتل، مما يؤدي في النهاية إلى زيادة الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) وبنية ميكرو افتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تعتبر شبكة Pharos Network بمثابة شبكة بلوكشين L1 متوازية بالكامل وقابلة للتعديل، يُعرف آلية الحوسبة المتوازية الأساسية بها باسم "Rollup Mesh". تدعم هذه البنية العمل المتزامن بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة من الآلات الافتراضية (EVM و Wasm)، وقد دمجت تقنيات متقدمة مثل إثبات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEE).

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

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

  1. معالجة الأنابيب غير المتزامنة على مدار دورة الحياة الكاملة (Full Lifecycle Asynchronous Pipelining): تقوم Pharos بفصل مراحل الصفقة المختلفة (مثل الإجماع، التنفيذ، التخزين) وتستخدم طريقة المعالجة غير المتزامنة، مما يسمح لكل مرحلة بالعمل بشكل مستقل ومتوازي، وبالتالي زيادة كفاءة المعالجة العامة.
  2. التنفيذ المتوازي لآلتين افتراضيتين (Dual VM Parallel Execution): يدعم Pharos بيئتين افتراضيتين EVM و WASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة وفقًا لاحتياجاتهم. لا تعزز هذه البنية المزدوجة من مرونة النظام فحسب، بل تعزز أيضًا من قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
  3. الشبكات الخاصة (SPNs): تعتبر SPNs مكونًا أساسيًا في هيكل Pharos، مشابهةً لشبكات فرعية modular، مخصصة لمعالجة أنواع محددة من المهام أو التطبيقات. من خلال SPN
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 4
  • مشاركة
تعليق
0/400
TokenCreatorOPvip
· منذ 12 س
مشكلة التحجيم得重视
شاهد النسخة الأصليةرد0
ImpermanentTherapistvip
· منذ 12 س
أفضل آفاق للـ Rollup
شاهد النسخة الأصليةرد0
HashBrowniesvip
· منذ 12 س
الحل الأمثل Layer2
شاهد النسخة الأصليةرد0
LightningSentryvip
· منذ 12 س
لا يمكن تحمل زيادة السعة ببطء شديد
شاهد النسخة الأصليةرد0
  • تثبيت