أثار ملصق لإطلاق Polygon zkEVM نقاشا كبيرا بين مؤسسي السلسلة العامة حول قابلية التوسع

في 26 فبراير ، أثار ملصق ترويجي يعلن عن إطلاق الشبكة الرئيسية ل Polygon zkEVM نقاشا حول استخدام مصطلح تكافؤ “Ethereum” ، وأشار Ye Zhang ، مؤسس Scroll ، رسميا إلى أن Polygon zkEVM لا يحتوي على هذه الميزة. بعد فوات الأوان ، أجاب ريان وايت ، رئيس Polygon Labs ، أن هذا كان نتيجة لضعف التواصل بين المسوقين والفنيين داخل الفريق.

هذه ليست مسألة تافهة ، وسيكون مدى الفعالية مرتبطا بشكل مباشر بأداء L1 / L2 وقابلية التوسع ، قبل يومين فقط ، نشر Toly ، المؤسس المشارك في Solana ، مقالا مفاده أن ZK L2s لن يكون الحل الأفضل لحل قابلية التوسع.

في 27 فبراير ، استجاب الفريق الفني Polygon ، بطل الرواية لهذا الحدث ، بنشاط لمبدأ عمل zkRollup ، موضحا أين تشير قابلية التوسع في zkRollup.

في 1 مارس ، أعلنت Solana أيضا عن “خطة لتحسين ترقية الشبكة” لإعادة حمل راية قاتل Ethereum ، لكن آلية تشغيلها لم يتم ابتكارها بشكل أساسي بعد انقطاعات متعددة ، وهي أشبه بتحسين ما بعد الأزمة ، والذي يلقي بظلاله أيضا على استبدال Ethereum ب L1 عالي الأداء.

ستجمع هذه المقالة تغريدات العديد من مؤسسي L1 / L2 للكشف عن خصوصيات وعموميات النقاش الكبير حول أداء السلاسل العامة.

**الأصول: النقاش حول معادلة EVM **

zkEVM من Polygon ، بالمعنى الدقيق للكلمة ، هي آلية zk VM ، والتي تتوافق مع شبكة Ethereum الرئيسية على مستوى L2 من خلال رسم الخرائط ، وإدخال تقنية zk هو سبب تسميتها zk VM ، وبمعنى غير صارم ، طالما أنها يمكن أن تحافظ على التزامن ، فمن غير الضار تسميتها zk EVM.

ومع ذلك ، وفقا ل Ye Zhang ، مؤسس Scroll ، فإن تكافؤ EVM ليس بالضبط نفس مكافئ Ethereum ، لأن الأخير يجب أن يكون على الأقل متسقا مع شبكة Ethereum الرئيسية من حيث تخزين البيانات.

من منظور أوسع ، لا يمكن لأي من جسور L2s أو Ethereum عبر السلسلة الحالية أن تدعي أنها مكافئة ل Ethereum ، وستجلب مكدسات Ethereum الأكثر تعقيدا توافقا أكثر صعوبة.

يمكن إعطاء مثال بسيط لفهم الفرق بين الاثنين بشكل حدسي ، يتعامل التفاؤل مع الفرق بين الاثنين في تخطيط المنتج ، في رأيه:

معادلة EVM: بشكل أساسي من منظور مطوري dApp ، لا تختلف تجربتهم في OVM عن تجربة تطوير dApps على شبكة Ethereum الرئيسية ، لذلك فإن OVM لديها تكافؤ EVM ؛

تكافؤ Ethereum: بشكل أساسي من منظور مطوري البروتوكول ، من الضروري الحفاظ على درجة عالية من الاتساق مع Ethereum من حيث العميل وطبقة الاتصال وطبقة الإجماع وطبقة التنفيذ.

بالإضافة إلى مناقشة تكافؤ EVM ، تجدر الإشارة أيضا إلى أن الجدل حول قابلية التوسع هو حاليا محور المعركة بين L2 القائم على Ethereum و L1 عالي الأداء.

** سابقة: شكوك سولانا حول قابلية التوسع ZK **

في 24 فبراير ، قبل يومين من إطلاق مقطورة Polygon zkEVM ، نشر Toly ، المؤسس المشارك ل Solana ، منشورا على Twitter يشكك في قدرة ZK L2s على حل مشكلة توسيع السلسلة العامة ، من أجل تعويض شكوك الجمهور حول آلية تشغيل Solana.

نقاطه الرئيسية هي كما يلي:

• يتطلب تحميل البيانات في الوقت الفعلي إلى السلسلة قدرات تنفيذ متسلسلة مستقرة ؛
• مخطط إثبات ZK صالح ، بشرط أن يكون مجموع وقت إنشاء إثبات ZK + وقت التحقق أقل من وقت التنفيذ في الوقت الفعلي ؛
• لا يمكن لحل ZK معالجة كميات كبيرة من البيانات في الوقت الفعلي ، ويمكنه فقط إجراء تجميع متقطع ، ولكن لا يمكنه الحفاظ على حالة الوقت الفعلي للحالة على السلسلة ؛

لذلك ، يعد حل ZK أكثر ملاءمة لسيناريوهات التردد المنخفض لمرة واحدة ، مثل تسوية الدفعات ، بينما لا يزال Solana مطلوبا لقابلية التوسع في السلسلة العامة.

لسوء الحظ ، عانى سولانا من انقطاع شديد في 25 فبراير ، واستعاد المجتمع والمهندسون والمدققون الشبكة الرئيسية بعد إعادة تشغيل مرتين ، وتزامن تسرب المنزل مع هطول الأمطار بين عشية وضحاها ، وانتهز “فاعلو الخير” الفرصة للتشكيك في آلية سولانا ، حيث جادل مستخدم تويتر DBCryptoX بأن “90-95٪ من المعاملات على Solana تحتوي على رسائل مدقق وتصويت على السلسلة”.

يستخدم Solana آلية إجماع PoS ، والتي تطلق على نفسها آلية “إثبات التاريخ”. يمكن PoH الشبكة من العمل بشكل أسرع لأن العقد لا تحتاج إلى الاتصال للتحقق من صحة الكتلة ، ويمكن PoH المدققين من تحديد الأحداث في وقت معين.

من ناحية ، تجلب هذه الآلية درجة عالية من التوحيد ، مما يجعل TPS أبعد من شبكة Ethereum الرئيسية ، ولكن من ناحية أخرى ، فإنها تشغل الكثير من مساحة الكتلة على السلسلة ، وبمجرد حدوث خطأ ما ، من الصعب التوصل إلى توافق في الآراء لاستعادة الشبكة. حدث انقطاع واحد على الأقل في الشبكة الرئيسية سنويا للفترة 2021-2023 على الأقل.

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

ومع ذلك ، اتضح أن L1 Solana عالي الأداء لا يبدو أنه يحل مشكلة التنفيذ في الوقت الفعلي ، بعد كل شيء ، ستفقد الشبكة المنهارة في النهاية النظام المعمول به ، وستصبح البيانات المستردة بالقوة “إجماعا” مصطنعا بدلا من الحالة التلقائية للشبكة نفسها.

العواقب: قابلية توسع المضلع تكمن بشكل حاسم

تم استجواب Polygon zkEVM أولا من قبل Solana ثم أعلن أن هناك حادث أولونغ ، والذي يشتبه في أنه غير مهني ومضلل. لذلك قفز المطور ، جوردي بايلينا ، وواجه تحدي الاحتراف ، مع التركيز على شرح أن البروفير ليس هو العامل المحدد ل ZK L2s ، والعائق الحقيقي هو DA (توافر البيانات).

الأول هو عملية تشغيل zkRollup ، والتي يمكن تقسيمها تقريبا إلى ثلاث خطوات ، كما هو موضح في الشكل أدناه:

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

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

بمجرد تشغيل ZKP ، يتم إنشاء شبكة كاملة مقاومة للشجرة للبيانات ، مما يسمح لخوادم مختلفة بالتحقق من البيانات وإرسال النتائج إلى سلسلة L1.

والثاني هو مشكلة التكلفة ، وأهمها تكلفة الإثبات ، وسيتم تضمين البرامج والأجهزة ووقت استدعاء تشغيل ZK في عامل الحساب من خلال رسوم TX (المعاملة) ، وتنعكس أخيرا في رسوم الغاز للشبكة ، وستعمل الخوارزميات المختلفة ، مثل STARK / SNARK / FLONK ، وما إلى ذلك ، على تحسين تكلفة استخدام الشبكة بشكل كبير. النقطة الأساسية هي أن تحميل البيانات لا يلزم إجراؤه بالتتابع من أجل تسهيل التوازي.

لذلك ، فإن Prover الذي يعتقد Solana أنه لا يمكن أن يعيق تشغيل براهين ZK ، والعقبة الحقيقية هي توفر البيانات ، والتي يجب حلها بواسطة ETH 2.0 و DankHanging و EIP4844 وغيرها من الحلول.

**الخلاصة: إلى أين تتجه قابلية التوسع **

سيستمر النقاش حول Polygon zkEVM ، وسيكون المفتاح هو مدى قدرة zk EVM على حل مشكلة قابلية التوسع الحالية ، والتي ستكون الاختبار التالي ل L1 / L2s لمواجهة dApps والمستخدمين على نطاق واسع.