فيتاليك مقال جديد: مستقبل وتحديات ZK-EVM

العنوان الأصلي: “كيف يمكن أن يبدو “ZK-EVM المكرس”؟”

المؤلف الأصلي: فيتاليك

التجميع الأصلي: Luccy ، BlockBeats

• ملاحظة المحرر: في 13 ديسمبر ، نشر فيتاليك بوتيرين ، المؤسس المشارك لشركة ETH Place ، مقالا تعمق في التنفيذ المحتمل ل “ZK-EVM” (آلة Ethereum الافتراضية صفر المعرفة) وناقش تصميم إصدارات مختلفة من ZK-EVM. *

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

• بالإضافة إلى ذلك ، ذكر دعم “almost-EVM” ، والذي يسمح للأجهزة الظاهرية L2 باستخدام ZK-EVM داخل البروتوكول مع اختلافات طفيفة فقط عن EVM ، مع توفير المرونة أيضا لبعض التخصيص ل EVM. *

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

هذا الموقف ليس مثاليا ، لأن هذه المشاريع تكرر الوظائف الموجودة بالفعل في بروتوكول ETH Fang ، وحوكمة ETH Fang مسؤولة بالفعل عن ترقية الأخطاء وإصلاحها: يقوم ZK-EVM بشكل أساسي بنفس عمل التحقق من صحة كتل ETH L1! بالإضافة إلى ذلك ، في السنوات القليلة المقبلة ، نتوقع أن يصبح العملاء الخفيفون أكثر قوة ، وقريبا للتحقق الكامل من تنفيذ L1 ETH Fang باستخدام ZK-SNARKs. في هذه المرحلة ، ستحتوي شبكة ETH بشكل فعال على ZK-EVM مدمج. لذا فإن السؤال الذي يطرح نفسه: لماذا لا تجعل توطين ZK-EVM هذا متاحا لمشروع مجموعة التحديثات؟

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

ما هي السمات الرئيسية التي يمكن أن نتوقعها من ZK-EVM المنصوص عليها كمعيار؟

الوظيفة الأساسية: التحقق من صحة كتل ETH. يجب أن تقبل ميزة البروتوكول (التي لا تزال غير مؤكدة ما إذا كانت رمز التشغيل أو التحويل البرمجي المسبق أو آلية أخرى) على الأقل جذر ما قبل الحالة والكتلة وجذر ما بعد الحالة كمدخلات ، والتحقق من أن جذر ما بعد الحالة هو بالفعل نتيجة لتنفيذ كتلة أعلى جذر ما قبل الحالة.

التوافق مع مفهوم ETH متعدد العملاء. هذا يعني أننا نريد تجنب اتباع نظام تصديق واحد وبدلا من ذلك السماح لعملاء مختلفين باستخدام أنظمة تصديق مختلفة. وهذا بدوره يعني بضع نقاط:

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

· يوجد إثبات خارج بنية بيانات EVM وقطعها: لا تستخدم ميزة ZK-EVM بشكل مباشر SNARKs كمدخلات داخل EVM ، حيث يتوقع العملاء المختلفون أنواعا مختلفة من SNARKs. بدلا من ذلك ، قد يكون مشابها للتحقق من صحة blob: يمكن أن تحتوي المعاملات على عبارات تحتاج إلى إثبات (ما قبل الحالة ، وجسم الكتلة ، وما بعد الحالة) ، والتي يمكن الوصول إلى محتوياتها عن طريق رموز التشغيل أو التجميع المسبق ، وستتحقق قواعد الإجماع من جانب العميل من توفر البيانات ووجود أدلة لكل مطالبة يتم إجراؤها في الكتلة ، على التوالي.

قابلية التدقيق. إذا تم إثبات أي تنفيذ ، فنحن نريد أن تكون البيانات الأساسية قابلة للاستخدام بحيث يمكن للمستخدمين والمطورين فحصها في حالة حدوث أي خطأ. في الممارسة العملية ، يضيف هذا سببا آخر لأهمية متطلبات توافر البيانات.

قابلية الترقية. إذا وجدنا ثغرة أمنية في حل ZK-EVM معين ، فنحن نريد أن نكون قادرين على إصلاحه بسرعة. هذا يعني أنه ليست هناك حاجة إلى هارد فورك لإصلاحه. هذا يضيف سببا آخر لإثبات أهمية الوجود خارج EVM وهياكل بيانات الكتلة.

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

أنظمة متعددة العملاء “مفتوحة” و “مغلقة”

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

خيار آخر هو نظام مغلق متعدد العملاء حيث تعرف مجموعة ثابتة من أنظمة التصديق داخل البروتوكول. على سبيل المثال ، قد نقرر استخدام ثلاثة ZK-EVMs: PSE ZK-EVM و Polygon ZK-EVM و Kakarot. يجب أن تحمل الكتلة دليلا على اثنين من هؤلاء الثلاثة حتى يتم اعتبارها صالحة. هذا أفضل من نظام إثبات واحد ، لكنه يجعل النظام أقل قابلية للتكيف لأن المستخدمين يجب أن يحتفظوا بمدققين لكل نظام إثبات معروف ، ولا بد أن تكون هناك عملية حوكمة سياسية لدمج أنظمة إثبات جديدة ، وما إلى ذلك.

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

ما هي الميزات الرئيسية التي نريد أن يتمتع بها تطبيق ZK-EVM؟

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

على الرغم من أن الأمر يستغرق عدة دقائق أو ساعات لإنشاء إثباتات لكتل ETH اليوم ، إلا أننا نعلم أنه لا يوجد سبب نظري لمنع التوازي الشامل: يمكننا دائما الجمع بين ما يكفي من وحدات معالجة الرسومات لإثبات الأجزاء المختلفة من تنفيذ الكتلة بشكل منفصل ثم استخدام SNARKs العودية لوضع هذه البراهين معا. بالإضافة إلى ذلك ، قد يساعد تسريع الأجهزة من خلال FPGAs و ASICs في زيادة تحسين البراهين. ومع ذلك ، فإن الوصول إلى هذه النقطة يمثل تحديا هندسيا كبيرا لا ينبغي الاستهانة به.

كيف قد تبدو ميزات ZK-EVM داخل البروتوكول؟

على غرار معاملات EIP-4844 Blob ، نقدم نوعا جديدا من المعاملات يتضمن مطالبات ZK-EVM:

على غرار EIP-4844 ، سيكون الكائن الذي تم تمريره في mempool نسخة معدلة من المعاملة:

يمكن تحويل الأخير إلى الأول ، ولكن ليس العكس. لقد قمنا أيضا بتوسيع كائن الكتلة الجانبية (الذي تم تقديمه في EIP-4844) ليشمل قائمة من البراهين التي تم إجراؤها في كتلة.

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

في أعلى طبقة الإجماع، أضفنا قاعدة التحقق من الصحة التي تنص على أنه لن يتم قبول الكتلة إلا إذا رأى العميل دليلا صالحا لكل مطالبة في الكتلة. يجب أن يكون الدليل عبارة عن بيان تصديق ZK-SNARK ، أي أن تسلسل المعاملة \ _and \ _witness \ _blobs هو تسلسل زوج (Block ، Witness) ، وتكون كتلة التنفيذ صالحة في pre_state_root باستخدام الشاهد (i) ، و (ii) إخراج المنشور الصحيح _state_root. من المحتمل أن يختار العملاء انتظار M-of-N لأنواع الشهادات المتعددة.

هناك ملاحظة فلسفية هنا مفادها أنه يمكن التعامل مع تنفيذ الكتلة نفسه على أنه شيء يحتاج فقط إلى التحقق منه مع أحد الثلاثيات (σpre ، σpost ، Proof) المتوفرة في كائن ZKEVMClaimTransaction. نتيجة لذلك ، يمكن أن يحل تطبيق ZK-EVM الخاص بالمستخدم محل عميل التنفيذ الخاص به ، والذي سيظل مستخدما من قبل (i) provers وبناة الكتل ، و (ii) العقد التي تهتم بفهرسة البيانات وتخزينها للاستخدام المحلي.

التحقق وإعادة التصديق

لنفترض أن لديك عميلين ETH ، أحدهما يستخدم PSE ZK-EVM والآخر يستخدم Polygon ZK-EVM. لنفترض أنه بحلول هذه المرحلة ، تطور كلا التطبيقين إلى النقطة التي يمكنهما فيها إثبات تنفيذ الكتلة ETH في أقل من 5 ثوان ، ولكل نظام إثبات ، هناك ما يكفي من المتطوعين المستقلين الذين يقومون بتشغيل الأجهزة لإنشاء البراهين.

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

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

يؤدي هذا إلى زيادة إجمالي الحد الأقصى لزمن الوصول بين أقدم عقدة صادقة تقبل كتلة وأحدث عقدة صادقة تقبل نفس الكتلة من δ إلى 2 δ + Tprov (بافتراض أن Tprov < 5 ثوان هنا).

ومع ذلك ، فإن الخبر السار هو أنه إذا أخذنا حتمية الفتحة الواحدة ، فمن شبه المؤكد أنه يمكننا “توجيه” هذا الكمون الإضافي جنبا إلى جنب مع زمن انتقال الإجماع متعدد الجولات المتأصل في SSFs. على سبيل المثال ، في هذا الاقتراح المكون من 4 فتحات ، قد تحتاج خطوة “تصويت الرأس” فقط إلى التحقق من صلاحية الكتلة الأساسية ، لكن خطوة “التجميد والتأكيد” ستتطلب وجود دليل.

التمديد: دعم “تقريبا-EVM”

الهدف المرغوب فيه لميزة ZK-EVM هو دعم “تقريبا-EVM”: EVMs مع بعض الميزات الإضافية. يمكن أن يشمل ذلك التجميع المسبق الجديد ، ورموز التشغيل الجديدة ، والسماح بكتابة العقود في EVMs أو أجهزة افتراضية مختلفة تماما (على سبيل المثال ، في Arbitrum Stylus) ، أو حتى EVMs متوازية متعددة مع اتصال متقاطع متزامن.

يمكن دعم بعض التعديلات بطريقة بسيطة: يمكننا تحديد لغة تسمح ل ZKEVMClaimTransaction بتمرير الوصف الكامل لقواعد EVM المعدلة. يمكن استخدام هذا من أجل:

· جدول تكلفة الغاز المخصص (لا يسمح للمستخدمين بتقليل تكاليف الغاز ، ولكن يمكنهم زيادتها)

· تعطيل بعض رموز التشغيل

· قم بتعيين رقم الكتلة (وهذا يعني أنه ستكون هناك قواعد مختلفة اعتمادا على الهارد فورك)

· قم بتعيين علامة تنشط المجموعة الكاملة من تغييرات EVM التي تم توحيدها لاستخدام L2 بدلا من استخدام L1 ، أو تغييرات أخرى أبسط

من أجل السماح للمستخدمين بإضافة وظائف جديدة عن طريق تقديم ترجمة مسبقة جديدة (أو رموز تشغيلية) بطريقة أكثر انفتاحا ، يمكننا إضافة محتوى يحتوي على نصوص إدخال / إخراج مترجمة مسبقا إلى جزء من نقطة ZKEVMClaimNetworkTransaction:

سيتم تعديل تنفيذ EVM على النحو التالي. ستتم تهيئة إدخالات الصفيف على أنها فارغة. في كل مرة يتم فيها استدعاء العنوان المستخدم _precompile_addresses ، نقوم بإلحاق كائن InputsRecord (callee \ _address ، gas ، input \ _calldata) بالمدخلات وتعيين RETURNDATA للمكالمة على المخرجات[i]。 أخيرا ، نتحقق من أن المستخدم \ _precompile \ _addresses قد تم استدعاؤه len (outputs) إجمالي المرات ، وأن المدخلات \ _commitments تتطابق مع نتيجة تسلسل SSZ لالتزامات blob التي تم إنشاؤها للمدخلات. الغرض من كشف المدخلات \ _commitments هو تسهيل SNARKs الخارجية لإثبات العلاقة بين المدخلات والمخرجات.

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

قد تكون ميزة أخرى مفيدة هي السماح ب “المعاملات المميزة” ، أي المعاملات التي تبدأ المكالمات من أي حساب مرسل. يمكن تشغيل هذه المعاملات بين معاملتين أخريين ، أو عند استدعاء التحويل البرمجي المسبق في معاملة أخرى (وربما مميزة). يمكن استخدام هذا للسماح للآليات غير EVM بالاتصال مرة أخرى ب EVM.

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

· من خلال تعيين used_precompile_addresses ، بما في ذلك قائمة بعناوين الحسابات العادية مع تعيين علامات معينة في كائنات حساباتهم في الولاية ، وإنشاء SNARK لإثبات أنه تم إنشاؤه بشكل صحيح ، يمكنك دعم ميزات نمط Arbitrum Stylus حيث يمكن كتابة رمز العقد في EVM أو WASM (أو أجهزة افتراضية أخرى). يمكن استخدام المعاملات المميزة للسماح باستدعاء حسابات WASM مرة أخرى إلى EVM.

· من خلال إضافة فحص خارجي للتأكد من مطابقة نسخ الإدخال / الإخراج والمعاملات المميزة التي يتم إجراؤها بواسطة EVMs متعددة بالطريقة الصحيحة ، يمكنك إظهار نظام متوازي من EVMs متعددة تتواصل مع بعضها البعض عبر قناة مزامنة.

· يمكن أن يعمل النوع الرابع من ZK-EVM من خلال وجود تطبيقات متعددة: واحد يحول Solidity أو اللغات الأخرى عالية المستوى مباشرة إلى أجهزة افتراضية صديقة ل SNARK ، وآخر يقوم بتجميعها في كود EVM وينفذها في ZK-EVM المكرس. لا يتم تشغيل التنفيذ الثاني (والأبطأ حتما) إلا إذا أرسل محترف الخطأ معاملة تفيد بوجود خطأ ، وإذا كان قادرا على تقديم معاملة يتم التعامل معها بشكل مختلف من قبل الاثنين ، فيمكن مكافأتهم.

· يمكن تحقيق VM غير متزامن تماما عن طريق جعل جميع المكالمات ترجع صفرا وتعيين المكالمات إلى المعاملات المميزة التي تتم إضافتها إلى نهاية الكتلة.

التمديد: دعم المصدقين ذوي الحالة

أحد التحديات في التصميم أعلاه هو أنه عديم الجنسية تماما ، مما يجعله أقل كفاءة من حيث استخدام البيانات. من خلال دعم ضغط الحالة ، يمكن أن توفر عمليات إرسال ERC 20 مساحة أكبر بما يصل إلى 3 أضعاف مقارنة باستخدام الضغط عديم الحالة وحده ، باستخدام ضغط البيانات المثالي.

بالإضافة إلى ذلك ، لا تحتاج EVMs ذات الحالة إلى تقديم بيانات الشهود. في كلتا الحالتين ، المبدأ هو نفسه: إنه مضيعة لطلب إتاحة البيانات ، لأننا نعلم بالفعل أن البيانات قابلة للاستخدام لأنها تم إدخالها أو إنتاجها من خلال تنفيذ سابق ل EVM.

إذا أردنا أن تكون ميزة ZK-EVM ذات حالة ، فلدينا خياران:

1. اطلب أن تكون σpre إما فارغة ، أو قائمة بيانات متاحة لزوج قيمة مفتاح معلن مسبقا ، أو بعض σpost الذي تم تنفيذه مسبقا.

2. أضف التزام النقطة لإيصال تم إنشاؤه بواسطة الكتلة R إلى مجموعة (σpre ، σpost ، Proof). يمكن الرجوع إلى أي وعود blob تم إنشاؤها أو استخدامها مسبقا ، بما في ذلك تلك التي تمثل الكتل أو الشهود أو الإيصالات أو حتى معاملات EIP-4844 blob العادية ، والتي قد يكون لها حد زمني معين ، في ZKEVMClaimTransaction والوصول إليها أثناء تنفيذها (ربما من خلال سلسلة من التعليمات: "أدخل البايت N من الالتزام i في الموضع j من بيانات الكتلة + الشاهد … N+k− 1 」)。

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

الجدل بين الأنظمة المغلقة متعددة المقاومات والبيانات خارج السلسلة

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

ومع ذلك ، فإن الأنظمة المغلقة متعددة المحاور تزيد من تعقيد الحوكمة وتقلل من قابلية التدقيق ، وهي مفاضلة بين التكلفة العالية وهذه الفوائد.

إذا أنشأنا ZK-EVM كميزة بروتوكول ، فما هو الدور المستمر ل “مشروع L2”؟

سيتعامل البروتوكول مع ميزات التحقق من EVM التي تنفذها فرق L2 حاليا ، لكن مشروع L2 سيظل مسؤولا عن عدد من الميزات المهمة:

تأكيد مسبق سريع: يمكن أن تؤدي نهائية الفتحة الواحدة إلى إبطاء فتحات L1 ، وتوفر مشاريع L2 بالفعل لمستخدميها “تأكيدا مسبقا” مدعوما بأمان L2 الخاص ، مع زمن انتقال أقل بكثير من فتحة واحدة. ستظل هذه الخدمة مسؤولية L2 خالصة.

استراتيجيات التخفيف من MEV: قد يشمل ذلك مجموعات mempools المشفرة ، والاختيار المتسلسل المستند إلى السمعة ، والميزات الأخرى التي تحجم L1s عن تنفيذها.

امتدادات ل EVM: يمكن أن تتضمن مشاريع L2 امتدادات كبيرة ل EVM لتوفير قيمة كبيرة لمستخدميها. وهذا يشمل كلا من “EVMs تقريبا” ومناهج مختلفة اختلافا جوهريا مثل دعم WASM من Arbitrum Stylus ولغة القاهرة الصديقة ل SNARK.

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

رابط المقال الأصلي