مناقشة حول ZK / Optimistic Hybrid Rollup

المؤلف: kelvinfichter ؛ المترجم: MarsBit ، MK

لقد أصبحت مقتنعًا مؤخرًا أن مستقبل Ethereum Rollups هو في الواقع مزيج من النهجين الرئيسيين (ZK و Optimistic). في هذا المنشور ، سأحاول شرح البنية الأساسية لما أتخيله وأشرح لماذا أعتقد أن هذا هو أفضل طريق للمضي قدمًا.

لن أقضي الكثير من الوقت في مناقشة طبيعة ZK أو Optimistic Rollups. يفترض هذا المنشور أن لديك بالفعل فهمًا جيدًا لكيفية عمل هذه الأشياء. لست بحاجة إلى أن تكون خبيرًا ، ولكن يجب أن تعرف على الأقل ما هي وكيف تعمل على مستوى عالٍ. إذا حاولت شرح Rollups لك ، فستكون هذه المشاركة طويلة جدًا جدًا. الكل في الكل ، استمتع بالقراءة!

** ابدأ بـ Optimistic Rollup **

بدأ Hybrid ZK / Optimistic Rollup كـ Optimistic Rollup ، وهو مشابه جدًا لهندسة Bedrock للتفاؤل. يهدف Bedrock إلى أقصى قدر من التوافق مع Ethereum ("EVM Equivalent") ، ويحقق ذلك من خلال تشغيل عميل تنفيذ مطابق تقريبًا لعميل Ethereum عادي. يستخدم Bedrock نموذج فصل العميل / التنفيذ القادم من Ethereum ، مما يقلل بشكل كبير من التباين في EVM (ستكون بعض التغييرات مطلوبة دائمًا ، ولكن يمكننا إدارة ذلك). بينما أكتب هذا ، فإن فرق Bedrock Geth هو +388-30 التزام.

! [الوقت] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-4c8b4d3697-dd1a6f-7649e1)

مثل أي مجموعة بيانات جيدة ، يأخذ Optimism بيانات الكتلة / المعاملات من Ethereum ، ويفرز هذه البيانات بطريقة حتمية داخل عميل الإجماع ، ثم يغذي هذه البيانات في عميل تنفيذ L2 للتنفيذ. تحل هذه البنية النصف الأول من لغز "التجميع المثالي" ، مما يمنحنا مكافئًا لـ EVM L2.

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

يمكننا إخبار Ethereum بحالة أي تراكم من خلال تقديم التزام لتلك الحالة وإثبات أن الالتزام قد تم إنشاؤه بشكل صحيح. طريقة أخرى لقول ذلك هي أننا نثبت أن "برنامج التجميع" تم تنفيذه بشكل صحيح. الفرق الحقيقي الوحيد بين ZK و Optimistic Rollups هو شكل هذا الدليل. في ZK Rollup ، تحتاج إلى تقديم دليل صريح لـ ZK على أن البرنامج قد تم تنفيذه بشكل صحيح. في Optimistic Rollup ، تقدم ادعاءات حول الوعود ، لكن لا توجد أدلة واضحة. يمكن للمستخدمين الآخرين تحدي ادعاءاتك وإجبارك على لعب لعبة تكرارية حيث تكتشف في النهاية من هو على حق.

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

بمجرد إنشاء مترجم فوري على السلسلة لهندسة الآلة البسيطة الخاصة بك ، وإنشاء بعض الأدوات خارج السلسلة ، يجب أن يكون لديك مجموعة Optimistic Rollup تعمل بكامل طاقتها.

** تم تحويله إلى ZK Rollup **

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

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

نبدأ بالهندسة المعمارية على طراز Bedrock التي وصفتها أعلاه. لاحظ أنني (باختصار) أوضحت كيف أن Bedrock لديه لعبة تحدي تؤكد على برنامج L2 (تشغيل EVM + بعض الأشياء الإضافية لتحويلها إلى ZK Rollup

بشكل عام ، أعتقد أن التراكمية المتفائلة ستهيمن على مدى السنوات القليلة المقبلة. هناك رأي مفاده أن ZK Rollup سيتفوق في النهاية على Optimistic Rollup ، لكنني أعتقد أن هذا قد يكون خطأ. أعتقد أن البساطة والمرونة النسبية لـ Optimistic Rollups تعني أنه يمكن تحويلها إلى ZK Rollups بمرور الوقت. إذا تمكنا من اكتشاف نموذج لهذا الانتقال ، فلا يوجد حافز قوي للنشر إلى أنظمة ZK أقل مرونة وأكثر عرضة للمشكلات.

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

نبدأ بالهندسة المعمارية على طراز Bedrock التي وصفتها سابقًا. لاحظ أنني (باختصار) أوضحت كيف أن Bedrock لديه لعبة التحدي التي يمكن أن تؤكد صحة تنفيذ برنامج L2 (برنامج MIPS يقوم بتشغيل EVM + بعض الإضافات). تتمثل إحدى العوائق الرئيسية لهذا النهج في أننا نحتاج إلى إتاحة فترة زمنية للمستخدم لاكتشاف اقتراح نتيجة برنامج خاطئ وتحديه بنجاح. يضيف هذا قدرًا كبيرًا من الوقت لعملية سحب الأصول (حاليًا 7 أيام على Optimism mainnet).

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

** لماذا تعمل هذه الطريقة بشكل جيد **

ملاحظة سريعة: في هذا القسم ، ذكرت "zkMIPS" ، لكنني حقًا أستخدمها للإشارة إلى أي zkVM "بسيط" عام.

** zkMIPS أبسط من zkEVM **

من الفوائد الكبيرة لبناء zkMIPS (أو zk [أدخل اسم الجهاز الآخر]) بدلاً من zkEVM أن بنية الجهاز المستهدف بسيطة وثابتة. يتغير EVM بشكل متكرر. ستتغير أسعار الغاز ، وسيتم تعديل أكواد التشغيل ، وستتم إضافة الأشياء أو إزالتها. ولم يتغير MIPS-V منذ عام 1996. من خلال استهداف zkMIPS ، فإنك تعمل على مساحة مشكلة ثابتة. لست بحاجة إلى التغيير وربما إعادة تدقيق دائرتك في كل مرة يتم فيها تحديث EVM.

** zkMIPS أكثر مرونة من zkEVM **

نقطة الخلاف الرئيسية الأخرى هي أن zkMIPS أكثر مرونة من zkEVM. مع zkMIPS ، لديك المزيد من المرونة لتعديل رمز العميل حسب الرغبة لتحقيق تحسينات متنوعة أو تحسينات في تجربة المستخدم. لم تعد هناك حاجة لتحديثات العميل مع تحديثات الدائرة. يمكنك أيضًا إنشاء مكون أساسي يمكن استخدامه لتحويل أي blockchain إلى ZK Rollup ، وليس فقط Ethereum.

** سؤالك يتحول إلى وقت إثبات **

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

لكن تقليل أوقات الإثبات هو مشكلة متجذرة بقوة في مساحة Web2. بالنظر إلى أن بنية آلة MIPS لن تتغير في المستقبل القريب ، يمكننا تحسين دوائرنا وبرامج الإثبات بشكل كبير دون القلق بشأن تغييرات EVM في مرحلة لاحقة. أنا متأكد تمامًا من أن مجموعة التوظيف لمهندسي الأجهزة الذين يمكنهم تحسين برنامج محدد جيدًا هي على الأقل 10 مرات (إن لم يكن 100) أكبر من مجموعة التوظيف لبناء ومراجعة هدف zkEVM المتغير باستمرار. ربما يكون لدى شركة مثل Netflix الكثير من مهندسي الأجهزة الذين يعملون على تحسين رقائق تحويل الشفرات ، ويسعدهم قبول مجموعة من أموال VC لمواجهة تحدي ZK المثير للاهتمام.

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

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

** يمكنك التركيز على قضايا مهمة أخرى **

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

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

** **** بعض الاستنتاجات **

لكي أكون صريحًا تمامًا ، لا يمكنني رؤية أي جانب سلبي كبير لهذا النهج بافتراض أنه يمكن تحسين مُثبّت zkMIPS بشكل كبير بمرور الوقت. التأثير الحقيقي الوحيد الذي أراه على التطبيق هو أن تكاليف الغاز لأكواد التشغيل المختلفة قد تحتاج إلى تعديل لتعكس وقت الإثبات الذي أضافته أكواد التشغيل هذه. إذا كان من المستحيل حقًا تحسين هذا المثل إلى مستوى معقول ، فأنا أعترف بالهزيمة. إذا كان من الممكن بالفعل تحسين هذا المُثبِت ، فإن نهج zkMIPS / zkVM يبدو أفضل بكثير من نهج zkEVM الحالي الذي قد يجعل الأخير عفا عليه الزمن تمامًا. قد يبدو هذا بمثابة بيان جذري ، ولكن منذ وقت ليس ببعيد ، تم استبدال براهين الفشل المتفائلة ذات الخطوة الواحدة تمامًا بأدلة متعددة الخطوات.