نظرة عامة على الحوسبة المتوازية في Web3: استكشاف أفضل الحلول لتوسيع البلوكتشين الأصلي
يكشف "مثلث الاستحالة" (الأمان، اللامركزية، القابلية للتوسع) في البلوكتشين عن التوازن الجوهري في تصميم أنظمة البلوكتشين. بالنسبة لموضوع "القابلية للتوسع" الذي لا ينتهي، فإن الحلول الرئيسية لتوسيع البلوكتشين في السوق الحالية تُصنف حسب الأنماط، بما في ذلك:
تنفيذ توسيع معزز: تعزيز القدرة التنفيذية في مكانها، مثل المعالجة المتوازية، 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 أو حلول التوسع عبر التقسيم، تنتمي إلى آلية التوازي على مستوى النظام، ولا تنتمي إلى الحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة مستوى التوازي داخل كتلة واحدة/آلة افتراضية. هذه الأنواع من حلول التوسع ليست محور النقاش في هذه المقالة ولكننا سنستخدمها على أي حال لمقارنة أوجه التشابه والاختلاف في مفاهيم الهيكل.
ثانياً، سلسلة تعزيز التوازي من نوع EVM: كسر حدود الأداء في التوافق
تطور هيكل المعالجة التسلسلية للإيثريوم حتى الآن، ومر بتجارب توسيع متعددة مثل التجزئة، وRollup، والهندسة المعمارية المعيارية، لكن لا يزال عنق الزجاجة في السعة التنفيذية لم يشهد突破ًا جذريًا. ومع ذلك، لا يزال EVM وSolidity هما الأكثر تأثيرًا في قاعدة المطورين وإمكانات النظام البيئي لمنصات العقود الذكية الحالية. لذلك، تعتبر سلسلة تعزيز EVM المتوازية كمسار رئيسي يجمع بين توافق النظام البيئي وتحسين الأداء التنفيذي، وهي تتجه لتكون اتجاهًا مهمًا في التطور الجديد للتوسع. يُعد Monad وMegaETH من المشاريع الأكثر تمثيلًا في هذا الاتجاه، حيث يبنيان هيكل معالجة EVM المتوازي الذي يستهدف المشاهد ذات التزامن العالي والسعة العالية، بدءًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحوسبة المتوازية لمناد
Monad هو بلوكتشين عالي الأداء من الطبقة الأولى مصمم من أجل آلة Ethereum الافتراضية (EVM)، يعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) وتنفيذ الطبقة بشكل متوازي متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي التوافق والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، لتحقيق تحسين شامل من النهاية إلى النهاية.
التدفق: آلية تنفيذ متوازية متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بالتوازي، حيث أن الفكرة الرئيسية هي تقسيم عملية تنفيذ البلوكتشين إلى عدة مراحل مستقلة ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خط أنابيب ثلاثية الأبعاد، حيث تعمل كل مرحلة على خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويؤدي في النهاية إلى زيادة الإنتاجية وتقليل الكمون. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: فك الارتباط بين الإجماع والتنفيذ
في السلسلة التقليدية، عادةً ما تكون عملية التوافق والتنفيذ متزامنة، وهذا النموذج المتسلسل يحد بشدة من توسيع الأداء. حقق Monad من خلال "التنفيذ غير المتزامن" توافقًا غير متزامن في طبقة التوافق، وتنفيذ غير متزامن في طبقة التنفيذ، وتخزين غير متزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلًا، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات، ولا تنفذ منطق العقد.
يتم تفعيل عملية التنفيذ (طبقة التنفيذ) بشكل غير متزامن بعد اكتمال الإجماع.
بعد إتمام الإجماع، يتم الدخول مباشرة في عملية إجماع الكتلة التالية دون الحاجة إلى انتظار اكتمال التنفيذ.
التنفيذ المتوازي المتفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذجًا صارمًا للتنفيذ التسلسلي للمعاملات لتجنب صراعات الحالة. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يعزز بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
Monad ستقوم بتنفيذ جميع المعاملات بشكل متوازي بتفاؤل، على افتراض أن معظم المعاملات لا توجد بينها صراعات حالة.
تشغيل "كشف التداخل (Conflict Detector)" في نفس الوقت لمراقبة ما إذا كانت المعاملات قد قامت بالوصول إلى نفس الحالة (مثل تعارضات القراءة/الكتابة).
إذا تم اكتشاف تعارض، فسيتم تنفيذ المعاملات المتعارضة بشكل متسلسل مرة أخرى لضمان صحة الحالة.
اختارت Monad مسار التوافق: مع تقليل التعديلات على قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة واكتشاف التعارضات ديناميكياً لتحقيق التوازي، مما يجعلها تشبه نسخة الأداء من الإيثيريوم، مما يسهل انتقال النظام البيئي لـ EVM بفضل نضوجها، وهي مسرع التوازي لعالم EVM.
تحليل آلية حسابات MegaETH المتوازية
بخلاف定位 L1 لـ Monad، تم تحديد MegaETH كطبقة تنفيذ متوازية عالية الأداء ومتوافقة مع EVM، يمكن أن تعمل ككتلة L1 مستقلة، أو كطبقة تعزيز تنفيذ على الإيثيريوم (Execution Layer) أو مكونات مهيكلة. الهدف الأساسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة قابلة للتخطيط المستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة زمن الانتظار. الابتكار الرئيسي الذي قدمته MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة (Directed Acyclic Graph للاعتماد على الحالة) وآلية التزامن المهيكلة، التي تبني معًا نظام تنفيذ متوازي موجه نحو "التخيط داخل السلسلة".
Micro-VM (الميكرو آلة الافتراضية) الهيكل: الحساب هو الخيط
ميغا إيث قدمت نموذج تنفيذ "آلة افتراضية مصغرة (Micro-VM) لكل حساب"، مما يجعل بيئة التنفيذ "مُتعدّدة الخيوط"، لتوفير وحدة العزل الدنيا لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
اعتماد الحالة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتمادات
أنشأت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي، وكل معاملة تعدل أي حسابات، وتقرأ أي حسابات، يتم نمذجتها جميعًا كعلاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة مباشرة بالتوازي، بينما سيتم جدولة المعاملات التي لها علاقات اعتماد وفقًا لترتيب توبولوجي بشكل تسلسلي أو مؤجل. يضمن رسم الاعتماد التناسق في الحالة وعدم الكتابة المكررة أثناء عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدية EVM، من خلال تحقيق تغليف الميكرو-آلة الافتراضية على أساس الحسابات، وإدارة جدولة المعاملات من خلال رسم اعتماد الحالة، واستبدال آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنها منصة حساب متوازٍ مُعاد تصميمها بالكامل من "هيكل الحسابات→بنية الجدولة→سير العمل التنفيذية"، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت 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 متعددة النسخ، والترميز التفاضلي، وعنوان النسخ، ودفع ADS بإعادة بناء نموذج التنفيذ من أسفل محرك التخزين، وأطلقت محرك التخزين عالي الأداء Pharos Store القائم على البلوكتشين، مما يحقق قدرة معالجة على السلسلة ذات سعة عالية، وزمن استجابة منخفض، وقابلية تحقق قوية.
بشكل عام، يحقق هيكل Rollup Mesh الخاص بـ Pharos قدرة حساب متوازية عالية الأداء من خلال التصميم المعياري وآلية المعالجة غير المتزامنة، حيث يقوم Pharos بعمل
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
*sigh* إحصائيًا، لا تعالج أي من هذه التصنيفات بشكل كافٍ التطور النشوءي لحل التحجيم... أين جدول البيانات الخاص بي؟
شاهد النسخة الأصليةرد0
blocksnark
· 08-09 13:47
لقد انتهيت من المشاهدة، أشعر بالارتباك، كل شيء متكرر
شاهد النسخة الأصليةرد0
OnChainDetective
· 08-09 13:46
لقد انتهيت للتو من دراسة البيانات داخل السلسلة في سلة المهملات، حيث أن العقدة الرئيسية هي تفاعل مجموعات المحفظة.. الأموال المتداولة تحتل مكانة بارزة، من الواضح أن هناك من يعيد هيكلة الحصة.
صورة شاملة للحوسبة المتوازية في Web3: استكشاف خمسة مسارات للتوسع الأصلي للبلوكتشين
نظرة عامة على الحوسبة المتوازية في Web3: استكشاف أفضل الحلول لتوسيع البلوكتشين الأصلي
يكشف "مثلث الاستحالة" (الأمان، اللامركزية، القابلية للتوسع) في البلوكتشين عن التوازن الجوهري في تصميم أنظمة البلوكتشين. بالنسبة لموضوع "القابلية للتوسع" الذي لا ينتهي، فإن الحلول الرئيسية لتوسيع البلوكتشين في السوق الحالية تُصنف حسب الأنماط، بما في ذلك:
تشمل حلول توسيع البلوكتشين: الحساب الموازي داخل السلسلة، Rollup، التجزئة، وحدة DA، الهيكلية المعيارية، نظام Actor، ضغط إثبات zk، الهيكلية غير الحالة، وغيرها، وتغطي عدة مستويات من التنفيذ والحالة والبيانات والهياكل، وهي نظام توسيع كامل "متعدد الطبقات، تعاون وتكوين وحدات". تركز هذه المقالة على طريقة التوسع التي تعتمد بشكل رئيسي على الحساب الموازي.
حساب متوازي داخل السلسلة ( intra-chain parallelism )، مع التركيز على التنفيذ المتوازي للمعاملات/الأوامر داخل الكتلة. وفقًا لآلية التوازي، يمكن تقسيم طرق التوسع إلى خمس فئات، كل فئة تمثل طموحات أداء مختلفة، ونماذج تطوير وفلسفات معمارية، حيث تصبح درجة التوازي أكثر تفصيلًا، وزيادة قوة التوازي أعلى، وزيادة تعقيد الجدولة أيضًا أعلى، وتعقيد البرمجة وصعوبة التنفيذ أيضًا أعلى.
نموذج التزامن غير المتزامن خارج السلسلة، مع نظام الوكلاء (نموذج الوكيل / الوكيل) كنموذج ممثل، وهو ينتمي إلى نوع آخر من نماذج الحوسبة المتوازية، كنظام رسائل عبر السلاسل / غير متزامن (نموذج غير متزامن للكتل)، حيث يعمل كل وكيل ك"عملية ذكية مستقلة"، بطريقة غير متزامنة من خلال الرسائل، مدفوعة بالأحداث، دون الحاجة إلى جدولة متزامنة، ومن بين المشاريع الممثلة AO و ICP و Cartesi.
إن الحلول المعروفة لنا مثل Rollup أو حلول التوسع عبر التقسيم، تنتمي إلى آلية التوازي على مستوى النظام، ولا تنتمي إلى الحوسبة المتوازية داخل السلسلة. إنها تحقق التوسع من خلال "تشغيل عدة سلاسل/مجالات تنفيذ بشكل متوازي"، بدلاً من زيادة مستوى التوازي داخل كتلة واحدة/آلة افتراضية. هذه الأنواع من حلول التوسع ليست محور النقاش في هذه المقالة ولكننا سنستخدمها على أي حال لمقارنة أوجه التشابه والاختلاف في مفاهيم الهيكل.
ثانياً، سلسلة تعزيز التوازي من نوع EVM: كسر حدود الأداء في التوافق
تطور هيكل المعالجة التسلسلية للإيثريوم حتى الآن، ومر بتجارب توسيع متعددة مثل التجزئة، وRollup، والهندسة المعمارية المعيارية، لكن لا يزال عنق الزجاجة في السعة التنفيذية لم يشهد突破ًا جذريًا. ومع ذلك، لا يزال EVM وSolidity هما الأكثر تأثيرًا في قاعدة المطورين وإمكانات النظام البيئي لمنصات العقود الذكية الحالية. لذلك، تعتبر سلسلة تعزيز EVM المتوازية كمسار رئيسي يجمع بين توافق النظام البيئي وتحسين الأداء التنفيذي، وهي تتجه لتكون اتجاهًا مهمًا في التطور الجديد للتوسع. يُعد Monad وMegaETH من المشاريع الأكثر تمثيلًا في هذا الاتجاه، حيث يبنيان هيكل معالجة EVM المتوازي الذي يستهدف المشاهد ذات التزامن العالي والسعة العالية، بدءًا من تنفيذ التأخير وتفكيك الحالة.
تحليل آلية الحوسبة المتوازية لمناد
Monad هو بلوكتشين عالي الأداء من الطبقة الأولى مصمم من أجل آلة Ethereum الافتراضية (EVM)، يعتمد على مفهوم المعالجة المتوازية الأساسية (Pipelining)، حيث يتم تنفيذ الطبقة التوافقية بشكل غير متزامن (Asynchronous Execution) وتنفيذ الطبقة بشكل متوازي متفائل (Optimistic Parallel Execution). بالإضافة إلى ذلك، في طبقتي التوافق والتخزين، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB)، لتحقيق تحسين شامل من النهاية إلى النهاية.
التدفق: آلية تنفيذ متوازية متعددة المراحل
Pipelining هو المفهوم الأساسي لتنفيذ Monad بالتوازي، حيث أن الفكرة الرئيسية هي تقسيم عملية تنفيذ البلوكتشين إلى عدة مراحل مستقلة ومعالجة هذه المراحل بشكل متوازي، مما يشكل بنية خط أنابيب ثلاثية الأبعاد، حيث تعمل كل مرحلة على خيوط أو أنوية مستقلة، مما يحقق معالجة متزامنة عبر الكتل، ويؤدي في النهاية إلى زيادة الإنتاجية وتقليل الكمون. تشمل هذه المراحل: اقتراح المعاملات (Propose) التوصل إلى توافق (Consensus) تنفيذ المعاملات (Execution) وتقديم الكتل (Commit).
التنفيذ غير المتزامن: فك الارتباط بين الإجماع والتنفيذ
في السلسلة التقليدية، عادةً ما تكون عملية التوافق والتنفيذ متزامنة، وهذا النموذج المتسلسل يحد بشدة من توسيع الأداء. حقق Monad من خلال "التنفيذ غير المتزامن" توافقًا غير متزامن في طبقة التوافق، وتنفيذ غير متزامن في طبقة التنفيذ، وتخزين غير متزامن. مما يقلل بشكل ملحوظ من زمن الكتلة (block time) وتأخير التأكيد، مما يجعل النظام أكثر مرونة، وعملية المعالجة أكثر تفصيلًا، وزيادة كفاءة استخدام الموارد.
التصميم الأساسي:
التنفيذ المتوازي المتفائل: تنفيذ متوازي متفائل
تستخدم الإيثريوم التقليدية نموذجًا صارمًا للتنفيذ التسلسلي للمعاملات لتجنب صراعات الحالة. بينما تعتمد Monad على استراتيجية "التنفيذ المتوازي المتفائل"، مما يعزز بشكل كبير من سرعة معالجة المعاملات.
آلية التنفيذ:
اختارت Monad مسار التوافق: مع تقليل التعديلات على قواعد EVM قدر الإمكان، من خلال تأجيل كتابة الحالة واكتشاف التعارضات ديناميكياً لتحقيق التوازي، مما يجعلها تشبه نسخة الأداء من الإيثيريوم، مما يسهل انتقال النظام البيئي لـ EVM بفضل نضوجها، وهي مسرع التوازي لعالم EVM.
تحليل آلية حسابات MegaETH المتوازية
بخلاف定位 L1 لـ Monad، تم تحديد MegaETH كطبقة تنفيذ متوازية عالية الأداء ومتوافقة مع EVM، يمكن أن تعمل ككتلة L1 مستقلة، أو كطبقة تعزيز تنفيذ على الإيثيريوم (Execution Layer) أو مكونات مهيكلة. الهدف الأساسي من التصميم هو فصل منطق الحساب وبيئة التنفيذ والحالة إلى وحدات صغيرة قابلة للتخطيط المستقل، لتحقيق تنفيذ متزامن عالي داخل السلسلة وقدرة استجابة منخفضة زمن الانتظار. الابتكار الرئيسي الذي قدمته MegaETH هو: بنية Micro-VM + DAG الاعتماد على الحالة (Directed Acyclic Graph للاعتماد على الحالة) وآلية التزامن المهيكلة، التي تبني معًا نظام تنفيذ متوازي موجه نحو "التخيط داخل السلسلة".
Micro-VM (الميكرو آلة الافتراضية) الهيكل: الحساب هو الخيط
ميغا إيث قدمت نموذج تنفيذ "آلة افتراضية مصغرة (Micro-VM) لكل حساب"، مما يجعل بيئة التنفيذ "مُتعدّدة الخيوط"، لتوفير وحدة العزل الدنيا لجدولة متوازية. تتواصل هذه الآلات الافتراضية فيما بينها عبر الرسائل غير المتزامنة (Asynchronous Messaging)، بدلاً من الاستدعاءات المتزامنة، مما يسمح للعديد من الآلات الافتراضية بالتنفيذ المستقل والتخزين المستقل، مما يجعلها متوازية بشكل طبيعي.
اعتماد الحالة DAG: آلية جدولة مدفوعة بالرسم البياني للاعتمادات
أنشأت MegaETH نظام جدولة DAG يعتمد على علاقات الوصول إلى حالة الحساب، حيث يقوم النظام بصيانة رسم بياني عالمي للاعتماد (Dependency Graph) في الوقت الحقيقي، وكل معاملة تعدل أي حسابات، وتقرأ أي حسابات، يتم نمذجتها جميعًا كعلاقات اعتماد. يمكن تنفيذ المعاملات غير المتعارضة مباشرة بالتوازي، بينما سيتم جدولة المعاملات التي لها علاقات اعتماد وفقًا لترتيب توبولوجي بشكل تسلسلي أو مؤجل. يضمن رسم الاعتماد التناسق في الحالة وعدم الكتابة المكررة أثناء عملية التنفيذ المتوازي.
التنفيذ غير المتزامن وآلية الاستدعاء
تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية.
بشكل عام، يكسر MegaETH نموذج آلة الحالة أحادية الخيط التقليدية EVM، من خلال تحقيق تغليف الميكرو-آلة الافتراضية على أساس الحسابات، وإدارة جدولة المعاملات من خلال رسم اعتماد الحالة، واستبدال آلية الاستدعاء المتزامن بآلية الرسائل غير المتزامنة. إنها منصة حساب متوازٍ مُعاد تصميمها بالكامل من "هيكل الحسابات→بنية الجدولة→سير العمل التنفيذية"، مما يوفر أفكارًا جديدة على مستوى النموذج لبناء أنظمة سلسلة عالية الأداء من الجيل التالي.
اختارت 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 متعددة النسخ، والترميز التفاضلي، وعنوان النسخ، ودفع ADS بإعادة بناء نموذج التنفيذ من أسفل محرك التخزين، وأطلقت محرك التخزين عالي الأداء Pharos Store القائم على البلوكتشين، مما يحقق قدرة معالجة على السلسلة ذات سعة عالية، وزمن استجابة منخفض، وقابلية تحقق قوية.
بشكل عام، يحقق هيكل Rollup Mesh الخاص بـ Pharos قدرة حساب متوازية عالية الأداء من خلال التصميم المعياري وآلية المعالجة غير المتزامنة، حيث يقوم Pharos بعمل