نظرة شاملة على الحوسبة المتوازية في Web3: تحليل خمسة مجالات وابتكارات سلاسل متوافقة مع EVM

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

١. المقدمة: "مثلث المستحيل" في البلوكشين وحلول التوسع

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

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

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

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

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

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

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

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

2. سلسلة تعزيز التوازي EVM: كسر حدود الأداء في التوافق

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

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

Monad هو سلسلة بلوكشين عالية الأداء من Layer1 تم إعادة تصميمها لآلة Ethereum الافتراضية (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))" لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة (مثل النزاعات في القراءة/الكتابة).
  • إذا تم الكشف عن تعارض، فسيتم تسلسل وإعادة تنفيذ المعاملات المتعارضة لضمان صحة الحالة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تتركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل رئيسي على مسارات تحسين الإنتاجية، بهدف رئيسي هو تعزيز TPS داخل السلسلة، من خلال التنفيذ المؤجل (Deferred Execution) وهيكل الميكرو-آلة الافتراضية (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)، وتحقق من خلال بروتوكول إعادة الرهن (Restaking) المشاركة الآمنة والتكامل بين الشبكة الرئيسية وSPNs.

علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من قاعدة محرك التخزين من خلال تقنيات مثل شجرة ميركل متعددة الإصدارات، والترميز التفاضلي، والعنوانة المعتمدة على الإصدارات، ودفع ADS، مما أدى إلى إطلاق محرك التخزين عالي الأداء Pharos Store، الذي يحقق نسبة نقل عالية وزمن تأخير منخفض.

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 5
  • إعادة النشر
  • مشاركة
تعليق
0/400
CryptoMomvip
· منذ 13 س
那还是 مشاركة靠谱些
شاهد النسخة الأصليةرد0
ApeShotFirstvip
· منذ 17 س
لا يمكن الحصول على الأمان والسرعة معًا
شاهد النسخة الأصليةرد0
RugpullTherapistvip
· منذ 17 س
هل يمكن أن يعزز التنفيذ حقًا؟
شاهد النسخة الأصليةرد0
MidnightTradervip
· منذ 17 س
الكفاءة ليست بأهمية الأمان
شاهد النسخة الأصليةرد0
MaticHoleFillervip
· منذ 18 س
تبدو مشاركة البطاقات موثوقة
شاهد النسخة الأصليةرد0
  • تثبيت