بانوراما سباق الحوسبة المتوازية في Web3: طريق التوسع من مستوى الحساب إلى مستوى التعليمات

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

1. الموضوع الدائم لتوسيع نطاق البلوكشين

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

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

تشمل حلول توسيع نطاق blockchain: الحساب المتوازي داخل السلسلة، 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 عالية الأداء مصممة من جديد لجهاز افتراضي إيثريوم (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 مسار حسابات متوازية: أفضل حل للتوسع الأصلي؟

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

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

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

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

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

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

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

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

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

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

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

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

تركز مشاريع الحوسبة المتوازية مثل 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) وتتيح إعادة الرهن.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 6
  • مشاركة
تعليق
0/400
MrRightClickvip
· 07-24 23:24
التوسع هو حفرة بلا قاع
شاهد النسخة الأصليةرد0
CrossChainBreathervip
· 07-24 23:24
تم مناقشة خطة التوسع مرة أخرى~
شاهد النسخة الأصليةرد0
GmGmNoGnvip
· 07-24 23:19
هل تعود GPU لتنافس في web3؟
شاهد النسخة الأصليةرد0
NotGonnaMakeItvip
· 07-24 23:19
أه ، مهما قلت بشكل جيد ، لن يتمكن من التوسع.
شاهد النسخة الأصليةرد0
DecentralizeMevip
· 07-24 23:10
يا إلهي، هل يقوم البلوكتشين بلعب الأكوان المتوازية مرة أخرى؟
شاهد النسخة الأصليةرد0
GateUser-1a2ed0b9vip
· 07-24 23:04
هل جاءت زيادة السعة ولكن لم تزد السرعة؟
شاهد النسخة الأصليةرد0
  • تثبيت