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

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

1. نظرة عامة على مسار تقنية الحوسبة المتوازية

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

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

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

الحوسبة المتوازية داخل السلسلة (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: كسر حدود الأداء في التوافق

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

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

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

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

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

الاعتماد على 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).

تحليل آلية الحساب المتوازي 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،
شاهد النسخة الأصلية
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • أعجبني
  • 4
  • مشاركة
تعليق
0/400
SilentObservervip
· 07-12 04:33
مرة أخرى تم توسيع السعة
شاهد النسخة الأصليةرد0
SquidTeachervip
· 07-09 10:53
مثلث لا يمكنه الاقتراب بأي شكل، آه
شاهد النسخة الأصليةرد0
consensus_whisperervip
· 07-09 10:35
نظرية فخ فخ التطبيق؟
شاهد النسخة الأصليةرد0
GasFeeSobbervip
· 07-09 10:27
توسيع السعة إلى حد الدوار يعني أن الكتل لم تصبح أرخص بعد.
شاهد النسخة الأصليةرد0
  • تثبيت