نظرة عامة على التقدم المحرز في مشاريع zkEVM الرئيسية في عام 2023

المؤلف: Alex Connolly، المؤسس المشارك والرئيس التنفيذي للتكنولوجيا لشركة Immutable؛ الترجمة: Golden Finance xiaozou

في أغسطس 2022، كتبت تدوينة حول حالة التطوير الحالية لـ zkEVM، بعنوان "ZkEVM و EVM Compatibility and Rollup Basic Guide" (الدليل الشامل لـ zkEVM، توافق EVM والمجموعات). في نفس الأسبوع، نشر V God مقالًا يقدم أنواعًا مختلفة من zkEVM ويحدد تصنيفات النوع 1 والنوع 2. في الوقت الحاضر، يُطلق على الأنواع المختلفة من zkEVM عادةً أنواع مختلفة - المنافسة شرسة جدًا!

في مشاركة المدونة تلك، قمت بالتنبؤ التالي:

.. .يجب أن يكون لديك أيضًا فهم واضح للحالة الحالية التراكمية للعقد الذكي. لدى كل فريق حافز قوي لتسويق نفسه باعتباره الفريق الذي على وشك السيطرة على العالم - ولكن ليس حتى أقرب > لن تظهر العقود الذكية على مستوى الإنتاج على إيثريوم حتى نهاية عام 2022، والعديد من لن تظهر هذه الفرق حتى 2023 وستكون جاهزة في وقت لاحق من العام.

لقد وصلنا الآن إلى "نهاية عام 2023" - كيف يتم تطوير واعتماد zkEVM؟ يعد هذا عامًا كبيرًا لـ zkEVM من نواحٍ عديدة:

· تم إصدار Polygon zkEVM وLinea وScroll!

· يعلن Immutable عن المجموعة التالية - zkEVM غير قابل للتغيير

· تم الإعلان عن المضلع تخطط لترقية Polygon PoS إلى zkEVM Validium

· أعلنت شركة Optimism عن خطط لدعم تشغيل سلسلة OP Stack كـ zkEVM

مهما كان الأمر، فإن البيانات تشرح نفسها بنفسها:

باختصار، تطوير zkEVM مستمر، لكن لا شيء من zkEVM شهدت اعتمادًا كبيرًا حتى الآن مقارنةً بسلاسل الكتل الحالية. الغرض من هذه المقالة هو الإجابة على سؤال واضح -كيف تتقدم مشاريع zkEVM المختلفة، وكيف يمكن أن تحظى باهتمام مرحب به؟

أولاً وقبل كل شيء، دعونا نراجع سريعًا "نوع zkEVM" الخاص ببوترين للمساعدة في فهم مشروع zkEVM:

قد يبدو هذا معقدًا، لكنه في الواقع سهل الفهم. اعتقد الجميع في البداية أن zkEVM يأخذ فقط عميل تنفيذ Ethereum الحالي (مثل Geth وNethermind وErigon)، ويولد أدلة zk (المعرفة الصفرية) لآثار التنفيذ، ويستخدم هذه البراهين لتأمين جسر الرسائل من L1 إلى L2. ومع ذلك، فإن اعتبارات التصميم الأصلية لـ EVM لم تتضمن إثبات ZK، وهذا النهج غير فعال للغاية (على سبيل المثال، وظيفة تجزئة keccak الخاصة بـ Ethereum باهظة الثمن). لذلك، لدينا بعض الخيارات:

· النوع 1  – فقط تعامل مع الأمر، سأدفع للمستخدمين/أنا . هناك ميزتان رئيسيتان هنا: يمكنك استخدام Type 1 Prover الموجود في blockchain، ولا تحتاج إلى الحفاظ على عميل Ethereum الخاص بك (يمكن أن تكون تكاليف التطوير مرتفعة مثل تكاليف الإثبات)، ولكن يتعين عليك الحفاظ على إجراء تحديثات العميل .

· النوع 2 -- لا يمس "طبقة التطبيق" (على سبيل المثال، لا يغير تكلفة كود التشغيل/ التنفيذ) ، ولكن قم بتغيير العقد الموجودة على السلسلة للحصول على بنية داخلية أكثر ملاءمة للمُثبِّت (على سبيل المثال، استخدم شجرة Sparse Merkle لتمثيل الحالة). العيب الكبير في هذا النهج هو أنك تحتاج إلى الحفاظ على عميل Ethereum متشعب بشكل دائم. وبالنظر إلى أن إيثريوم تكافح بالفعل للحفاظ على عملاء متعددين على مستوى الإنتاج، فهذه مهمة مهمة للغاية تتطلب فريقًا متخصصًا من مهندسي البلوكشين.

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

· النوع 4 --إنشاء جهاز افتراضي مخصص مصمم لإثباتات zk الفعالة، وإنشاء وتشغيل A المخصص ضيف لVM. سيؤدي هذا إلى تقليل تكاليف التحقق بشكل كبير، ولكنه يتطلب إنشاء نظام بيئي كبير من الأدوات والبنية التحتية لدعم جهاز افتراضي/ضيف مخصص. قد تكون قادرًا على توفير شكل من أشكال تحويل كود Solidity، ولكن قد يتعين على المطورين إجراء تغييرات جوهرية على عقودهم وأدواتهم الحالية لنشرها على سلسلتك. في رأيي، معظم مجموعات القيمة من النوع 4 ليست صحيحة. zkEVM - "العقد الذكي zk-rollup" قد يكون وصفًا أكثر دقة.

قد يكون من الأسهل فهمه في شكل جدول:

بحلول نهاية عام 2023، تقريبًا كل المشروع النشط كلاهما النوع 3 أو النوع 4 التراكمي لسبب واحد بسيط: أن بناءهما أسرع بكثير (على حساب التوافق وتكاليف الصيانة المتزايدة باستمرار)! ومن المثير للاهتمام أن جميع المشاريع التي تنتمي حاليًا إلى النوع 3 تقريبًا تخطط لأن تصبح في النهاية مجموعات من النوع 2 أو النوع 1 لتحسين توافقها مع إيثريوم وربما القضاء على الحاجة إلى تطوير عملائها.

في منشور مدونة العام الماضي، ركزت بشكل أساسي على كيفية تصميم فرق zkEVM المختلفة لمثبتاتهم. هذا العام، أردت تغطية الجوانب المهمة الأخرى لنهج كل مشروع، بما في ذلك تلك التي لا تتم مناقشتها كثيرًا (مثل كل خطة عميل لتنفيذ zkEVM). على سبيل المثال، يعتقد الكثير من الناس أن L2 هو "مُسلسل" ومثبت، في حين أن تصميم zkEVM القياسي يبدو في الواقع أكثر مثل هذا!

p>

هناك تصميمات أخرى للتسلسل (والتي سنناقشها لاحقًا)، ولكن معظم zkEVMs تخطط حاليًا لتشغيل blockchain منفصل كمتسلسل L2، مع عميل التنفيذ الخاص ( يتلقى المعاملات وينفذها) والعميل المتوافق (يصل إلى الإجماع على أمر المعاملة عبر جميع عقد L2).

الأهم من ذلك، أن هناك تكلفة لتعديل عميل Ethereum القياسي لإنشاء سلسلتك المخصصة. سيكون كل تغيير في عميل Ethereum (خاصة كل هارد فورك) بمثابة قرار حوكمة لجميع فرق zKEVM. كلما زاد عدد الأجزاء التي قمت بتخصيصها، أصبح من الصعب إجراء تغييرات أولية. مع مرور الوقت، من السهل تطوير عدم تزامن zkEVM - عند نقطة معينة، سوف يفقد zkEVM الذي يطابق Ethereum المزامنة بسرعة.

1، zkEVMحالة المشروع

فماذا عن تلك المشاريع التي ناقشناها العام الماضي؟

(1) Polygon zkEVM (وسلسلة Polygon CDK)< /p>

تم إطلاق Polygon zkEVM على الشبكة الرئيسية في مارس 2023 وعالج ما يقرب من 10 ملايين معاملة حتى الآن. وهي حاليًا من النوع 3، بهدف أن تصبح من النوع 2 في وقت ما في عام 2024.

بالطبع، مثل النوع 2/3، يتطلب Polygon zkEVM تنفيذ العميل المخصص الخاص به. اختار Polygon إنشاء عميله الخاص (zkevm-node) من الصفر من أجل التوافق، لكن هذا العميل الجديد واجه انقطاعات في الخدمة ويفتقر إلى العديد من الميزات الموجودة في عملاء Ethereum القياسيين.

لعلاج ذلك، يعمل Polygon مع gate.fm لتعديل Erigon (المعروف سابقًا باسم Turbo-geth) لدعم التغييرات المطلوبة لمثبتات النوع 2/3. سيوفر هذا لـ Polygon zkEVM طبقة أساسية أكثر استقرارًا وأداءً أفضل، على الرغم من أن الحفاظ على التوافق مع Erigon الأولي يظل تحديًا مستمرًا.

كما أعلنت العديد من الفرق أنها ستستخدم مجموعة أدوات تطوير سلسلة المضلع (CDK) لبناء zkEVM، بما في ذلك Astar وOKX وPalm Network. تتمثل رؤية Polygon CDK في دعم المطورين لبناء سلاسل مخصصة خاصة بهم وفقًا لاحتياجاتهم من خلال الجمع بين العملاء المختلفين والمثبتين وحلول توفر البيانات (أي إنشاء مجموعة أدوات zkEVM الخاصة بهم). اليوم، يدعم CDK تنفيذ العميل (zkevm-node) والإثبات (Polygon zkEVM). في المستقبل، يخطط فريق Polygon لإضافة المزيد من تطبيقات العميل (مثل Type-2-Erigon) والمثبتات (مثل Polygon Zero) إلى CDK.

p>

وهذا يعني أنه يمكنك نشر نسختك الخاصة من Polygon zkEVM اليوم! ومع ذلك، قد يحتاج أي فريق يقوم بالنشر باستخدام zkevm-node إلى الانتقال إلى عملاء آخرين في المستقبل، لذلك قد يرغب في الانتظار حتى يصبحوا جاهزين.

يجب أن نلاحظ أيضًا أن Polygon تخطط لترقية Polygon PoS (واحدة من أكبر وأنجح سلاسل الكتل في العالم) إلى blockchain مع بيانات خارج السلسلة zkEVM، ولكن لم يتم تحديد جدول الترقية المحدد بعد.

(2)التمرير

في عام 2023، أطلقت Scroll شبكتي اختبار وشبكة رئيسية واحدة (أكتوبر) - هذا هو عام البناء واسع النطاق! Scroll هو حاليًا نوع zkEVM من النوع 3. وقد صرحوا سابقًا أنهم يعتزمون التحويل إلى النوع 1/2 في المستقبل، لكن الوقت المحدد غير واضح. لديهم قائمة بالاختلافات عن إيثريوم، والتي تتضمن بعض التجميعات المسبقة غير المنفذة وبعض التعديلات الطفيفة على الحالة. عميل Scroll هو شوكة لـ Geth v1.10.13 ويعمل حاليًا في وضع التسلسل الفردي. تجدر الإشارة إلى أن أجزاء من عميل التنفيذ في Scroll متأخرة بالفعل لمدة عامين عن Ethereum (على الرغم من أنهم اختاروا EIPs لعميل التنفيذ في شنغهاي لتقليل تحيز طبقة التطبيق). لا يسبب هذا أي انقطاع مباشر في السلسلة، ولكنه يدل على تحديات الحوكمة التي ستواجهها العديد من المشاريع في تحديد مدى القرب من المنبع للإيثريوم على المدى الطويل، ومقدار الجهد الهندسي المطلوب لسد هذه الفجوة باستمرار.

(3)zkEVM غير قابل للتغيير

منذ يوليو، كان لدى Immutable zkEVM شبكة اختبار عامة وتخطط لإطلاق الشبكة الرئيسية في يناير. يستخدم zkEVM غير القابل للتغيير إصدارًا من عميل go-ethereum القياسي الذي تم تخصيصه لمجالنا الأساسي (الألعاب). ومن المثير للاهتمام أن zkEVM غير القابل للتغيير هو zkEVM الوحيد الخاص بالمجال الذي تمت مناقشته في هذه المقالة حتى الآن، على الرغم من أن قدرة L2 على التخصيص وفقًا للمتطلبات الخاصة بالمجال مع الحفاظ على أمان Ethereum تعد عامل جذب رئيسي لها. على سبيل المثال، يكتفي zkEVM غير القابل للتغيير باستخدام توفر بيانات الصلاحية لتقليل التكاليف ويختار تصميم PoSBFT نهائي أحادي الكتلة لتوفير تأكيدات شبه فورية، وهي قرارات قد لا تكون مناسبة لسلاسل الأغراض العامة. بالإضافة إلى ذلك، إذا تدفق عدد كبير من الألعاب ومستخدمي الألعاب على هذه السلسلة، فقد يكون هناك تأثير على الشبكة - نتوقع ظهور المزيد من لغات L2 الخاصة بالمجال في المستقبل.

ومع ذلك، فإن إصدار هذه السلسلة لن يوفر دعمًا للإثبات. وذلك لأن خطة zkEVM غير القابلة للتغيير تخطط لاعتماد مُثبتات Polygon Zero من النوع 1 بمجرد توفرها وفعالة من حيث التكلفة. الطريقة الوحيدة لإصدار Immutable للنوع 3 هي إجراء تغييرات جوهرية على العميل، وهو ما لا نرغب في القيام به نظرًا لتأثير ابتعاد العميل عن Ethereum. اليوم، يتم تشغيل Polygon Zero بواسطة Plonky-2، مع Plonky-3 قيد التطوير النشط ومن المتوقع أن يصل إلى درجة الإنتاج في منتصف إلى أواخر عام 2024، مما سيؤدي إلى تحسين الأداء بحوالي أمر من حيث الحجم. سيوفر هذا لـ Polygon مُثبتين مستقلين (Polygon Zero وPolygon zkEVM)، وسيتمكن المطورون من اختيار المُثبت الذي سيتم استخدامه في سلاسلهم المستندة إلى CDK.

(4)الخط

أصدرت Linea شبكتها الرئيسية في أغسطس واعتمدت نهجًا مشابهًا لـ Polygon/Scroll: بدءًا من النوع 3 التراكمي والانتقال تدريجيًا إلى النوع 1 أو النوع 2. تختلف Linea حاليًا عن Ethereum London في بعض النواحي فقط، كما هو موضح في الجدول.

تستخدم Linea نسختها المحدثة من Geth، والتي أطلقوا عليها اسم "zkGeth". تجدر الإشارة إلى أن الكود المصدري لهذا العميل ليس مفتوح المصدر، ولا هو أيضًا المثبت - لا يمكن للمستخدمين التحقق من أنه يعمل كما هو متوقع. إنهم يخططون لفتح كل هذه المكونات كجزء من خارطة طريق اللامركزية الموثقة جيدًا. تشير وثائق Linea إلى أنهم يخططون للانتقال من "zkGeth" إلى linea-besu، وهو إصدار محدث من عميل Besu تم تطويره بواسطة Consensys. على المدى المتوسط، يخطط فريق Linea لدمج linea-besu وbesu العادي، والاعتماد على نظام البرنامج الإضافي الخاص بـ Besu لإجراء تعديلات الحالة اللازمة ليصبح zkEVM من النوع 2.

(5)تايكو

تعمل Taiko على تحسين شبكة الاختبار الخامسة الخاصة بها وتخطط لإطلاق الشبكة الرئيسية في العام المقبل. تقوم Taiko بتطوير مُثبت zk الخاص بها بناءً على تنفيذ PSE (على غرار Scroll). ومن المثير للاهتمام أن Taiko هو الفريق الوحيد في هذه المقالة الذي لا يأخذ في الاعتبار حاليًا نمط التصميم المتمثل في تحقيق اللامركزية التدريجية لطلب واحد في blockchain L2. يعتمد تصميم Taiko على مفهوم Based Rollup الذي وصفه جاستن دريك - بدلاً من وجود مجموعة مرخصة من المدققين، يمكن لأي شخص إرسال حزم المعاملات والبراهين إلى Ethereum L1. يعني هذا التنفيذ أن عملية التجميع تقوم بتفويض الطلب بشكل كامل إلى Ethereum L1، مما يسمح لها بوراثة ميزات الحيوية واللامركزية الخاصة بـ Ethereum L1 تلقائيًا. ومع ذلك، فإنه يحتوي على عيب مهم: لا يوفر جهاز تسلسل L2 تأكيدًا "نهائيًا سريعًا"، مما يعني أن المستخدمين ينتظرون وقتًا أطول لتأكيد المعاملة. اقترح جاستن دريك آلية "التأكيدات المسبقة المستندة" لتوفير تأكيدات احتمالية بزمن وصول يبلغ 100 مللي ثانية فقط، لكنها لم تكن قريبة من مستويات الإنتاج وقدمت التزامًا منفصلاً بـ "التأكيد المسبق (التأكيد المسبق)" ونظام "نصائح ما قبل التكوين" وقد يكون هناك تأثير على أدوات الايثيريوم الموجودة. هذا مجال بحثي نشط!

صرحت Taiko منذ البداية أنها تخطط لتصبح من النوع 1 zkEVM. وهم يعتقدون أن اختلافات التوافق التي تجلبها أجهزة zkEVMs الأخرى ستكون أسوأ من التكلفة المرتفعة لتوليد الإثبات، وعلى أي حال، مع تقدم التكنولوجيا، ستنخفض التكلفة في النهاية. يعد تنفيذ عميل Taiko أمرًا مثيرًا للاهتمام - "عميل التنفيذ" الأساسي هو نسخة معدلة من Geth v1.13 (taiko-geth). ومع ذلك، فإنهم يحتفظون أيضًا بـ "عميل الإجماع" الخاص بهم (عميل تايكو)، الذي يتعامل مع الاتصال مع L1 ويراقب عملية الطلب القائمة.

p>

(6)عصر zkSync

تم إصدار zkSync Era في مارس 2023 وقد حقق نجاحًا حتى الآن، مع شائعات عن عملية إسقاط جوي قادمة دفعت TVL إلى أكثر من 500 مليون دولار. zkSync هو نوع 4 zkEVM، وهم يقومون بإثبات جهاز VM المخصص الخاص بهم (eraVM) بدلاً من محاولة تعديل EVM مباشرةً. إنهم يهدفون إلى "التوافق على مستوى اللغة" مع Ethereum ويوفرون مترجمًا مباشرًا من كود Solidity إلى جهاز VM المخصص لهم. لقد قاموا بإجراء تغييرات جوهرية على تنفيذ العديد من أكواد تشغيل EVM الرئيسية، كما قاموا أيضًا بإجراء بعض التغييرات على عملية التجميع، لذلك غالبًا ما يحتاج المطورون إلى تعديل عقودهم أو نصوص النشر الخاصة بهم للنشر في zkSync Era.

يمتلك zkSync Era عميله المخصص الخاص، مما يسمح له بتنفيذ ميزات غير تابعة لـ EVM مثل تجريد الحساب الأصلي. في يوليو 2023، قاموا بترقية الإثبات إلى "Boojum"، وهو نظام إثبات STARK، ثم استخدموا عبوة SNARK للتحقق على السلسلة، على غرار Polygon zkEVM. يتطلب عصر zkSync بيانات كاملة على السلسلة، لكنهم يخططون لتقديم "zkPorter" في المستقبل، والذي سيسمح للمستخدمين بالاختيار بين نماذج مختلفة لتوفر البيانات بنقاط أسعار مختلفة، على غرار نموذج Volition الذي اقترحته StarkWare.

p>

(7)StarkNet

يعد StarkNet واحدًا من أكثر المشاريع طموحًا في نظام Ethereum البيئي: فهم يقومون ببناء نظام تراكمي ونظام بيئي من النوع 4 من الصفر، والذي يتضمن جهاز افتراضي جديد (CairoVM)، ولغة برمجة جديدة (القاهرة)، ومثل جديد (Stone) والعملاء الجدد (باثفايندر، بابيروس، جونو). سيتم افتتاح StarkNet تدريجيًا في عامي 2021 و2022، ولديها الآن أكثر من 150 مليون دولار أمريكي في قيمة TVL وحجم معالجة شهري يزيد عن 10 ملايين معاملة.

يعد بناء نظام بيئي جديد من الصفر أمرًا صعبًا للغاية، ولكنه يوفر أيضًا ابتكارًا أساسيًا في المجالات التي تعمل فيها EVM بجد (مثل تجريد الحساب الأصلي) وفرصًا كبيرة تحسين الأداء. تم اختبار جزء كبير من سلسلة الأدوات على نطاق واسع من خلال المشاريع المستندة إلى StarkEx مثل Immutable X وdydx v3 وSorare، والتي تم تشغيلها منذ عام 2020 وتم اعتمادها على نطاق واسع.

في البداية، استكشف نظام StarkNet البيئي التوافق على مستوى اللغة من خلال مشاريع مثل Warp Solidity → مترجم القاهرة الذي ذكرته العام الماضي. ومع ذلك، تم الآن إهمال Warp وقرر النظام البيئي StarkNet الالتزام الكامل بمجموعة أدوات CAIRO الجديدة ولم يعد يدعم أي نوع من التوافق مع الإصدارات السابقة من Solidity. والآن، يواجهون نفس التحديات التي تواجهها الأنظمة البيئية التي لا تعتمد على EVM مثل Solana أو Sui - هل يمكنك إقناع عدد كبير من المطورين بتبني أداتك الجديدة؟ أم أن EVM العالمي سيفوز؟

العمل الذي يقوم به فريق Kakarot هو الاستثناء الوحيد. فهم يقومون بتطوير Type 2.5 EVM باستخدام لغة CAIRO، والتي ستكون بمثابة مجموعة من العقود يعمل على ستارك نت. من خلال Kakarot، سيتمكن المستخدمون من النشر والتفاعل مع عقود EVM التي تحتوي على رمز/حالة على StarkNet، مما يسمح للمستخدمين بالاستفادة من أداء StarkNet مع الحفاظ على توافق EVM. نظرًا لأن بيئة التنفيذ الأساسية ستظل هي StarkNet، فإن هذا سيضحي بتوافق أداة Ethereum - ولكن بالنسبة لبعض المشاريع، قد تكون هذه مقايضة مقبولة. لم تصل Kakarot بعد إلى مستوى الإنتاج، كما أن تأثير الأداء وتوافق الأدوات لهذا النهج متعدد الطبقات غير واضح، ولكنها محاولة مثيرة لسد الفجوة بين أنواع zkEVM المختلفة وتُظهر أننا نستكشفها فيما يتعلق بمساحة التصميم، نحن تصرفت في وقت مبكر جدا.

p>

(8)التفاؤل

لأسباب واضحة، غالبًا ما يُنظر إلى التفاؤل على أنه فريق يركز على التراكمات المتفائلة. ومع ذلك، فقد ذكروا مرارًا وتكرارًا أنهم يخططون لدعم أدلة المعرفة الصفرية في ZK كخيار في المستقبل، وأجروا مناقشات حية مع العديد من الفرق المساهمة بنشاط. تقدم الآن مشاريع النظام البيئي zk المثيرة مثل zeth دعمًا لكتلة التفاؤل. ومع ذلك، لم نر أي جدول زمني أو تصميم رسمي حتى الآن – ربما ستكون هناك تغييرات مثيرة في مراجعة zkEVM العام المقبل!

كما ترون، هناك اختلافات كبيرة بين فرق kEVM. حتى المجموعات المجمعة من نفس النوع غالبًا ما يكون لها تصميمات مختلفة تمامًا عن المُثبتين والعملاء وآليات الفرز.

p>

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

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

ما هي المشكلات التي لم يتم حلها في تطوير 2 وzkEVM؟

بادئ ذي بدء، هناك نقص في الواجهة الموحدة بين العميل والمُثبِّت. حاليًا، كل مُثبِّت متوافق فقط مع العميل الذي تم إنشاؤه معه في الأصل. لا يمكنك استخدام إثبات Polygon zkEVM مع أي عميل آخر من النوع 2/3. من الناحية المثالية، يجب أن يكون أي مُثبِّت أو عميل جديد متوافقًا مع أكبر عدد ممكن من المُثبِّتين/العملاء الحاليين. يعد تشجيع فرق zkEVM المختلفة على اتباع EIP لواجهة واحدة خطوة حاسمة للتطوير المستقبلي.

من المفهوم أن معظم الفرق تعطي الأولوية حاليًا لتحسين عمليات النشر الخاصة بها بدلاً من السعي إلى التوافق مع الآخرين. قد يكون هذا مقبولاً في الوقت الحالي، ولكن في النهاية نود أن يستخدم zkEVM الذي تم طلبه من L2 على وجه الخصوص إعداد متعدد العملاء/المثبت لتقليل مخاطر الأخطاء الرئيسية. بالإضافة إلى ذلك، فإن توحيد تطبيقات ميزات النوع 2 "الكلاسيكية" (على سبيل المثال، أشجار Merkle المتفرقة، ووظائف تجزئة Poseidon بدلاً من keccak) قد يساعد العديد من المثبتين على استخدام نفس العملاء أو عملاء مشابهين. سيكون تقليل عدد عملاء "geth" بمثابة فوز كبير للنظام البيئي! تم اقتراح مبادرة توحيد تسمى "RollCall"، إلى جانب سلسلة من توصيات تحسين التراكم (RIPs)، على الرغم من أنه من غير الواضح مدى انتشار هذه المبادرة.

ثانيًا، هذه zkEVMs هي تقريبًا جميعها أجهزة تسلسل فردية، مما يشكل تحديًا لللامركزية وأمن هذه المجموعات المجمعة. على وجه الخصوص، لاحظ أن سلوك المُثبت يهدف فقط إلى التأكد من أن الجسر L1-L2 آمن. أي نظام خارجي يعتمد على التأكيد المسبق للمستوى الثاني (مثل CEX) يعرض الكثير من الأموال للخطر لأنه يعتمد كليًا على مُسلسِل واحد - بالنسبة للعديد من مُسلسِلات L2 الحالية، لا يتطلب الاختراق الضار جدًا سوى سرقة مُسلسِل. مفتاح. ومع ذلك، بمجرد إلغاء مركزية جهاز الفرز، تظهر تحديات مختلفة (كما ترون في محتوى Taiko أعلاه!). هل تحتاج إلى تقديم دليل zk إلى L1 لإثبات أنه تم التوصل إلى إجماع L2؟ ماذا عن قضايا النشاط؟ ماذا عن MEV؟ لا تستخدم معظم مجموعات التسلسل الفردي حاليًا MEV لأسباب تتعلق بالعلامة التجارية/السمعة/السلسلة، ولكن هذا قد يتغير في المستقبل.

ثالثًا، لا يوجد إطار قياسي لقياس أداء وتكلفة zkEVM. لقد تم إنفاق جزء كبير من هذه المقالة في مقارنة تأثيرات الأداء المحتملة لتصميمات zkEVM المختلفة، ولكن حاليًا قام عدد قليل من فرق zkEVM بنشر أي مواصفات أو اختبارات أداء حقيقية. تتكون "تكلفة zkEVM" من الأجزاء التالية:

· تكلفة الحوسبة السحابية لإنشاء الدليل (تتأثر بكفاءة الدائرة)

· تكلفة إثبات التحقق من المستوى الأول

· تكلفة توفر البيانات

· تكلفة إرسال المعلومات من طبقة إلى أخرى

يجب أن أكون قادرًا على إنشاء اختبارات موحدة لهذه المجالات و يتم جدولة النتائج لمساعدة البناة على اتخاذ قرارات أكثر استنارة - وهو أمر غير ممكن حاليًا. إليك الفارق الدقيق: ستكون بعض تطبيقات الإثبات أفضل من غيرها بالنسبة لأنواع معينة من المعاملات، وسيعتمد جزء من التكلفة على الاستخدام، نظرًا للقدرة على توزيع تكاليف المعاملات عبر حزمة المعاملات. إن كيفية تقديم هذه التكاليف للمستخدمين هي أيضًا حالة عدم يقين كبيرة (على سبيل المثال، خطط zkEVM غير القابلة للتغيير لدفع تكاليف الإصدار للمستخدمين في معظم الحالات، في حين أن Scroll لديه إعداد شحن معقد L1 + L2 لضمان أن كل معاملة كلها مربحة). بالإضافة إلى ذلك، قد تواجه العديد من أجهزة zkEVM مشكلات في الأداء تتعلق بنمو الحالة - فتوسيع مساحة كتلة Ethereum ليس مجانيًا! وكل هذا سيتطلب قدراً أكبر من القدرة على القياس/المقارنة مما هو ممكن حالياً.

رابعًا، بالنسبة لمعظم مجموعات العقود الذكية، لا تزال آلية الخروج غير مفهومة ومحددة جيدًا. يتم تعريف الاستضافة الذاتية بشكل جيد في مجموعة تطبيقات محددة (مثل Immutable X) - أي أصول تقوم بإيداعها في جسر L1 هذا يجب أن تكون قابلة للاسترداد، حتى لو كان جهاز التسلسل غير متصل بالإنترنت تمامًا أو ضارًا تمامًا. غالبًا ما يُطلق على هذا اسم "فتحة الهروب". ولكن ماذا يعني هذا في سياق تراكم العقود الذكية؟ ماذا لو كانت عملة ETH الخاصة بك مراهنة على عقد لا ينبغي أن يكون متاحًا على أي حال؟ هل يتعلق الأمر كله بمقاومة الرقابة (هل نحتاج إلى ضمان القدرة على فرض المعاملات)؟ ما مستوى توفر البيانات المقبول لـ zkEVM المستخدم لأغراض مختلفة (مثل أصول الألعاب مقابل DeFi)؟ نحن بحاجة إلى إطار عمل متسق لتوصيل حالات الفشل الفعلية للمستخدمين - يعد L2 Beat بداية جيدة في هذا الصدد!

خامسًا، لا تزال العلاقة بين zkEVM وEthereum L1 غير واضحة. أثناء كتابة هذا المقال، انجذبت مرة أخرى إلى منشور مدونة نشره Buterin والذي انعكس على "enshrined zkEVM". الفكرة الرئيسية هي أن طبقة عميل Ethereum يمكنها "تكريس" تنفيذ إثبات zk، والذي يمكن استخدامه للتحقق من تنفيذ كتل EVM المقدمة من مصادر أخرى (مثل L2). يؤدي هذا إلى تجنب الاضطرار إلى إبقاء جميع مثبتات L2 zkEVM محدثة (فوز كبير!) - يمكنهم الاعتماد على عمل الفرق الأخرى، بما في ذلك فريق عملاء Ethereum الأساسي، وقد أصبح SNARKed Ethereum حقيقة واقعة. لذا، هل يجب أن أفسر اقتراح "zkEVM" باعتباره خروجًا عن خارطة طريق التوسع التي تركز على L2 الخاصة بـ Ethereum، مما يعيد القيمة التي تم التقاطها بواسطة L2؟

ليس بالضبط. لا يزال L2 بحاجة إلى جهاز التسلسل الخاص به لتوفير تأكيدات سريعة (مهم في مجالات مثل الألعاب)، والتصميم الذي اقترحه Buterin يدعم فقط zkEVM مع البيانات الموجودة على السلسلة بالكامل. معظم مستخدمي L2 يريدون تقريبًا أن يظلوا مستقلين لأسباب مثل تحقيق الدخل، وهو مقايضة مهمة لنظام Ethereum البيئي. يعد L2 أمرًا بالغ الأهمية لتوسيع مساحة كتلة Ethereum، لكن دوافعهم (وفريق BD) قد لا تتوافق دائمًا مع Ethereum.

أخيرًا، ستستمر أجهزة zkEVM المتعددة في تشتيت المستخدمين والسيولة، مما يؤدي إلى تجربة مستخدم سيئة. اليوم، سيستمر كل Ethereum L2 إضافي في تحقيق اللامركزية في الحالة والسيولة - إذا كان لديك 2 ETH على Arbitrum، فسيكون الوصول إلى ETH على أي L2 آخر أمرًا صعبًا. في رأيي، هذه هي أفضل حجة حتى الآن بالنسبة لسلاسل المونومر، حيث تم تحسين قابلية التركيب بشكل كبير ولا يضطر المستخدمون إلى الموازنة بين سلاسل متعددة. مع الشعبية الحالية لـ "مجموعات أدوات L2" (مثل Polygon CDK وArbitrum Orbit وOP Stack)، لم يكن إطلاق السلسلة أسهل من أي وقت مضى، ولكن على حساب تجزئة أكبر.

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

3، الاستنتاج

بالنسبة لـ zkEVM، 2023 هذا العام سيكون عامًا مهمًا لكل من تقدم التطوير والتحضير للتبني العملي. سيكون عام 2024 هو العام الأول الذي تصبح فيه مركبات zkEVM من النوع 1 والنوع 2 جاهزة للاستخدام في الإنتاج، ولكن من الناحية الواقعية لن نحصل عليها حتى الربع الثالث/الربع الرابع على أقرب تقدير - هناك الكثير مما نحتاج إلى حله للوصول إلى مشكلات الأداء!

أريد أن أوضح أن المشكلة الرئيسية التي ستحلها zkEVM في عام 2024 ليست مشكلة فنية (على الرغم من أنه من الواضح أنه لا يزال لدينا بعض المشكلات الفنية التي يتعين علينا حلها)، لكن السؤال المهم هو: هل يمكننا إنشاء تطبيقات مثيرة للمستخدمين على الجيل التالي من اللغة الثانية؟ نحن بحاجة إلى مطوري بروتوكولات رائعين ومطوري تطبيقات رائعين!