العنوان الأصلي: "OP + ZK ، هل سيصبح Hybrid Rollup المستقبل النهائي لتوسيع Ethereum؟" "
المنشور الأصلي بواسطةkelvinfichter
التجميع الأصلي: جليل ، بلوك بيتس
لقد أصبحت مؤخرًا مقتنعًا تمامًا أن مستقبل Ethereum Rollup هو في الواقع مزيج من النهجين الرئيسيين ، ZK و Optimistic. في هذا المنشور ، سأحاول وضع الأساسيات لما أتخيله أن تكون هذه البنية ، ولماذا أعتقد أن هذا هو الاتجاه الذي يجب أن نسير فيه. لاحظ أنني أقضي معظم وقتي في العمل على Optimism ، المعروف أيضًا باسم Optimistic Rollup ، لكنني لست خبيرًا في ZK. إذا ارتكبت أي أخطاء في الحديث عن ZK ، فلا تتردد في التواصل معي وسأقوم بتصحيح ذلك.
لا أنوي وصف مبدأ تشغيل ZK و Optimistic Rollups بالتفصيل في هذه المقالة. إذا أمضيت وقتًا في شرح جوهر Rollups ، فستكون هذه المقالة طويلة جدًا. لذلك ، تستند هذه المقالة إلى حقيقة أن لديك بالفعل فهمًا معينًا لهذه التقنيات. بالطبع ، لست بحاجة إلى أن تكون خبيرًا ، ولكن يجب أن تعرف على الأقل ما هي ZK و Optimistic Rollups وآلية التشغيل العامة. على أي حال ، من فضلك استمتع بقراءة هذا المقال.
لنبدأ مع Optimistic Rollup
كان النظام الذي مزج بين ZK و Optimistic Rollup يعتمد في الأصل على Optimistic Rollup بناءً على بنية Bedrock للتفاؤل. تم تصميم Bedrock ليكون متوافقًا إلى أقصى حد ("مكافئ EVM") مع Ethereum من خلال تشغيل عميل تنفيذ متطابق تقريبًا مع عميل Ethereum. يستفيد Bedrock من نموذج تقسيم العميل / التنفيذ القادم من Ethereum ، مما يقلل بشكل كبير من التباين من EVM (بالطبع ستكون هناك دائمًا بعض التغييرات على طول الطريق ، ولكن يمكننا التعامل معها).
[هل سيكون مزيج ZK و OP هو مستقبل Ethereum Rollup؟ ] (https://img-cdn.gateio.im/social/moments-69a80767fe-6c65d0c13b-dd1a6f-7649e1)
مثل جميع التراكميات الجيدة ، يستخرج التفاؤل بيانات الكتلة / المعاملات من Ethereum ، ثم يفرز هذه البيانات بطريقة حتمية في عميل الإجماع ، ويغذي هذه البيانات إلى عميل تنفيذ L2 للتنفيذ. تحل هذه البنية النصف الأول من لغز "التجميع المثالي" وتعطينا مكافئ L2 لـ EVM.
بالطبع ، المشكلة التي ما زلنا بحاجة إلى حلها الآن هي إخبار Ethereum بما حدث داخل التفاؤل بطريقة يمكن التحقق منها. إذا لم يتم حل هذه المشكلة ، فلا يمكن للعقود الذكية اتخاذ قرارات بناءً على حالة التفاؤل. هذا يعني أنه يمكن للمستخدمين الإيداع في التفاؤل ، لكن لا يمكنهم سحب أصولهم. على الرغم من إمكانية تجميع التحديثات في اتجاه واحد في بعض الحالات ، إلا أنه في معظم الحالات ، يكون التجميع ثنائي الاتجاه أكثر فاعلية.
من خلال تقديم نوع من الالتزام بهذه الحالة ، وإثبات صحة هذا الالتزام ، يمكننا توصيل حالة جميع التراكميات إلى Ethereum. بمعنى آخر ، نحن نثبت أن "برنامج التجميع" قد تم تنفيذه بشكل صحيح. الاختلاف الجوهري الوحيد بين ZK و Optimistic Rollups هو شكل هذا الإثبات. في ZK Rollup ، تحتاج إلى تقديم إثبات صريح بعدم المعرفة لإثبات التنفيذ الصحيح للبرنامج. في Optimistic Rollup ، يمكنك الإدلاء ببيان حول الوعد دون تقديم دليل واضح. من خلال تحدي بيانك والتشكيك فيه ، يمكن للمستخدمين الآخرين إجبارك على المشاركة في "لعبة" من المداولات والتحدي ذهابًا وإيابًا لتحديد من هو "نعم" في النهاية.
لن أخوض في التفاصيل حول تحديات Optimistic Rollup. تجدر الإشارة إلى أن أحدث ما توصلت إليه التقنية في هذه المرحلة هو تجميع برنامجك (Geth EVM + بعض البتات الهامشية في حالة التفاؤل) إلى بعض هندسة الماكينة البسيطة مثل MIPS. نقوم بذلك لأننا نحتاج إلى بناء مترجم برنامج على السلسلة ، ومن الأسهل بكثير بناء مترجم MIPS من مترجم EVM. يعد EVM أيضًا هدفًا متحركًا (لدينا شوكات ترقية منتظمة) ولا يغطي بالكامل البرامج التي نريد إثباتها (هناك بعض الأشياء غير المتعلقة بـ EVM هناك أيضًا).
بمجرد إنشاء مترجم فوري على السلسلة لهندسة الآلة البسيطة الخاصة بك ، وإنشاء بعض الأدوات غير المتصلة بالإنترنت ، يجب أن يكون لديك مجموعة Optimistic Rollup تعمل بكامل طاقتها.
انتقل إلى ZK Rollup
بشكل عام ، أعتقد اعتقادًا راسخًا أن التراكمية المتفائلة ستهيمن على مدى السنوات القليلة المقبلة. يعتقد بعض الناس أن ZK Rollups ستتفوق في النهاية على Optimistic Rollups ، لكنني لا أتفق مع هذا الرأي. أشعر أن البساطة والمرونة النسبية الحالية لـ Optimistic Rollups تعني أنه يمكن تحويلها تدريجياً إلى ZK Rollups. إذا تمكنا من العثور على نمط لإجراء هذا الانتقال ، فبدلاً من محاولة بناء نظام بيئي ZK أكثر مرونة وهشاشة ، يمكننا ببساطة نشره في نظام إيكولوجي Optimistic Rollup موجود بالفعل.
لذلك ، فإن هدفي هو إنشاء مسار معماري وهجرة يمكّن نظام OP البيئي الحديث الحالي (مثل Bedrock) من الانتقال بسلاسة إلى نظام ZK البيئي. أعتقد أن هذا ليس ممكنًا فحسب ، بل طريقة لتجاوز نهج zkEVM الحالي.
لنبدأ بهندسة Bedrock التي وصفتها سابقًا. لاحظ أنني أوضحت (باختصار) أن Bedrock لديه لعبة تحدي للتحقق من صحة عمليات تنفيذ معينة لبرامج L2 (برامج MIPS التي تشغل EVM + بعض الإضافات). يتمثل أحد الجوانب السلبية الرئيسية لهذا النهج في أننا نحتاج إلى إتاحة فترة زمنية للمستخدمين لإتاحة الفرصة لاكتشاف اقتراح نتيجة برنامج خاطئ وتحديه بنجاح. يضيف هذا قدرًا كبيرًا من الوقت لعملية سحب الأصول (7 أيام على الشبكة الرئيسية الحالية للتفاؤل).
ومع ذلك ، فإن 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.
تتحول مهمتك إلى اختبار الوقت
يقيس وقت براهين المعرفة الصفرية على محورين: عدد القيود وحجم الدائرة. من خلال التركيز على دوائر آلة بسيطة مثل MIPS (بدلاً من آلة أكثر تعقيدًا مثل EVM) ، تمكنا من تقليل حجم الدائرة وتعقيدها بشكل كبير. ومع ذلك ، فإن عدد القيود يعتمد على عدد تعليمات الجهاز المنفذة. يتم تقسيم كل شفرة تشغيل EVM إلى عدة أكواد تشغيل MIPS ، مما يعني أن عدد القيود يزداد بشكل كبير ، وكذلك وقت الإثبات الإجمالي.
ومع ذلك ، يعد تقليل أوقات الإثبات أيضًا مشكلة متجذرة بعمق في مجال Web2. نظرًا لأنه من غير المرجح أن تتغير بنية آلة MIPS في أي وقت قريب ، يمكننا تحسين الدائرة والمثقف بشكل كبير بغض النظر عن التغييرات المستقبلية في EVM. أشعر بثقة تامة في تعيين مهندس أجهزة كبير لتحسين مشكلة محددة جيدًا ، ربما عشرة أو حتى مائة ضعف عدد المهندسين الذين يقومون ببناء ومراجعة هدف zkEVM المتحرك. من المحتمل أن تمتلك شركة مثل Netflix عددًا كبيرًا من مهندسي الأجهزة الذين يعملون على تحسين رقائق تحويل الشفرات ، ومن المحتمل أن يكونوا على استعداد لإنفاق مجموعة من أموال رأس المال الاستثماري لمواجهة تحدي ZK المثير للاهتمام.
قد يتجاوز وقت الإثبات الأولي لدائرة كهذه فترة سحب التراكمية المتفائلة البالغة 7 أيام. سينخفض وقت الإثبات هذا بمرور الوقت. من خلال تقديم ASICs و FPGAs ، يمكننا تسريع وقت الإثبات بشكل كبير. مع هدف ثابت ، يمكننا بناء المزيد من المحفزات المثلى.
أخيرًا ، سيكون وقت الإثبات لهذه الدائرة أقل من فترة سحب التفاؤل الحالية البالغة 7 أيام ، ويمكننا بدء عملية التحدي للنظر في إزالة التفاؤل. ربما لا يزال تشغيل مثقف لمدة 7 أيام مكلفًا للغاية ، لذلك قد نرغب في الانتظار لفترة أطول قليلاً ، لكن النقطة يمكن الدفاع عنها. يمكنك حتى تشغيل كلا نظامي الإثبات في نفس الوقت ، حتى نتمكن من البدء في استخدام براهين ZK بأسرع ما يمكن والعودة إلى براهين التفاؤل إذا فشل المثل لأي سبب. عندما تكون جاهزًا ، يمكن إزالة أدلة التفاؤل بطريقة شفافة تمامًا للتطبيق ، بحيث تصبح مجموعة Optimistic Rollup الخاصة بك ZK Rollup.
يمكنك الذهاب والاهتمام بالقضايا المهمة الأخرى
يعد تشغيل blockchain مشكلة معقدة تتضمن أكثر من مجرد كتابة الكثير من التعليمات البرمجية الخلفية. في Optimism ، يركز الكثير من عملنا على تحسين تجربة المستخدم والمطور من خلال توفير أدوات مفيدة من جانب العميل. كما أننا نخصص الكثير من الوقت والطاقة في القضايا "اللينة": إجراء محادثات مع المشاريع ، وفهم نقاط الضعف فيها ، وتصميم الحوافز. كلما زاد الوقت الذي تقضيه في برامج السلسلة ، قل الوقت الذي تقضيه في التعامل مع هذه الأشياء الأخرى. بينما يمكنك دائمًا محاولة توظيف المزيد من الأشخاص ، لا تتوسع المؤسسات بشكل خطي ، ويزيد كل موظف جديد من تكاليف الاتصال الداخلي.
نظرًا لأنه يمكن تطبيق عمل دائرة المعرفة الصفرية بشكل مباشر على السلسلة التي تعمل بالفعل ، يمكنك بناء النظام الأساسي الأساسي وتطوير برنامج الإثبات في نفس الوقت. نظرًا لأنه يمكن تعديل العميل دون تغيير الدائرة ، يمكنك فصل العميل وفريق الإثبات. يمكن أن يكون التراكمي المتفائل بهذه الطريقة متقدمًا بسنوات على المنافسين ذوي المعرفة الصفرية من حيث النشاط الفعلي على السلسلة.
ختاماً
بصراحة تامة ، لا أرى أي جوانب سلبية كبيرة لمثقف zkMIPS ، ما لم يكن من الممكن تحسينه بشكل كبير بمرور الوقت. التأثير الحقيقي الوحيد الذي أراه على التطبيق هو أن تكلفة الغاز لأكواد التشغيل المختلفة قد تحتاج إلى تعديل لتعكس وقت الإثبات المتزايد لأكواد التشغيل هذه. إذا لم يكن من الممكن حقًا تحسين هذا المثل إلى مستوى معقول ، فأنا أعترف بأنني فشلت. ولكن إذا كان من الممكن تحسين هذا المُثبِت ، فقد يحل نهج zkMIPS / zkVM محل نهج zkEVM الحالي تمامًا. قد يبدو هذا بمثابة تصريح جذري ، ولكن منذ وقت ليس ببعيد ، تم استبدال براهين الفشل المتفائلة ذات الخطوة الواحدة تمامًا بأدلة متعددة الخطوات.
الارتباط الأصلي
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
هل سيكون مزيج ZK و OP هو مستقبل Ethereum Rollup؟
العنوان الأصلي: "OP + ZK ، هل سيصبح Hybrid Rollup المستقبل النهائي لتوسيع Ethereum؟" "
المنشور الأصلي بواسطةkelvinfichter
التجميع الأصلي: جليل ، بلوك بيتس
لقد أصبحت مؤخرًا مقتنعًا تمامًا أن مستقبل Ethereum Rollup هو في الواقع مزيج من النهجين الرئيسيين ، ZK و Optimistic. في هذا المنشور ، سأحاول وضع الأساسيات لما أتخيله أن تكون هذه البنية ، ولماذا أعتقد أن هذا هو الاتجاه الذي يجب أن نسير فيه. لاحظ أنني أقضي معظم وقتي في العمل على Optimism ، المعروف أيضًا باسم Optimistic Rollup ، لكنني لست خبيرًا في ZK. إذا ارتكبت أي أخطاء في الحديث عن ZK ، فلا تتردد في التواصل معي وسأقوم بتصحيح ذلك.
لا أنوي وصف مبدأ تشغيل ZK و Optimistic Rollups بالتفصيل في هذه المقالة. إذا أمضيت وقتًا في شرح جوهر Rollups ، فستكون هذه المقالة طويلة جدًا. لذلك ، تستند هذه المقالة إلى حقيقة أن لديك بالفعل فهمًا معينًا لهذه التقنيات. بالطبع ، لست بحاجة إلى أن تكون خبيرًا ، ولكن يجب أن تعرف على الأقل ما هي ZK و Optimistic Rollups وآلية التشغيل العامة. على أي حال ، من فضلك استمتع بقراءة هذا المقال.
لنبدأ مع Optimistic Rollup
كان النظام الذي مزج بين ZK و Optimistic Rollup يعتمد في الأصل على Optimistic Rollup بناءً على بنية Bedrock للتفاؤل. تم تصميم Bedrock ليكون متوافقًا إلى أقصى حد ("مكافئ EVM") مع Ethereum من خلال تشغيل عميل تنفيذ متطابق تقريبًا مع عميل Ethereum. يستفيد Bedrock من نموذج تقسيم العميل / التنفيذ القادم من Ethereum ، مما يقلل بشكل كبير من التباين من EVM (بالطبع ستكون هناك دائمًا بعض التغييرات على طول الطريق ، ولكن يمكننا التعامل معها).
[هل سيكون مزيج ZK و OP هو مستقبل Ethereum Rollup؟ ] (https://img-cdn.gateio.im/social/moments-69a80767fe-6c65d0c13b-dd1a6f-7649e1)
مثل جميع التراكميات الجيدة ، يستخرج التفاؤل بيانات الكتلة / المعاملات من Ethereum ، ثم يفرز هذه البيانات بطريقة حتمية في عميل الإجماع ، ويغذي هذه البيانات إلى عميل تنفيذ L2 للتنفيذ. تحل هذه البنية النصف الأول من لغز "التجميع المثالي" وتعطينا مكافئ L2 لـ EVM.
بالطبع ، المشكلة التي ما زلنا بحاجة إلى حلها الآن هي إخبار Ethereum بما حدث داخل التفاؤل بطريقة يمكن التحقق منها. إذا لم يتم حل هذه المشكلة ، فلا يمكن للعقود الذكية اتخاذ قرارات بناءً على حالة التفاؤل. هذا يعني أنه يمكن للمستخدمين الإيداع في التفاؤل ، لكن لا يمكنهم سحب أصولهم. على الرغم من إمكانية تجميع التحديثات في اتجاه واحد في بعض الحالات ، إلا أنه في معظم الحالات ، يكون التجميع ثنائي الاتجاه أكثر فاعلية.
من خلال تقديم نوع من الالتزام بهذه الحالة ، وإثبات صحة هذا الالتزام ، يمكننا توصيل حالة جميع التراكميات إلى Ethereum. بمعنى آخر ، نحن نثبت أن "برنامج التجميع" قد تم تنفيذه بشكل صحيح. الاختلاف الجوهري الوحيد بين ZK و Optimistic Rollups هو شكل هذا الإثبات. في ZK Rollup ، تحتاج إلى تقديم إثبات صريح بعدم المعرفة لإثبات التنفيذ الصحيح للبرنامج. في Optimistic Rollup ، يمكنك الإدلاء ببيان حول الوعد دون تقديم دليل واضح. من خلال تحدي بيانك والتشكيك فيه ، يمكن للمستخدمين الآخرين إجبارك على المشاركة في "لعبة" من المداولات والتحدي ذهابًا وإيابًا لتحديد من هو "نعم" في النهاية.
لن أخوض في التفاصيل حول تحديات Optimistic Rollup. تجدر الإشارة إلى أن أحدث ما توصلت إليه التقنية في هذه المرحلة هو تجميع برنامجك (Geth EVM + بعض البتات الهامشية في حالة التفاؤل) إلى بعض هندسة الماكينة البسيطة مثل MIPS. نقوم بذلك لأننا نحتاج إلى بناء مترجم برنامج على السلسلة ، ومن الأسهل بكثير بناء مترجم MIPS من مترجم EVM. يعد EVM أيضًا هدفًا متحركًا (لدينا شوكات ترقية منتظمة) ولا يغطي بالكامل البرامج التي نريد إثباتها (هناك بعض الأشياء غير المتعلقة بـ EVM هناك أيضًا).
بمجرد إنشاء مترجم فوري على السلسلة لهندسة الآلة البسيطة الخاصة بك ، وإنشاء بعض الأدوات غير المتصلة بالإنترنت ، يجب أن يكون لديك مجموعة Optimistic Rollup تعمل بكامل طاقتها.
انتقل إلى ZK Rollup
بشكل عام ، أعتقد اعتقادًا راسخًا أن التراكمية المتفائلة ستهيمن على مدى السنوات القليلة المقبلة. يعتقد بعض الناس أن ZK Rollups ستتفوق في النهاية على Optimistic Rollups ، لكنني لا أتفق مع هذا الرأي. أشعر أن البساطة والمرونة النسبية الحالية لـ Optimistic Rollups تعني أنه يمكن تحويلها تدريجياً إلى ZK Rollups. إذا تمكنا من العثور على نمط لإجراء هذا الانتقال ، فبدلاً من محاولة بناء نظام بيئي ZK أكثر مرونة وهشاشة ، يمكننا ببساطة نشره في نظام إيكولوجي Optimistic Rollup موجود بالفعل.
لذلك ، فإن هدفي هو إنشاء مسار معماري وهجرة يمكّن نظام OP البيئي الحديث الحالي (مثل Bedrock) من الانتقال بسلاسة إلى نظام ZK البيئي. أعتقد أن هذا ليس ممكنًا فحسب ، بل طريقة لتجاوز نهج zkEVM الحالي.
لنبدأ بهندسة Bedrock التي وصفتها سابقًا. لاحظ أنني أوضحت (باختصار) أن Bedrock لديه لعبة تحدي للتحقق من صحة عمليات تنفيذ معينة لبرامج L2 (برامج MIPS التي تشغل EVM + بعض الإضافات). يتمثل أحد الجوانب السلبية الرئيسية لهذا النهج في أننا نحتاج إلى إتاحة فترة زمنية للمستخدمين لإتاحة الفرصة لاكتشاف اقتراح نتيجة برنامج خاطئ وتحديه بنجاح. يضيف هذا قدرًا كبيرًا من الوقت لعملية سحب الأصول (7 أيام على الشبكة الرئيسية الحالية للتفاؤل).
ومع ذلك ، فإن 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.
تتحول مهمتك إلى اختبار الوقت
يقيس وقت براهين المعرفة الصفرية على محورين: عدد القيود وحجم الدائرة. من خلال التركيز على دوائر آلة بسيطة مثل MIPS (بدلاً من آلة أكثر تعقيدًا مثل EVM) ، تمكنا من تقليل حجم الدائرة وتعقيدها بشكل كبير. ومع ذلك ، فإن عدد القيود يعتمد على عدد تعليمات الجهاز المنفذة. يتم تقسيم كل شفرة تشغيل EVM إلى عدة أكواد تشغيل MIPS ، مما يعني أن عدد القيود يزداد بشكل كبير ، وكذلك وقت الإثبات الإجمالي.
ومع ذلك ، يعد تقليل أوقات الإثبات أيضًا مشكلة متجذرة بعمق في مجال Web2. نظرًا لأنه من غير المرجح أن تتغير بنية آلة MIPS في أي وقت قريب ، يمكننا تحسين الدائرة والمثقف بشكل كبير بغض النظر عن التغييرات المستقبلية في EVM. أشعر بثقة تامة في تعيين مهندس أجهزة كبير لتحسين مشكلة محددة جيدًا ، ربما عشرة أو حتى مائة ضعف عدد المهندسين الذين يقومون ببناء ومراجعة هدف zkEVM المتحرك. من المحتمل أن تمتلك شركة مثل Netflix عددًا كبيرًا من مهندسي الأجهزة الذين يعملون على تحسين رقائق تحويل الشفرات ، ومن المحتمل أن يكونوا على استعداد لإنفاق مجموعة من أموال رأس المال الاستثماري لمواجهة تحدي ZK المثير للاهتمام.
قد يتجاوز وقت الإثبات الأولي لدائرة كهذه فترة سحب التراكمية المتفائلة البالغة 7 أيام. سينخفض وقت الإثبات هذا بمرور الوقت. من خلال تقديم ASICs و FPGAs ، يمكننا تسريع وقت الإثبات بشكل كبير. مع هدف ثابت ، يمكننا بناء المزيد من المحفزات المثلى.
أخيرًا ، سيكون وقت الإثبات لهذه الدائرة أقل من فترة سحب التفاؤل الحالية البالغة 7 أيام ، ويمكننا بدء عملية التحدي للنظر في إزالة التفاؤل. ربما لا يزال تشغيل مثقف لمدة 7 أيام مكلفًا للغاية ، لذلك قد نرغب في الانتظار لفترة أطول قليلاً ، لكن النقطة يمكن الدفاع عنها. يمكنك حتى تشغيل كلا نظامي الإثبات في نفس الوقت ، حتى نتمكن من البدء في استخدام براهين ZK بأسرع ما يمكن والعودة إلى براهين التفاؤل إذا فشل المثل لأي سبب. عندما تكون جاهزًا ، يمكن إزالة أدلة التفاؤل بطريقة شفافة تمامًا للتطبيق ، بحيث تصبح مجموعة Optimistic Rollup الخاصة بك ZK Rollup.
يمكنك الذهاب والاهتمام بالقضايا المهمة الأخرى
يعد تشغيل blockchain مشكلة معقدة تتضمن أكثر من مجرد كتابة الكثير من التعليمات البرمجية الخلفية. في Optimism ، يركز الكثير من عملنا على تحسين تجربة المستخدم والمطور من خلال توفير أدوات مفيدة من جانب العميل. كما أننا نخصص الكثير من الوقت والطاقة في القضايا "اللينة": إجراء محادثات مع المشاريع ، وفهم نقاط الضعف فيها ، وتصميم الحوافز. كلما زاد الوقت الذي تقضيه في برامج السلسلة ، قل الوقت الذي تقضيه في التعامل مع هذه الأشياء الأخرى. بينما يمكنك دائمًا محاولة توظيف المزيد من الأشخاص ، لا تتوسع المؤسسات بشكل خطي ، ويزيد كل موظف جديد من تكاليف الاتصال الداخلي.
نظرًا لأنه يمكن تطبيق عمل دائرة المعرفة الصفرية بشكل مباشر على السلسلة التي تعمل بالفعل ، يمكنك بناء النظام الأساسي الأساسي وتطوير برنامج الإثبات في نفس الوقت. نظرًا لأنه يمكن تعديل العميل دون تغيير الدائرة ، يمكنك فصل العميل وفريق الإثبات. يمكن أن يكون التراكمي المتفائل بهذه الطريقة متقدمًا بسنوات على المنافسين ذوي المعرفة الصفرية من حيث النشاط الفعلي على السلسلة.
ختاماً
بصراحة تامة ، لا أرى أي جوانب سلبية كبيرة لمثقف zkMIPS ، ما لم يكن من الممكن تحسينه بشكل كبير بمرور الوقت. التأثير الحقيقي الوحيد الذي أراه على التطبيق هو أن تكلفة الغاز لأكواد التشغيل المختلفة قد تحتاج إلى تعديل لتعكس وقت الإثبات المتزايد لأكواد التشغيل هذه. إذا لم يكن من الممكن حقًا تحسين هذا المثل إلى مستوى معقول ، فأنا أعترف بأنني فشلت. ولكن إذا كان من الممكن تحسين هذا المُثبِت ، فقد يحل نهج zkMIPS / zkVM محل نهج zkEVM الحالي تمامًا. قد يبدو هذا بمثابة تصريح جذري ، ولكن منذ وقت ليس ببعيد ، تم استبدال براهين الفشل المتفائلة ذات الخطوة الواحدة تمامًا بأدلة متعددة الخطوات.
الارتباط الأصلي