اشرح الأنواع الخمسة من ZK-EVM بالتفصيل: الهندسة المعمارية ، المزايا والعيوب والحلول

مؤلف النص الأصلي: تجميع النص الأصلي: Deep Tide TechFlow

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

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

دعنا نستكشف أنواع ZK-EVM ومزاياها وعيوبها.

1. النوع 1: مكافئ تمامًا لـ Ethereum ؛

2. النوع 2: مكافئ تمامًا لـ EVM ؛

3. النوع 2.5: مكافئ جزئي لـ EVM ؛

4. النوع 3: مكافئ تقريبًا لـ EVM ؛

5. اكتب 4: حيث تكون اللغة عالية المستوى متكافئة.

! [تفصيلي خمسة أنواع من ZK-EVM: الهندسة المعمارية ، المزايا والعيوب والحلول] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-e9c783f5e9-dd1a6f-7649e1)

النوع 1: مكافئ تمامًا لـ Ethereum

الهندسة المعمارية: إنها تمامًا مثل Ethereum ولا تغير أي جزء من نظام Ethereum.

ميزة

التوافق التام:

• القدرة على التحقق من كتل Ethereum ؛
• المساعدة في جعل Ethereum L1 أكثر قابلية للتوسع ؛
• مناسب للتجميعات حيث يمكنهم إعادة استخدام الكثير من البنية التحتية.

عيب

التوافق التام:

• لم يتم تصميم Ethereum في الأصل لوظيفة ZK ؛
• تتطلب العديد من مكونات Ethereum الكثير من الحسابات لإنشاء أدلة ZK (ZKP) ؛
• يستغرق إنشاء إثباتات كتل Ethereum عدة ساعات.

حل المشكلة:

• مَثَل موازاة واسعة النطاق ؛
• ZK-SNARK ASIC.

النوع 2: مكافئ تمامًا لـ EVM

بنيان:

• تختلف بنية البيانات (بنية الكتلة وشجرة الحالة) اختلافًا كبيرًا عن Ethereum ؛
• متوافق تمامًا مع التطبيقات الحالية ؛
• تعديلات طفيفة على Ethereum من أجل تطوير أسهل وتوليد برهان أسرع.

ميزة

• يوفر أوقات إثبات أسرع من النوع 1 ؛
• لا يتم الوصول إلى بنية البيانات مباشرة بواسطة EVM ؛
• التطبيقات التي تعمل على Ethereum: من المحتمل أن تعمل على النوع 2 ؛
• دعم أدوات تصحيح أخطاء EVM الحالية والبنية التحتية للتطوير الأخرى.

عيب

قبل فهم العيوب ، افهم أولاً ما هو “Keccak”:

• خوارزمية التجزئة في Ethereum blockchain ؛
• تستخدم لحماية البيانات على Ethereum ؛
• تأكد من تحويل الرسالة إلى تجزئة.

النوع 2 غير متوافق مع التطبيقات التي تتحقق من أدلة Merkle للكتل التاريخية للتحقق من المعلومات حول المعاملات التاريخية والإيصالات / الحالات. هذا لأنه إذا تغيرت خوارزمية التجزئة (لم تعد Keccak) ، فسيصبح الإثبات غير صالح.

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

الحل المحتمل لأوجه القصور: يمكن أن تضيف Ethereum التجميع المسبق للوصول إلى التاريخ القابل للتطوير في المستقبل.

مشروع

• التمرير ؛
• مضلع هيرمز.

ومع ذلك ، فإن هذه المشاريع لم تنفذ بعد تجميعًا أكثر تعقيدًا ، وبالتالي ، يمكن اعتبارها غير مكتملة من النوع 2.

النوع 2.5: مكافئ جزئيًا لـ EVM

بنيان:

زيادة تكلفة الغاز لعمليات EVM المحددة التي يصعب إثبات ZK ؛

• مترجمة مسبقا.
• كود تشغيل Keccak ؛
• طريقة استدعاء العقد.
• ذاكرة الوصول ؛
• تخزين.

ميزة

• تحسن بشكل ملحوظ وقت إثبات الحالة الأسوأ ؛
• أكثر أمانًا من إجراء تغييرات أعمق على مكدس EVM.

عيب

• تقليل توافق أدوات التطوير ؛
• لن تعمل بعض التطبيقات.

النوع 3: مكافئ تقريبًا لـ EVM

بنيان:

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

ميزة

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

عيب

• المزيد من حالات عدم التوافق.
• ستحتاج التطبيقات التي تستخدم الترجمة المسبقة التي تمت إزالتها في النوع 3 إلى إعادة كتابتها.

مشروع

حاليًا ، يعتبر Scroll و Polygon من النوع 3 ، ومع ذلك ، لا ينبغي أن يكون فريق ZK-EVM راضيًا عن النوع 3 ، والنوع 3 هو مرحلة انتقالية حيث يضيف ZK-EVM التجميع المسبق لتحسين التوافق والانتقال إلى النوع 2.5.

النوع 4: مكافئ لغوي عالي المستوى

بنيان:

• قبول رمز العقد الذكي المكتوب بلغات عالية المستوى (مثل Solidity و Vyper) ؛
• تم تجميعه بلغة مصممة لتكون صديقة لـ ZK-SNARK.

ميزة

• وقت إثبات سريع جدًا ؛
• تقليل النفقات العامة (التكلفة والوقت والجهد الحسابي) ؛
• خففي حاجز التحول إلى المثل: زدوا درجة اللامركزية.

عيب

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

! [تفصيلي خمسة أنواع من ZK-EVM: الهندسة المعمارية ، المزايا والعيوب والحلول] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-80d37e97c2-dd1a6f-7649e1)

مشروع

• zkSync

أخيرًا ، يمكننا مقارنة الأنواع المذكورة أعلاه معًا لمساعدة الجميع على فهم نماذج zkEVM المختلفة في لمحة.

! [تفصيلي خمسة أنواع من ZK-EVM: الهندسة المعمارية ، المزايا والعيوب والحلول] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-7b7ad7fe91-dd1a6f-7649e1)