تقديم إكليبس مينيت: شبكة إيثريوم SVM L2

Eclipse Mainnet عبارة عن L2 للأغراض العامة يجمع بين أفضل قطع المكدس المعياري:

1. التسوية: إيثريوم - ستستقر إكليبس على إيثريوم (أي أن جسر التحقق المكرس سيكون على إيثريوم) وستستخدم إيثريوم كرمز للغاز.
2. التنفيذ: آلة سولانا الافتراضية (SVM) - ستقوم Eclipse بتشغيل SVM عالية الأداء كبيئة التنفيذ الخاصة بها.
3. توفر البيانات: ستقوم Celestia - Eclipse بنشر بياناتها إلى Celestia لتوافر البيانات القابلة للتطوير (DA).
4. الإثبات: RISC Zero - سيستخدم Eclipse RISC Zero لأدلة ZK للاحتيال (بدون تسلسل الحالة الوسيطة!)

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

غالبًا ما يتم تقديم ثنائية خاطئة بين الرؤية التجميعية المعيارية مقابل القدرة على الحصول على سلسلة واحدة ذات نطاق واسع وتنفيذ متوازي وحالة مشتركة. غالبًا ما يتم الخلط بين «Modular» و «الخاصة بالتطبيق»، مما قد يقودك إلى الاعتقاد بأن عمليات التجميع تعني عالمًا من العديد من السلاسل المجزأة ومنخفضة الإنتاجية. نحن نتحدى هذه الفكرة.

التنفيذ: مقياس سولانا للسرعة &

سوف تتبنى Eclipse Mainnet بيئة التنفيذ الأفضل في فئتها في Solana. هذا يجلب مزايا هائلة:

التنفيذ المتوازي الأمثل

من المعروف أن SVM ووقت تشغيل Sealevel الخاص به يتيحان تنفيذ المعاملات الموازية. يمكن تنفيذ المعاملات التي لا تلمس حالة التداخل بالتوازي وليس بالتتابع.

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

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

أسواق الرسوم المحلية

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

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

هناك أيضًا بحث مبكر جار من شأنه أن يسمح للتطبيقات باستيعاب القيمة المحلية المنسوبة إليها بسهولة، والتي تتطلب اليوم عمومًا تصميمًا أكثر إبداعًا على مستوى التطبيق.

إدارة نمو الدولة

قبل أن تصطدم EVM حتى بالتنفيذ المتسلسل باعتباره عقبة، فإن نمو الدولة هو العقبة الأكثر إلحاحًا.

نظرًا لعدم وجود شجرة Merkle للحالة، لا يتحمل Solana عبء تحديث شجرة Merkle لكل تحديث للحالة. بدلاً من ذلك، بعد كل حقبة (حوالي 2.5 يوم)، يتم دمج الدولة بأكملها. هذا أرخص بكثير من المتوسط في الوقت الفعلي (كما هو الحال في EVM).

والأهم من ذلك، تتمتع EVM بوصول ديناميكي إلى الحساب (أي أن المعاملات يمكن أن تمس أي حالة عند الطلب). يعني بحث الحالة الديناميكي هذا أنه لا يمكن تحميل الحالة في الذاكرة قبل التنفيذ. في SVM، تحدد كل معاملة كل الحالة المطلوبة للتنفيذ.

ونتيجة لذلك، لا يؤثر حجم الحالة على تنفيذ SVM. يمكن للشبكة مضاعفة حجم اللقطة بأمان كل عامين دون التعرض لمشكلات كبيرة على افتراض قيام المدققين بترقية أقراص التخزين الخاصة بهم كل عامين.

علاوة على ذلك، تعمل فرق مثل Helius بنشاط على تحسين إمكانية الوصول إلى البيانات التاريخية وتقليل حجم الحالة بالضغط.

التوافق مع EVM

Neon EVM عبارة عن EVM تعمل كعقد ذكي يمكن نشره على أي سلسلة SVM. يؤدي هذا إلى توافق EVM الكامل مع Eclipse Mainnet (بما في ذلك دعم الرمز الثانوي لـ EVM و Ethereum JSON-RPC) مع إنتاجية أكبر من وحدات EVM أحادية الخيط. نظرًا لأن كل مثيل من Neon EVM له سوق رسوم محلي خاص به، يمكن للتطبيقات فقط نشر عقدها الخاص لتحقيق فوائد سلسلة التطبيقات دون تجزئة تجربة المستخدم أو الأمان أو السيولة.

بشكل منفصل، يتيح مترجم Solang تجميع كود عقود Solidity الذكية في كود SVM الثانوي.

لقطات ميتا ماسك

لطالما كان إلحاق مستخدمي EVM بالسلاسل غير التابعة لـ EVM عقبة رئيسية، ولكن من المقرر أن تكسر Metamask Snaps التي تم الكشف عنها مؤخرًا هذا الحاجز. يمكن لمستخدمي EVM الاستمرار في استخدام MetaMask دون الحاجة إلى تبديل المحافظ. يمكن مقارنة UX بالتفاعل مع أي سلسلة EVM، وذلك بفضل مساهمات Driftمفتوحة المصدر في إنشاء تطبيق MetaMask Snap الرائع. سيتمكن مستخدمو Eclipse Mainnet من التفاعل مع التطبيقات محليًا في MetaMask أو استخدام محفظة Solana الأصلية مثل Salmon.

إليك نظرة خاطفة على UX من Drift:

فاير دانسر

Firedancer هو عميل Solana المرتقب للغاية الذي طورته Jump لزيادة إنتاجية الشبكة ومرونتها وكفاءتها بشكل كبير. عند الإطلاق، سنلتزم بأكبر قدر ممكن بعميل Solana الأساسي، لكننا نخطط لاعتماد Firedancer بمجرد أن تصبح الشفرة حية ومستقرة.

الأمان

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

إثبات أسهل

يعتمد SVM على التسجيل ولديه مجموعة تعليمات أصغر بكثير مقابل EVM، مما يجعل تنفيذ SVM أسهل في الإثبات في ZK. بالنسبة للمجموعات المتفائلة، يتيح التصميم المستند إلى السجل إمكانية التحقق بشكل أسهل.

التسوية: السيولة & لأمن إيثريوم

كما هو الحال مع المجموعات الرئيسية اليوم، ستستقر Eclipse Mainnet على إيثريوم. وبشكل ملموس، هذا يعني أن جسر التحقق الخاص بنا على إيثريوم سيتم تكريسه مباشرة في Eclipse. ستنظر عُقد الكسوف إلى هذا الجسر لتحديد «السلسلة الأساسية». يفرض الجسر الترتيب الصحيح لـ Eclipse.

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

نظرًا لخصائص الأمان هذه، غالبًا ما يشار إلى الفاليديوم والأعلى باسم «Ethereum L2s ». تُعرّف L2BEAT L2 بأنها «سلسلة تستمد أمنها كليًا أو جزئيًا من الطبقة الأولى من إيثريوم بحيث لا يضطر المستخدمون إلى الاعتماد على صدق مدققي L2 لأمان أموالهم.»

تدرك تسوية إيثريوم الأهمية التي من المرجح أن تلعبها أصول إيثريوم الأصلية في اقتصادات DeFi وNFT التابعة لشركة Eclipse Mainnet. ETH هي أفضل الأموال اللامركزية التي يفضلها معظم المستخدمين بوضوح، لذلك سنستخدم أيضًا ETH كرمز للغاز الخاص بنا. على المدى الطويل، سيمكن سحب الرسوم المستخدمين من الدفع بأي رمز من اختيارهم (على سبيل المثال، USDC). لا توجد خطط للحصول على رمز Eclipse Mainnet الخاص بها في الوقت الحالي.

توفر البيانات: إمكانية التحقق من النطاق الترددي لـ Celestia &

ستستخدم Eclipse Mainnet سيليستيا لتوافر البيانات (المعروفة أيضًا باسم. نشر البيانات أو نشر البيانات). كانت Celestia شريكًا طويل الأمد للنظام البيئي لـ Eclipse.

للأسف، لا يتم دعم الإنتاجية والرسوم المستهدفة لـ Eclipse Mainnet بواسطة النطاق الترددي الحالي لإيثريوم. وسيظل هذا الأمر كذلك حتى بعد EIP-4844 (المعروف أيضًا باسم. «Proto-Danksharding»)، والذي يوفر متوسط مساحة نقطية تبلغ حوالي 0.375 ميجابايت لكل كتلة (بحد أقصى 0.75 ميجابايت تقريبًا لكل كتلة).

1. بالنسبة لعمليات نقل ERC-20 ذات الضغط الأساسي (حوالي 154 بايت لكل معاملة)، يُترجم هذا إلى ~ 213 TPS عبر جميع عمليات التجميع مجتمعة.
2. بالنسبة للمقايضات ذات الضغط (حوالي 400 بايت لكل معاملة)، يُترجم هذا إلى ~ 82 TPS عبر جميع عمليات التجميع المجمعة.

وبالمقارنة، سيتم إطلاق Celestia بكتل بحجم 2 ميجابايت في وقت لاحق من هذا العام. من المتوقع أن تزداد مساحة Blobspace إلى 8 ميغابايت بعد وقت قصير من الإطلاق، بمجرد ظهور عدد كافٍ من العقد الضوئية لأخذ عينات من البيانات (DAS) عبر الإنترنت وإثبات استقرار الشبكة. تخدم العقد الضوئية DAS وظيفتين مهمتين:

1. تمكين المستخدمين من التحقق بأنفسهم من إتاحة بيانات كتلة Eclipse
2. ساهم في توسيع نطاق الشبكة بالكامل بشكل آمن، حيث يمكن لطبقات DA زيادة إنتاجيتها بأمان مع ظهور المزيد من العقد الضوئية DAS عبر الإنترنت

من المتوقع أن تكون Celestia أول طبقة DA يتم إطلاقها مع DAS في الإنتاج. وهذا يتناقض مع لجان إتاحة البيانات التقليدية (DACs)، التي تعيد تقديم افتراضات أمانة اللجان دون التحقق من المستخدم (على غرار سلاسل الكتل المتجانسة الحالية).

هناك افتراض أمني متأصل للمستخدمين الذين يقومون بجسر أموالهم من Ethereum Mainnet إلى أي سلسلة تستخدم offchain DA. وعلى وجه الخصوص، من الممكن تقنيًا لمدققي Celestia حجب بيانات المعاملات ولكنهم يدعون لجسر إيثريوم أن البيانات متاحة. من الناحية العملية، فإن إجماع سيليستيا على إثبات الحصة يعني أن حجب البيانات عن سيليستيا نفسها أمر قابل للتخفيض، مما يجعل هذا الخطر غير واقعي من وجهة نظرنا.

بشكل عام، فإن دعم عقدة DAS الخفيفة من Celestia منذ اليوم الأول، وخصائص الأمان الاقتصادي المشفر، وإنتاجية DA القابلة للتطوير بدرجة كبيرة تجعلها الخيار الواضح لـ Eclipse Mainnet اليوم.

لاحظ أن البعض ينظر إلى Onchain Ethereum DA كشرط ليكون «L2" حقيقيًا هنا للأسباب الموضحة أعلاه. نحن نتبع مصطلحات L2 الأكثر شيوعًا التي تم الاستشهاد بها سابقًا، ونريد أن نكون واضحًا بشأن الاعتبارات الأمنية.

ونعتزم أيضًا مراقبة تقدم إيثريوم في توسيع نطاق DA بعد EIP-4844. يستمر البحث الجديد المثير في الظهور، ومن المحتمل أن يقدم DA عالي الإنتاجية في وقت أقرب من الأفكار السابقة (التي تستخدم جداول التجزئة الموزعة الأكثر تقدمًا). إذا كانت إيثريوم تقدم نطاقًا أكبر لـ Eclipse لصالح مستخدمينا، فسنقوم بتقييم إمكانية الترحيل إلى Ethereum DA.

إثبات: أدلة RISC Zero ZK للاحتيال (بدون تسلسل الحالة الوسيطة!)

سيبدو إثباتنا مشابهًا لبراهين الاحتيال الخاصة بـ SVM من Anatoly SIMD، والتي تشبه في حد ذاتها رؤية جون أدلر بأن التسلسل الحكومي مكلف، ومن الممكن تجنبه.

على وجه التحديد، نريد تجنب إعادة إدخال شجرة Merkle إلى SVM. لقد جربنا إدخال Sparse Merkle Tree في SVM في وقت مبكر، ولكن تحديث شجرة Merkle بعد كل معاملة يؤدي إلى نتائج كبيرة في الأداء. إن الإثبات بدون شجرة Merkle يستبعد أطر التجميع العامة الحالية مثل OP Stack كأساس لمجموعات SVM، ويتطلب أيضًا بنية أكثر إبداعًا لمقاومة الأخطاء.

على مستوى عالٍ، يتطلب إثبات الخطأ ما يلي:

1. الالتزام بالمدخلات للمعاملة،
2. المعاملة نفسها، و
3. دليل على أن إعادة تنفيذ المعاملة تؤدي إلى مخرجات مختلفة عما تم تحديده على السلسلة.

عادةً ما يتم الالتزام بالإدخال من خلال توفير جذر Merkle لشجرة حالة التجميع. بدلاً من ذلك، سيقوم المنفذ الخاص بنا بنشر قائمة بالمدخلات والمخرجات (بما في ذلك تجزئات الحساب والحالة العالمية ذات الصلة) لكل معاملة، إلى جانب فهرس المعاملة التي أنتجت كل إدخال. ويتم نشر المعاملات إلى Celestia، بحيث يمكن لأي عقدة كاملة المتابعة لسحب حسابات الإدخال من حالتها الخاصة، وحساب حسابات المخرجات، وتأكيد صحة الالتزام على إيثريوم.

هناك نوعان محتملان من الأخطاء الرئيسية:

1. مخرجات غير صحيحة - في هذه الحالة، يوفر المدقق دليل ZK على سلسلة المخرجات الصحيحة. نحن نستخدم RISC Zero لإنشاء براهين ZK لتنفيذ SVM، ونواصل عملنا السابق لإثبات تنفيذ كود BPF الثانوي. وهذا يسمح لعقد التسوية الخاص بنا بضمان صحته دون الحاجة إلى تشغيل المعاملات نفسها على السلسلة.
2. مدخلات غير صحيحة - في هذه الحالة، ينشر المدقق على السلسلة مرجعًا للبيانات التاريخية يوضح أن حالة الإدخال ليست كما يُزعم. باستخدام جسر الجاذبية الكمومية من Celestia، يضمن عقد التسوية الخاص بنا أن هذه البيانات التاريخية تثبت بالفعل الاحتيال.

لماذا إكليبس، لماذا إيثريوم، لماذا الآن

نحن نقف على أكتاف العمالقة. لقد أدت عمليات تجميع البيانات اليوم إلى تطوير حالة البحث في صناعتنا بأكملها، وقد زودت مستخدمي إيثريوم برسوم أرخص مقارنة بـ L1.

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

1. أجهزة افتراضية متوازية عالية الأداء (مثل SVM)
2. تحجيم DA مع دعم عقدة DAS الخفيفة (على سبيل المثال، Celestia)
3. التقدم في البنية التحتية للإثبات لجعلها عملية في أي مكان (على سبيل المثال، RISC Zero)
4. زيادة قابلية نقل التعليمات البرمجية (على سبيل المثال، Neon و Solang) والمستخدمين (على سبيل المثال، MetaMask Snaps) عبر النظم البيئية

يتمتع Eclipse بفائدة كبيرة تتمثل في الإدراك المتأخر. نتعلم من القيود التي واجهتها السلاسل الأخرى ثم نختار أفضل القطع لتوسيع نطاقها على المدى الطويل.

https://twitter.com/0xMert؟ ref_src=twsrc%5Etfw%7Ctcamp%5Etweetembed%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwgr 7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2fme7bxlwjds177v6nl8j1uzf1mxpx6nbgolneybawxgs%5E1680271128537726976%

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctcamp%5Etweetembed%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwgr 7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2fme7bxlwjds177v6nl8j1uzf1mxpx6nbgolneybawxgs%5E1680285353662468097%

غالبًا ما نسمع عن المستقبل مع مليون مجموعة خاصة بالتطبيقات.

يمكن أن تكون التخصيصات على مستوى الإجماع ذات قيمة كبيرة لتطبيقات معينة (على سبيل المثال، DydX v4)، ونحن متحمسون لمساعدة الفرق في إطلاق مجموعات خاصة بالتطبيقات.

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

حتى لو كان الطلب الحقيقي موجودًا، فإن البنية التحتية المطلوبة لدعم العديد من سلاسل التطبيقات ذات تجربة المستخدم التنافسية لا تزال على بعد سنوات (إذا وصلت إلى المستوى المطلوب). تحتوي سلسلة Optimism الفائقة (OP Stack)، وسلاسل Hyperchains الخاصة بـ ZKSync (ZK Stack)، وسلاسل Arbitrum Orbit، وما إلى ذلك على رؤى متعددة السلاسل مع بنية تحتية مشتركة. يهدف هذا إلى توفير تجربة مستخدم أكثر سلاسة بين السلاسل في نفس النظام البيئي (على سبيل المثال، بين سلسلتين داخل Superchain) مقابل السلاسل المعزولة تمامًا (على سبيل المثال، بين Ethereum و Solana).

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

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

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

ينشأ هذا المفهوم الخاطئ بسبب حقيقة أن مجموعات البيانات الحالية تعمل إلى حد كبير على تشغيل EVM أحادي الخيط من الفانيليا بشكل فعال دون تغيير من أجل الاستفادة من تأثيرات الشبكة المبكرة. ونتيجة لذلك، غالبًا ما نرى «مساحة الكتل المخصصة» التي يُشار إليها كسبب لنشر مجموعة خاصة بالتطبيق. لا ينبغي أن تؤدي منتجات NFT Mint المجنونة هذه إلى رفع أسعار جميع التطبيقات الأخرى في سلسلتك، ولكن الإجابة ليست إنشاء سلسلتك الخاصة. هذا مثل استخدام مطرقة ثقيلة لكسر الفول السوداني. يمكنك إجراء مقايضات مؤلمة وغير ضرورية (التعقيد والتكلفة وتجربة المستخدم الأسوأ والسيولة المجزأة وما إلى ذلك). الحل الأمثل واضح للغاية - ما عليك سوى استخدام جهاز افتراضي متوازي مع أسواق الرسوم المحلية للنقاط الساخنة الحكومية. هذا هو بالضبط ما تجلبه SVM.

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

نعتقد أن Eclipse Mainnet هو الحل الواضح: توحيد أداء Solana مع الأمان وإمكانية التحقق وتأثيرات الشبكة لخارطة الطريق المتمحورة حول التجميع.

أفكار الفراق

يكمن جمال الإيثيريوم في أنها تأكل الابتكار. إن خارطة الطريق التي تركز على التجميع هي مثال على ذلك، حيث تقوم بتفويض التنفيذ والابتكار إلى السوق الحرة. تتمتع L2s بقدرة مذهلة على الاستفادة من تأثيرات شبكة Ethereum وضمانات التسوية أثناء تجربة أفضل بيئات التنفيذ الجديدة. Eclipse Mainnet هو الإنجاز الطبيعي لهذه الرؤية.

إذا ظهرت طبقة تنفيذ أكثر أداءً في يوم من الأيام، فسنكون متحمسين للغاية لرؤيتها منتشرة باعتبارها طبقة إيثريوم L2 تنافسية. حتى ذلك الحين، تظل SVM هي المعيار.

للمشاركة، تواصل معنا على < a href= "http://mailto:team@eclipse.builders/" " > team@eclipse.builders للحصول على تعليمات testnet.

إخلاء المسؤولية：

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