a16z: استكشاف كفاءة وأمان zkVM

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

تهدف الآلات الافتراضية عديمة المعرفة (zkVMs) إلى "إضفاء الطابع الديمقراطي على SNARKs" بحيث يمكن حتى للأشخاص الذين لا يمتلكون خبرة في SNARK إثبات أنهم قاموا بتشغيل برنامج بشكل صحيح على مدخلات محددة (أو شاهد). تتمثل ميزتها الأساسية في تجربة المطور، ولكن لا تزال أجهزة zkVM تواجه حاليًا تحديات ضخمة من حيث الأمان والأداء. يتعين على المصممين التغلب على هذه العقبات إذا كان من المقرر أن تفي zkVMs بوعودها. ستستكشف هذه المقالة المراحل المحتملة في تطوير zkVM، وهي عملية قد تستغرق عدة سنوات حتى تكتمل - لا تدع أحدًا يخبرك أنها ستحدث بسرعة.

التحديات

من حيث الأمان، تعد zkVMs مشاريع برمجية معقدة للغاية ولا تزال مليئة بالثغرات الأمنية.

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

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

مرحلة تطوير الأمان

الخلفية

تتكون zkVMs المستندة إلى SNARK عادةً من مكونين أساسيين:

1. Polynomial Interactive Oracle Proof (PIOP): إطار عمل تفاعلي لإثبات كثيرات الحدود (أو القيود المستمدة من كثيرات الحدود). 2. مخطط الالتزام متعدد الحدود (PCS): يضمن عدم قدرة المُثبت على تزوير نتائج التقييم متعدد الحدود دون أن يتم اكتشافه. يضمن zkVM الاستخدام الصحيح لسجلات الجهاز الظاهري وذاكرته من خلال ترميز مسار التنفيذ الصحيح في نظام القيود، ثم يستخدم SNARK لإثبات استيفاء هذه القيود.

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

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

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

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

تتطلب هذه المرحلة التحقق الرسمي من التنفيذ الفعلي للمحقق zkVM (مثل Rust وSolidity وما إلى ذلك) لضمان امتثاله للبروتوكول الذي تم التحقق منه في المرحلة الأولى. إن إكمال هذه المرحلة يعني أن تنفيذ zkVM يتوافق مع التصميم النظري، وليس مجرد بروتوكول آمن على الورق أو مواصفات غير فعالة مكتوبة بلغة مثل Lean. هناك سببان رئيسيان وراء تركيزنا على المُتحقق فقط وليس المُثبت: أولاً، التأكد من صحة المُتحقق يمكن أن يضمن اكتمال نظام إثبات zkVM (أي التأكد من عدم إمكانية خداع المُتحقق لقبول إثبات خاطئ). ثانيًا، إن تنفيذ المُتحقق لـ zkVM أبسط بكثير من تنفيذ المُثبت، كما أن صحة المُتحقق أسهل في الضمان على المدى القصير.

المرحلة الثالثة من الأمان: التنفيذ الصحيح لأداة الإثبات

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

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

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

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

ملاحظة رئيسية: أمان تحويل فيات-شامير مقابل البايت كود الذي تم التحقق منه

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

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

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

حول الأمن الكمي

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

مستويات الأمان المحددة

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

مرحلة الأداء

الوضع الحالي

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

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

1. جيل الدليل في الوقت الفعلي تقريبًا لكتل ​​Ethereum ، مع بضع عشرات فقط من وحدات معالجة الرسومات. " ؛ "> • 1000x أسرع من ZKVM القديم لا يزال بطيئًا جدًا ، والذي يقول أكثر عن مدى سوء الأمر في الماضي من مدى جودته الآن . • قد تزيد قوة الحوسبة لشبكة Ethereum الرئيسية بمقدار 10 مرات في المستقبل، مما سيجعل أداء zkVM الحالي أقل بكثير من الطلب. • لا يزال ما يسمى بتوليد الإثبات "في الوقت الفعلي تقريبًا" بطيئًا للغاية بالنسبة لاحتياجات العديد من تطبيقات blockchain (على سبيل المثال، يبلغ وقت كتلة Optimism ثانيتين، وهو أسرع بكثير من 12 ثانية في Ethereum).

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

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

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

قياس الأداء

يتكون أداء SNARK من ثلاثة مكونات رئيسية:

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

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

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

مراحل الأداء

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

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

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

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

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

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

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

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

• الحد الأقصى لحجم النسخة التجريبية: 256 كيلوبايت.

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

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

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

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

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

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

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

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

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

1. احسب عدد أنوية RISC-V التي يمكن لـ FPGA محاكاتها بالسرعة الأصلية. 2. احسب عدد وحدات FPGA المطلوبة لمحاكاة وإثبات تنفيذ RISC-V (في الوقت الفعلي تقريبًا). 3. إذا كان مقدار (2) لا يتجاوز 10000 مرة مقدار (1)، فإن المرحلة 2 تكون قد تحققت.

• حجم النسخة التجريبية: الحد الأقصى 256 كيلوبايت.

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

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

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

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

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

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

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

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

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

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

مشاكل في التجميع المسبق

1. لا يزال بطيئًا للغاية: حتى مع التجميع المسبق للتجزئة والتوقيع، لا يزال zkVM يعاني من عدم كفاءة في نظام إثبات النواة داخل وخارج blockchain. 2. الثغرات الأمنية: إذا لم يتم التحقق رسميًا من التجميع المسبق المكتوب بخط اليد، فمن المؤكد تقريبًا أنه يحتوي على ثغرات أمنية، مما قد يؤدي إلى فشل أمني كارثي. 3. خبرة ضعيفة للمطورين: حاليًا، تتطلب العديد من أجهزة zkVM من المطورين كتابة أنظمة القيود يدويًا، وهو ما يشبه طريقة البرمجة في الستينيات، مما يؤثر بشكل خطير على تجربة التطوير. 4. تضليل المعايير: إذا كانت المعايير تعتمد على تحسين التجميع المسبق المحدد، فقد يؤدي ذلك إلى تضليل الأشخاص للتركيز على تحسين نظام القيود المصمم يدويًا بدلاً من تحسين تصميم SNARK نفسه. 5. تكاليف الإدخال/الإخراج وعدم الوصول إلى ذاكرة الوصول العشوائي (RAM)في حين أن التجميعات المسبقة قد تعمل على تحسين الأداء للمهام التي تعتمد على التشفير بشكل كبير، إلا أنها قد لا توفر تسريعًا ذا معنى لأحمال العمل الأكثر تنوعًا لأنها تتكبد تكاليف إضافية كبيرة عند تمرير الإدخال/الإخراج ولا يمكنها استخدام ذاكرة الوصول العشوائي (RAM). حتى في بيئة blockchain، بمجرد أن تتجاوز مستوى L1 واحد مثل Ethereum (على سبيل المثال، تريد بناء سلسلة من الجسور عبر السلسلة)، ستواجه وظائف تجزئة مختلفة ومخططات توقيع. إن التجميع المسبق المستمر لحل هذه المشكلة ليس قابلاً للتطوير ويشكل خطرًا أمنيًا كبيرًا. أعتقد أن التجميعات المسبقة ستظل بالغة الأهمية على المدى الطويل، ولكن فقط بعد أن يتم تجميعها تلقائيًا والتحقق منها رسميًا. بهذه الطريقة، يمكننا الحفاظ على فوائد تجربة المطور التي يوفرها zkVM مع تجنب مخاطر الأمان الكارثية. وينعكس هذا الرأي في المرحلة الثالثة.

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

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

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