Eclipse Mainnet هي طبقة عالمية ثانية تجمع بين أفضل أجزاء البنية المعيارية:
طبقة التسوية: Ethereum - سوف يستقر Eclipse مع Ethereum (أي سيكون جسر التحقق على Ethereum) ويستخدم ETH كرمز غاز خاص به.
طبقة التنفيذ: Solana Virtual Machine (SVM) - سيقوم Eclipse بتشغيل SVM عالي الأداء كبيئة تنفيذ خاصة به.
توفر البيانات: ستقوم Celestia - Eclipse بنشر بياناتها إلى Celestia لتوفير البيانات القابلة للتطوير (DA).
الإثبات: RISC Zero - سيستخدم Eclipse RISC Zero لإثباتات الاحتيال ذات المعرفة الصفرية (دون الحاجة إلى تسلسل الحالة المتوسطة!)
كانت معظم النقاط البارزة في Eclipse تدور حول نشر مجموعات خاصة بالتطبيقات لمشاريع مختلفة، ولكن من الواضح الآن أكثر من أي وقت مضى أن Ethereum يحتاج إلى طبقة 2 عالمية يمكنها تحقيق نطاق حقيقي. لن تستفيد معظم التطبيقات من تخصيص السلاسل الخاصة بالتطبيقات، وقد يؤدي العزل والتعقيد الناتجان في الواقع إلى تجربة أسوأ للمستخدم والمطور.
غالبًا ما يكون هناك انقسام زائف بين رؤية المجموعات المعيارية والقدرة على الحصول على سلسلة واحدة ذات مقياس ضخم وتنفيذ متوازي وحالة مشتركة. غالبًا ما يتم الخلط بين "معياري" و"خاص بالتطبيقات"، مما يقود المرء إلى الاعتقاد بأن التجميع يعني عالمًا يضم العديد من السلاسل المجزأة ومنخفضة الإنتاجية.
طبقة التنفيذ: سرعة وحجم سولانا
ستستخدم 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 هو عقد ذكي لـ Ethereum Virtual Machine يمكن نشره على أي سلسلة SVM. وهذا يجلب التوافق الكامل لـ EVM (بما في ذلك دعم EVM bytecode وEthereum JSON-RPC) إلى Eclipse Mainnet، مع إنتاجية أكبر من EVM أحادي الترابط. نظرًا لأن كل مثيل Neon EVM له سوق رسوم أصلي خاص به، يمكن للتطبيقات ببساطة نشر عقودها الخاصة لجني فوائد سلسلة التطبيقات دون تعطيل تجربة المستخدم أو الأمان أو السيولة.
بالإضافة إلى ذلك، يمكن لمترجم Solang تجميع كود عقد Solidity الذكي في كود SVM الثانوي.
لقطات MetaMask
تاريخيًا، كان توجيه مستخدمي EVM لاستخدام سلاسل غير تابعة لـ EVM عائقًا كبيرًا، ولكن MetaMask Snaps التي تم الإعلان عنها مؤخرًا ستكسر هذا الحاجز. يمكن لمستخدمي EVM الاستمرار في استخدام MetaMask دون تبديل المحافظ. بفضل مساهمات Drift مفتوحة المصدر في إنشاء تطبيق MetaMask Snaps الرائع، فإن التجربة تشبه التفاعل مع أي سلسلة EVM. سيتمكن مستخدمو Eclipse Mainnet من التفاعل مع التطبيقات الأصلية في MetaMask أو استخدام محافظ Solana الأصلية مثل Salmon.
الراقص الناري
Firedancer هو عميل Solana المرتقب والذي تم تطويره بواسطة Jump وهو مصمم لتحسين إنتاجية الشبكة ومرونتها وكفاءتها بشكل كبير. عند الإطلاق، سنبقى على مقربة من عميل Solana الأساسي قدر الإمكان، ولكننا نخطط لاعتماد Firedancer بمجرد أن يصبح الكود نشطًا ومستقرًا.
أمان
يعمل Solana بمساحة هجوم منخفضة بشكل كبير، مما يمنع هجمات إعادة الدخول التي رأيناها مرات عديدة. على وجه التحديد، يسمح وقت تشغيل Solana فقط بالتكرار الذاتي للبرنامج ولا يسمح بالمكالمات العشوائية عبر البرامج. بالإضافة إلى ذلك، يؤدي الفصل بين الحالة والتعليمات البرمجية إلى إنشاء تعليمات برمجية عديمة الحالة، والتي يسهل اختبارها بشكل فعال بشكل عام.
إثبات أبسط
يعتمد SVM على التسجيل ومجموعة التعليمات أصغر بكثير من EVM، مما يجعل إثبات تنفيذ SVM أسهل في ZK. بالنسبة لعمليات التجميع المتفائلة، يسمح التصميم القائم على السجل بإجراء عمليات فحص أبسط.
طبقة التسوية: الأمان والسيولة على الإيثيريوم
مثل التحديث الرئيسي اليوم، سيتم تسوية Eclipse Mainnet مع Ethereum. على وجه التحديد، هذا يعني أن جسر التحقق الخاص بنا على Ethereum سيتم دمجه مباشرة في Eclipse. ستنظر عقدة Eclipse إلى هذا الجسر لتحديد "السلسلة الأساسية". يفرض هذا الجسر الترتيب الصحيح لـ Eclipse.
يتيح ذلك لمستخدمينا الحصول على خصائص أمان معينة من Ethereum. سيقوم الجسر بالتحقق من صحة جميع معاملات Eclipse ويمنع الالتزام بالحالات غير الصالحة. بالإضافة إلى ذلك، فإنه سيتم فرض الحيوية النهائية ومقاومة الرقابة في بعض حالات الفشل. حتى إذا توقف طلب L2 عن العمل أو بدأ في فرض الرقابة، فسيتمكن المستخدمون من فرض إدراج معاملاتهم عبر الجسر.
نظرًا لخصائص الأمان هذه، غالبًا ما يُشار إلى المكتبات الصالحة والمثالية باسم "Ethereum L2". تُعرّف L2BEAT L2 بأنها "سلسلة تستمد أمانها كليًا أو جزئيًا من طبقة Ethereum Layer 1 بحيث لا يحتاج المستخدمون إلى الاعتماد على صدق مدققي L2 للحفاظ على أموالهم آمنة."
تعكس تسوية Ethereum أهمية أصول Ethereum المحلية في اقتصادات DeFi وNFT الخاصة بـ Eclipse Mainnet. ETH هي العملة اللامركزية المفضلة لدى معظم المستخدمين، لذلك سنستخدم ETH أيضًا كرمز الغاز الخاص بنا. على المدى الطويل، سيمكن تجريد الرسوم المستخدمين من الدفع بأي رمز من اختيارهم (مثل USDC). حاليًا، ليس لدى Eclipse Mainnet أي خطط لإصدار الرموز المميزة الخاصة بها.
توفر البيانات: عرض النطاق الترددي لـ Celestia وإمكانية التحقق منه
سوف يستخدم Eclipse Mainnet Celestia لتوفير البيانات (المعروف أيضًا باسم نشر البيانات أو نشر البيانات). لقد كانت Celestia شريكًا طويل الأمد للنظام البيئي لـ Eclipse.
لسوء الحظ، فإن الإنتاجية والرسوم المستهدفة لـ Eclipse Mainnet غير مدعومة من خلال قيود النطاق الترددي الحالية لـ Ethereum. وينطبق هذا حتى بعد EIP-4844 (المعروف أيضًا باسم "Proto-danksharding")، والذي يوفر ~0.375 ميجابايت من مساحة blobspace لكل كتلة (مع حد لكل كتلة يبلغ ~0.75 ميجابايت).
بالنسبة لعمليات نقل ERC-20 ذات الضغط الأساسي (حوالي 154 بايت لكل معاملة)، فإن هذا يعادل ~213 TPS لجميع عمليات التجميع.
بالنسبة للتبادلات المضغوطة (~ 400 بايت لكل معاملة)، فإن هذا يعادل ~ 82 TPS كلها مجمعة.
وبالمقارنة، ستطلق سيليستيا كتل بحجم 2 ميجابايت بحلول نهاية هذا العام. بمجرد وصول ما يكفي من العقد الخفيفة لأخذ عينات توفر البيانات (DAS) عبر الإنترنت وإثبات استقرار الشبكة، فمن المتوقع أن تزيد مساحة النقطة إلى 8 ميجابايت بعد وقت قصير من الإطلاق. تخدم العقدة الضوئية DAS وظيفتين رئيسيتين:
تمكين المستخدمين من التحقق بأنفسهم من توفر بيانات كتلة Eclipse؛
يساعد على توسيع نطاق الشبكة بالكامل بأمان لأنه مع وصول المزيد من العقد الضوئية DAS عبر الإنترنت، يمكن لطبقة DA زيادة إنتاجيتها بأمان.
من المتوقع أن تكون Celestia هي أول طبقة DA لتمكين DAS في الإنتاج. وهذا على النقيض من لجان توافر البيانات التقليدية (DACs)، التي تعيد تقديم افتراض صدق اللجنة دون التحقق من المستخدم (على غرار سلاسل الكتل المتجانسة الحالية).
هناك افتراضات أمنية متأصلة للمستخدمين الذين يقومون بتوصيل الأموال من شبكة Ethereum الرئيسية إلى أي سلسلة تستخدم DA خارج السلسلة. على وجه الخصوص، يمكن لمدققي Celestia رفض بيانات المعاملة من الناحية الفنية ولكنهم يزعمون أن البيانات متاحة على جسر Ethereum. في الواقع، إن إجماع سيليستيا على إثبات المصلحة يعني أن حجب البيانات من قبل سيليستيا نفسها يعاقب عليه، مما يجعلنا نعتقد أن هذا الخطر غير واقعي.
بشكل عام، فإن دعم عقدة DAS الخفيفة من Celestia، وخصائص أمان الاقتصاد المشفر، وإنتاجية DA القابلة للتطوير بشكل كبير من اليوم الأول، يجعلها الخيار الواضح لـ Eclipse Mainnet اليوم.
نعتزم أيضًا مراقبة تقدم Ethereum في توسيع نطاق DA بعد EIP-4844. تظهر أبحاث جديدة مثيرة قد توفر DA عالي الإنتاجية في وقت أبكر مما كان يُعتقد سابقًا (الأخير يستخدم جداول التجزئة الموزعة الأكثر تقدمًا). إذا وفرت Ethereum نطاقًا أكبر لمستخدمينا، فسنقوم بتقييم إمكانية الانتقال إلى Ethereum DA.
الدليل: إثبات الاحتيال RISC Zero ZK (لا يلزم إجراء تسلسل للحالة المتوسطة!)
سيكون دليلنا مشابهًا لإثبات احتيال SVM الخاص بـ Anatoly SIMD، والذي يشبه في حد ذاته رؤية جون أدلر بأن تسلسل الحالة مكلف وأنه يمكن تجنبه.
على وجه التحديد، نريد تجنب إعادة تقديم أشجار Merkle في SVM. لقد حاولنا إدراج شجرة Merkle متفرقة بعد كل معاملة في SVM، ولكن تحديث شجرة Merkle أدى إلى خسارة كبيرة في الأداء. يؤدي عدم استخدام أشجار Merkle إلى استبعاد أطر العمل المجمعة ذات الأغراض العامة الحالية (مثل مكدس OP) كأساس لمجموعة SVM، ويتطلب أيضًا تصميمات أكثر إبداعًا مقاومة للفشل.
باختصار، يتطلب إثبات الفشل ما يلي:
الالتزام بإدخال المعاملة،
المعاملة نفسها، و
إثبات أن إعادة تنفيذ المعاملة ينتج عنها مخرجات مختلفة عن تلك المحددة في السلسلة.
يتم عادةً تحقيق التزامات الإدخال من خلال توفير جذر Merkle لشجرة الحالة المجمعة. سيقوم منفذنا بنشر قائمة المدخلات والمخرجات (بما في ذلك تجزئات الحساب والحالة العالمية المرتبطة بها) لكل معاملة، بالإضافة إلى فهرس المعاملة التي أنتجت كل مدخلات. يتم نشر المعاملات على Celestia، بحيث يمكن لأي عقدة كاملة استخراج الحساب ذاتيًا في حالته الخاصة، وحساب حساب الإخراج، والتأكد من صحة الالتزام على Ethereum.
هناك نوعان رئيسيان من حالات الفشل المحتملة:
خطأ في الإخراج - في هذه الحالة، يوفر المدقق دليلاً على المعرفة الصفرية على السلسلة للإخراج الصحيح لتنفيذ SVM. نحن نستخدم RISC Zero لإنشاء دليل المعرفة الصفرية لتنفيذ SVM، وهو استمرار لإثباتنا السابق لتنفيذ كود BPF الثانوي. وهذا يسمح لعقد التسوية الخاص بنا بالتأكد من صحته دون الحاجة إلى تشغيل هذه المعاملات على السلسلة نفسها.
إدخال غير صالح - في هذه الحالة، ينشر المدقق مرجعًا للبيانات التاريخية الموجودة على السلسلة، مما يوضح أن حالة الإدخال لا تتطابق مع ما تمت المطالبة به. باستخدام جسر الجاذبية الكمي الخاص بشركة سيليستيا، يضمن عقد التسوية الخاص بنا أن هذه البيانات التاريخية تثبت الاحتيال بالفعل.
نحن نقف على أكتاف العمالقة. لقد أدى العرض المجمع اليوم إلى تطوير حالة البحث عبر صناعتنا ويوفر لمستخدمي Ethereum رسومًا أقل من L1.
ومع ذلك، فإنها لا تستفيد استفادة كاملة من أحدث التقنيات التي تتطلب نطاقًا واسعًا. لقد أدت التطورات الحديثة المذهلة إلى القضاء على الحاجة إلى إجراء هذه المقايضات التي قامت بها عمليات التجميع السابقة، مما يضعها فعليًا في وضع غير مؤات:
جهاز افتراضي متوازي عالي الأداء (مثل SVM)؛
امتداد DA مع دعم عقدة DAS الخفيفة (مثل Celestia)؛
التقدم في البنية التحتية للإثبات الذي يجعله عمليًا في كل مكان (مثل RISC Zero)؛
تحسين إمكانية النقل عبر الأنظمة البيئية للتعليمات البرمجية (مثل Neon وSolang) والمستخدمين (مثل MetaMask Snaps)
يمكننا أن نتعلم من القيود التي تواجهها السلاسل الأخرى ونختار أفضل الأجزاء للتوسع على المدى الطويل.
كثيرًا ما نسمع الحديث عن مليون مجموعة مجمعة خاصة بالتطبيقات في المستقبل.
يمكن أن يكون التخصيص على مستوى الإجماع ذا قيمة كبيرة لتطبيقات معينة (مثل dYdX v4)، ويسعدنا مساعدة الفريق في إطلاق مجموعات البيانات الخاصة بالتطبيقات.
ومع ذلك، فإن هذه الحالات نادرة. هذا هو السبب في أن معظم المجموعات الجديدة لا تزال مجرد شوكات EVM عادية. لن يتم حل مشكلات المطورين عن طريق تجزئة تجربة المستخدم عبر المزيد من السلاسل. غالبًا ما يبدو أن حالة الاستخدام الرئيسية الموجودة لملايين السلاسل اليوم هي مجرد إطلاق المزيد من العملات المعدنية. بالنسبة للغالبية العظمى من حالات الاستخدام، لا توجد حاجة اليوم إلى التخصيص الكامل لمكدس التكنولوجيا.
حتى في حالة وجود طلب حقيقي، فإن البنية التحتية المطلوبة لدعم العديد من سلاسل التطبيقات ذات تجربة المستخدم التنافسية لن تكون موجودة لسنوات (إن وجدت). تتمتع كل من سلسلة Optimism's Superchain (OP stack)، وZkSync's Hyperchains (ZK stack)، وسلسلة Orbit الخاصة بـ Arbitrum، وما إلى ذلك برؤية العديد من السلاسل ذات البنية التحتية المشتركة. يهدف هذا إلى توفير تجربة مستخدم أكثر سلاسة لعمليات interchain داخل نفس النظام البيئي (على سبيل المثال، بين سلسلتين داخل Superchain)، بدلاً من السلاسل المنعزلة تمامًا (على سبيل المثال، بين Ethereum و Solana).
ومع ذلك، فإن الخطط الحالية (إذا كانت موجودة) بعيدة كل البعد عن الوعد بالتنافس مع دولة مشتركة واحدة. بالإضافة إلى ذلك، فهي لا تعالج مشكلات قابلية التشغيل البيني عبر الأنظمة البيئية (على سبيل المثال، من Superchain إلى Hyperchain). لا ينبغي أن يعني بناء الوحدات النمطية بناء الصوامع.
يعد الأمر أكثر تعقيدًا بالنسبة للمستخدمين للاحتفاظ بحسابات في العديد من السلاسل. يعد عبور السلاسل باستمرار والقلق بشأن رموز الغاز المطلوبة تجربة مستخدم أسوأ. إن الاعتماد على موفري البنية التحتية لتشغيل وصيانة العديد من السلاسل يعد أيضًا أكثر تعقيدًا وتكلفة.
لقد أعجبنا دائماً بساطة رؤية سولانا. جهاز حالة مشترك محسّن للغاية مع مقياس لدعم حالات الاستخدام الأكثر قيمة. غالبًا ما يُنظر إلى هذا على أنه غير متوافق مع خرائط الطريق التي تركز على القيمة المجمعة، لكن الأمر ليس كذلك في الواقع. أردنا الجمع بين أفضل ما في العالمين.
يرجع سوء الفهم هذا إلى حقيقة أن المجموعات الحالية تعمل إلى حد كبير على تشغيل EVM الأصلي أحادي الترابط، والذي ظل دون تغيير إلى حد كبير للاستفادة من تأثيرات الشبكة المبكرة. لذلك، غالبًا ما نرى "مساحة الكتلة الخاصة" مذكورة كسبب لنشر مجموعات البيانات الخاصة بالتطبيقات. لا ينبغي أن ترتفع أسعار التطبيقات الأخرى في سلسلتك بسبب بعض عمليات سك NFT المجنونة، ولكن الحل ليس بناء سلسلتك الخاصة. أنت تقوم بمقايضات مؤلمة وغير ضرورية (التعقيد، والتكلفة، وتجربة المستخدم الأسوأ، والسيولة المجزأة، وما إلى ذلك). الحل الأفضل واضح - ما عليك سوى استخدام جهاز افتراضي متوازي مع سوق رسوم أصلي لنقاط الاتصال الحكومية. هذا هو بالضبط ما يجلبه SVM.
Ethereum هو المركز الفكري والاجتماعي والاقتصادي للعملات المشفرة. لقد كان كعب أخيل دائمًا هو التوسع. لا يزال توسيع نطاق توفر البيانات قيد التنفيذ، ولا يمكن لبيئات تنفيذ L2 الحالية التنافس مع الابتكارات الأحدث مثل SVMs. نحن قلقون من أنه إذا استمر الوضع الراهن اليوم، فسوف يتفاجأ النظام البيئي للإيثريوم في حالة حدوث أي زيادة كبيرة في النشاط. يمكن أن تؤدي أجهزة EVM أحادية الترابط ومحدودية توافر البيانات بسرعة إلى ظهور التكاليف المرتفعة مرة أخرى، ولكن هذه المرة فقط في عمليات التجميع.
نحن نعتقد أن Eclipse Mainnet هو الحل الواضح: الجمع بين أداء Solana مع الأمان وإمكانية التحقق وتأثيرات الشبكة لخارطة طريق تتمحور حول مجموعة التحديثات.
خاتمة
يكمن جمال Ethereum في أنه يبتكر باستمرار. تجسد خرائط الطريق المرتكزة على مجموعة التحديثات هذا الأمر، حيث تقوم بتفويض التنفيذ والابتكار إلى السوق الحرة. يتمتع L2 بقدرة خارقة على الاستفادة من تأثيرات شبكة Ethereum وضمانات التسوية أثناء تجربة أفضل بيئات التنفيذ الجديدة. يعد Eclipse Mainnet تنفيذًا طبيعيًا لهذه الرؤية.
إذا ظهرت طبقة تنفيذ ذات أداء أعلى يومًا ما، فسنكون متحمسين جدًا لرؤيتها منتشرة باعتبارها Ethereum L2 تنافسية. وحتى ذلك الحين، يظل SVM هو المعيار.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
Eclipse Mainnet: طبقة معيارية ثانية مع أمان Ethereum وسرعة Solana التي تعتمد على نقاط قوة الآخرين
بقلم : الخسوف
تم إعداده بواسطة: Deep Wave TechFlow
Eclipse Mainnet هي طبقة عالمية ثانية تجمع بين أفضل أجزاء البنية المعيارية:
كانت معظم النقاط البارزة في Eclipse تدور حول نشر مجموعات خاصة بالتطبيقات لمشاريع مختلفة، ولكن من الواضح الآن أكثر من أي وقت مضى أن Ethereum يحتاج إلى طبقة 2 عالمية يمكنها تحقيق نطاق حقيقي. لن تستفيد معظم التطبيقات من تخصيص السلاسل الخاصة بالتطبيقات، وقد يؤدي العزل والتعقيد الناتجان في الواقع إلى تجربة أسوأ للمستخدم والمطور.
غالبًا ما يكون هناك انقسام زائف بين رؤية المجموعات المعيارية والقدرة على الحصول على سلسلة واحدة ذات مقياس ضخم وتنفيذ متوازي وحالة مشتركة. غالبًا ما يتم الخلط بين "معياري" و"خاص بالتطبيقات"، مما يقود المرء إلى الاعتقاد بأن التجميع يعني عالمًا يضم العديد من السلاسل المجزأة ومنخفضة الإنتاجية.
طبقة التنفيذ: سرعة وحجم سولانا
ستستخدم 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 هو عقد ذكي لـ Ethereum Virtual Machine يمكن نشره على أي سلسلة SVM. وهذا يجلب التوافق الكامل لـ EVM (بما في ذلك دعم EVM bytecode وEthereum JSON-RPC) إلى Eclipse Mainnet، مع إنتاجية أكبر من EVM أحادي الترابط. نظرًا لأن كل مثيل Neon EVM له سوق رسوم أصلي خاص به، يمكن للتطبيقات ببساطة نشر عقودها الخاصة لجني فوائد سلسلة التطبيقات دون تعطيل تجربة المستخدم أو الأمان أو السيولة.
بالإضافة إلى ذلك، يمكن لمترجم Solang تجميع كود عقد Solidity الذكي في كود SVM الثانوي.
لقطات MetaMask
تاريخيًا، كان توجيه مستخدمي EVM لاستخدام سلاسل غير تابعة لـ EVM عائقًا كبيرًا، ولكن MetaMask Snaps التي تم الإعلان عنها مؤخرًا ستكسر هذا الحاجز. يمكن لمستخدمي EVM الاستمرار في استخدام MetaMask دون تبديل المحافظ. بفضل مساهمات Drift مفتوحة المصدر في إنشاء تطبيق MetaMask Snaps الرائع، فإن التجربة تشبه التفاعل مع أي سلسلة EVM. سيتمكن مستخدمو Eclipse Mainnet من التفاعل مع التطبيقات الأصلية في MetaMask أو استخدام محافظ Solana الأصلية مثل Salmon.
الراقص الناري
Firedancer هو عميل Solana المرتقب والذي تم تطويره بواسطة Jump وهو مصمم لتحسين إنتاجية الشبكة ومرونتها وكفاءتها بشكل كبير. عند الإطلاق، سنبقى على مقربة من عميل Solana الأساسي قدر الإمكان، ولكننا نخطط لاعتماد Firedancer بمجرد أن يصبح الكود نشطًا ومستقرًا.
أمان
يعمل Solana بمساحة هجوم منخفضة بشكل كبير، مما يمنع هجمات إعادة الدخول التي رأيناها مرات عديدة. على وجه التحديد، يسمح وقت تشغيل Solana فقط بالتكرار الذاتي للبرنامج ولا يسمح بالمكالمات العشوائية عبر البرامج. بالإضافة إلى ذلك، يؤدي الفصل بين الحالة والتعليمات البرمجية إلى إنشاء تعليمات برمجية عديمة الحالة، والتي يسهل اختبارها بشكل فعال بشكل عام.
إثبات أبسط
يعتمد SVM على التسجيل ومجموعة التعليمات أصغر بكثير من EVM، مما يجعل إثبات تنفيذ SVM أسهل في ZK. بالنسبة لعمليات التجميع المتفائلة، يسمح التصميم القائم على السجل بإجراء عمليات فحص أبسط.
طبقة التسوية: الأمان والسيولة على الإيثيريوم
مثل التحديث الرئيسي اليوم، سيتم تسوية Eclipse Mainnet مع Ethereum. على وجه التحديد، هذا يعني أن جسر التحقق الخاص بنا على Ethereum سيتم دمجه مباشرة في Eclipse. ستنظر عقدة Eclipse إلى هذا الجسر لتحديد "السلسلة الأساسية". يفرض هذا الجسر الترتيب الصحيح لـ Eclipse.
يتيح ذلك لمستخدمينا الحصول على خصائص أمان معينة من Ethereum. سيقوم الجسر بالتحقق من صحة جميع معاملات Eclipse ويمنع الالتزام بالحالات غير الصالحة. بالإضافة إلى ذلك، فإنه سيتم فرض الحيوية النهائية ومقاومة الرقابة في بعض حالات الفشل. حتى إذا توقف طلب L2 عن العمل أو بدأ في فرض الرقابة، فسيتمكن المستخدمون من فرض إدراج معاملاتهم عبر الجسر.
نظرًا لخصائص الأمان هذه، غالبًا ما يُشار إلى المكتبات الصالحة والمثالية باسم "Ethereum L2". تُعرّف L2BEAT L2 بأنها "سلسلة تستمد أمانها كليًا أو جزئيًا من طبقة Ethereum Layer 1 بحيث لا يحتاج المستخدمون إلى الاعتماد على صدق مدققي L2 للحفاظ على أموالهم آمنة."
تعكس تسوية Ethereum أهمية أصول Ethereum المحلية في اقتصادات DeFi وNFT الخاصة بـ Eclipse Mainnet. ETH هي العملة اللامركزية المفضلة لدى معظم المستخدمين، لذلك سنستخدم ETH أيضًا كرمز الغاز الخاص بنا. على المدى الطويل، سيمكن تجريد الرسوم المستخدمين من الدفع بأي رمز من اختيارهم (مثل USDC). حاليًا، ليس لدى Eclipse Mainnet أي خطط لإصدار الرموز المميزة الخاصة بها.
توفر البيانات: عرض النطاق الترددي لـ Celestia وإمكانية التحقق منه
سوف يستخدم Eclipse Mainnet Celestia لتوفير البيانات (المعروف أيضًا باسم نشر البيانات أو نشر البيانات). لقد كانت Celestia شريكًا طويل الأمد للنظام البيئي لـ Eclipse.
لسوء الحظ، فإن الإنتاجية والرسوم المستهدفة لـ Eclipse Mainnet غير مدعومة من خلال قيود النطاق الترددي الحالية لـ Ethereum. وينطبق هذا حتى بعد EIP-4844 (المعروف أيضًا باسم "Proto-danksharding")، والذي يوفر ~0.375 ميجابايت من مساحة blobspace لكل كتلة (مع حد لكل كتلة يبلغ ~0.75 ميجابايت).
وبالمقارنة، ستطلق سيليستيا كتل بحجم 2 ميجابايت بحلول نهاية هذا العام. بمجرد وصول ما يكفي من العقد الخفيفة لأخذ عينات توفر البيانات (DAS) عبر الإنترنت وإثبات استقرار الشبكة، فمن المتوقع أن تزيد مساحة النقطة إلى 8 ميجابايت بعد وقت قصير من الإطلاق. تخدم العقدة الضوئية DAS وظيفتين رئيسيتين:
من المتوقع أن تكون Celestia هي أول طبقة DA لتمكين DAS في الإنتاج. وهذا على النقيض من لجان توافر البيانات التقليدية (DACs)، التي تعيد تقديم افتراض صدق اللجنة دون التحقق من المستخدم (على غرار سلاسل الكتل المتجانسة الحالية).
هناك افتراضات أمنية متأصلة للمستخدمين الذين يقومون بتوصيل الأموال من شبكة Ethereum الرئيسية إلى أي سلسلة تستخدم DA خارج السلسلة. على وجه الخصوص، يمكن لمدققي Celestia رفض بيانات المعاملة من الناحية الفنية ولكنهم يزعمون أن البيانات متاحة على جسر Ethereum. في الواقع، إن إجماع سيليستيا على إثبات المصلحة يعني أن حجب البيانات من قبل سيليستيا نفسها يعاقب عليه، مما يجعلنا نعتقد أن هذا الخطر غير واقعي.
بشكل عام، فإن دعم عقدة DAS الخفيفة من Celestia، وخصائص أمان الاقتصاد المشفر، وإنتاجية DA القابلة للتطوير بشكل كبير من اليوم الأول، يجعلها الخيار الواضح لـ Eclipse Mainnet اليوم.
نعتزم أيضًا مراقبة تقدم Ethereum في توسيع نطاق DA بعد EIP-4844. تظهر أبحاث جديدة مثيرة قد توفر DA عالي الإنتاجية في وقت أبكر مما كان يُعتقد سابقًا (الأخير يستخدم جداول التجزئة الموزعة الأكثر تقدمًا). إذا وفرت Ethereum نطاقًا أكبر لمستخدمينا، فسنقوم بتقييم إمكانية الانتقال إلى Ethereum DA.
الدليل: إثبات الاحتيال RISC Zero ZK (لا يلزم إجراء تسلسل للحالة المتوسطة!)
سيكون دليلنا مشابهًا لإثبات احتيال SVM الخاص بـ Anatoly SIMD، والذي يشبه في حد ذاته رؤية جون أدلر بأن تسلسل الحالة مكلف وأنه يمكن تجنبه.
على وجه التحديد، نريد تجنب إعادة تقديم أشجار Merkle في SVM. لقد حاولنا إدراج شجرة Merkle متفرقة بعد كل معاملة في SVM، ولكن تحديث شجرة Merkle أدى إلى خسارة كبيرة في الأداء. يؤدي عدم استخدام أشجار Merkle إلى استبعاد أطر العمل المجمعة ذات الأغراض العامة الحالية (مثل مكدس OP) كأساس لمجموعة SVM، ويتطلب أيضًا تصميمات أكثر إبداعًا مقاومة للفشل.
باختصار، يتطلب إثبات الفشل ما يلي:
يتم عادةً تحقيق التزامات الإدخال من خلال توفير جذر Merkle لشجرة الحالة المجمعة. سيقوم منفذنا بنشر قائمة المدخلات والمخرجات (بما في ذلك تجزئات الحساب والحالة العالمية المرتبطة بها) لكل معاملة، بالإضافة إلى فهرس المعاملة التي أنتجت كل مدخلات. يتم نشر المعاملات على Celestia، بحيث يمكن لأي عقدة كاملة استخراج الحساب ذاتيًا في حالته الخاصة، وحساب حساب الإخراج، والتأكد من صحة الالتزام على Ethereum.
هناك نوعان رئيسيان من حالات الفشل المحتملة:
نحن نقف على أكتاف العمالقة. لقد أدى العرض المجمع اليوم إلى تطوير حالة البحث عبر صناعتنا ويوفر لمستخدمي Ethereum رسومًا أقل من L1.
ومع ذلك، فإنها لا تستفيد استفادة كاملة من أحدث التقنيات التي تتطلب نطاقًا واسعًا. لقد أدت التطورات الحديثة المذهلة إلى القضاء على الحاجة إلى إجراء هذه المقايضات التي قامت بها عمليات التجميع السابقة، مما يضعها فعليًا في وضع غير مؤات:
يمكننا أن نتعلم من القيود التي تواجهها السلاسل الأخرى ونختار أفضل الأجزاء للتوسع على المدى الطويل.
كثيرًا ما نسمع الحديث عن مليون مجموعة مجمعة خاصة بالتطبيقات في المستقبل.
يمكن أن يكون التخصيص على مستوى الإجماع ذا قيمة كبيرة لتطبيقات معينة (مثل dYdX v4)، ويسعدنا مساعدة الفريق في إطلاق مجموعات البيانات الخاصة بالتطبيقات.
ومع ذلك، فإن هذه الحالات نادرة. هذا هو السبب في أن معظم المجموعات الجديدة لا تزال مجرد شوكات EVM عادية. لن يتم حل مشكلات المطورين عن طريق تجزئة تجربة المستخدم عبر المزيد من السلاسل. غالبًا ما يبدو أن حالة الاستخدام الرئيسية الموجودة لملايين السلاسل اليوم هي مجرد إطلاق المزيد من العملات المعدنية. بالنسبة للغالبية العظمى من حالات الاستخدام، لا توجد حاجة اليوم إلى التخصيص الكامل لمكدس التكنولوجيا.
حتى في حالة وجود طلب حقيقي، فإن البنية التحتية المطلوبة لدعم العديد من سلاسل التطبيقات ذات تجربة المستخدم التنافسية لن تكون موجودة لسنوات (إن وجدت). تتمتع كل من سلسلة Optimism's Superchain (OP stack)، وZkSync's Hyperchains (ZK stack)، وسلسلة Orbit الخاصة بـ Arbitrum، وما إلى ذلك برؤية العديد من السلاسل ذات البنية التحتية المشتركة. يهدف هذا إلى توفير تجربة مستخدم أكثر سلاسة لعمليات interchain داخل نفس النظام البيئي (على سبيل المثال، بين سلسلتين داخل Superchain)، بدلاً من السلاسل المنعزلة تمامًا (على سبيل المثال، بين Ethereum و Solana).
ومع ذلك، فإن الخطط الحالية (إذا كانت موجودة) بعيدة كل البعد عن الوعد بالتنافس مع دولة مشتركة واحدة. بالإضافة إلى ذلك، فهي لا تعالج مشكلات قابلية التشغيل البيني عبر الأنظمة البيئية (على سبيل المثال، من Superchain إلى Hyperchain). لا ينبغي أن يعني بناء الوحدات النمطية بناء الصوامع.
يعد الأمر أكثر تعقيدًا بالنسبة للمستخدمين للاحتفاظ بحسابات في العديد من السلاسل. يعد عبور السلاسل باستمرار والقلق بشأن رموز الغاز المطلوبة تجربة مستخدم أسوأ. إن الاعتماد على موفري البنية التحتية لتشغيل وصيانة العديد من السلاسل يعد أيضًا أكثر تعقيدًا وتكلفة.
لقد أعجبنا دائماً بساطة رؤية سولانا. جهاز حالة مشترك محسّن للغاية مع مقياس لدعم حالات الاستخدام الأكثر قيمة. غالبًا ما يُنظر إلى هذا على أنه غير متوافق مع خرائط الطريق التي تركز على القيمة المجمعة، لكن الأمر ليس كذلك في الواقع. أردنا الجمع بين أفضل ما في العالمين.
يرجع سوء الفهم هذا إلى حقيقة أن المجموعات الحالية تعمل إلى حد كبير على تشغيل EVM الأصلي أحادي الترابط، والذي ظل دون تغيير إلى حد كبير للاستفادة من تأثيرات الشبكة المبكرة. لذلك، غالبًا ما نرى "مساحة الكتلة الخاصة" مذكورة كسبب لنشر مجموعات البيانات الخاصة بالتطبيقات. لا ينبغي أن ترتفع أسعار التطبيقات الأخرى في سلسلتك بسبب بعض عمليات سك NFT المجنونة، ولكن الحل ليس بناء سلسلتك الخاصة. أنت تقوم بمقايضات مؤلمة وغير ضرورية (التعقيد، والتكلفة، وتجربة المستخدم الأسوأ، والسيولة المجزأة، وما إلى ذلك). الحل الأفضل واضح - ما عليك سوى استخدام جهاز افتراضي متوازي مع سوق رسوم أصلي لنقاط الاتصال الحكومية. هذا هو بالضبط ما يجلبه SVM.
Ethereum هو المركز الفكري والاجتماعي والاقتصادي للعملات المشفرة. لقد كان كعب أخيل دائمًا هو التوسع. لا يزال توسيع نطاق توفر البيانات قيد التنفيذ، ولا يمكن لبيئات تنفيذ L2 الحالية التنافس مع الابتكارات الأحدث مثل SVMs. نحن قلقون من أنه إذا استمر الوضع الراهن اليوم، فسوف يتفاجأ النظام البيئي للإيثريوم في حالة حدوث أي زيادة كبيرة في النشاط. يمكن أن تؤدي أجهزة EVM أحادية الترابط ومحدودية توافر البيانات بسرعة إلى ظهور التكاليف المرتفعة مرة أخرى، ولكن هذه المرة فقط في عمليات التجميع.
نحن نعتقد أن Eclipse Mainnet هو الحل الواضح: الجمع بين أداء Solana مع الأمان وإمكانية التحقق وتأثيرات الشبكة لخارطة طريق تتمحور حول مجموعة التحديثات.
خاتمة
يكمن جمال Ethereum في أنه يبتكر باستمرار. تجسد خرائط الطريق المرتكزة على مجموعة التحديثات هذا الأمر، حيث تقوم بتفويض التنفيذ والابتكار إلى السوق الحرة. يتمتع L2 بقدرة خارقة على الاستفادة من تأثيرات شبكة Ethereum وضمانات التسوية أثناء تجربة أفضل بيئات التنفيذ الجديدة. يعد Eclipse Mainnet تنفيذًا طبيعيًا لهذه الرؤية.
إذا ظهرت طبقة تنفيذ ذات أداء أعلى يومًا ما، فسنكون متحمسين جدًا لرؤيتها منتشرة باعتبارها Ethereum L2 تنافسية. وحتى ذلك الحين، يظل SVM هو المعيار.