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

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

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

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

تشمل حلول توسيع نطاق 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: ما هو أفضل حل للتوسع الأصلي؟

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

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

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

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

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

التسلسل الهرمي هو الفكرة الأساسية لتنفيذ Monad بالتوازي، حيث تتمثل الفكرة الأساسية في تقسيم عملية التنفيذ على blockchain إلى عدة مراحل مستقلة، ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خطوط أنابيب ثلاثية الأبعاد، حيث تعمل كل مرحلة على خيوط أو نوى مستقلة، لتحقيق معالجة متزامنة عبر الكتل، مما يؤدي في النهاية إلى تحسين معدل الإنتاجية وتقليل التأخير. تشمل هذه المراحل: اقتراح المعاملات (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 نموذج تنفيذ "آلة افتراضية صغيرة لكل حساب (Micro-VM)"، مما أدى إلى "تجميع" بيئة التنفيذ، لتوفير أقل وحدة عزل ممكنة لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.

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

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

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

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

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

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

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

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

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

تتركز مشاريع الحساب المتوازي مثل Monad و MegaETH بشكل رئيسي على مسار تحسين الإنتاجية، حيث يعد تحسين TPS داخل السلسلة هو الهدف الأساسي، ويتم تحقيق المعالجة المتوازية على مستوى الصفقة أو الحساب من خلال التنفيذ المؤجل (Deferred Execution) وعمارة micro-VM. بينما تعتبر شبكة Pharos Network شبكة بلوكتشين من الطبقة الأولى (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. إجماع معياري و
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 5
  • إعادة النشر
  • مشاركة
تعليق
0/400
MetaMuskRatvip
· 08-13 13:56
السرعة والأمان يمكن اختيار واحد فقط، لن ألعب بعد الآن، وداعًا
شاهد النسخة الأصليةرد0
LightningClickervip
· 08-10 15:07
هل لا زلت تلعب بأربعة خيارات؟ سألت فقط، ما هو tps؟
شاهد النسخة الأصليةرد0
FUD_Whisperervip
· 08-10 15:03
扩啥容啊 基本ا مرة أخرى تم خداع مجموعة من الحمقى
شاهد النسخة الأصليةرد0
EntryPositionAnalystvip
· 08-10 14:57
مشاركة也搞不定这问题
شاهد النسخة الأصليةرد0
GraphGuruvip
· 08-10 14:50
الرفع في المكان هو الصحيح، لماذا التسرع في مشاركة الشبكات؟
شاهد النسخة الأصليةرد0
  • تثبيت