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

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

تشمل حلول توسيع البلوكشين: الحوسبة المتوازية على السلسلة، وRollup، والتقسيم، ووحدات DA، والهياكل المودولية، وأنظمة الممثل، وضغط zk-proof، والهندسة المعمارية عديمة الحالة، وما إلى ذلك، تغطي عدة طبقات من التنفيذ، والحالة، والبيانات، والبنية، مما يشكل نظام توسيع متكامل "تعاون متعدد الطبقات وتركيب مودولي". تركز هذه المقالة على الطريقة الرئيسية للتوسع المستندة إلى الحوسبة المتوازية.

يركز التوازي داخل السلسلة على التنفيذ المتوازي للمعاملات/التعليمات داخل الكتلة. وفقًا للآلية المتوازية، يمكن تقسيم طرق التوسع إلى خمس فئات، تمثل كل منها سعيًا مختلفًا للأداء، ونماذج تطوير، وفلسفات معمارية مختلفة. يصبح حجم التوازي أدق، وتزداد كثافة التوازي، وترتفع تعقيد الجدولة، كما تزداد أيضًا تعقيد البرمجة وصعوبة التنفيذ.

• مستوى الحساب: يمثل مشروع سولانا
• التوازي على مستوى الكائن: يمثل مشروع Sui
• مستوى المعاملات: يمثل المشاريع Monad و Aptos
• مستوى المكالمة / MicroVM: يمثل المشروع MegaETH
• التوازي على مستوى التعليمات: يمثل مشروع GatlingX

نموذج التزامن غير المتزامن خارج السلسلة، الممثل بنظام الممثلين (نموذج الوكيل / الممثل)، ينتمي إلى نموذج آخر للحوسبة المتوازية. كنظام رسائل عبر السلاسل / غير متزامن (نموذج عدم التزامن المحظور)، يعمل كل وكيل كـ "عملية وكيل" تعمل بشكل مستقل، ترسل رسائل بشكل غير متزامن، مدفوعة بالأحداث، ودون الحاجة إلى جدولة متزامنة. تشمل المشاريع البارزة AO و ICP و Cartesi وغيرها.

تندرج حلول التوسع المعروفة مثل Rollup أو الشاردينغ تحت آليات التزامن على مستوى النظام ولا تقع ضمن الحسابات المتوازية على السلسلة. إنها تحقق التوسع من خلال "تشغيل سلاسل متعددة / مجالات تنفيذ بالتوازي" بدلاً من تعزيز التوازي داخل كتلة واحدة / آلة افتراضية واحدة. هذه الحلول للتوسع ليست محور هذا المقال، ولكننا سنستخدمها مع ذلك لإجراء تحليل مقارن للمفاهيم المعمارية.

2. سلسلة معززة متوازية قائمة على EVM: كسر حدود الأداء من خلال التوافق

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

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

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

خط أنابيب: آلية التنفيذ المتوازي متعددة المراحل
تعتبر عملية الأنابيب المفهوم الأساسي للتنفيذ المتوازي في الموناد. تتمثل فكرتها الأساسية في تقسيم عملية تنفيذ سلسلة الكتل إلى مراحل مستقلة متعددة ومعالجة هذه المراحل بالتوازي، مما يشكل بنية أنابيب ثلاثية الأبعاد. تعمل كل مرحلة على خيوط أو نوى مستقلة، مما يحقق معالجة متوازية عبر الكتل، مما يحسن في النهاية من القدرة الإنتاجية ويقلل من زمن الانتظار. تشمل هذه المراحل: اقتراح المعاملات (Propose)، الوصول إلى الإجماع (Consensus)، تنفيذ المعاملات (Execution)، والتزام الكتلة (Commit).

التنفيذ غير المتزامن: التوافق - فصل غير متزامن
في سلاسل الكتل التقليدية، يكون توافق المعاملات والتنفيذ عادةً عمليات متزامنة، ونموذج التسلسل هذا يحد بشدة من قدرة الأداء على التوسع. تحقق Monad طبقة توافق غير متزامنة، وطبقة تنفيذ غير متزامنة، وتخزين غير متزامن من خلال "التنفيذ غير المتزامن". وهذا يقلل بشكل كبير من زمن الكتلة وتأخيرات التأكيد، مما يجعل النظام أكثر مرونة، وتدفقات المعالجة أكثر تفصيلاً، واستخدام الموارد أعلى.

التصميم الأساسي:

• عملية التوافق (طبقة التوافق) مسؤولة فقط عن ترتيب المعاملات ولا تنفذ منطق العقد.
• تتم عملية التنفيذ (طبقة التنفيذ) بشكل غير متزامن بعد اكتمال الإجماع.
• بعد اكتمال الإجماع، الدخول فوراً في عملية الإجماع للكتلة التالية دون الانتظار لإنهاء التنفيذ.

التنفيذ المتوازي المتفائل
تستخدم إيثريوم التقليدية نموذجًا صارمًا لتنفيذ المعاملات بشكل متسلسل لتجنب تعارضات الحالة. على النقيض من ذلك، تعتمد مونايد استراتيجية "تنفيذ متوازي متفائل"، مما يعزز بشكل كبير سرعة معالجة المعاملات.

آلية التنفيذ:

• ستقوم Monad بتنفيذ جميع المعاملات بشكل متفائل بالتوازي، مع افتراض أن معظم المعاملات لا تحتوي على تعارضات في الحالة.
• في نفس الوقت، قم بتشغيل "كاشف النزاعات" لمراقبة ما إذا كانت المعاملات تصل إلى نفس الحالة (مثل النزاعات في القراءة/الكتابة).
• إذا تم الكشف عن تعارض، سيتم تسلسل المعاملات المتعارضة وإعادة تنفيذها لضمان صحة الحالة.

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

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

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

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

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

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

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

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

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

تركز مشاريع مثل Monad و MegaETH على مسارات تحسين الإنتاجية، مع الهدف الأساسي المتمثل في تعزيز TPS على السلسلة. تحقق هذه المشاريع معالجة متوازية على مستوى المعاملات أو الحسابات من خلال تنفيذ مؤجل وهياكل Micro-VM. تعتبر شبكة Pharos، كشبكة بلوكتشين متوازية من المستوى الأول كاملة الموديول، أن لديها آلية حوسبة متوازية أساسية تعرف باسم "Rollup Mesh". تدعم هذه البنية بيئات متعددة الآلات الافتراضية (EVM و Wasm) من خلال العمل التعاوني بين الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs)، مع دمج تقنيات متقدمة مثل إثباتات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEE).

تحليل آلية الحوسبة المتوازية لشبكة رول أب:

• خط الأنابيب غير المتزامن لكامل دورة الحياة: يقوم Pharos بفصل المراحل المختلفة للمعاملة (مثل الإجماع، التنفيذ، التخزين) ويتبنى نهج المعالجة غير المتزامنة، مما يسمح لكل مرحلة بالتقدم بشكل مستقل وفي وقت واحد، مما يؤدي إلى تحسين الكفاءة العامة للمعالجة.
• تنفيذ متوازي على بيئتين افتراضيتين: تدعم Pharos بيئتين افتراضيتين، EVM و WASM، مما يتيح للمطورين اختيار بيئة التنفيذ المناسبة بناءً على احتياجاتهم. لا تعزز هذه البنية المزدوجة للآلة الافتراضية مرونة النظام فحسب، بل تحسن أيضًا قدرات معالجة المعاملات من خلال التنفيذ المتوازي.
• شبكات المعالجة الخاصة (SPNs): تعتبر SPNs مكونات رئيسية في بنية Pharos، مشابهة للشبكات الفرعية المودولارية، المصممة خصيصًا للتعامل مع أنواع معينة من المهام أو التطبيقات. من خلال SPNs، يمكن لـ Pharos تحقيق تخصيص ديناميكي للموارد ومعالجة المهام بالتوازي، مما يعزز من قابلية التوسع وأداء النظام.
• التوافق المعياري وإعادة التخزين: يقدم Pharos آلية توافق مرنة تدعم نماذج توافق متعددة (مثل PBFT و PoS و PoA) وتحقق مشاركة آمنة وتكامل الموارد بين الشبكة الرئيسية و SPNs من خلال بروتوكول إعادة التخزين.

بالإضافة إلى ذلك، أعادت Pharos هيكلة نموذج التنفيذ من محرك التخزين الأساسي باستخدام أشجار ميركل متعددة الإصدارات، والترميز دلتا، والعناوين المصدرة، وتقنيات دفع ADS، مما أدى إلى إطلاق محرك التخزين عالي الأداء Pharos Store، مما يحقق إنتاجية عالية، وزمن استجابة منخفض، وقدرات معالجة على-chain قابلة للتحقق.

بشكل عام، يحقق هيكل شبكة Rollup الخاصة بـ Pharos قدرات حوسبة متوازية عالية الأداء من خلال تصميم معياري وآلية معالجة غير متزامنة. تعمل Pharos كمنسق جدولة للتوازي عبر Rollup، وليس كمحسن تنفيذ لـ "التوازي على السلسلة"، بل تتولى مهام التنفيذ المخصصة المتغايرة من خلال SPNs.

بالإضافة إلى بنية التنفيذ المتوازي لـ Monad و MegaETH و Pharos، نلاحظ أيضًا أن هناك بعض المشاريع في السوق تستكشف مسارات تطبيق تسريع GPU في الحوسبة المتوازية لـ EVM، والتي تعد مكملًا مهمًا وتجربة متطورة للنظام البيئي المتوازي لـ EVM. من بينها، تعتبر Reddio و GatlingX اتجاهين تمثيليين:

• ريديو هو منصة عالية الأداء تجمع بين zkRollup وهندسة التنفيذ المتوازي باستخدام وحدة معالجة الرسوميات. تكمن جوهرها في إعادة بناء عملية تنفيذ EVM، مما يحقق التوازي الأصلي في طبقة التنفيذ من خلال جدولة متعددة الخيوط، وتخزين الحالة غير المتزامن، وتنفيذ مجموعات المعاملات المعززة بواسطة وحدة معالجة الرسوميات. إنها تنتمي إلى مستوى المعاملات + مستوى العمليات (التنفيذ المتعدد الخيوط للأكواد التشغيلية) من حبيبات التوازي. يقدم تصميمها تنفيذ دفعات متعددة الخيوط، وتحميل الحالة غير المتزامن، ومعالجة منطق المعاملات المتوازي باستخدام وحدة معالجة الرسوميات (EVM متوافق مع CUDA). مثل موناد / ميغا ETH، يركز ريديو أيضًا على المعالجة المتوازية في طبقة التنفيذ، مع الاختلاف في إعادة بناء محرك التنفيذ من خلال هندسة المعالجة المتوازية باستخدام وحدة معالجة الرسوميات، المصممة خصيصًا لحالات الإنتاجية العالية والمكثفة من حيث الحوسبة (مثل استنتاج الذكاء الاصطناعي). تم إطلاق SDK، مما يوفر وحدة تنفيذ قابلة للإدماج.
• تدعي GatlingX أنها "GPU-EVM" وتقترح معمارية أكثر جذرية تحاول نقل نموذج "تنفيذ التعليمات المتسلسل" لجهاز EVM الافتراضي التقليدي إلى بيئة تنفيذ متوازية قائمة على GPU. تتضمن آليتها الأساسية تجميع كود بايت EVM ديناميكيًا إلى مهام CUDA المتوازية، وتنفيذ تدفقات التعليمات من خلال نواة متعددة لـ GPU، مما يكسر عنق الزجاجة التسلسلي لجهاز EVM على أدنى مستوى. إنها تنتمي إلى توازي مستوى التعليمات (Instruction-Level Parallelism, ILP). مقارنة بتوازي "مستوى المعاملات/مستوى الحسابات" لـ Monad / MegaETH، فإن آلية التوازي لـ GatlingX أقرب إلى مسارات تحسين مستوى التعليمات، وأكثر شبهًا بإعادة بناء المحرك الافتراضي على المستوى الأساسي. حاليًا، هي في المرحلة المفاهيمية، مع إصدار ورقة بيضاء ورسومات معمارية، ولكن لا يوجد SDK أو شبكة رئيسية حتى الآن.

تقدم Artela مفهوم تصميم متوازي متميز. من خلال إدخال بنية EVM++ مع آلة افتراضية WebAssembly (WASM)، يسمح ذلك للمطورين بإضافة وتنفيذ الإضافات ديناميكيًا على السلسلة مع الحفاظ على توافق EVM، باستخدام نموذج برمجة Aspect. يأخذ دقة استدعاءات العقود (وظيفة / إضافة) كوحدة متوازية دنيا، داعمًا حقن وحدات الإضافة (المشابهة لـ "البرمجيات الوسيطة القابلة للتوصيل") خلال وقت تشغيل عقد EVM، محققًا فصلًا منطقيًا، واستدعاءات غير متزامنة، وتنفيذ متوازي على مستوى الوحدة. يركز أكثر على القابلية للتكوين والهندسة المعمارية المودولية لطبقة التنفيذ. يقدم هذا المفهوم أفكارًا جديدة للتطبيقات المعقدة متعددة الوحدات في المستقبل.

3. سلسلة الهندسة المعمارية الموازية الأصلية: إعادة بناء كيان التنفيذ للآلة الافتراضية

لقد اعتمد نموذج تنفيذ EVM الخاص بـ Ethereum بنية "ترتيب إجمالي للمعاملات + تنفيذ متسلسل" أحادية الخيط منذ تصميمه، بهدف ضمان الحتمية والاتساق في تغييرات الحالة عبر جميع العقد في الشبكة. ومع ذلك، فإن هذه البنية تحتوي على اختناقات أداء جوهرية تحد من قدرة النظام على المعالجة والتوسع. وعلى النقيض من ذلك، فإن سلاسل البنية التحتية للحوسبة المتوازية الأصلية مثل Solana (SVM) و MoveVM (Sui، Aptos) و Sei v2 المبنية على Cosmos SDK مصممة للتنفيذ المتوازي من الأساس، مما يوفر المزايا التالية:

• يفصل نموذج الحالة بشكل طبيعي: تتبنى سولانا آلية إعلان قفل الحساب، ويقدم MoveVM نموذج ملكية الكائنات، بينما تصنف Sei v2 بناءً على أنواع المعاملات لتحقيق تحديد الصراع الثابت، مما يدعم جدولة متزامنة على مستوى المعاملات.
• تحسين تزامن الآلة الافتراضية: يدعم محرك Sealevel في سولانا التنفيذ متعدد الخيوط بشكل أصلي؛ يمكن لـ MoveVM إجراء تحليل الرسم البياني للتزامن الثابت؛ يدمج Sei v2 محرك مطابقة متعدد الخيوط ووحدة VM متوازية.

بالطبع، يواجه هذا النوع من السلاسل الأصلية المتوازية أيضًا تحديات التوافق البيئي. غالبًا ما تتطلب الهياكل غير EVM لغات تطوير جديدة تمامًا (مثل Move و Rust) وأدوات جديدة، مما يمثل تكلفة انتقال معينة للمطورين؛ بالإضافة إلى ذلك، يجب على المطورين أيضًا إتقان مجموعة من المفاهيم الجديدة مثل نماذج الوصول إلى الحالة، وحدود التزامن، ودورات حياة الكائنات، وكل ذلك يزيد من عتبة الفهم ويفرض متطلبات أعلى على نماذج التطوير.

3.1 مبدأ سولانا ومحرك سيفيل المتوازي SVM

نموذج تنفيذ Sealevel لـ Solana هو آلية جدولة متوازية تعتمد على الحسابات، وهي المحرك الأساسي الذي تستخدمه Solana لتحقيق تنفيذ المعاملات المتوازية على السلسلة. من خلال آلية "إعلان الحساب + الجدولة الثابتة + التنفيذ متعدد الخيوط"، يحقق ذلك تزامن عالي الأداء على مستوى العقود الذكية. Sealevel هو أول نموذج تنفيذ في مجال blockchain ينجح في تنفيذ الجدولة المتزامنة على السلسلة في بيئة الإنتاج، وقد أثرت أفكاره المعمارية على العديد من مشاريع الحوسبة المتوازية اللاحقة، مما جعله نموذجًا مرجعيًا لتصميم المستوى الأول المتوازي عالي الأداء.

الآلية الأساسية:

1. إعلان وصول الحساب الصريح (قوائم وصول الحسابات): يجب على كل معاملة أن تُعلن عن الحسابات المعنية (قراءة/كتابة) في وقت التقديم، مما يسمح للنظام بتحديد ما إذا كانت هناك تعارضات في الحالة بين المعاملات.

2. الكشف عن النزاعات وجدولة تعدد الخيوط

• إذا لم يكن هناك تداخل بين مجموعة الحسابات التي تم الوصول إليها من قبل المعاملتين → يمكن تنفيذها بالتوازي;
• توجد تعارضات → التنفيذ بشكل متسلسل حسب ترتيب الاعتماد؛
• يقوم الجدول الزمني بتخصيص المعاملات إلى خيوط مختلفة بناءً على رسم الاعتماد.

3. سياق تنفيذ مستقل (سياق استدعاء البرنامج): يتم تشغيل كل استدعاء عقد في سياق معزول، بدون مكدس مشترك، مما يمنع التداخل بين الاستدعاءات.

سيليفل هو محرك جدولة التنفيذ المتوازي لسولانا، بينما SVM هو بيئة تنفيذ العقود الذكية المبنية على سيليفل (باستخدام آلة BPF الافتراضية). معًا، يشكلان الأساس الفني لنظام التنفيذ المتوازي عالي الأداء في سولانا.

إكليبس هو مشروع ينشر آلة Solana الافتراضية على سلاسل معيارية (مثل Ethereum L2 أو Celestia)، مستفيدًا من محرك التنفيذ المتوازي الخاص بـ Solana كطبقة تنفيذ Rollup. إكليبس هو أحد المشاريع الأولى التي تقترح فصل طبقة تنفيذ Solana (Sealevel + SVM) عن الشبكة الرئيسية لـ Solana ونقلها إلى بنية معيارية، مما يجعل نموذج التنفيذ المتوازي "القوي للغاية" لـ Solana كخدمة طبقة تنفيذ. لذلك، يدخل إكليبس أيضًا ضمن فئة الحوسبة المتوازية.

نهج نيون مختلف؛ فهو يقدم EVM للعمل في بيئة SVM / Sealevel. إنه يبني طبقة وقت تشغيل متوافقة مع EVM، مما يسمح للمطورين باستخدام Solidity لتطوير العقود التي تعمل في بيئة SVM، ولكن جدولة التنفيذ تستخدم SVM + Sealevel. نيون يميل أكثر نحو فئة Blockchain المودولارية بدلاً من التأكيد على الابتكارات في الحوسبة المتوازية.

باختصار، تعتمد سولانا و SVM على محرك التنفيذ Sealevel، وفلسفة الجدولة في نظام تشغيل سولانا مشابهة لتلك الخاصة بجدولة النواة، حيث يتم التنفيذ بسرعة ولكن مع مرونة منخفضة نسبيًا. إنها سلسلة عامة متوازية عالية الأداء أصلية.

3.2 عمارة MoveVM: مدفوعة بالموارد والأشياء

MoveVM هو آلة افتراضية للعقود الذكية مصممة لأمان الموارد على السلسلة والتنفيذ المتوازي. تم تطوير لغتها الأساسية، Move، في الأصل بواسطة Meta (المعروفة سابقًا باسم فيسبوك) لمشروع Libra، مع التركيز على مفهوم "المورد ككائن". جميع الحالات على السلسلة موجودة ككائنات ذات ملكية واضحة ودورة حياة. وهذا يسمح لـ MoveVM بتحليل ما إذا كانت هناك تعارضات في الحالة بين المعاملات في وقت الترجمة، مما يمكّن الجدولة الثابتة المتوازية على مستوى الكائن، ويستخدم على نطاق واسع في سلاسل الكتل العامة المتوازية الأصلية مثل Sui و Aptos.

نموذج ملكية الكائنات في سوي
ت stems القدرة على الحوسبة المتوازية لـ Sui من نهج نمذجة الحالة الفريد وآلية التحليل الثابت على مستوى اللغة. على عكس سلاسل الكتل التقليدية التي تستخدم شجرة حالة عالمية، قامت Sui ببناء مجموعة من نماذج الحالة المركزية على الكائنات، بالتزامن مع نظام النوع الخطي لـ MoveVM، مما يسمح بجدولة متوازية كعملية حتمية يمكن إكمالها في وقت الترجمة.

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

تقسم Sui مساحة الحالة بناءً على الكائنات وتجمع تحليل الملكية في وقت الترجمة لتحقيق تنفيذ متوازي على مستوى الكائن بتكلفة منخفضة ودون تراجع. مقارنةً بالتنفيذ التسلسلي أو الفحوصات في وقت التشغيل للسلاسل التقليدية، حققت Sui تحسينات كبيرة في كفاءة التنفيذ، والحتمية النظامية، واستخدام الموارد.

آلية تنفيذ Block-STM في Aptos
أبتوس هي بلوكتشين عالية الأداء من الطبقة الأولى تعتمد على لغة موف، والتي تأتي قدرتها على التنفيذ المتوازي بشكل أساسي من إطار العمل الخاص بها Block-STM (ذاكرة المعاملات البرمجية على مستوى الكتلة). على عكس سوي، التي تميل إلى اعتماد استراتيجية "التوازي الثابت في وقت الترجمة"، فإن Block-STM ينتمي إلى آلية جدولة ديناميكية "التزامن المتفائل في وقت التشغيل + التراجع عن النزاعات"، مناسبة للتعامل مع مجموعات المعاملات ذات الاعتمادات المعقدة.

تقسم Block-STM تنفيذ معاملات الكتلة إلى ثلاث مراحل:

• التنفيذ المضاربي: يُفترض أن جميع المعاملات خالية من النزاعات قبل التنفيذ، ويقوم النظام بجدولة المعاملات لعدة خيوط من أجل التنفيذ المتزامن، مع تسجيل حالات الحسابات التي تصل إليها (مجموعة القراءة / مجموعة الكتابة).
• مرحلة اكتشاف النزاعات والتحقق: يقوم النظام بالتحقق من نتائج التنفيذ: إذا كان هناك صراع قراءة-كتابة بين معاملتين (على سبيل المثال، Tx1 تقرأ الحالة المكتوبة بواسطة Tx2)، سيتم إرجاع أحدهما.
• إعادة محاولة إلغاء المعاملات المتعارضة (مرحلة الإعادة): سيتم إعادة جدولة المعاملات المتعارضة للتنفيذ حتى يتم حل تبعياتها، مما يؤدي في النهاية إلى تشكيل تسلسل التزام حالة صالح وقابل للتحديد لجميع المعاملات.

Block-STM هو نموذج تنفيذ ديناميكي يستخدم "التوازي المتفائل + إعادة المحاولة بالرجوع"، وهو مناسب لسيناريوهات معالجة دفعات المعاملات على السلسلة التي تتطلب حالة مكثفة ومعقدة منطقياً. إنه جوهر الحوسبة المتوازية لـ Aptos لبناء سلسلة عامة عالية التنوع وعالية الإنتاجية.

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

3.3 نوع التوسع المتوازي في Cosmos SDK

Sei V2 هو سلسلة عامة للتداول عالية الأداء مبنية على Cosmos SDK. تنعكس قدراتها المتوازية بشكل رئيسي في جانبين: محرك المطابقة متعدد الخيوط وتحسين التنفيذ المتوازي على مستوى الآلة الافتراضية، بهدف خدمة سيناريوهات التداول على السلسلة عالية التردد ومنخفضة الكمون، مثل DEXs دفتر الطلبات وبنية تبادل على السلسلة.

آلية التوازي الأساسية:

• محرك المطابقة المتوازي: يقدم Sei V2 مسار تنفيذ متعدد الخيوط في منطق مطابقة الأوامر، حيث يفصل دفتر الطلبات عن منطق المطابقة على مستوى الخيط، مما يسمح بمعالجة مهام المطابقة بين أسواق متعددة (أزواج التداول) بشكل متوازي، وبالتالي يتجنب عنق الزجاجة الأحادي الخيط.
• تحسين التزامن على مستوى الآلة الافتراضية: قامت Sei V2 بإنشاء بيئة تشغيل CosmWasm مع قدرات التنفيذ المتزامن، مما يسمح لبعض استدعاءات العقود بالعمل بالتوازي بشرط عدم تعارض حالاتهم، وتحقيق تحكم أعلى في الإنتاجية بالتزامن مع آلية تصنيف أنواع المعاملات.
• التوافق المتوازي المدمج مع جدولة طبقة التنفيذ: تقديم ما يُسمى آلية التوافق "توين-توربو" لتعزيز فصل الإنتاجية بين طبقة التوافق وطبقة التنفيذ، مما يعزز الكفاءة العامة لمعالجة الكتل.

3.4 نموذج UTXO لإعادة بناء الوقود

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

4. نموذج الممثل: نموذج جديد للتنفيذ المتزامن للوكلاء

نموذج الممثل هو نموذج تنفيذ متوازي يستخدم عمليات الوكلاء (وكيل أو عملية) كوحدات، مما يختلف عن الحوسبة المتزامنة التقليدية مع حالة عالمية على السلسلة (سيناريوهات مثل "الحوسبة المتوازية على السلسلة" مثل سولانا/سوي/مونا)، حيث يركز على أن لكل وكيل حالته وسلوكه المستقلين، ويتواصل ويجدول من خلال رسائل غير متزامنة. تحت هذه البنية، يمكن للأنظمة على السلسلة تشغيل عدد كبير من العمليات المفصولة بشكل متزامن، مما يوفر قابلية توسيع قوية وتحمل أخطاء غير متزامنة. تشمل المشاريع الممثلة AO (Arweave AO) و ICP (Internet Computer) و Cartesi، والتي تدفع تطور blockchain من محرك تنفيذ إلى "نظام تشغيل على السلسلة"، وتوفر بنية تحتية أصلية لوكلاء الذكاء الاصطناعي، والتفاعلات متعددة المهام، وتنسيق المنطق المعقد.

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

4.1 AO (Arweave) ، حاسوب فائق متوازي فوق طبقة التخزين

AO هو منصة حوسبة لامركزية تعمل على طبقة التخزين الدائم Arweave، مع الهدف الأساسي لبناء نظام تشغيل على السلسلة يدعم تشغيل وكلاء غير متزامنين على نطاق واسع.

ميزات البنية الأساسية الرئيسية:

• هندسة العمليات: يُشار إلى كل وكيل على أنه عملية، تمتلك حالة مستقلة، وجدولة مستقلة، ومنطق تنفيذ.
• لا توجد بنية سلسلة الكتل: AO ليست سلسلة، بل هي طبقة تخزين لامركزية تعتمد على Arweave + محرك تنفيذ مدفوع بالرسائل متعدد الوكلاء؛
• نظام جدولة الرسائل غير المتزامنة: تتواصل العمليات من خلال الرسائل، معتمدةً نموذج تشغيل غير متزامن خالٍ من الأقفال، مما يدعم بشكل جوهري التوسع المتزامن؛
• التخزين الدائم للحالة: يتم تسجيل جميع حالات الوكلاء وسجلات الرسائل والتعليمات بشكل دائم على Arweave، مما يضمن إمكانية التدقيق التام وشفافية لامركزية.
• الوكيل الأصلي: مناسب لنشر المهام المعقدة متعددة الخطوات (مثل الوكلاء الذكاء الاصطناعي، وحدات التحكم في بروتوكول DePIN، منسقو المهام المؤ automatisés، إلخ)، يمكنه بناء "معالج مساعد ذكاء اصطناعي على السلسلة".

يتبع AO نهج "الجسم الذكي المحلي المتطرف + التخزين المدفوع + بنية بدون سلسلة"، مما يبرز المرونة وفصل المكونات بشكل وحدوي. إنه "إطار ميكروkernel مبني فوق طبقة التخزين"، مع حدود نظام ضيقة عن قصد، مما يبرز الحوسبة الخفيفة + الهياكل التحكم القابلة للتكوين.

4.2 ICP (حاسوب الإنترنت)، منصة استضافة ويب 3 كاملة

ICP هي منصة تطبيقات سلسلة الكتل كاملة المكدس الأصلية لـ Web3 التي أطلقتها DFINITY، وتهدف إلى توسيع قدرات الحوسبة على السلسلة لتوفير تجربة مشابهة لتجربة Web2، وتدعم استضافة الخدمات الكاملة، وربط النطاقات، وهندسة بدون خادم.

ميزات بنية النظام الأساسية:

• معمارية الحاويات (الحاويات كعوامل ذكية): كل حاوية هي عامل ذكي يعمل على آلة Wasm الافتراضية، تمتلك حالة مستقلة، كود، وقدرات جدولة غير متزامنة؛
• نظام توافق موزع للشبكة الفرعية: تتكون الشبكة بأكملها من عدة شبكات فرعية، يحتفظ كل منها بمجموعة من الحاويات ويصل إلى توافق من خلال آلية توقيع BLS.
• نموذج الاستدعاء غير المتزامن: تتواصل الحاويات مع بعضها البعض من خلال الرسائل غير المتزامنة، مما يدعم التنفيذ غير الحاجز ولديه توازي داخلي؛
• استضافة الويب على السلسلة: تدعم العقود الذكية لاستضافة صفحات الواجهة الأمامية مباشرة، مع تعيين DNS محلي، مما يجعلها أول منصة بلوكتشين تدعم الوصول المباشر من المتصفح إلى التطبيقات اللامركزية.
• وظائف نظام شاملة: مزودة بترقيات ساخنة على السلسلة، مصادقة الهوية، عشوائية موزعة، مؤقتات، وغيرها من واجهات برمجة التطبيقات النظامية، مناسبة لنشر خدمات معقدة على السلسلة.

تختار ICP منصة ثقيلة، مع تكامل التغليف، ونموذج نظام تشغيل قوي للتحكم في المنصة، تتميز بـ "نظام تشغيل البلوكشين" مع توافق متكامل، وتنفيذ، وتخزين، والوصول. تؤكد على قدرات استضافة الخدمة الكاملة، ويتوسع حد النظام إلى منصة استضافة ويب 3 كاملة.

بالإضافة إلى ذلك، يمكن لمشاريع الحوسبة المتوازية الأخرى المستندة إلى نموذج الممثل الرجوع إلى الجدول أدناه:

V. ملخص وتوقعات

استنادًا إلى الاختلافات في هندسة الآلات الافتراضية وأنظمة اللغات، يمكن تقسيم حلول الحوسبة المتوازية في blockchain إلى فئتين رئيسيتين: سلاسل تعزيز متوازية قائمة على EVM وسلاسل معمارية متوازية أصلية (غير EVM).

يحقق الأول إنتاجية أعلى وقدرات معالجة متوازية من خلال تحسين عميق لطبقة التنفيذ مع الحفاظ على التوافق مع نظام EVM / Solidity. إنه مناسب للسيناريوهات التي توجد فيها رغبة في وراثة أصول Ethereum وأدوات التطوير مع تحقيق أيضًا اختراقات في الأداء. تشمل المشاريع التمثيلية:

• موناد: تحقق نموذج تنفيذ متوازي متفائل متوافق مع EVM من خلال الكتابات المؤجلة واكتشاف التضارب في وقت التشغيل، وبناء رسم بياني للاعتماد وجدولة التنفيذ مع تعدد الخيوط بعد الوصول إلى الإجماع.
• ميغا ETH: تُجسد كل حساب/عقد كـ Micro-VM مستقل، مما يحقق جدولة متوازية على مستوى الحساب بشكل متباعد بناءً على الرسائل غير المتزامنة ورسوم اعتماد الحالة.
• فاروس: بناء بنية شبكة رول أب تتعاون مع وحدة SPN من خلال خطوط أنابيب غير متزامنة لتحقيق المعالجة المتوازية على مستوى النظام عبر العمليات.
• ريديو: تعتمد على بنية zkRollup + GPU، مع التركيز على تسريع عملية التحقق خارج السلسلة لـ zkEVM من خلال توليد SNARK بالجملة، مما يعزز من قدرة التحقق.

الأخير يتحرر تمامًا من قيود التوافق مع إيثيريوم، معادلاً تصميم نموذج التنفيذ من الآلة الافتراضية، نموذج الحالة، وآلية الجدولة لتحقيق قدرات التزامن عالية الأداء الأصلية. الفئات الفرعية النموذجية تشمل:

• سولانا (نظام SVM): يعتمد على إعلانات الوصول إلى الحسابات وجدولة رسم بياني ثابت للصراعات، مما يمثل نموذج تنفيذ متوازي على مستوى الحساب؛
• سوي / أبتوس (نظام MoveVM): بناءً على نموذج كائن المورد ونظام النوع، يدعم التحليل الثابت في وقت الترجمة ويحقق التوازي على مستوى الكائن.
• سي V2 (مسار Cosmos SDK): يقدم محرك مطابقة متعدد الخيوط وتحسين التزامن للآلة الافتراضية ضمن بنية Cosmos، مناسب لتطبيقات التداول عالية التردد.
• الوقود (UTXO + بنية Sway): تحقيق التوازي على مستوى المعاملات من خلال التحليل الثابت لمجموعات مدخلات UTXO، بالاشتراك مع طبقة تنفيذ معيارية ولغة العقود الذكية المخصصة Sway.

بالإضافة إلى ذلك، يقوم نموذج الممثل، كنظام متوازي أوسع، ببناء نموذج تنفيذ على السلسلة للعمليات المستقلة متعددة الوكلاء + التعاون المدفوع بالرسائل من خلال آلية جدولة العمليات غير المتزامنة المستندة إلى Wasm أو VMs مخصصة. تشمل المشاريع التمثيلية ما يلي:

• AO (Arweave AO): نظام تشغيل وكيل مدفوع بالتخزين الدائم، يبني نظام نواة دقيقة غير متزامنة على السلسلة.
• ICP (الكمبيوتر الإنترنت): يحقق تنفيذًا عالي القابلية للتوسع غير المتزامن من خلال تنسيق الشبكات الفرعية مع الوكيل الحاوي (Canister) كأصغر وحدة.
• كارتيزي: يقدم نظام تشغيل لينوكس كبيئة حوسبة خارج السلسلة، مما يوفر مسار تحقق على السلسلة لنتائج الحوسبة الموثوقة، مناسب للسيناريوهات التطبيقية المعقدة أو التي تتطلب موارد كبيرة.

استنادًا إلى المنطق أعلاه، يمكننا تصنيف حلول سلسلة الكتل العامة الحاسوبية المتوازية السائدة حاليًا ضمن هيكل التصنيف الموضح في الرسم البياني أدناه:

من منظور أوسع للتوسع، تركز التقسيم والتجميع (L2) على تحقيق التوسع الأفقي للنظام من خلال تقسيم الحالة أو التنفيذ خارج السلسلة، بينما تعيد سلاسل الحوسبة المتوازية (مثل Monad، Sui، Solana) والنظم الموجهة للممثلين (مثل AO، ICP) بناء نموذج التنفيذ مباشرة لتحقيق التوازي الأصلي على مستوى السلسلة أو النظام. الأول يعزز من خلال المعالجة على السلسلة عبر طرق مثل الآلات الافتراضية متعددة الخيوط، ونماذج الكائنات، وتحليل تعارض المعاملات؛ بينما تستخدم النظم الموجهة للممثلين العمليات/الوكلاء كوحدات أساسية وتتبنى طرق تنفيذ مدفوعة بالرسائل وغير متزامنة لتمكين التشغيل المتزامن لعدة وكلاء. بالمقارنة، يعد التقسيم والتجميع أكثر شبهاً بـ 'توزيع الحمل عبر سلاسل متعددة' أو 'الاستعانة بمصادر خارج السلسلة'، بينما تتعلق السلاسل المتوازية ونموذج الممثلين بـ 'تحرير الإمكانات الأداء من محرك التنفيذ نفسه'، مما يعكس اتجاه تطور معماري أكثر شمولاً.

مقارنة بين الحوسبة المتوازية vs هيكلية الشظايا vs قابلية التوسع باستخدام الرفع vs مسار التمديد الموجه نحو الممثلين

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

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

بيان:

1. هذه المقالة مستنسخة من [تيك فلو] حقوق الطبع والنشر تعود للمؤلف الأصلي [0xjacobzhao و ChatGPT 4o] إذا كانت لديك أي اعتراضات على إعادة الطبع، يرجى الاتصال بـفريق Gate Learnسيتولى الفريق معالجة ذلك بأسرع ما يمكن وفقًا للإجراءات ذات الصلة.
2. تنبيه: الآراء والأفكار المعبر عنها في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تمت ترجمة النسخ الأخرى من المقالة بواسطة فريق Gate Learn، ما لم يُذكر خلاف ذلك.بوابةلا يجوز تحت أي ظرف من الظروف نسخ أو توزيع أو سرقة مقالات مترجمة.