سعر ‏AO

كتب بواسطة 0xjacobzhao و ChatGPT 4o تكشف "الأمان" و "اللامركزية" و "قابلية التوسع" ل blockchain "Blockchain Trilemma" عن المقايضة الأساسية في تصميم أنظمة blockchain ، أي أنه من الصعب على مشاريع blockchain تحقيق "أمان شديد ، يمكن للجميع المشاركة ، ومعالجة عالية السرعة" في نفس الوقت. استجابة للموضوع الأبدي المتمثل في "قابلية التوسع" ، يتم تقسيم حلول توسيع نطاق blockchain السائدة في السوق وفقا للنماذج ، بما في ذلك: التحجيم المحسن للتنفيذ: يحسن قدرات التنفيذ، مثل التوازي ووحدة معالجة الرسومات ومتعددة النواة في الموقع التحجيم المعزول عن الحالة: يقسم الحالة / الأجزاء أفقيا ، مثل الأجزاء و UTXOs والشبكات الفرعية المتعددة توسيع نطاق الاستعانة بمصادر خارجية خارج السلسلة: وضع التنفيذ خارج السلسلة، مثل المجموعات المحتسبة والمعالجات المساعدة والبيانات الإجمالية توسيع قدرة الفصل الهيكلي: البنية معيارية وتعمل معا ، مثل سلاسل الوحدات النمطية ، وأجهزة التسلسل المشتركة ، وشبكات التجميع التحجيم المتزامن غير المتزامن: نموذج الممثل، وعزل العملية، والمستند إلى الرسائل، مثل الوكلاء والسلاسل غير المتزامنة متعددة مؤشرات الترابط يتضمن حل تحجيم blockchain: الحوسبة المتوازية على السلسلة ، والتجميع ، والتجزئة ، ووحدة DA ، والهيكل المعياري ، ونظام الممثل ، وضغط دليل zk ، والهندسة المعمارية عديمة الحالة ، وما إلى ذلك ، والتي تغطي مستويات متعددة من التنفيذ والحالة والبيانات والهيكل ، وهو نظام تحجيم كامل ل "التعاون متعدد الطبقات ومجموعة الوحدة". تركز هذه المقالة على أساليب التحجيم التي تعميم الحوسبة المتوازية. التوازي داخل السلسلة ، والذي يركز على التنفيذ الموازي للمعاملات / التعليمات داخل الكتلة. وفقا للآلية المتوازية ، يمكن تقسيم طرق القياس الخاصة بها إلى خمس فئات ، كل منها يمثل سعي أداء مختلفا ونموذج تطوير وفلسفة هندسة معمارية ، وتصبح الدقة المتوازية أدق وأدق ، وتزداد كثافة التوازي أكثر فأكثر ، ويزداد تعقيد الجدولة أكثر فأكثر ، كما يزداد تعقيد البرمجة وصعوبة التنفيذ. على مستوى الحساب: يمثل مشروع Solana التوازي على مستوى الكائن: يمثل المشروع Sui مستوى المعاملة: يمثل مشروع Monad ، Aptos مستوى المكالمة / MicroVM: يمثل مشروع MegaETH مستوى التعليمات: يمثل مشروع GatlingX ينتمي نموذج التزامن غير المتزامن خارج السلسلة ، الذي يمثله نموذج الممثل / الممثل ، إلى نموذج حوسبة متوازي آخر ، كنظام رسائل عبر السلسلة / غير متزامن (نموذج مزامنة غير كتلة) ، يعمل كل عامل بشكل مستقل ك "عملية وكيل" ، رسائل غير متزامنة في الوضع المتوازي ، مدفوعة بالحدث ، لا توجد جدولة متزامنة ، مشاريع تمثيلية مثل AO ، ICP ، Cartesi ، إلخ. ينتمي مخطط التجميع أو قياس الشظايا المعروف إلى آلية التزامن على مستوى النظام ، وليس الحوسبة المتوازية داخل السلسلة. إنهم يحققون التوسع من خلال "تشغيل سلاسل متعددة / مجالات تنفيذ بالتوازي" ، بدلا من زيادة التوازي داخل كتلة واحدة / جهاز افتراضي. هذا النوع من حلول القياس ليس محور هذه المقالة ، لكننا سنستمر في استخدامه لمقارنة أوجه التشابه والاختلاف في المفاهيم المعمارية. 2. سلسلة التحسين المتوازي EVM: اختراق حدود الأداء في التوافق منذ تطوير بنية المعالجة التسلسلية ل Ethereum ، خضعت لجولات متعددة من محاولات القياس مثل التجزئة والتجميع والبنية المعيارية ، ولكن عنق الزجاجة في الإنتاجية لطبقة التنفيذ لم يتم كسره بشكل أساسي بعد. ولكن في الوقت نفسه ، لا تزال EVM و Solidity منصات العقود الذكية التي تتمتع بأكبر قاعدة مطورين وإمكانات بيئية. لذلك ، أصبحت سلسلة التحسين المتوازي EVM اتجاها مهما لجولة جديدة من التوسع والتطور كمسار رئيسي يأخذ في الاعتبار التوافق البيئي وتحسين أداء التنفيذ. Monad و MegaETH هما المشروعان الأكثر تمثيلا في هذا الاتجاه ، بدءا من التنفيذ المؤجل وتحلل الحالة على التوالي ، لبناء بنية معالجة متوازية EVM لسيناريوهات عالية التزامن وعالية الإنتاجية. تحليل الآلية الحسابية المتوازية ل Monad Monad عبارة عن سلسلة كتل من الطبقة 1 عالية الأداء أعيد تصميمها لجهاز Ethereum الظاهري (EVM) ، بناء على المفهوم المتوازي الأساسي لخطوط الأنابيب ، مع التنفيذ غير المتزامن في طبقة الإجماع والتنفيذ المتوازي المتفائل في طبقة التنفيذ. بالإضافة إلى ذلك ، بناء على طبقات الإجماع والتخزين ، قدمت Monad بروتوكول BFT عالي الأداء (MonadBFT) ونظام قاعدة بيانات مخصص (MonadDB) على التوالي لتحقيق التحسين الشامل. خطوط الأنابيب: آلية تنفيذ متوازية لخطوط الأنابيب متعددة المراحل Pipelining هو المفهوم الأساسي للتنفيذ المتوازي ل Monad ، وفكرته الأساسية هي تقسيم عملية تنفيذ blockchain إلى مراحل مستقلة متعددة ، ومعالجة هذه المراحل بالتوازي لتشكيل بنية خط أنابيب ثلاثية الأبعاد ، تعمل كل مرحلة على خيوط أو نوى مستقلة لتحقيق معالجة متزامنة عبر الكتل ، وتحقيق تأثير تحسين الإنتاجية وتقليل زمن الوصول. تشمل هذه المراحل: الاقتراح والإجماع والتنفيذ والالتزام. التنفيذ غير المتزامن: الإجماع - ينفذ الفصل غير المتزامن في السلاسل التقليدية ، عادة ما يكون الإجماع على المعاملات وتنفيذها عمليتين متزامنة ، ويحد هذا النموذج التسلسلي بشدة من قياس الأداء. ينفذ Monad طبقة الإجماع غير المتزامنة ، وطبقة التنفيذ غير المتزامنة ، والتخزين غير المتزامن من خلال "التنفيذ غير المتزامن". تقليل وقت الحظر وزمن انتقال التأكيد بشكل كبير، مما يجعل النظام أكثر مرونة ومعالجة أكثر تجزئة واستخدام الموارد. التصميم الأساسي: عملية الإجماع (طبقة الإجماع) مسؤولة فقط عن ترتيب المعاملات ولا تنفذ منطق العقد. يتم تشغيل عملية التنفيذ (طبقة التنفيذ) بشكل غير متزامن بعد اكتمال الإجماع. بعد اكتمال الإجماع ، سيدخل في عملية الإجماع للكتلة التالية على الفور ، دون انتظار اكتمال التنفيذ. التنفيذ الموازي المتفائل: التنفيذ الموازي المتفائل تستخدم Ethereum التقليدية نموذجا تسلسليا صارما لتنفيذ المعاملات لتجنب تعارضات الدول. من ناحية أخرى ، تتبنى Monad استراتيجية "التنفيذ الموازي المتفائل" لزيادة سرعة معالجة المعاملات بشكل كبير. آلية الإنفاذ: ينفذ Monad جميع المعاملات بالتوازي بتفاؤل ، على افتراض أن معظمها ليس لديه تعارضات بين الحالة. قم أيضا بتشغيل "كاشف التعارض" لمراقبة ما إذا كان يتم الوصول إلى نفس الحالة (مثل تعارضات القراءة/الكتابة) بين المعاملات. إذا تم اكتشاف تعارض، يتم تسلسل المعاملة المتعارضة وإعادة تنفيذها للتأكد من صحة الحالة. اختارت Monad مسارا متوافقا: نقل أقل عدد ممكن من قواعد EVM ، لتحقيق التوازي عن طريق تأجيل حالة الكتابة والكشف الديناميكي عن التعارضات أثناء التنفيذ ، وهو أشبه بإصدار أداء Ethereum ، بمستوى نضج يجعل من السهل الانتقال إلى نظام EVM البيئي ، وهو مسرع مواز في عالم EVM. التحليل الحسابي المتوازي ل MegaETH يختلف عن وضع Monad L1 ، يتم وضع MegaETH كطبقة تنفيذ متوازية معيارية عالية الأداء متوافقة مع EVM ، والتي يمكن استخدامها كسلسلة عامة مستقلة L1 ، كطبقة تحسين تنفيذ أو مكون معياري على Ethereum. يتمثل هدف التصميم الأساسي في تفكيك منطق الحساب وبيئة التنفيذ وعزل الحالة إلى أصغر وحدة يمكن جدولتها بشكل مستقل لتحقيق تنفيذ عالي التزامن وقدرة استجابة بزمن انتقال منخفض داخل السلسلة. الابتكار الرئيسي الذي اقترحته MegaETH هو أن بنية Micro-VM + DAG لتبعية الحالة (الرسم البياني لتبعية الحالة الموجهة وغير الدورية) وآلية المزامنة المعيارية تبنيان بشكل مشترك نظام تنفيذ متوازي ل "الخيوط داخل السلسلة". بنية الجهاز الظاهري الصغير: الحسابات عبارة عن مؤشرات ترابط يقدم MegaETH نموذج التنفيذ ل "جهاز ظاهري صغير واحد لكل حساب"، والذي "يربط" بيئة التنفيذ ويوفر حدا أدنى من وحدة العزل للجدولة المتوازية. تتواصل هذه الأجهزة الظاهرية مع بعضها البعض من خلال المراسلة غير المتزامنة بدلا من المكالمات المتزامنة، ويمكن تنفيذ عدد كبير من الأجهزة الظاهرية بشكل مستقل وتخزينها بشكل مستقل وبشكل طبيعي متوازي. مجموعة جدول أعمال تبعية الحالة: آلية جدولة تستند إلى الرسم البياني قامت MegaETH ببناء نظام جدولة DAG بناء على علاقة الوصول إلى حالة الحساب ، ويحتفظ النظام برسم بياني للتبعية العالمية في الوقت الفعلي ، والحسابات التي يتم تعديلها والحسابات التي تتم قراءتها لكل معاملة يتم تصميمها جميعا في تبعيات. يمكن تنفيذ المعاملات الخالية من التعارض مباشرة بالتوازي ، وسيتم جدولة المعاملات التابعة وفرزها بشكل متسلسل أو تأجيل بترتيب طوبولوجي. تضمن الرسوم البيانية للتبعية تناسق الحالة وعمليات الكتابة غير المكررة أثناء التنفيذ المتوازي. التنفيذ غير المتزامن وآليات معاودة الاتصال تم بناء MegaETH على رأس نموذج البرمجة غير المتزامن ، على غرار الرسائل غير المتزامنة لنموذج الممثل ، والذي يحل مشكلة المكالمات التسلسلية التقليدية EVM. استدعاءات العقد غير متزامنة (تنفيذ غير متكرر) ، وعندما يتم استدعاء العقد A -> B -> C ، تكون كل مكالمة غير متزامنة دون منع الانتظار ؛ يتم توسيع مكدس المكالمات إلى رسم بياني للاستدعاء غير المتزامن. معالجة المعاملات = اجتياز الرسم البياني غير المتزامن + دقة التبعية + الجدولة المتوازية. بشكل عام ، يكسر MegaETH نموذج آلة الحالة أحادية الخيط EVM التقليدي ، وينفذ تغليف الجهاز الظاهري الصغير على أساس حساب على حدة ، ويقوم بجدولة المعاملات من خلال الرسوم البيانية المعتمدة على الحالة ، ويستبدل مكدس المكالمات المتزامن بآلية مراسلة غير متزامنة. إنها منصة حوسبة متوازية أعيد تصميمها من الأبعاد الكاملة ل "هيكل الحساب→ وبنية الجدولة ، وعملية التنفيذ →" ، مما يوفر فكرة جديدة على مستوى النموذج لبناء الجيل التالي من نظام عالي الأداء على السلسلة. اختارت MegaETH مسار إعادة الهيكلة: فهي تلخص الحسابات والعقود بالكامل في أجهزة ظاهرية مستقلة ، وتطلق العنان لإمكانات التوازي النهائية من خلال جدولة التنفيذ غير المتزامنة. من الناحية النظرية ، يحتوي MegaETH على سقف متوازي أعلى ، ولكن من الصعب أيضا التحكم في التعقيد ، وهو أشبه بنظام تشغيل فائق التوزيع بموجب مفهوم Ethereum. تختلف مفاهيم التصميم لكل من Monad و MegaETH تماما عن التجزئة: يقسم التجزئة أفقيا blockchain إلى سلاسل فرعية مستقلة متعددة (شظايا) ، وكل سلسلة فرعية مسؤولة عن جزء من المعاملات والحالات ، وكسر حد السلسلة الواحدة والتوسع في طبقة الشبكة. من ناحية أخرى ، يحافظ كل من Monad و MegaETH على سلامة السلسلة الفردية ، ويتوسع أفقيا فقط في طبقة التنفيذ ، ويؤديان اختراقات التحسين بالتوازي عند حدود السلسلة الواحدة. يمثل الاثنان اتجاهين: التعزيز الرأسي والتوسع الأفقي في مسار توسيع blockchain. تركز مشاريع الحوسبة المتوازية مثل Monad و MegaETH بشكل أساسي على مسار تحسين الإنتاجية ، مع الهدف الأساسي المتمثل في تحسين TPS على السلسلة ، وتحقيق المعالجة المتوازية على مستوى المعاملات أو على مستوى الحساب من خلال التنفيذ المؤجل وبنى الأجهزة الافتراضية الصغيرة. شبكة فاروس هي شبكة بلوكتشين L1 متوازية معيارية كاملة المكدس ، ويسمى نظام الحوسبة المتوازية الأساسي "Rollup Mesh". تدعم هذه البنية بيئات الأجهزة الافتراضية المتعددة (EVM و Wasm) من خلال تآزر الشبكة الرئيسية وشبكات المعالجة الخاصة (SPNs) ، وتدمج التقنيات المتقدمة مثل إثباتات المعرفة الصفرية (ZK) وبيئات التنفيذ الموثوقة (TEEs). تحليل الحوسبة المتوازية لشبكة الالتفاف: دورة الحياة الكاملة لخطوط الأنابيب غير المتزامنة: تقوم فاروس بفصل المراحل المختلفة للمعاملة (على سبيل المثال ، الإجماع والتنفيذ والتخزين) وتعتمد المعالجة غير المتزامنة بحيث يمكن تنفيذ كل مرحلة بشكل مستقل وبالتوازي ، وبالتالي تحسين كفاءة المعالجة الإجمالية. التنفيذ المتوازي للجهاز الظاهري المزدوج: يدعم Pharos كلا من بيئات الجهاز الظاهري EVM و WASM ، مما يسمح للمطورين باختيار بيئة التنفيذ المناسبة لاحتياجاتهم. لا تزيد بنية الجهاز الظاهري المزدوج هذه من مرونة النظام فحسب ، بل تزيد أيضا من معالجة المعاملات من خلال التنفيذ المتوازي. شبكات المعالجة الخاصة (SPNs): تعد شبكات المعالجة الخاصة مكونات رئيسية في بنية فاروس ، على غرار الشبكات الفرعية المعيارية المصممة للتعامل مع أنواع معينة من المهام أو التطبيقات. باستخدام SPNs ، يتيح Pharos التخصيص الديناميكي للموارد والمعالجة المتوازية للمهام ، مما يعزز قابلية التوسع وأداء النظام. الإجماع المعياري وإعادة التخزين: تقدم فاروس آلية إجماع مرنة تدعم نماذج إجماع متعددة (مثل PBFT و PoS و PoA) ، وتتيح المشاركة الآمنة وتكامل الموارد بين الشبكة الرئيسية و SPNs من خلال بروتوكول إعادة التخزين. بالإضافة إلى ذلك ، يعيد فاروس بناء نموذج التنفيذ من الطبقة السفلية من محرك التخزين من خلال شجرة Merkle متعددة الإصدارات ، وترميز Delta ، والعنونة الإصدارية ، وتقنية ADS Pushdown ، وتطلق متجر فاروس ، وهو محرك تخزين عالي الأداء لسلسلة الكتل الأصلية ، لتحقيق إنتاجية عالية وزمن انتقال منخفض وقدرات معالجة قوية يمكن التحقق منها على السلسلة. بشكل عام ، تحقق بنية Rollup Mesh من Paros قدرات حوسبة متوازية عالية الأداء من خلال التصميم المعياري وآلية المعالجة غير المتزامنة. بالإضافة إلى بنى التنفيذ المتوازي ل Monad و MegaETH و Pharos ، نلاحظ أيضا أن هناك بعض المشاريع في السوق التي تستكشف مسار تطبيق تسريع GPU في الحوسبة المتوازية EVM ، كمكمل مهم وتجربة متطورة للنظام البيئي الموازي EVM. من بينها ، Reddio و GatlingX هما اتجاهان تمثيليان: Reddio عبارة عن نظام أساسي عالي الأداء يجمع بين zkRollup وبنية التنفيذ المتوازي لوحدة معالجة الرسومات ، ويتمثل جوهرها في إعادة بناء عملية تنفيذ EVM لتحقيق التوازي الأصلي لطبقة التنفيذ من خلال الجدولة متعددة الخيوط ، وتخزين الحالة غير المتزامن ، والتنفيذ المتسارع لدفعات المعاملات بواسطة GPU. الدقة المتوازية على مستوى المعاملة + مستوى التشغيل (رمز التشغيل متعدد مؤشرات الترابط). إنه مصمم لتقديم تنفيذ الدفعات متعددة الخيوط ، وتحميل الحالة غير المتزامنة ، ومنطق معاملات المعالجة المتوازية لوحدة معالجة الرسومات (EVM المتوازي المتوافق مع CUDA). مثل Monad / MegaETH ، يركز Reddio أيضا على المعالجة المتوازية في طبقة التنفيذ ، مع الاختلاف في أنه يتم إعادة بناء محرك التنفيذ من خلال بنية متوازية لوحدة معالجة الرسومات ، مصممة لسيناريوهات عالية الإنتاجية وكثيفة الحوسبة مثل استدلال الذكاء الاصطناعي. في الوقت الحاضر ، تم إطلاق SDK ، وتم توفير وحدة تنفيذ متكاملة تطلق GatlingX على نفسها اسم "GPU-EVM" ، وتقترح بنية أكثر راديكالية تحاول ترحيل نموذج "التنفيذ التسلسلي على مستوى التعليمات" لأجهزة EVM الافتراضية التقليدية إلى بيئات وقت التشغيل المتوازية الأصلية لوحدة معالجة الرسومات. تتمثل الآلية الأساسية في تجميع الرمز الثانوي ل EVM ديناميكيا في مهام متوازية CUDA ، وتنفيذ دفق التعليمات من خلال وحدة معالجة الرسومات متعددة النواة ، وذلك لكسر عنق الزجاجة المتسلسل ل EVM عند أدنى مستوى. الدقة المتوازية التي تنتمي إلى التوازي على مستوى التعليمات (ILP). بالمقارنة مع الدقة المتوازية "على مستوى المعاملة / مستوى الحساب" ل Monad / MegaETH ، تنتمي آلية التوازي في GatlingX إلى مسار التحسين على مستوى التعليمات ، وهو أقرب إلى إعادة بناء التعليمات الأساسية لمحرك الجهاز الظاهري. إنه حاليا في مرحلة المفهوم ، مع نشر ورقة بيضاء ورسم معماري ، ولا يوجد SDK أو mainnet حتى الآن. يقترح Artela مفهوم تصميم متباين وموازي. مع إدخال الجهاز الظاهري WebAssembly (WASM) لبنية EVM ++ ، يسمح للمطورين بإضافة الامتدادات وتنفيذها ديناميكيا على السلسلة باستخدام نموذج برمجة Aspect مع الحفاظ على توافق EVM. يستخدم دقة استدعاء العقد (الوظيفة / الملحق) كوحدة متوازية دنيا ، ويدعم حقن وحدات التمديد (على غرار "البرامج الوسيطة القابلة للتوصيل") عند تشغيل عقد EVM ، وذلك لتحقيق الفصل المنطقي والاستدعاء غير المتزامن والتنفيذ المتوازي على مستوى الوحدة. يتم إيلاء المزيد من الاهتمام لقابلية التركيب والهندسة المعيارية لطبقة التنفيذ. يوفر المفهوم أفكارا جديدة للتطبيقات المعقدة متعددة الوحدات في المستقبل. 3. سلسلة البنية المتوازية الأصلية: إعادة بناء أنطولوجيا تنفيذ الأجهزة الظاهرية اعتمد نموذج تنفيذ EVM الخاص ب Ethereum بنية أحادية الخيط ل "أمر المعاملات الكامل + التنفيذ التسلسلي" منذ بداية تصميمه ، بهدف ضمان اليقين والاتساق في تغييرات الحالة لجميع العقد في الشبكة. ومع ذلك ، فإن هذه البنية لها عنق زجاجة طبيعي في الأداء ، مما يحد من إنتاجية النظام وقابلية التوسع. في المقابل ، تم تصميم سلاسل بنية الحوسبة المتوازية الأصلية مثل Solana (SVM) و MoveVM (Sui و Aptos) و Sei v2 المبنية على Cosmos SDK للتنفيذ المتوازي من الطبقة السفلية ، ولها المزايا التالية: الفصل الطبيعي لنماذج الحالة: يستخدم Solana آلية إعلان قفل الحساب، ويقدم MoveVM نموذج ملكية الكائن، وينفذ Sei v2 حكما ثابتا على التعارض استنادا إلى تصنيف نوع المعاملة ويدعم الجدولة المتزامنة على مستوى المعاملة. تم تحسين الأجهزة الافتراضية من أجل التزامن: يدعم محرك Solana Sealevel أصلا التنفيذ متعدد الخيوط. يمكن ل MoveVM إجراء تحليل الرسم البياني المتزامن الثابت. يدمج Sei v2 محرك مطابقة متعدد الخيوط مع وحدة VM متوازية. بالطبع ، يواجه هذا النوع من السلسلة المتوازية الأصلية أيضا تحدي التوافق البيئي. تتطلب البنى غير EVM عادة لغات تطوير جديدة (مثل Move وRust) وسلاسل أدوات، والتي لها تكاليف ترحيل معينة للمطورين. بالإضافة إلى ذلك ، يحتاج المطورون إلى إتقان سلسلة من المفاهيم الجديدة مثل نماذج الوصول ذات الحالة ، وحدود التزامن ، ودورات حياة الكائنات ، وما إلى ذلك ، والتي تطرح متطلبات أعلى لفهم العتبات ونماذج التطوير. 3.1 مبدأ المحرك موازية مستوى البحر من [سولنا] و [سفم] نموذج تنفيذ Sealevel الخاص ب Solana هو آلية جدولة متوازية للحساب ، وهو المحرك الأساسي الذي تستخدمه Solana لتحقيق تنفيذ المعاملات المتوازية داخل السلسلة ، ويحقق التزامن عالي الأداء على مستوى العقد الذكي من خلال آلية "إعلان الحساب + الجدولة الثابتة + التنفيذ متعدد الخيوط". Sealevel هو أول نموذج تنفيذ في مجال blockchain ينفذ بنجاح الجدولة المتزامنة داخل السلسلة في بيئة الإنتاج ، وقد أثرت أفكاره المعمارية على العديد من مشاريع الحوسبة المتوازية اللاحقة ، وهو نموذج مرجعي للتصميم المتوازي عالي الأداء من الطبقة 1. الميكانيكا الأساسية: 1. قوائم الوصول الصريح إلى الحساب: يجب أن تعلن كل معاملة عن الحساب المعني (قراءة / كتابة) عند الإرسال ، حتى يتمكن النظام من تحديد ما إذا كان هناك تعارض في الحالة بين المعاملات. 2. كشف التعارض والجدولة متعددة الخيوط إذا لم يكن هناك تداخل بين مجموعات الحسابات التي تم الوصول إليها من خلال المعاملتين → فيمكن تنفيذها بالتوازي. هناك تعارض→ يتم تنفيذها بشكل متسلسل بترتيب تابع. يقوم المجدول بتخصيص الحركات إلى مؤشرات ترابط مختلفة استنادا إلى الرسم البياني للتبعية. 3. سياق استدعاء البرنامج: يتم تشغيل كل استدعاء عقد في سياق معزول بدون مكدس مشترك لتجنب تداخل المكالمات المتقاطعة. Sealevel هو محرك جدولة التنفيذ المتوازي ل Solana ، بينما SVM هي بيئة تنفيذ عقود ذكية مبنية على مستوى البحر (باستخدام الجهاز الظاهري BPF). معا ، يشكلون الأساس التقني لنظام التنفيذ المتوازي عالي الأداء من Solana. Eclipse هو مشروع ينشر أجهزة Solana الظاهرية على سلاسل معيارية مثل Ethereum L2 أو Celestia، مستفيدا من محرك التنفيذ المتوازي ل Solana كطبقة تنفيذ القيمة المحتسبة. Eclipse هو أحد المشاريع الأولى التي اقترحت فصل طبقة تنفيذ Solana (Sealevel + SVM) عن شبكة Solana الرئيسية وترحيلها إلى بنية معيارية ، والإخراج المعياري ل "نموذج التنفيذ المتزامن الفائق" ل Solana هو طبقة التنفيذ كخدمة ، لذلك ينتمي Eclipse أيضا إلى فئة الحوسبة المتوازية. مسار نيون مختلف ، فهو يقدم EVM للعمل في بيئة SVM / Sealevel. قم ببناء طبقة وقت تشغيل متوافقة مع EVM ، يمكن للمطورين استخدام Solidity لتطوير العقود وتشغيلها في بيئة SVM ، لكن تنفيذ الجدولة يستخدم SVM + Sealeve. يميل Neon إلى فئة Modular Blockchain أكثر من ابتكار الحوسبة المتوازية. بشكل عام ، تعتمد Solana و SVMs على محرك تنفيذ Sealevel ، وتتشابه فلسفة الجدولة المستندة إلى نظام التشغيل في Solana مع جدولة kernel ، وهي سريعة ولكنها غير مرنة نسبيا. إنها سلسلة عامة أصلية عالية الأداء ومتوازية للحوسبة. 3.2 بنية MoveVM: المستندة إلى الموارد والكائنات MoveVM هو جهاز افتراضي ذكي مصمم لأمان الموارد على السلسلة والتنفيذ المتوازي ، وقد تم تطوير لغته الأساسية ، Move ، في الأصل بواسطة Meta (Facebook سابقا) لمشروع Libra ، مع التركيز على مفهوم "الموارد كائنات" ، وجميع الحالات على السلسلة موجودة ككائنات ، مع ملكية واضحة ودورات حياة. يتيح ذلك ل MoveVM تحليل ما إذا كانت هناك تعارضات في الحالة بين المعاملات أثناء وقت التحويل البرمجي، وتنفيذ جدولة متوازية ثابتة على مستوى الكائن، والتي تستخدم على نطاق واسع في السلاسل العامة المتوازية الأصلية مثل Sui و Aptos. نموذج ملكية الكائنات في Sui تنبع قدرات الحوسبة المتوازية في Sui من نهجها الفريد لنمذجة الحالة والتحليل الثابت على مستوى اللغة. على عكس سلاسل الكتل التقليدية ، التي تستخدم أشجار الحالة العالمية ، قامت Sui ببناء نموذج يركز على الكائنات يعتمد على "الكائن" ، والذي يعمل مع نظام النوع الخطي ل MoveVM لجعل الجدولة المتوازية عملية حتمية يمكن إكمالها في وقت الترجمة. نموذج الكائن هو أساس الهندسة المعمارية المتوازية ل Sui. تقوم Sui بتلخيص كل الحالة على السلسلة إلى كائنات منفصلة ، لكل منها معرف فريد ومالك واضح (حساب أو عقد) وتعريف نوع. لا تشترك هذه الكائنات في الحالة مع بعضها البعض وهي معزولة بطبيعتها. يجب أن يعلن العقد صراحة عن مجموعة الكائنات المعنية عند استدعاؤه ، وتجنب مشكلة اقتران الحالة ل "شجرة الحالة العالمية" التقليدية على السلسلة. يقسم هذا التصميم الحالة على السلسلة إلى عدة وحدات مستقلة ، مما يجعل التنفيذ المتزامن فرضية جدولة مجدية من الناحية الهيكلية. تحليل الملكية الثابتة هو آلية تحليل وقت التحويل البرمجي يتم تنفيذها بدعم من نظام النوع الخطي للغة Move. يسمح للنظام بجدولة المعاملات التي سيتم تنفيذها بالتوازي عن طريق استنتاج المعاملات التي لا تحتوي على تعارضات في الحالة من خلال ملكية الكائن قبل تنفيذها. بالمقارنة مع اكتشاف التعارض والتراجع عن أوقات التشغيل التقليدية ، تقلل آلية التحليل الثابت من Sui بشكل كبير من تعقيد الجدولة مع تحسين كفاءة التنفيذ ، وهو المفتاح لتحقيق إنتاجية عالية وقدرات معالجة متوازية حتمية. يقسم Sui مساحة الحالة على أساس كل كائن على حدة ، جنبا إلى جنب مع تحليل ملكية وقت التحويل البرمجي ، لتحقيق تنفيذ متوازي منخفض التكلفة وخالي من التراجع على مستوى الكائن. بالمقارنة مع التنفيذ التسلسلي أو الكشف عن وقت التشغيل للسلاسل التقليدية ، حققت Sui تحسينات كبيرة في كفاءة التنفيذ وحتمية النظام واستخدام الموارد. آلية إنفاذ Block-STM الخاصة ب Aptos Aptos عبارة عن blockchain من الطبقة 1 عالية الأداء تعتمد على لغة Move ، وتستمد قدرتها على التنفيذ المتوازي بشكل أساسي من إطار عمل Block-STM (ذاكرة معاملات البرامج على مستوى الكتل) المطور ذاتيا. على عكس استراتيجية Sui المتمثلة في "التوازي الثابت في وقت الترجمة" ، ينتمي Block-STM إلى آلية الجدولة الديناميكية المتمثلة في "التزامن المتفائل في وقت التشغيل + التراجع عن الصراع" ، وهو مناسب للتعامل مع مجموعات المعاملات ذات التبعيات المعقدة. يقسم Block-STM تنفيذ المعاملات في الكتلة إلى ثلاث مراحل: تنفيذ المضاربة: جميع المعاملات خالية من التعارضات بشكل افتراضي قبل التنفيذ، ويقوم النظام بجدولة المعاملات إلى مؤشرات ترابط متعددة لمحاولات التنفيذ المتزامنة، ويسجل حالة الحساب (مجموعة القراءة/الكتابة) التي يتم الوصول إليها من قبلهم. مرحلة التحقق من الصحة: يتحقق النظام من نتيجة التنفيذ: إذا كان هناك تعارض في القراءة والكتابة بين معاملتين (على سبيل المثال ، يقرأ Tx1 حالة الكتابة بواسطة Tx2) ، التراجع عن إحداهما. مرحلة إعادة المحاولة: ستتم إعادة جدولة الحركات المتعارضة حتى يتم حل تبعياتها، وفي النهاية تشكل جميع الحركات تسلسلا صالحا وحتميا لعمليات إرسال الحالة. Block-STM هو نموذج تنفيذ ديناميكي ل "التوازي المتفائل + التراجع والمحاولة" ، وهو مناسب لسيناريوهات معالجة دفعات المعاملات كثيفة الحالة والمعقدة منطقيا على السلسلة ، وهو جوهر الحوسبة المتوازي ل Aptos لبناء سلسلة عامة عالية التنوع وعالية الإنتاجية. Solana هي مدرسة جدولة هندسية ، تشبه إلى حد كبير "نواة نظام التشغيل" ، ومناسبة لحدود الدولة الواضحة ، والتداول عالي التردد الذي يمكن التحكم فيه ، وهو أسلوب مهندس أجهزة ، والذي يجب أن يدير السلسلة مثل الأجهزة (التنفيذ المتوازي على مستوى الأجهزة) ؛ Aptos هو نظام متسامح مع أخطاء النظام ، أشبه ب "محرك تزامن قاعدة البيانات" ، وهو مناسب لأنظمة العقود ذات اقتران الحالة القوي وسلاسل المكالمات المعقدة. يشبه Aptos و Sui مهندسي لغة البرمجة ، ويمثل أمان الموارد على مستوى البرامج مسار التنفيذ التقني للحوسبة المتوازية Web3 في ظل فلسفات مختلفة. 3.3 الامتداد المتوازي ل Cosmos SDK Sei V2 هي سلسلة معاملات عامة عالية الأداء تم إنشاؤها بناء على Cosmos SDK ، وتنعكس قدرتها على التوازي بشكل أساسي في جانبين: محرك المطابقة متعدد الخيوط (محرك المطابقة المتوازي) وتحسين التنفيذ المتوازي لطبقة الجهاز الظاهري ، بهدف خدمة سيناريوهات المعاملات عالية التردد وزمن الوصول المنخفض على السلسلة ، مثل DEXs دفتر الطلبات ، والبنية التحتية للتبادل على السلسلة ، وما إلى ذلك. الآلية الموازية الأساسية: محرك المطابقة المتوازي: يقدم SEI V2 مسار تنفيذ متعدد الخيوط في منطق مطابقة الأوامر ، وتقسيم دفتر الأوامر المعلق ومنطق المطابقة على مستوى مؤشر الترابط ، بحيث يمكن معالجة مهام المطابقة بين أزواج التداول المتعددة بالتوازي وتجنب الاختناقات أحادية الخيط. تحسين التزامن على مستوى الجهاز الظاهري: يقوم Sei V2 ببناء بيئة وقت تشغيل CosmWasm مع إمكانات تنفيذ متزامنة، مما يسمح لبعض استدعاءات العقود بالعمل بالتوازي دون تعارضات في الحالة، ويتعاون مع آلية تصنيف نوع المعاملة لتحقيق تحكم أعلى في معدل النقل. الإجماع الموازي وجدولة طبقة التنفيذ: يتم تقديم ما يسمى بآلية الإجماع "Twin-Turbo" لتعزيز الإنتاجية والفصل بين طبقة الإجماع وطبقة التنفيذ ، وتحسين الكفاءة الإجمالية لمعالجة الكتلة. 3.4 وقود مصلح نموذج UTXO الوقود عبارة عن طبقة تنفيذ عالية الأداء مصممة بناء على بنية Ethereum المعيارية ، وتوازيها الأساسي مشتق من نموذج UTXO المحسن (إخراج المعاملات غير المنفقة). على عكس نموذج حساب Ethereum ، يستخدم Fuel هيكل UTXO لتمثيل الأصول والحالات ، وهو بطبيعته معزول عن الحالة ، مما يجعل من السهل تحديد المعاملات التي يمكن تنفيذها بأمان بالتوازي. بالإضافة إلى ذلك ، تقدم Fuel لغة العقود الذكية المطورة ذاتيا Sway (على غرار Rust) ، جنبا إلى جنب مع أدوات التحليل الثابتة ، لتحديد تعارضات المدخلات قبل تنفيذ المعاملات ، وذلك لتحقيق جدولة متوازية فعالة وآمنة على مستوى المعاملات. إنها طبقة تنفيذ بديلة EVM توازن بين الأداء والنمطية. 4. نموذج الممثل: نموذج جديد للتنفيذ المتزامن للوكلاء نموذج الممثل هو نموذج تنفيذ متوازي يعتمد على الوكيل أو العملية ، والذي يختلف عن الحساب المتزامن التقليدي للحالة العالمية على السلسلة (Solana / Sui / Monad وسيناريوهات "الحوسبة المتوازية على السلسلة") ، والتي تؤكد أن كل وكيل له حالة وسلوك مستقل ، ويتواصل ويجدول من خلال الرسائل غير المتزامنة. في ظل هذه البنية ، يمكن تشغيل النظام على السلسلة بشكل متزامن من خلال عدد كبير من العمليات المنفصلة عن بعضها البعض ، ولديها قابلية توسع قوية وتسامح غير متزامن مع الأخطاء. تشمل المشاريع التمثيلية AO (Arweave AO) و ICP (كمبيوتر الإنترنت) و Cartesi ، والتي تقود تطور blockchain من محرك تنفيذ إلى "نظام تشغيل على السلسلة" ، مما يوفر بنية تحتية أصلية لوكلاء الذكاء الاصطناعي ، والتفاعلات متعددة المهام ، والتنسيق المنطقي المعقد. في حين أن تصميم نموذج الممثل يشبه التجزئة من حيث الخصائص السطحية (على سبيل المثال ، التوازي ، وعزل الحالة ، والمعالجة غير المتزامنة) ، فإن الاثنين يمثلان بشكل أساسي مسارات تقنية وفلسفات نظام مختلفة تماما. يؤكد نموذج الممثل على "الحوسبة غير المتزامنة متعددة العمليات" ، حيث يعمل كل وكيل بشكل مستقل ، ويحافظ على الحالة بشكل مستقل ، ويتفاعل بطريقة تعتمد على الرسالة. من ناحية أخرى ، فإن التجزئة هي آلية "التجزئة الأفقية للحالة والإجماع" ، والتي تقسم blockchain بأكملها إلى أنظمة فرعية متعددة (شظايا) تعالج المعاملات بشكل مستقل. تشبه نماذج الممثل إلى حد كبير "نظام تشغيل الوكيل الموزع" في عالم Web3 ، في حين أن التجزئة هي حل توسيع هيكلي لإمكانيات معالجة المعاملات على السلسلة. كلاهما يحقق التوازي ، ولكن لهما نقاط انطلاق وأهداف وبنى تنفيذ مختلفة. 4.1 AO (Arweave) ، كمبيوتر فائق الموازي أعلى طبقة التخزين AO عبارة عن منصة حوسبة لامركزية تعمل على طبقة التخزين الثابتة من Arweave، بهدف أساسي يتمثل في بناء نظام تشغيل على السلسلة يدعم تشغيل الوكيل غير المتزامن على نطاق واسع. ميزات الهندسة المعمارية الأساسية: بنية العملية: يطلق على كل عامل عملية، مع حالة مستقلة ومجدول مستقل ومنطق تنفيذ. لا يوجد هيكل blockchain: AO ليست سلسلة ، ولكنها طبقة تخزين لامركزية + محرك تنفيذ متعدد الوكلاء يعتمد على الرسائل يعتمد على Arweave. نظام جدولة الرسائل غير المتزامنة: تتواصل العمليات مع بعضها البعض من خلال الرسائل ، وتعتمد نموذج تشغيل غير متزامن خال من القفل ، وتدعم بشكل طبيعي التوسع المتزامن. تخزين الحالة الدائمة: يتم تسجيل جميع حالات الوكيل وسجلات الرسائل والتعليمات بشكل دائم على Arweave، مما يضمن قابلية التدقيق الكاملة والشفافية اللامركزية. الوكيل الأصلي: إنه مناسب لنشر المهام المعقدة متعددة الخطوات (مثل وكلاء الذكاء الاصطناعي ، ووحدات التحكم في بروتوكول DePIN ، ومنسقي المهام التلقائيين ، وما إلى ذلك) ، ويمكنه بناء "معالج الذكاء الاصطناعي المساعد على السلسلة". يأخذ AO المسار النهائي ل "الوكيل الأصلي + سائق التخزين + الهندسة المعمارية بدون سلسلة" ، مع التركيز على المرونة وفصل الوحدة النمطية ، وهو "إطار عمل microkernel على السلسلة المبني أعلى طبقة التخزين" ، مع تقلص حدود النظام عمدا ، مع التركيز على الحوسبة خفيفة الوزن + هيكل التحكم القابل للتكوين. 4.2 ICP (كمبيوتر الإنترنت) ، منصة استضافة Web3 كاملة المكدس ICP عبارة عن منصة تطبيقات مكدس كامل على السلسلة أصلية من Web3 أطلقتها DFINITY ، بهدف توسيع قوة الحوسبة على السلسلة لتشمل تجارب شبيهة ب Web2 ، ودعم استضافة الخدمة الكاملة ، وربط اسم المجال ، والهندسة المعمارية بدون خادم. ميزات الهندسة المعمارية الأساسية: بنية العلبة (الحاويات كوكلاء): كل علبة هي عامل يعمل على جهاز Wasm الظاهري مع حالة مستقلة وتعليمات برمجية وإمكانيات جدولة غير متزامنة. نظام الإجماع الموزع للشبكة الفرعية (الشبكة الفرعية): تتكون الشبكة بأكملها من شبكات فرعية متعددة ، كل منها يحتفظ بمجموعة من العلب ويصل إلى توافق في الآراء من خلال آلية توقيع BLS. نموذج الاستدعاء غير المتزامن: يتصل Canister ب Canister من خلال رسائل غير متزامنة ، ويدعم التنفيذ غير المحظور ، وله توازي طبيعي. استضافة الويب على السلسلة: يدعم العقود الذكية لاستضافة صفحات الواجهة الأمامية مباشرة ، ورسم خرائط DNS الأصلي ، وهو أول منصة blockchain تدعم المتصفحات للوصول مباشرة إلى dApps ؛ يحتوي النظام على وظائف كاملة: يحتوي على واجهات برمجة تطبيقات للنظام مثل الترقية الساخنة على السلسلة ، ومصادقة الهوية ، والعشوائية الموزعة ، والمؤقت ، وهو مناسب لنشر الخدمة المعقدة على السلسلة. يختار برنامج المقارنات الدولية نموذجا لنظام التشغيل للنظام الأساسي الثقيل ، والتغليف المتكامل ، والتحكم القوي في النظام الأساسي ، ولديه "نظام تشغيل blockchain" يدمج الإجماع والتنفيذ والتخزين والوصول ، مع التركيز على قدرات استضافة الخدمة الكاملة ، وتوسيع حدود النظام إلى منصة استضافة Web3 كاملة. بالإضافة إلى ذلك ، يمكن العثور على مشاريع الحساب المتوازي لنماذج نموذج الممثل الأخرى في الجدول التالي: 5. الملخص والتوقعات بناء على الاختلافات بين بنية الجهاز الظاهري ونظام اللغة ، يمكن تقسيم حلول الحوسبة المتوازية blockchain تقريبا إلى فئتين: سلسلة التحسين المتوازية EVM وسلسلة الهندسة المعمارية المتوازية الأصلية (غير EVM). على أساس الحفاظ على توافق النظام البيئي EVM / Solidity ، يحقق الأول إنتاجية أعلى وقدرات معالجة متوازية من خلال التحسين المتعمق لطبقة التنفيذ ، وهو مناسب للسيناريوهات التي ترغب في وراثة أصول Ethereum وأدوات التطوير وتحقيق اختراقات في الأداء في نفس الوقت. تشمل المشاريع التمثيلية ما يلي: Monad: تنفيذ نموذج تنفيذ متوازي متفائل متوافق مع EVM من خلال الكشف عن تعارض الكتابة ووقت التشغيل المؤجل ، وإنشاء الرسوم البيانية للتبعية بعد اكتمال الإجماع ، وجدولة التنفيذ في مؤشرات ترابط متعددة. MegaETH: يلخص كل حساب/عقد في جهاز ظاهري صغير مستقل، وينفذ جدولة متوازية منفصلة للغاية على مستوى الحساب استنادا إلى الرسائل غير المتزامنة والرسوم البيانية المعتمدة على الحالة. Pharos: قم بإنشاء بنية شبكة القيمة المحتسبة لتحقيق معالجة متوازية على مستوى النظام عبر العمليات من خلال خطوط الأنابيب غير المتزامنة ووحدات SPN. Reddio: يستخدم بنية zkRollup + GPU لتسريع عملية التحقق خارج السلسلة ل zkEVM من خلال توليد SNARK الدفعي وتحسين إنتاجية التحقق. يتخلص هذا الأخير تماما من قيود توافق Ethereum ويعيد تصميم نموذج التنفيذ من الجهاز الظاهري ونموذج الحالة وآلية الجدولة لتحقيق التزامن الأصلي عالي الأداء. تشمل الفئات الفرعية النموذجية ما يلي: Solana (SVM): استنادا إلى مطالبات الوصول إلى الحساب وجدولة الرسم البياني للتعارض الثابت، فإنه يمثل نموذج تنفيذ متوازي على مستوى الحساب. Sui / Aptos (نظام MoveVM): استنادا إلى نموذج كائن المورد ونظام النوع ، فإنه يدعم التحليل الثابت في وقت التحويل البرمجي ويحقق التوازي على مستوى الكائن. Sei V2 (مسار Cosmos SDK): يقدم محرك مطابقة متعدد الخيوط وتحسين التزامن للجهاز الظاهري في بنية Cosmos، وهو مناسب لتطبيقات المعاملات عالية التردد. الوقود (بنية UTXO + Sway): التوازي على مستوى المعاملة من خلال التحليل الثابت لمجموعة مدخلات UTXO ، والجمع بين طبقة التنفيذ المعيارية ولغة العقد الذكية المخصصة Sway ؛ بالإضافة إلى ذلك، كنظام متوازي أكثر عمومية، يبني نموذج الممثل نموذج تنفيذ على السلسلة من "عملية مستقلة متعددة الوكلاء + تعاون قائم على الرسائل" من خلال آلية جدولة عملية غير متزامنة تستند إلى Wasm أو الأجهزة الظاهرية المخصصة. تشمل المشاريع التمثيلية ما يلي: AO (Arweave AO): يبني نظام microkernel غير متزامن على السلسلة استنادا إلى وقت تشغيل العامل القائم على التخزين المستمر. ICP (كمبيوتر الإنترنت): يستخدم العامل المعبأ في حاويات (Canister) كأصغر وحدة لتحقيق تنفيذ غير متزامن وقابل للتطوير بدرجة كبيرة من خلال تنسيق الشبكة الفرعية. Cartesi: يقدم نظام التشغيل Linux كبيئة حوسبة خارج السلسلة لتوفير مسار تحقق على السلسلة لنتائج الحوسبة الموثوقة ، ومناسبة لسيناريوهات التطبيقات المعقدة أو كثيفة الاستخدام للموارد. بناء على المنطق أعلاه ، يمكننا تلخيص مخطط السلسلة العامة للحوسبة المتوازية السائدة الحالية في هيكل تصنيف كما هو موضح في الشكل التالي: من منظور توسيع نطاق أوسع ، يركز التجزئة والالتجميعية (L2) على القياس الأفقي من خلال تجزئة الحالة أو التنفيذ خارج السلسلة ، بينما تقوم سلاسل الحوسبة المتوازية (على سبيل المثال ، Monad و Sui و Solana) والأنظمة الموجهة للجهات الفاعلة (على سبيل المثال ، AO ، ICP) بإعادة بناء نموذج التنفيذ مباشرة وتحقيق التوازي الأصلي داخل السلسلة أو في طبقة النظام. الأول يحسن الإنتاجية داخل السلسلة من خلال الأجهزة الافتراضية متعددة الخيوط ، ونماذج الكائنات ، وتحليل تعارض المعاملات ، وما إلى ذلك ؛ يأخذ الأخير العملية / الوكيل كوحدة أساسية ويعتمد أوضاع التنفيذ غير المتزامنة التي تعتمد على الرسائل لتحقيق عملية متزامنة متعددة الوكلاء في المقابل ، فإن التجزئة واللفات تشبه إلى حد كبير "تقسيم الحمل إلى سلاسل متعددة" أو "الاستعانة بمصادر خارجية خارج السلسلة" ، في حين أن نموذج السلسلة المتوازية والممثل "يطلق العنان لإمكانات الأداء من محرك التنفيذ نفسه" ، مما يعكس تطورا معماريا أكثر شمولا. الحوسبة المتوازية مقابل هندسة التجزئة مقابل تحجيم التجميع مقابل مقارنة مسار التحجيم الموجه للممثل وتجدر الإشارة إلى أن معظم سلاسل الهندسة المعمارية المتوازية الأصلية قد دخلت مرحلة إطلاق الشبكة الرئيسية ، على الرغم من أنه لا يزال من الصعب مقارنة النظام البيئي العام للمطورين بنظام Solidity لنظام EVM ، لكن المشاريع التي يمثلها Solana و Sui ، ببنية التنفيذ عالية الأداء والازدهار التدريجي للتطبيقات البيئية ، أصبحت السلاسل العامة الأساسية التي يولي السوق اهتماما كبيرا لها. في المقابل ، على الرغم من أن النظام البيئي Ethereum Rollup (L2) قد دخل مرحلة "10,000 سلسلة في وقت واحد" أو حتى "السعة الزائدة" ، إلا أن سلسلة التحسين المتوازية الحالية ل EVM السائدة لا تزال في مرحلة شبكة الاختبار بشكل عام ، ولم يتم التحقق منها بعد من قبل بيئة الشبكة الرئيسية الفعلية ، ولا تزال قدرتها على التوسع واستقرار النظام بحاجة إلى مزيد من الاختبار. يبقى أن نرى ما إذا كانت هذه المشاريع يمكن أن تحسن بشكل كبير أداء EVM وتقود قفزات بيئية دون التضحية بالتوافق ، أو ما إذا كان بإمكانها زيادة التمييز بين السيولة وموارد التنمية في Ethereum.

أحب أن أرى لقاءات مجتمع Permabites تنمو!