يجلب Eclipse وقت التشغيل الموازي لـ Solana إلى Ethereum

لقد تقاربت غالبية مجموعات Ethereum في نموذج واحد، حيث لا يزال EVM هو محرك التنفيذ. لذلك يظل التنفيذ الموازي طموحًا غامضًا وليس سمة من سمات معظم Ethereum L2s. الكسوف يأخذ مسارا مختلفا. إنه يجلب جهاز Solana الظاهري إلى بيئة ترتكز على Ethereum ويعيد هيكلة المجموعة المجمعة حوله.

يبحث أحدث تقرير صادر عن Cointelegraph Research كيفية ظهور هذا التصميم والمشكلات التي يحلها والأسئلة التي يثيرها للنظام البيئي الأوسع للطبقة الثانية. إنه يسلط الضوء على أين يختلف Eclipse عن المجموعات الحالية وسبب أهمية هذه الاختلافات للمطورين والمستخدمين والمؤسسات.

اقرأ التقرير الكامل هنا لاستكشاف بنية Eclipse واقتصادياته والمسار نحو حالة القيمة المجمعة التي يمكن التحقق منها.

لماذا Eclipse ليس مجرد “L2 آخر”

يقدم SVM التوازي الحتمي في المشهد التراكمي لـ Ethereum. بدلاً من التنافس على نفس قائمة الانتظار العالمية، يمكن للتطبيقات العمل في مسارات منفصلة. ويؤثر هذا على التحكم في الازدحام وأسواق الرسوم وكيفية قياس الأداء على مستوى النظام في فترات النشاط المرتفع.

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

يعكس التصميم أيضًا تراجع Eclipse المتعمد عن نموذج Rollups-as-a-Service الفائق الوحدات الذي اتبعوه لأول مرة. بدلاً من تقديم العشرات من التكوينات، قام Eclipse بإصلاح بنيته. يتتبع تقريرنا المسار من تجارب Eclipse الأصلية مع Polygon SVM وCascade إلى شبكة مشتركة واحدة يتم تنفيذها على SVM، وتستقر على Ethereum وتنشر البيانات إلى Celestia.

نظام إثبات بديل

يستخدم Eclipse أدلة احتيال ZK المعجلة والمدعومة بـ RISC Zero. في معظم التقارير المتفائلة، تتكشف الخلافات من خلال الألعاب التفاعلية متعددة الجولات التي تعيد تشغيل أجزاء من التنفيذ على إيثريوم. بدلاً من ذلك، يقوم Eclipse بتغليف الحسابات المتنازع عليها في دليل واحد موجز، والذي يمكن تقديمه عند ظهور تحدي. يؤدي هذا إلى تقصير عملية النزاع وتجنب إعادة بناء الحالات الوسيطة على الإيثيريوم.

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

المعلم التالي: التحرك نحو المرحلة الثانية

يستهدف Eclipse علنًا تصنيف المرحلة 2 الخاص بـ L2BEAT، والذي يتطلب أدلة احتيال غير مرخصة وقواعد ترقية صارمة ونافذة خروج واضحة للمستخدمين. يتناول تقريرنا الفجوة بين التصميم الحالي وهذه المتطلبات الفنية. ويوضح أيضًا سبب إدراج Eclipse حاليًا في فئة “أخرى” بواسطة L2BEAT وما هي الخطوات اللازمة ليتم التعرف عليه كمجموعة كاملة من Ethereum.

إحدى الترقية الأخيرة لتحقيق هذه الغاية هي النظام الفرعي لتحدي توفر البيانات ZK، والذي يتحقق من التزامات Celestia على Ethereum بتكلفة يمكن التنبؤ بها. إنه يحسن متطلبات توفر البيانات التي يمكن التحقق منها لأنه يسمح لعقود Ethereum الذكية بالتحقق من التزامات Celestia بدلاً من الثقة بها ضمنيًا. وعلى الرغم من أهميته، إلا أن هذا وحده لا يكفي لتلبية متطلبات المرحلة 0.

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

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

هذه المقالة هي لأغراض المعلومات العامة وليس المقصود منها ولا ينبغي أن تؤخذ على أنها نصيحة قانونية أو استثمارية. الآراء والأفكار والآراء الواردة هنا هي آراء المؤلف وحده ولا تعكس بالضرورة أو تمثل وجهات نظر وآراء Cointelegraph.

لا يؤيد Cointelegraph محتوى هذه المقالة ولا أي منتج مذكور هنا. يجب على القراء إجراء أبحاثهم الخاصة قبل اتخاذ أي إجراء يتعلق بأي منتج أو شركة مذكورة وتحمل المسؤولية الكاملة عن قراراتهم.