خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟
أولاً، المقدمة: تطور تقنية الحوسبة المتوازية في البلوك تشين
"مثلث عدم الإمكانية" في Blockchain (Blockchain Trilemma) "الأمان" و"اللامركزية" و"القابلية للتوسع" يكشف عن التوازن الأساسي في تصميم أنظمة blockchain، أي أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة عالمية، ومعالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "القابلية للتوسع"، هناك حلول توسيع blockchain السائدة في السوق التي تتميز وفقًا للأنماط، بما في ذلك:
تنفيذ التوسع المعزز: تحسين القدرة التنفيذية في مكانها، مثل المعالجة المتوازية، GPU، والأنوية المتعددة
نوع التوسع المعزول عن الحالة: تقسيم أفقي للحالة / شظايا، مثل التجزئة، UTXO، متعددة الشبكات الفرعية
توسيع نوع الاستعانة بمصادر خارجية خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل Rollup، Coprocessor، DA
توسيع هيكلية مفككة: هيكلية وحدات، تشغيل متعاون، مثل سلسلة الوحدات، مرتبة مشتركة، شبكة Rollup
التوسع المتزامن غير المتزامن: نموذج الممثل، عزل العمليات، مدفوع بالرسائل، مثل الوكلاء، سلسلة غير متزامنة متعددة الخيوط
تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، التقسيم، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط zk، والهندسة المعمارية Stateless، مما يغطي عدة مستويات من التنفيذ، الحالة، البيانات، والبنية. إنها نظام توسيع كامل "تعاون متعدد الطبقات، وتركيبات معيارية". وتركز هذه المقالة على طريقة التوسع الرئيسية التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة ( intra-chain parallelism )، تركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، كل فئة تمثل طموحات أداء مختلفة، ونماذج تطوير وفلسفات معمارية، مع تزايد دقة التوازي تدريجياً، وزيادة قوة التوازي، وزيادة تعقيد الجدولة، وزيادة تعقيد البرمجة وصعوبة التنفيذ.
المستوى الحسابي المتوازي (Account-level): يمثل مشروع سولانا
التوازي على مستوى الكائن (Object-level): يمثل مشروع Sui
مستوى المعاملة (Transaction-level): يمثل المشروع Monad، Aptos
مستوى الاتصال/الميكرو VM المتوازي (Call-level/MicroVM): يمثل مشروع MegaETH
التوازي على مستوى التعليمات (Instruction-level): يمثل المشروع GatlingX
نموذج التوازي غير المتزامن خارج السلسلة، تمثله أنظمة الوكلاء (نموذج الوكيل/الفاعل)، والتي تنتمي إلى نمط حسابي متوازي آخر، كنظام رسائل غير متزامن عبر السلاسل (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل ك"عملية وكيل مستقلة"، ويستخدم طريقة غير متزامنة للرسائل المدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، والمشاريع الممثلة تشمل AO و ICP و Cartesi وغيرها.
إن الحلول المعروفة لنا مثل Rollup أو حلول توسيع الشقوق تُعتبر آليات تزامن على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، وليس من خلال زيادة التوازي داخل كتلة/آلة افتراضية واحدة. لا تُعتبر هذه الحلول التوسعية محور النقاش في هذه المقالة، لكننا سنستخدمها مع ذلك لمقارنة الاختلافات في المفاهيم المعمارية.
٢. سلسلة تعزيز التوازي المعتمد على 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) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، واستخدام الموارد أعلى.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقود.
عملية التنفيذ (طبقة التنفيذ) يتم تفعيلها بشكل غير متزامن بعد اكتمال الإجماع.
بعد الانتهاء من التوافق، يتم الدخول مباشرة في عملية توافق الكتلة التالية دون الحاجة إلى انتظار إتمام التنفيذ.
تنفيذ متوازي متفائل: التنفيذ المتوازي المتفائل
تستخدم Ethereum التقليدية نموذج تسلسلي صارم في تنفيذ المعاملات لتجنب تضارب الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
سيقوم Monad بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، مع افتراض أن معظم المعاملات لا تتعارض في الحالة.
تشغيل "كاشف النزاعات (Conflict Detector))" في نفس الوقت لمراقبة ما إذا كانت المعاملات قد وصلت إلى نفس الحالة (مثل النزاعات في القراءة/الكتابة).
إذا تم الكشف عن تعارض، فسيتم تسلسل إعادة تنفيذ المعاملات المتعارضة لضمان صحة الحالة.
اختارت Monad مساراً متوافقاً: تقليل تغيير قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات، مما يجعلها تشبه نسخة الأداء من Ethereum، حيث أن نضجها يسهل نقل نظام EVM البيئي، وهي معجل التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 لـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومتوازية وقابلة للتوافق مع EVM، يمكن أن تعمل كشبكة عامة مستقلة L1 أو كطبقة تعزيز تنفيذ على Ethereum أو كمكون مدمج. الهدف الأساسي من تصميمها هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة قابلة للتخطيط المستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة سريعة ذات تأخير منخفض. الابتكار الرئيسي الذي قدمه MegaETH هو: بنية Micro-VM + DAG (مخطط الاعتماد على الحالة الموجه غير الدوري) وآلية التزامن المعيارية، مما يبني نظام تنفيذ متوازي موجه نحو "تسلسل داخل السلسلة".
بنية Micro-VM (مايكرو-آلة افتراضية): الحساب هو الخيط
تقدم MegaETH نموذج تنفيذ "مايكرو-آلة افتراضية واحدة لكل حساب (Micro-VM)"، مما يجعل بيئة التنفيذ "مُعَدَّلَة"، لتوفير وحدة عزل الحد الأدنى لجدولة متوازية. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل، والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
اعتماد الحالة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنت MegaETH نظام جدولة DAG قائم على علاقات الوصول إلى حالة الحسابات، حيث يقوم النظام بالحفاظ على رسم بياني اعتمادي عالمي (Dependency Graph) في الوقت الحقيقي، حيث يتم نمذجة جميع التعديلات على الحسابات التي تقوم بها كل صفقة، بالإضافة إلى الحسابات التي يتم قراءتها، كعلاقات اعتمادية. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي مباشرة، بينما سيتم جدولة وترتيب المعاملات التي لها علاقات اعتمادية تسلسليًا أو تأخيريًا حسب الترتيب الطوبولوجي. يضمن رسم الاعتماد التناسق الحالة وعدم الكتابة المتكررة خلال عملية التنفيذ المتوازي.
تنفيذ غير متزامن وآلية رد الاتصال
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدية لـ EVM، حيث يحقق تغليف الميكرو VM على مستوى الحسابات، من خلال جدول معاملات اعتماد الحالة، ويستبدل آلية الرسائل غير المتزامنة بدالة الاستدعاء المتزامنة. إنها منصة حوسبة متوازية تم إعادة تصميمها عبر الأبعاد الكاملة من "هيكل الحساب → هيكل الجدولة → سير التنفيذ"، مما يوفر أفكارًا نموذجية جديدة لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: تحويل الحسابات والعقود إلى VM مستقل بشكل كامل، من خلال جدولة التنفيذ غير المتزامن لتحرير أقصى إمكانيات التوازي. من الناحية النظرية، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ليشبه أكثر نظام التشغيل الموزع الفائق تحت فكرة الإيثيريوم.
تختلف فلسفة تصميم كل من Monad و MegaETH عن التجزئة (Sharding) بشكل كبير: تقوم التجزئة بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة (التجزئة Shards) ، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة على مستوى الشبكة؛ في حين أن Monad و MegaETH يحافظان على سلامة السلسلة الواحدة، ويتوسعان أفقيًا فقط في مستوى التنفيذ، مما يحقق تحسينات في الأداء من خلال التنفيذ المتوازي القصوى داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز الرأسي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على تحسين مسار الإنتاجية، بهدف رئيسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وعمارة الميكرو آلة الافتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تُعتبر شبكة Pharos شبكة لبلوكشين L1 متوازية كاملة المكدس وموحدة، يُطلق على آلية الحوسبة المتوازية الأساسية فيها اسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة للآلة الافتراضية (EVM و Wasm)، كما تدمج تقنيات متقدمة مثل الإثباتات الصفرية (ZK) وبيئة التنفيذ الموثوق بها (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh:
معالجة الأنابيب غير المتزامنة على مدار دورة الحياة الكاملة (Full Lifecycle Asynchronous Pipelining): تقوم Pharos بفصل مراحل المعاملة المختلفة (مثل الإجماع، التنفيذ، التخزين) وتستخدم طريقة المعالجة غير المتزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل ومتوازي، وبالتالي زيادة كفاءة المعالجة الكلية.
تنفيذ متوازي مزدوج للآلة الافتراضية (Dual VM Parallel Execution): تدعم Pharos بيئتين للآلة الافتراضية EVM وWASM، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة وفقًا لاحتياجاتهم. لا تعزز هذه البنية المزدوجة للآلة الافتراضية مرونة النظام فحسب، بل تزيد أيضًا من قدرة معالجة المعاملات من خلال التنفيذ المتوازي.
الشبكات المعالجة الخاصة (SPNs): تعتبر SPNs مكونًا رئيسيًا في بنية Pharos، تشبه الشبكات الفرعية المودولية، وتستخدم خصيصًا لمعالجة أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص الموارد الديناميكي ومعالجة المهام بالتوازي، مما يعزز بشكل أكبر قابلية توسعة النظام وأدائه.
إجماع معياري وآلية إعادة الرهان (Modular Consensus & Restaking): قدمت Pharos آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT، PoS، PoA)، ومن خلال بروتوكول إعادة الرهان (Restaking) تحقق المشاركة الآمنة والمشاركة في الموارد بين الشبكة الرئيسية وSPNs.
علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من أسفل محرك التخزين من خلال تقنيات شجرة Merkle متعددة النسخ، والترميز التفاضلي (Delta Encoding)، والعنوانة المعنونة (Versioned Addressing)، ودفع ADS (ADS Pushdown)، مما أدى إلى إطلاق محرك تخزين عالي الأداء قائم على blockchain يسمى Pharos Store، لتحقيق قدرة عالية على المعالجة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
3
مشاركة
تعليق
0/400
NotGonnaMakeIt
· 07-19 16:28
مرة أخرى، هي نفس المفاهيم الفارغة يُستغل بغباء.
شاهد النسخة الأصليةرد0
token_therapist
· 07-19 16:24
أوه، أليس هذا هو TPS مرة أخرى؟
شاهد النسخة الأصليةرد0
PerpetualLonger
· 07-19 16:14
شراء الانخفاض وزيادة المركزing تبقى نصف زجاجة صلصة الصويا لم تُستخدم هبطت دون تكلفة مئة بالمئة تجديد الهامش لا ننظر إلى القيمة السوقية بل إلى التقنية هذه الموجة ليست من الممكن للمتداولين الهابطين ومستثمر التجزئة التعامل معها
نظرة شاملة على حلبة الحوسبة المتوازية Web3: الابتكارات المعمارية لـ Monad و MegaETH و Pharos
خريطة شاملة لمجال الحوسبة المتوازية في Web3: أفضل حل للتوسع الأصلي؟
أولاً، المقدمة: تطور تقنية الحوسبة المتوازية في البلوك تشين
"مثلث عدم الإمكانية" في Blockchain (Blockchain Trilemma) "الأمان" و"اللامركزية" و"القابلية للتوسع" يكشف عن التوازن الأساسي في تصميم أنظمة blockchain، أي أنه من الصعب على مشاريع blockchain تحقيق "أقصى أمان، مشاركة عالمية، ومعالجة سريعة" في الوقت نفسه. بالنسبة لموضوع "القابلية للتوسع"، هناك حلول توسيع blockchain السائدة في السوق التي تتميز وفقًا للأنماط، بما في ذلك:
تشمل حلول توسيع blockchain: الحساب المتوازي داخل السلسلة، Rollup، التقسيم، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط zk، والهندسة المعمارية Stateless، مما يغطي عدة مستويات من التنفيذ، الحالة، البيانات، والبنية. إنها نظام توسيع كامل "تعاون متعدد الطبقات، وتركيبات معيارية". وتركز هذه المقالة على طريقة التوسع الرئيسية التي تعتمد على الحساب المتوازي.
الحوسبة المتوازية داخل السلسلة ( intra-chain parallelism )، تركز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، كل فئة تمثل طموحات أداء مختلفة، ونماذج تطوير وفلسفات معمارية، مع تزايد دقة التوازي تدريجياً، وزيادة قوة التوازي، وزيادة تعقيد الجدولة، وزيادة تعقيد البرمجة وصعوبة التنفيذ.
نموذج التوازي غير المتزامن خارج السلسلة، تمثله أنظمة الوكلاء (نموذج الوكيل/الفاعل)، والتي تنتمي إلى نمط حسابي متوازي آخر، كنظام رسائل غير متزامن عبر السلاسل (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل ك"عملية وكيل مستقلة"، ويستخدم طريقة غير متزامنة للرسائل المدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، والمشاريع الممثلة تشمل AO و ICP و Cartesi وغيرها.
إن الحلول المعروفة لنا مثل Rollup أو حلول توسيع الشقوق تُعتبر آليات تزامن على مستوى النظام، وليست حسابات متوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، وليس من خلال زيادة التوازي داخل كتلة/آلة افتراضية واحدة. لا تُعتبر هذه الحلول التوسعية محور النقاش في هذه المقالة، لكننا سنستخدمها مع ذلك لمقارنة الاختلافات في المفاهيم المعمارية.
٢. سلسلة تعزيز التوازي المعتمد على 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) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلاً، واستخدام الموارد أعلى.
التصميم الأساسي:
تنفيذ متوازي متفائل: التنفيذ المتوازي المتفائل
تستخدم Ethereum التقليدية نموذج تسلسلي صارم في تنفيذ المعاملات لتجنب تضارب الحالة. بينما تتبنى Monad استراتيجية "التنفيذ المتوازي المتفائل"، مما يزيد بشكل كبير من معدل معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مساراً متوافقاً: تقليل تغيير قواعد EVM قدر الإمكان، وتحقيق التوازي من خلال تأجيل كتابة الحالة، والكشف الديناميكي عن النزاعات، مما يجعلها تشبه نسخة الأداء من Ethereum، حيث أن نضجها يسهل نقل نظام EVM البيئي، وهي معجل التوازي في عالم EVM.
تحليل آلية الحساب المتوازي لـ MegaETH
بخلاف تحديد L1 لـ Monad، يتم تحديد MegaETH كطبقة تنفيذ عالية الأداء ومتوازية وقابلة للتوافق مع EVM، يمكن أن تعمل كشبكة عامة مستقلة L1 أو كطبقة تعزيز تنفيذ على Ethereum أو كمكون مدمج. الهدف الأساسي من تصميمها هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة قابلة للتخطيط المستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة واستجابة سريعة ذات تأخير منخفض. الابتكار الرئيسي الذي قدمه MegaETH هو: بنية Micro-VM + DAG (مخطط الاعتماد على الحالة الموجه غير الدوري) وآلية التزامن المعيارية، مما يبني نظام تنفيذ متوازي موجه نحو "تسلسل داخل السلسلة".
بنية Micro-VM (مايكرو-آلة افتراضية): الحساب هو الخيط
تقدم MegaETH نموذج تنفيذ "مايكرو-آلة افتراضية واحدة لكل حساب (Micro-VM)"، مما يجعل بيئة التنفيذ "مُعَدَّلَة"، لتوفير وحدة عزل الحد الأدنى لجدولة متوازية. تتواصل هذه الآلات الافتراضية مع بعضها البعض من خلال الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل، والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
اعتماد الحالة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتماد
بنت MegaETH نظام جدولة DAG قائم على علاقات الوصول إلى حالة الحسابات، حيث يقوم النظام بالحفاظ على رسم بياني اعتمادي عالمي (Dependency Graph) في الوقت الحقيقي، حيث يتم نمذجة جميع التعديلات على الحسابات التي تقوم بها كل صفقة، بالإضافة إلى الحسابات التي يتم قراءتها، كعلاقات اعتمادية. يمكن تنفيذ المعاملات غير المتعارضة بشكل متوازي مباشرة، بينما سيتم جدولة وترتيب المعاملات التي لها علاقات اعتمادية تسلسليًا أو تأخيريًا حسب الترتيب الطوبولوجي. يضمن رسم الاعتماد التناسق الحالة وعدم الكتابة المتكررة خلال عملية التنفيذ المتوازي.
تنفيذ غير متزامن وآلية رد الاتصال
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدية لـ EVM، حيث يحقق تغليف الميكرو VM على مستوى الحسابات، من خلال جدول معاملات اعتماد الحالة، ويستبدل آلية الرسائل غير المتزامنة بدالة الاستدعاء المتزامنة. إنها منصة حوسبة متوازية تم إعادة تصميمها عبر الأبعاد الكاملة من "هيكل الحساب → هيكل الجدولة → سير التنفيذ"، مما يوفر أفكارًا نموذجية جديدة لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت MegaETH مسار إعادة الهيكلة: تحويل الحسابات والعقود إلى VM مستقل بشكل كامل، من خلال جدولة التنفيذ غير المتزامن لتحرير أقصى إمكانيات التوازي. من الناحية النظرية، فإن الحد الأقصى للتوازي في MegaETH أعلى، لكنه أيضًا أكثر صعوبة في التحكم في التعقيد، ليشبه أكثر نظام التشغيل الموزع الفائق تحت فكرة الإيثيريوم.
تختلف فلسفة تصميم كل من Monad و MegaETH عن التجزئة (Sharding) بشكل كبير: تقوم التجزئة بتقسيم سلسلة الكتل إلى عدة سلاسل فرعية مستقلة (التجزئة Shards) ، حيث تتحمل كل سلسلة فرعية جزءًا من المعاملات والحالة، مما يكسر قيود السلسلة الواحدة على مستوى الشبكة؛ في حين أن Monad و MegaETH يحافظان على سلامة السلسلة الواحدة، ويتوسعان أفقيًا فقط في مستوى التنفيذ، مما يحقق تحسينات في الأداء من خلال التنفيذ المتوازي القصوى داخل السلسلة الواحدة. يمثل كلاهما اتجاهين مختلفين في مسار توسيع سلسلة الكتل: التعزيز الرأسي والتوسع الأفقي.
تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على تحسين مسار الإنتاجية، بهدف رئيسي هو تعزيز TPS داخل السلسلة، من خلال تنفيذ مؤجل (Deferred Execution) وعمارة الميكرو آلة الافتراضية (Micro-VM) لتحقيق معالجة متوازية على مستوى المعاملات أو الحسابات. بينما تُعتبر شبكة Pharos شبكة لبلوكشين L1 متوازية كاملة المكدس وموحدة، يُطلق على آلية الحوسبة المتوازية الأساسية فيها اسم "Rollup Mesh". تدعم هذه البنية العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، وتدعم بيئات متعددة للآلة الافتراضية (EVM و Wasm)، كما تدمج تقنيات متقدمة مثل الإثباتات الصفرية (ZK) وبيئة التنفيذ الموثوق بها (TEE).
تحليل آلية الحوسبة المتوازية Rollup Mesh:
علاوة على ذلك، قامت Pharos بإعادة بناء نموذج التنفيذ من أسفل محرك التخزين من خلال تقنيات شجرة Merkle متعددة النسخ، والترميز التفاضلي (Delta Encoding)، والعنوانة المعنونة (Versioned Addressing)، ودفع ADS (ADS Pushdown)، مما أدى إلى إطلاق محرك تخزين عالي الأداء قائم على blockchain يسمى Pharos Store، لتحقيق قدرة عالية على المعالجة.