من النوع 1 إلى النوع 4، ما هي الاختلافات بين الأنواع المختلفة من ZK-EVM؟

المؤلف الأصلي| ليزا أكسلرود

مجمعة | Odaily Planet Daily 0xAyA

*ملاحظة المحرر: قام المؤلف بتجميعها بناءً على مقالة مقدمة ZK-EVM التي كتبها Vitalik مسبقًا، وقدم بالتفصيل الأنواع المختلفة من ZK-EVM والاختلافات بينها. *

منذ حوالي عام، أعلنت مجموعة من ZK-EVMs أنها على وشك إطلاق شبكة اختبار. أثارت هذه التحركات فضول مجتمع إيثريوم وأثارت نقاشًا حول الفروق الدقيقة وراء مصطلحات مثل معادلة إيثريوم ومعادلة EVM.

من أجل الوضوح، كتب فيتاليك مقالًا مهمًا بعنوان "أنواع مختلفة من ZK-EVMs" يصنف مختلف ZK-EVMs إلى أربعة أنواع ويشرح الاختلافات بينها.

الفكرة الأساسية هي: النوع 1 (مثل Taiko) يعادل تمامًا Ethereum، بينما يتفوق النوع 4 (مثل zkSync) في إنشاء إثبات فعال. جميع الأنواع الأخرى، النوع 2، والنوع 2.5 والنوع 3، تقع بينهما (مثل Polygon zkEVM، وScroll، وLinea).

معظم ZK-EVMs هي في البداية من النوع 2.5 والنوع 3، مع الكشف عن بعض النية للتطور نحو النوع 1 أو النوع 2، على الرغم من أن هذه المشاريع لم تقدم جداول زمنية أو التزامات محددة لذلك.

** تركز هذه المقالة على الاختلافات بين النوع 1 والنوع 2/النوع 2.5، وتصف العواقب المحتملة لكسر تكافؤ الإيثريوم. وسنتطرق أيضًا بإيجاز إلى الأنواع الأخرى. **

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

• يوضح تنفيذ الكود الثانوي الأصلي غير المعدل (الذي يغطي 100% من أكواد تشغيل Ethereum) وفقًا لمواصفات Ethereum Virtual Machine في الكتاب الأصفر.
• توليد البراهين بسرعة بتكلفة منخفضة.
• يسمح بإعادة استخدام الأدوات والبنية التحتية التي تم تطويرها لـ Ethereum بنسبة 100%.
• السماح بإعادة نشر أي تطبيق Ethereum dApp على ZK-EVM "كما هو" ("كما هو" يعني عدم الحاجة إلى إجراء أي تغييرات، أو التنازلات).

الاختلافات بين أنواع ZK-EVM

في عالم ZK-EVM، تأتي الاختلافات بشكل أساسي من مستوى تكافؤ Ethereum/EVM، وتأثير العناصر غير الصديقة لـ ZK على تكلفة وسرعة إنشاء الدليل، وتعقيد تنفيذ الدائرة (مثل إنشاء VM أو الحالة الأشجار).

دعونا نحلل هذه الاختلافات، ونميز على وجه التحديد النوع 1 عن النوع 2/النوع 2.5. سنتطرق أيضًا إلى حالات الاستخدام الأكثر صلة بكل نوع.

عند مقارنة الأنواع المختلفة، غالبًا ما يتم استخدام المخطط التالي:

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

يقدم هذا الرسم البياني صورة أوضح لما يبدو عليه كل نوع في الواقع، لكنه لا يزال غامضًا بعض الشيء، فلنستكشف عالم ZK-EVM بالكامل من خلال شرح كل نوع على حدة.

النوع 1: يعادل الإيثيريوم

فيتاليك بوتيرين:

"النوع 1 ZK-EVM هو ما نحتاجه في النهاية لجعل طبقة Ethereum 1 نفسها أكثر قابلية للتطوير."

النوع الأول يعني عدم تغيير أي جزء من نظام الإيثيريوم لتسهيل إنشاء البراهين. عدم وجود تغييرات في Ethereum يعني عدم وجود تنازلات بشأن الأمن، حيث أن معظم أساسيات التشفير (مثل وظائف التجزئة)، أو البنية التحتية للمطورين (مثل مصححات الأخطاء) أو البنية التحتية للسلسلة (مثل عملاء التنفيذ) قد خضعت بالفعل لـ 9 سنوات من الاختبار الميداني.

النوع 1 ZK-EVM لا يحل محل أي شيء: التجزئة، أو أشجار الحالة، أو أشجار المعاملات، أو الترجمة المسبقة، أو أي منطق إجماع آخر، كل شيء مطابق تمامًا لـ EVM الخاص بالشبكة الرئيسية.

• النوع 1 هو النوع الوحيد الذي يمكنه التحقق من سلسلة Ethereum نفسها - بدءًا من الكتل الكاملة وحتى تنفيذ المعاملات والعقود الذكية ومنطق الحساب.

النوع 2: يعادل EVM

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

*ملاحظة: ما يعادل Ethereum وما يعادل EVM ليسا نفس الشيء. في حين أن التكافؤ مع Ethereum يعني أنه لم يتم تغيير أي جزء من Ethereum، مما يعني أنه متوافق تمامًا مع جميع تطبيقات Ethereum dApps، فإن التكافؤ مع EVM يسمح بإجراء تغييرات على هياكل البيانات (مثل هياكل الكتل أو أشجار الحالة). *

على الرغم من أن هذه التعديلات قد تبدو بسيطة، إلا أنها تؤثر على توافق إيثريوم. قد يؤدي تغيير هياكل البيانات إلى عدم توافق Ethereum dApps مع النوع 2 ZK-EVM، خاصة عند التحقق من صحة أدلة Merkle حول المعاملات أو الإيصالات أو الحالات السابقة (مثل عبر جسور السلسلة).

حذف عناصر ZK غير ودية

تهدف التعديلات على Ethereum إلى تبسيط عملية التطوير وزيادة سرعة إنشاء الإثبات. الهدف هو تقليم أجزاء الإيثيريوم التي تعتمد على تشفير المعرفة الصفرية غير الودي. وبمصطلحات أكثر تقنية، الأجزاء التي تتطلب عددًا كبيرًا من البوابات (عمليات الجمع والضرب) بسبب المجالات غير المحلية (مثل وظائف التجزئة)، وعدد كبير من الضربات متعددة السلالم و/أو تحويلات فورييه السريعة (FFT)؛ أو فقط الجزء الذي يتطلب الكثير من التلاعب.

أمثلة محددة لعناصر المعرفة الصفرية غير الودية التي قد يعدلها النوع 2 ZK-EVM:

• وظيفة التجزئة: بينما يستخدم Ethereum وظيفة تجزئة Keccak، تستخدم العديد من ZK-EVMs وظيفة تجزئة Poseidon، والتي تتطلب عددًا أقل بكثير من البوابات. على سبيل المثال، دعونا نقدر عدد وظائف التجزئة من كل نوع التي يمكن حسابها في الثانية (أي مقارنة توضح سرعة التوليد).

تتمتع وظائف تجزئة Poseidon بمزايا سرعة كبيرة في إنشاء الإثبات.

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

هذا هو السبب في أن Keccak، على الرغم من كونها أقدم ومعتمدة من قبل مجتمع أوسع (في صناعات أخرى، مثل أنظمة الأمان أو أجهزة الاستشعار في الأجهزة الذكية)، يمكن اعتبارها أكثر تجربة واختبارًا من Poseidon، والتي هي في نهاية المطاف ضمن مجتمع ZK تجزئة جديدة وظائف لإنشاء واستخدام.

• أشجار الحالة لتخزين البيانات: على سبيل المثال، بينما يستخدم Ethereum أشجار Merkle Patricia (باستخدام تجزئة Keccak)، تختار بعض أجهزة ZK-EVM من النوع 2 أشجار Merkle المتفرقة (باستخدام تجزئة Poseidon). قد يؤدي تغيير شجرة الحالة إلى حدوث بعض حالات عدم التوافق. على سبيل المثال، تحتوي شجرة Merkle الخاصة بـ Ethereum على أنواع عقد مختلفة وتستخدم RLP لتشفير البيانات، وهو أمر يصعب القيام به في ZK.
• بنية الكتلة: تحتوي الكتل على كمية كبيرة من المعلومات. ومع ذلك، عند استكشاف L2، فإننا نهتم فقط بـ ution_payload_header (أي تجزئة الكتلة). في الصورة أدناه، توجد البنية (تجزئة الكتلة) لجميع البيانات الموجودة في ution_payload_header.

**يرجى ملاحظة: تغيير أي من هذه المكونات سيؤدي إلى كسر تكافؤ الإيثيريوم. **

النوع 2.5: يعادل EVM، مع الأخذ في الاعتبار تكلفة الغاز

يعمل النوع 2.5 ZK-EVM على زيادة تكلفة الغاز لعمليات محددة يصعب إثباتها باستخدام تقنية ZK في EVM.

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

• الغاز وحدة قياس للعمل .
• يتم احتساب أسعار كود التشغيل بالغاز.
• تحدد رموز التشغيل العمليات ضمن تعليمات لغة الآلة.
• البرنامج عبارة عن قائمة ثابتة من أكواد التشغيل. تنفيذ البرنامج هو تتبع التنفيذ.
• تتبع التنفيذ عبارة عن قائمة مرتبة محددة من أكواد التشغيل التي ينفذها البرنامج.

** الأجزاء التي يصعب إثبات ZK تشمل: **

• أكواد التشغيل Keccak وبعض أكواد التشغيل الأخرى التي تعتمد على Keccak.
• مترجمة مسبقًا: وظائف يمكن الوصول إليها بواسطة EVM. ويقدم بعضها مهام معقدة أو معقدة رياضيا، مثل وظائف التشفير (مثل بليك 2 ف أو شا 256). لا يتم تنفيذها داخل EVM، بل كوظائف تم ترميزها بشكل ثابت في عميل التنفيذ ويتم عرضها على EVM باستخدام المكالمات إلى عناوين خاصة.
• الوصول إلى الذاكرة: على سبيل المثال، زيادة حجم فتحة الذاكرة (على سبيل المثال، يستخدم Ethereum ذاكرة محاذاة للبايت، بينما يستخدم Polygon zkEVM فتحات ذاكرة 32 بايت). لجعل هذا التغيير ممكنًا، كان لا بد من تغيير المنطق الداخلي لبعض أكواد التشغيل (مثل MLOAD).
• التخزين (أي تغيير وظيفة التجزئة أو شجرة الحالة كما هو موضح أعلاه).

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

النوع 3: يعادل تقريبًا EVM

يحذف النوع 3 ZK-EVM الترجمة المسبقة التي لا تنطبق على ZK وقد يضبط الوصول إلى الذاكرة والتخزين.

ستحتاج التطبيقات اللامركزية التي تعتمد على التطبيقات المترجمة مسبقًا التي تمت إزالتها إلى إعادة كتابتها. في حالات غير عادية، قد تتطلب الاختلافات في كيفية التعامل مع حالات الحافة بواسطة النوع 3 ZK-EVM وEVM الأصلي تعديلات على dApp.

النوع 4 (أي ما يعادل لغة عالية المستوى)

النوع 4 بعيد بالفعل عن EVM.

يتم تجميع الكود المصدري للعقد الذكي المكتوب بلغة عالية المستوى (على سبيل المثال، Solidity وZinc) في تمثيل وسيط، مما يؤدي إلى إنشاء أكواد تشغيل مناسبة للأجهزة الافتراضية الصديقة لـ ZK.

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

في دائرة ZK التي تثبت مسار التنفيذ، تنفذ كل خطوة القيد، وتكلفة كل خطوة هي مجموع جميع أكواد التشغيل. لذلك، تم تصميم النوع 4 ZK-EVM لاستخدام أقل عدد ممكن من رموز التشغيل المعقدة لتحسين الكفاءة.

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

لخص

تعطي أنواع ZK-EVM المختلفة الأولوية للأهداف والخصائص المختلفة. يركز النوع الأول على تكافؤ الإيثريوم، بينما يعطي النوع الرابع الأولوية لتوليد إثبات فعال. وتقع الأنواع الأخرى بين هذين النقيضين، وقد أعلنت العديد من بروتوكولات ZK-EVM من النوع 2 و3 عن نيتها الانتقال إلى مكافئات الإيثيريوم.

قد لا تكون هذه الأنواع الأربعة من التصنيف هي الحالة النهائية لمجموعة ZK وقد تخضع لمزيد من التعديلات في المستقبل. على سبيل المثال، قد تصبح بعض ZK-EVMs هجينة، وقد يقوم النوع 1/2 بتطوير حلول من النوع 4 (بأعلى كفاءة ممكنة) وتوفير dApps مع كلا الخيارين، بينما قد يضيف النوع 3 و4 ZK-EVMs خيارًا مكافئًا لـ Ethereum.