A16Z: استكشاف المسار الفعال والآمن لـ ZKVM

المؤلف: جوستين تالر المصدر: A16Z الترجمة: شان أوبا ، رؤية Baitchain

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

التحديات

يخرجحمايةمن ناحية ، تعد ZKVMs مشاريع برمجيات معقدة للغاية لا تزال مليئة بالضعف.

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

ومع ذلك ، لا تزال العديد من الأصوات في صناعة blockchain تعزز ZKVMsيمكن نشرها على الفور، وحتى بعض المشاريع تدفع بالفعل تكاليف حسابية عالية لتوليد أدلة المعرفة صفرية على النشاط على السلسلة.ومع ذلك ، نظرًا لعدم وجود العديد من نقاط الضعف في ZKVMS ، فإن هذا النهج هو في الواقع فقطتمويه باهظ الثمن، جعل النظام يبدو كما هو محمي من قبل Snark ، في الواقع يعتمد في الواقع علىالتحكم في الإذن، أو أسوأ-التعرض لمخاطر الهجوم.

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

مرحلة تطوير السلامة

خلفية

مرتكز علىSnarkلZKVMSعادة ما يحتوي على مكونين أساسيين:

1.إثبات أوراكل التفاعلي متعدد الحدود (PIOP): إطار إثبات تفاعلي لتدقيق متعدد الحدود (أو القيود المستمدة من متعدد الحدود).

2.مخطط الالتزام متعدد الحدود (PCS): تأكد من أن المثل لا يمكنه صياغة نتائج التقييم متعدد الحدود دون اكتشاف.

ZKVM PASSقم بتشفير مسارات تنفيذ صالحة في أنظمة القيود، تأكد من الجهاز الظاهرييسجلوذاكرةثم استخدم Snark لإثبات رضا هذه القيود.

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

المرحلة الأمنية 1: البروتوكول الصحيح

1. التحقق الرسمي من موثوقية piop ؛

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

3. إذا تم استخدام Fiat-shamir ، فإن الوسيطة الموجزة التي تم الحصول عليها من خلال الجمع بين PIOP وأجهزة الكمبيوتر هي دليل التحقق الرسمي للأمان في نموذج Oracle العشوائي (معززة مع افتراضات التشفير الأخرى حسب الحاجة) ؛

4. نظام القيد الذي يطبقه PIOP يعادل إثبات التحقق الرسمي من دلالات VMS ؛

5. كل هذه الأقسام “لصقها” بالكامل في دليل واحد آمن مؤكدة رسميًا لتشغيل أي برنامج محدد بواسطة VM bytecode.إذا كان البروتوكول يعتزم تنفيذ المعرفة الصفرية ، فيجب التحقق من هذه السمة رسميًا لضمان عدم الكشف عن المعلومات الحساسة حول الشاهد.

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

المرحلة الأمنية 2: تنفيذ التحقق الصحيح

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

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

المرحلة الأمنية 3: تطبيق المثل الصحيح

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

الجدول الزمني المقدر

المرحلة 1 التقدم: يمكننا أن نتطلع إلى بعض التقدم في العام المقبل (على سبيل المثال ،ZKLIBهذا جهد).ولكن لا يمكن لأي ZKVM تلبية متطلبات المرحلة الأولى خلال عامين على الأقل.

المرحلتين 2 و 3: يمكن تطوير هذه المراحل في وقت واحد مع جوانب معينة من المرحلة 1.على سبيل المثال ، أثبتت بعض الفرق أن تنفيذ مدقق Plonk يطابق البروتوكول في الورقة (على الرغم من أن البروتوكول نفسه قد لا يتم التحقق منه بالكامل).ومع ذلك ، لا أتوقع أن تصل أي ZKVM إلى المرحلة 3 في أقل من أربع سنوات – ربما أطول.

ملاحظات رئيسية: أمان فيات شامير مقابل رمز البايت المُحقن

مشكلة التعقيد الرئيسية هي ذلكلا تزال هناك أسئلة بحثية لم يتم حلها حول أمان تحول فيات شامير.تعامل جميع المراحل الأمنية الثلاث في Fiat-Shamir و Random Oracles على أنها آمنة تمامًا ، ولكن في الواقع قد تكون هناك نقاط ضعف في النموذج بأكمله.هذا بسببهناك فرق بين النموذج المثالي لـ Oracle العشوائي ووظيفة التجزئة المستخدمة بالفعل.

في أسوأ حالات ، وصل المرءمرحلة السلامة 2قد يكون النظاموجدت غير آمنة تماما بسبب القضايا المتعلقة فيات شامير.هذا يستحق اهتمامنا العالي والبحث المستمر.قد نحتاجتعديل تحول Fiat-Shamir نفسه للدفاع بشكل أفضل ضد هذه الثغرات الأمنية.

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

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

حول السلامة الكمية

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

مستوى أمن محدد

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

مرحلة الأداء

الوضع الحالي

حاليا ، ZKVMدليلحساب الحساب هو تقريبا1 مليون مرة التنفيذ الأصلي.بمعنى آخر ، إذا كان التنفيذ الأصلي للبرنامج يتطلبدورات وحدة المعالجة المركزية،لذاإنشاء دليل على التنفيذ الصحيحمطلوب تقريباX × 1،000،000 دورات وحدة المعالجة المركزية.هذا الوضعلذلك كان هذا قبل عام ، وما زال هذا اليوم(على الرغم من وجود بعض سوء الفهم).

يمكن أن تكون بعض البيانات الشائعة في الصناعة اليوم مضللة ، مثل:

1.“تكلفة توليد دليل على Ethereum Mainnet بأكمله أقل من مليون دولار في السنة.”

2.“لقد قمنا تقريبًا بتنفيذ توليد إثبات في الوقت الفعلي من كتل Ethereum ، مما يتطلب فقط عشرات من وحدات معالجة الرسومات.”

3.“آخر ZKVM هو 1000 مرة أسرع من الأجيال السابقة.”

ومع ذلك ، يمكن أن تكون هذه الادعاءات مضللة بدون سياق:

•1000 مرة أسرع من ZKVM الأقدم ، وربما لا يزال بطيئًا جدًا، هذا أكثر قولًاما مدى سوء الماضي ، وليس كم هو جيد الآن.

•قد يزداد حجم الحوسبة لشبكة Ethereum الرئيسية بمقدار 10 مرات في المستقبل، مما سيجعل الأداء الحالي لـ ZKVM أقل عرضة لمواكبة الطلب.

• لا يزال جيل الإثبات “في الوقت الفعلي تقريبًا” تحت احتياجات العديد من تطبيقات blockchainبطيء جدا(على سبيل المثالالتفاؤل لديه وقت كتلة قدره 2 ، أسرع بكثير من 12 ثانية من Ethereum).

•“لا يعمل وحدات معالجة الرسومات على مدار 24/7 لفترة طويلة”غير متوفرما يكفي من النشاط مضمون.

• هؤلاءعادة ما يكون وقت توليد الإثبات لأحجام الإثبات التي تزيد عن 1 ميغابايت، وهذا للعديد من التطبيقاتكبير جدا.

•“تكلفة أقل من مليون دولار في السنة”فقط لأنتؤدي العقدة الكاملة Ethereum فقط إلى إجراء حسابات تبلغ حوالي 25 دولارًا في السنة.

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

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

قياس الأداء

يحتوي Snark Performance على ثلاثة مكونات رئيسية:

1.الكفاءة الكامنة للنظام المثبت الأساسي.

2.التحسين لتطبيقات محددة(على سبيل المثال مسبق).

3.تسريع الهندسة والأجهزة(على سبيل المثال ، GPU ، FPGA ، أو وحدة المعالجة المركزية متعددة النواة).

في حين أن (2) و (3) ضرورية للنشر الفعلي ، إلا أنها مناسبة لأي نظام إثبات ، وبالتاليالتحسينات التي قد لا تعكس بالضرورة النفقات العامة الأساسية.على سبيل المثال ، يمكن لإضافة تسريع GPU و precompilation إلى ZKEVM تحسين السرعة بسهولة بمقدار 50 مرة أسرع من الاعتماد فقط على وحدات المعالجة المركزية – مما قد يجعل نظامًا أقل كفاءة بطبيعته يبدو أفضل من آخر لم يكن نفس التحسين.

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

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

مرحلة الأداء

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

في جميع المراحل ،يجب ألا يعدل المطورون رمزًا لأداء ZKVM.تجربة المطور هي الميزة الأساسية لـ ZKVM.إذا تم التضحية بـ Devex لتلبية معايير الأداء ، فلن يفقد ذلك فقط أهمية القياس ، ولكن أيضًا ينتهك النية الأصلية لـ ZKVM.

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

متطلبات المرحلة الأولى: “تكاليف التحقق غير التافهة العقلانية”

•حجم الإثبات: يجب أن تكون أصغر من حجم الشاهد.

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

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

المرحلة 2 وما فوق

•الحد الأقصى لحجم الدليل: 256 كيلو بايت.

•أقصى وقت للتحقق: 16 ميلي ثانية.

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

السرعة المرحلة 1

يجب ألا يكون دليل واحد من الخيوط أبطأ أكثر من 100000 مرة من التنفيذ الأصلي(ينطبق على تطبيقات متعددة ، وليس فقط إثبات كتلة Ethereum) ويجب ألا تعتمد على premompilation.

خاصة، لنفترض أن معالج RISC-V على جهاز كمبيوتر محمول حديث يعمل في حوالي.3 مليار دورة في الثانية، ثم الوصول إلى المرحلة 1 يعني أن دفتر الملاحظات يمكنه30000 دورات RISC-V/الثانيةإثبات توليد السرعة (موضوع واحد).

يجب أن تفي تكلفة المدقق بمعيار “تكلفة التحقق غير التافهة المعقولة” المحددة مسبقًا.

السرعة المرحلة 2

يجب ألا يكون دليل واحد من الخيوط أبطأ أكثر من 10000 مرة من التنفيذ الأصلي.

أو، نظرًا لأن بعض طرق Snark الواعدة (وخاصة Snark المجال الثنائي) تقتصر على وحدة المعالجة المركزية و GPU الحالية ، يمكن الوفاء بهذه المرحلة من خلال FPGAs (أو حتى ASICS):

1. احسب عدد النوى RISC-V التي يحاكي FPGA بسرعة أصلية.

2. حساب عدد FPGAs المطلوبة لمحاكاة وإثبات تنفيذ RISC-V (بالقرب من الوقت الحقيقي).

3. إذا (2) الكميةلا أكثر من 10000 مرة (1)، ثم المرحلة 2 راضية.

•حجم الإثبات: الحد الأقصى 256 كيلو بايت.

•وقت التحقق: كحد أقصى 16 ميلي ثانية على وحدة المعالجة المركزية القياسية.

السرعة المرحلة 3

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

مرحلة الذاكرة 1

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

ملاحظتان مهمتان:

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

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

مرحلة الذاكرة 2

في أقل من 200 ميجابايت من الذاكرةيحققالسرعة المرحلة 1(10 مرات أسرع من مرحلة الذاكرة 1).

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

مسبق: الميل الأخير ، أو عكازات؟

مسبقيشير إلىتم تحسين نظام قيود Snark خصيصًا لوظائف محددة (مثل التجزئة ، توقيعات منحنى الإهليلجي).في Ethereum ، يمكن أن يقلل التحميل المسبق من النفقات العامة لتجزئة Merkle والتحقق من التوقيع ، لكن الاعتماد المفرط على التحميل المسبق لا يمكن أن يحسن حقًا الكفاءة الأساسية لـ Snark.

قضايا premompilation

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

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

3. خبرة المطورين الفقيرة: حاليًا ، يحتاج العديد من ZKVMs إلى مطوريننظام قيود الكتابة اليدوية، على غرار طريقة البرمجة في الستينيات ، مما يؤثر بشكل خطير على تجربة التنمية.

4. المعيار المضللة: إذا كانت المعايير تعتمد على تحسين عمليات الإجراءات المحددة ، فقد تضلل الناس للتركيز على تحسين أنظمة القيود اليدوية بدلاً من تعزيز تصميم Snark نفسه.

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

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

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

الجدول الزمني المتوقع

أتوقع أن يصل عدد قليل من ZKVMs في وقت لاحق من هذا العامالسرعة المرحلة 1ومرحلة الذاكرة 1.أعتقد أنه يمكننا تحقيق ذلك في العامين المقبلين.السرعة المرحلة 2، لكن ليس من الواضح ما إذا كان يمكن تحقيق هذا الهدف بدون أفكار بحثية جديدة.

أتوقع بقية المراحل (السرعة المرحلة 3ومرحلة الذاكرة 2) سيستغرق تحقيق سنوات.

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

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