المؤلف: Justin Thaler المصدر: a16z الترجمة: شان أوبا، Golden Finance
يهدف Zero Knowledge Virtual Machines (zkVMs) إلى "جعل SNARKs مشهورة"، مما يتيح لأي شخص، حتى من ليس لديه معرفة متخصصة بـ SNARKs، إثبات أنهم قاموا بتشغيل برنامج معين بشكل صحيح على مدخل محدد (أو برهان). إيجابياتها الأساسية تكمن في تجربة المطور، لكن zkVMs الحالية تواجه تحديات كبيرة فيما يتعلق بـ الأمان و الأداء. إذا كانت zkVMs ترغب في تحقيق وعودها، يجب على المصممين التغلب على هذه العقبات. سيستكشف هذا المقال مراحل تطور zkVM وقد تستغرق العملية بأكملها سنوات للانتهاء - لا تصدق أي شخص يقول إن هذا يمكن تحقيقه بسرعة.
التحديات التي تواجهها
من حيث الأمان، تعتبر zkVMs مشروعًا برمجيًا معقدًا للغاية ولا يزال مليئًا بالثغرات.
من حيث الأداء، من الممكن أن يكون إثبات تنفيذ برنامج بشكل صحيح أبطأ بمقدار عشرات الآلاف من المرات من التشغيل الأصلي، مما يجعل تنفيذ معظم التطبيقات في العالم الحقيقي غير عملي حاليًا.
على الرغم من ذلك، لا يزال العديد من الأصوات في صناعة سلسلة الكتل يروجون لـ zkVMs يمكن نشرها على الفور، حتى أن بعض المشاريع قامت بدفع تكاليف حوسبة باهظة، لإنشاء دليل المعرفة الصفري لأنشطة السلسلة الجانبية. ومع ذلك، نظرًا لوجود العديد من الثغرات في zkVMs، فإن هذه الممارسة في الواقع ليست سوى نوع من التمويه المكلف، يجعل النظام يبدو وكأنه محمي بواسطة SNARK، على الرغم من أنه في الواقع يعتمد إما على التحكم في الإذن أو بشكل أسوأ—تعرض لمخاطر الهجوم.
الحقيقة هي أننا لسنوات عديدة بعيدة عن بناء zkVM الآمن والفعال حقًا. يقدم هذا المقال سلسلة من الأهداف المحددة والمرحلية لمساعدتنا في تتبع التقدم الحقيقي لـ zkVM والتخفيف من التضخيم، وتوجيه اهتمام المجتمع نحو الاختراقات التقنية الحقيقية.
مرحلة تطوير الأمان
الخلفية
الـ SNARK المعتمدة على zkVMs عادة ما تحتوي على مكونين أساسيين:
إثبات الآلة العصرية التفاعلي للعقد (PIOP): يستخدم لإثبات إطار الإثبات التفاعلي للعديد من (أو القيود المشتقة من العديد).
مخطط الالتزام بالمتعددات (Polynomial Commitment Scheme، PCS): يضمن أن جهاز الإثبات لا يمكنه تزوير نتائج تقييم متعددات دون اكتشافه.
عن طريق ترميز مسارات التنفيذ الفعالة كنظام قيد، يضمن zkVM استخدام صحيح لسجلات الجهاز الظاهري والذاكرة، ثم يستخدم SNARK لإثبات رضا هذه القيود.
في نظام معقد مثل هذا، الطريقة الوحيدة لضمان عدم وجود ثغرات في zkVM هيالتحقق الشكلي. وفيما يلي مراحل أمان zkVM المختلفة، حيث يركز المرحلة الأولى على صحة البروتوكول، بينما تركز المرحلتان الثانية والثالثة على صحة التنفيذ.
المرحلة الأولى: البروتوكول الصحيح
إثبات التحقق الرسمي من موثوقية PIOP؛
يتم التحقق من قيود PCS بشكل قوي في بعض النماذج الوهمية أو النماذج الوهمية للتشفير.
إذا تم استخدام فيات-شامير، فإن البرهان الموجز الذي تم الحصول عليه من خلال دمج PIOP و PCS يكون آمنًا في نموذج النبوءة العشوائي للتحقق الرسمي (باستخدام فرضيات تشفير أخرى حسب الحاجة)؛
نظام القيد المطبق من قبل PIOP مساوٍ لبرهان التحقق من النموذج الدلالي لـ VM؛
دمج جميع هذه الأجزاء معًا بشكل كامل في دليل SNARK آمن وموثق شكلاً لتشغيل أي برنامج محدد بواسطة بايت كود VM. إذا كان البروتوكول يهدف إلى تحقيق الصفر معرفة، فيجب التحقق من هذا الخصائص أيضًا بشكل موثق لضمان عدم تسرب معلومات حساسة حول الشهود.
إذا كان zkVM يستخدم التكرار، فيجب التحقق من PIOP وخطط الالتزام والأنظمة الملزمة التي تتعلق بها خلال عملية التكرار، وإلا لا يمكن اعتبار هذه المرحلة الفرعية كمكتملة.
المرحلة 2 من الأمان: تنفيذ محقق صحيح
تتطلب هذه المرحلة التحقق الرسمي من تنفيذ zkVM التحقق (مثل Rust، Solidity وما إلى ذلك)، لضمان توافقه مع البروتوكول الذي تم التحقق منه بالفعل في المرحلة الأولى. إكمال هذه المرحلة يعني أن تنفيذ zkVM متماشٍ مع التصميم النظري، وليس فقط بروتوكول أمني على الورق، أو مواصفة غير فعالة مكتوبة بلغة Lean وما شابها.
لماذا تركز فقط على المحققين ولا تولي اهتمامًا بالمثبتين هناك سببان رئيسيان: أولاً، ضمان صحة المحقق، يمكن أن يضمن استكمالية نظام إثبات zkVM (أي: ضمان عدم تعرض المحقق للخداع لقبول إثبات خاطئ). ثانيًا، تنفيذ محقق zkVM أبسط بمقدار أكثر من تنفيذ المثبت، وسهولة ضمان صحة المحقق في الفترة القصيرة أكبر.
المرحلة الثالثة من الأمان: تحقيق المثبت الصحيح
يتطلب هذه المرحلة التحقق الرسمي من تنفيذ zkVM البروف، لضمان قدرته على إنشاء بشكل صحيح دليل النظام المعتمد الذي تم التحقق منه في المراحل الأولى والثانية. هدف هذه المرحلة هو الاكتمال، أي: لن يتوقف أي نظام يستخدم zkVM بسبب عدم القدرة على إثبات جملة قانونية معينة. إذا كان يتطلب zkVM أن يكون له خاصية المعرفة الصفرية، فيجب توفير التحقق الرسمي لضمان عدم تسرب أي معلومات حول الشهادة.
الجدول الزمني المتوقع
المرحلة 1: التقدم يمكننا توقع تحقيق بعض التقدم العام المقبل (على سبيل المثال، ZKLib هو جهد مثل هذا). ولكن لن يتوفر zkVM يمكن أن يلبي متطلبات المرحلة 1 تمامًا على الأقل لمدة عامين.
المرحلة 2 والمرحلة 3 : يمكن تقدم هذه المراحل مع بعض جوانب المرحلة 1 في نفس الوقت. على سبيل المثال، أثبتت بعض الفرق أن تنفيذ محقق Plonk يتطابق مع بروتوكول الورقة (على الرغم من أن البروتوكول في الورقة قد لم يتم التحقق منه بالكامل). على الرغم من ذلك، أتوقع أن لن يتمكن أي zkVM من الوصول إلى المرحلة 3 في غضون أربع سنوات - ربما حتى أطول من ذلك.
أحد المشاكل الرئيسية للتعقيد هو أن أمان تحويل فيات-شامير ما زالت هناك مشكلات بحث غير محلولة. يُعتبر الجميع Fiat-Shamir وجهاز التنبؤ العشوائي آمنين تمامًا في جميع مراحل الأمان الثلاثة ، ولكن في الواقع قد تحتوي الباراديغم بأكمله على ثغرات. ويرجع ذلك إلى الاختلاف بين نموذج جهاز التنبؤ العشوائي المثالي ووظيفة التجزئة التي تستخدم في الواقع.
في أسوأ الحالات، قد يتم اكتشاف أن نظامًا قد وصل إلى مرحلة الأمان 2 قد يكون غير آمن تمامًا بسبب مشاكل ذات صلة بفيات-شامير. هذا يستحق اهتمامنا الكبير والبحث المستمر. قد نحتاج إلى تعديل ذات صلة بفيات-شامير نفسه، لتعزيز الدفاع عن هذه الثغرات.
نظام لا يستخدم التكرار أكثر أمانًا نظريًا، لأن بعض الهجمات المعروفة تشمل دوائر تشبه تلك المستخدمة في البراهين المتكررة. ومع ذلك، هذا المخاطر لا يزال مشكلة أساسية غير محلولة.
مشكلة أخرى تحتاج إلى اهتمام هي أنه حتى إذا ثبتت zkVM أن برنامج حسابي (الذي يحدده البايت كود) قد تم تنفيذه بشكل صحيح، فإذا كان هناك عيوب في البايت كود نفسه، فإن قيمة هذا الإثبات محدودة للغاية. لذلك، تعتمد فعالية zkVM إلى حد كبير على كيفية إنشاء بايت كود يمر بالتحقق الشكلي، وهذا التحدي ضخم للغاية، وخارج نطاق مناقشة هذه المقالة.
حول أمان مقاوم للكم
في السنوات الخمس القادمة على الأقل (ربما أكثر)، لن تكون أجهزة الكمبيوتر الكمية تهديدًا كبيرًا، بينما الثغرات في البرمجيات هي مسألة حيوية. لذلك، يجب أن يكون التركيز الأساسي حاليًا على تحقيق أهداف الأمان والأداء المذكورة في هذا المقال. إذا كان بإمكان SNARKs غير المقاومة للكمية تحقيق هذه الأهداف بشكل أسرع، فيجب علينا أن نعطي الأولوية لاستخدامها. عندما تتعقب SNARKs المقاومة للكمية التطورات، أو يظهر دليل على قرب ظهور أجهزة كمية تشكل تهديدًا فعليًا، يمكننا التفكير في التبديل.
مستوى الأمان الخاص بالتحديد
100-bit الأمان الكلاسيكي هو الحد الأدنى لأي SNARK المستخدم لحماية الأصول القيمة (لكن لا يزال هناك بعض الأنظمة التي لا تصل إلى هذا المستوى المنخفض). ومع ذلك، لا ينبغي قبول ذلك، وتتطلب ممارسات التشفير القياسية عادةً مستوى أمان 128-bit على الأقل. إذا كانت أداء SNARK يفي حقًا بالمعايير، فلا ينبغي أن نخفض مستوى الأمان من أجل تحسين الأداء.
مرحلة الأداء
الوضع الحالي
حالياً، يبلغ تكلفة حوسبة البروفر في zkVM حوالي مليون مرة من التنفيذ الأصلي. بمعنى آخر، إذا كان يتطلب تنفيذ البرنامج الأصلي X دورة للمعالج، فإن إنشاء برهان التنفيذ الصحيح يتطلب حوالي X × 1،000،000 دورة للمعالج. هذا هو الحال كان قبل سنة واليوم لا زال كذلك (على الرغم من وجود بعض الالتباسات).
بعض المصطلحات الشائعة في الصناعة قد تؤدي إلى الإرباك، مثل:
تكلفة إنشاء دليل لشبكة Ethereum الرئيسية بأقل من مليون دولار سنويًا.
"لقد تقربنا كثيرًا من تحقيق إنتاج بيانات الكتل في إيثيريوم بشكل حيني، فقط بحاجة لعدد قليل من وحدات GPU."
"zkVM الجديد لدينا أسرع بمقدار 1000 مرة من الإصدار السابق."
ومع ذلك، قد تكون هذه الادعاءات مضللة في حالة عدم وجود سياق:
• أسرع بمقدار 1000 مرة من الإصدار السابق zkVM ، ومع ذلك قد يكون بطيئًا للغاية ، وهذا يوضح أكثر كيف كانت سيئة في الماضي بدلاً من كيف جيدة الآن.
• قد تزيد قدرة الحوسبة على شبكة Ethereum الرئيسية بمقدار 10 أضعاف في المستقبل، مما سيجعل أداء zkVM الحالي بعيدًا كل البعد عن تلبية الطلب.
• ما يُسَمّى "شبه الزمن الحقيقي" في إنشاء البراهين، لا يزال بطيئًا جدًا في العديد من تطبيقات سلسلة الكتل (على سبيل المثال، يبقى وقت Optmism للكتلة 2 ثانية، أسرع بكثير من 12 ثانية لإثيريوم).
• “العمل المستمر لعدة عشرات من وحدات GPU على مدار الساعة طوال الوقت” لا يمكن أن يوفر ضمان النشاط الكافي.
• وعادة ما تكون أوقات إنشاء هذه البراهين موجهة نحو حجم البراهين الذي يزيد عن 1 ميجابايت، وهذا يعتبر كبيرًا جدًا بالنسبة للعديد من التطبيقات.
• "تكلفة أقل من مليون دولار سنويًا" هي فقط بسبب تنفيذ عقد الإيثيريوم الكامل يقدر بحوالي 25 دولارًا سنويًا فقط.
بالنسبة لسيناريوهات التطبيق خارج سلسلة الكتل، يبدو أن تكلفة هذه الحسابات مرتفعة للغاية. بغض النظر عن الحوسبة المتوازية أو الأمثلة الهندسية، لا يمكن تعويض تكلفة الحسابات الضخمة هذه.
يجب أن يكون الهدف الأساسي الذي نحدده: ألا يتجاوز الأداء التكلفة الأصلية بمعدل 100,000 مرة. ومع ذلك، هذه تظل الخطوة الأولى فقط. إذا كنا بحاجة إلى تحقيق تطبيقات كبيرة حقًا على نطاق واسع، فقد نحتاج إلى خفض التكلفة إلى 10,000 مرة أو أقل من الأداء الأصلي.
قياس الأداء
أداء SNARK مكون من ثلاثة أجزاء رئيسية:
كفاءة النظام الأساسي للإثبات الثابت.
التحسينات الخاصة بالتطبيقات المحددة (مثل الترجمة المسبقة).
الهندسة وتسريع الأجهزة (مثل وحدة معالجة الرسومات GPU، مجال بوابة البرمجة المنطقية FPGA أو وحدة المعالجة المركزية متعددة النوى).
على الرغم من أن (2) و (3) حاسمان للنشر الفعلي، إلا أنهما قابلان للتطبيق على أي نظام إثبات، وبالتالي قد لا تعكس بالضرورة تحسينات التكاليف الأساسية. على سبيل المثال، يمكن بسهولة إضافة تسريع GPU والترجمة المسبقة لـ zkEVM لزيادة السرعة بنسبة 50 مرة مقارنة بالاعتماد البسيط على وحدة المعالجة المركزية - وهذا قد يجعل نظامًا فعالًا منخفض الكفاءة يبدو أفضل من نظام آخر غير مُحسن بنفس الطريقة.
لذلك ، تركز هذه المقالة على قياس الأداء الأساسي ل SNARKs بدون أجهزة مخصصة وتجميع مسبق. هذا على النقيض من طرق المقارنة المعيارية الحالية ، والتي عادة ما تجمع بين العوامل الثلاثة في "قيمة سكانية" واحدة. إنه مثل الحكم على الماس من خلال تلميع الوقت ، بدلا من تقييم وضوحه المتأصل.
هدفنا هو عزل تكاليف نظام الإثبات العامة الأساسية وتقليل عتبة الدخول للتقنيات التي لم يتم دراستها بعمق بعد، ومساعدة المجتمع في التركيز على التقدم الحقيقي في تصميم نظام الإثبات من خلال إزالة العوائق.
مرحلة الأداء
فيما يلي خمس مراحل أداء قدمتها. أولاً، نحتاج إلى تخفيض كبير في تكاليف المثبت على وحدة المعالجة المركزية، قبل أن نتمكن من الاعتماد بشكل أكبر على الأجهزة لتقليل التكاليف. في الوقت نفسه، يجب تحسين استخدام الذاكرة أيضًا.
في جميع المراحل، لا ينبغي للمطورين تعديل الشفرة من أجل أداء zkVM. تجربة المطور هي الفائدة الأساسية لـ zkVM. إذا تم التضحية بـ DevEx لتحقيق معايير الأداء، فإن ذلك ليس فقداناً للهدف من اختبار الأداء فقط، بل يتعارض أيضًا مع الهدف الرئيسي لـ zkVM.
تركز هذه المؤشرات بشكل أساسي على تكلفة الدليل. ومع ذلك، إذا سمحنا بـ زيادة تكلفة المحقق بشكل غير محدود (أي حجم دليل أو وقت تحقق غير محدود)، فيمكن لأي مؤشر للدليل أن يتوافق بسهولة. لذا، لتلبية متطلبات المراحل التالية، يجب تحديد حجم الدليل الأقصى وأقصى وقت للتحقق في نفس الوقت.
المرحلة 1: 'تكلفة التحقق الغير تافهة المعقولة'
• حجم الإثبات: يجب أن يكون أقل من حجم الإثبات.
• وقت التحقق : يجب ألا يكون سرعة التحقق من البرهان أبطأ من تنفيذ البرنامج الأصلي (أي أبطأ من تنفيذ الحساب مباشرة).
هذه هي متطلبات الحد الأدنى للبساطة ، للتأكد من أن حجم الإثبات ووقت التحقق لن يكونا أسوأ من إرسال الشهادات مباشرة إلى المحقق والسماح له بالتحقق مباشرة.
المرحلة 2 وما فوق
• أقصى حجم للدليل: 256 كيلوبايت.
• أقصى وقت للتحقق : 16 مللي ثانية.
تم تعيين هذه الحدود بشكل فضفاض بشكل متعمد لتلبية التكنولوجيا الجديدة للإثبات السريعة، حتى لو كانت تترتب عنها تكاليف تحقق أعلى. في الوقت نفسه، يستبعد هذه الحدود الأدلة التي تكلفة ارتفاعها إلى درجة أنه لا يوجد مشروع يرغب في استخدامها على سلسلة الكتل.
المرحلة 1 من السرعة
يجب ألا يكون دليل الخط المفرد أبطأ من التنفيذ الأصلي بأكثر من 100,000 مرة (مناسب لعدة تطبيقات وليس فقط إثبات كتلة Ethereum) ويجب ألا يعتمد على الإعداد المسبق.
بشكل محدد، يفترض أن معالج RISC-V على كمبيوتر محمول حديث يعمل بسرعة تقدر بحوالي 30 مليار دورة في الثانية، فإذا تم التوصل إلى المرحلة 1، فهذا يعني أن الكمبيوتر المحمول يمكنه إنتاج الإثبات بسرعة 30,000 دورة RISC-V في الثانية (متسلسلة)
يجب أن تلبي تكلفة المحقق معيار "تكلفة التحقق الغير تافهة المعقولة" المعرفة مسبقا.
المرحلة 2 من السرعة
يجب ألا يكون إثبات السرعة أبطأ من التنفيذ الأصلي بأكثر من 10،000 مرة.
أو بالأحرى، يمكن أن يتم تلبية هذه المرحلة من خلال FPGA (حتى ASIC) بسبب قيود الـ CPU و GPU الحالية على بعض أساليب SNARK الواعدة (خاصة SNARK في مجال البيانات الثنائية).
حساب عدد نوى RISC-V المحاكية بسرعة الأصلي FPGA.
حساب ونمذجة وإثبات عدد الـ FPGA اللازمة لتنفيذ RISC-V (ما يقارب الزمن الحقيقي).
إذا كانت كمية (2) لا تتجاوز 10،000 مرة (1) ، فسيتم تحقيق المرحلة 2.
• حجم الإثبات: الحد الأقصى 256 كيلو بايت.
• وقت التحقق : 16 مللي ثانية كحد أقصى على وحدة المعالجة المركزية القياسية.
المرحلة 3 السرعة
حقق النفقات العامة للإثبات في حدود 1000× أعلى مرحلة السرعة 2 (لمجموعة كبيرة من التطبيقات) ويجب استخدام التجميع المسبق للتوليف التلقائي والتحقق الرسمي. بشكل أساسي ، يتم تخصيص مجموعة تعليمات كل برنامج ديناميكيا لتسريع توليد الإثبات ، ولكن يجب أن تكون سهلة الاستخدام والتحقق منها رسميا. (راجع القسم التالي حول سبب كون التجميع المسبق سيفا ذا حدين ، ولماذا لا يعد التجميع المسبق "بخط اليد" نهجا مستداما.) ）
المرحلة 1 الخاصة بالذاكرة
في ظل أقل من 2 GB من الذاكرة للوصول إلى مرحلة السرعة 1 وفي نفس الوقت تلبية متطلبات علم الصفر. تعد هذه المرحلة حاسمة لـ الأجهزة المحمولة أو المتصفحات وتفتح الباب أمام العديد من حالات استخدام zkVM على العميل. على سبيل المثال، يُستخدم الهواتف الذكية لـ خصوصية الموقع، وثائق الهوية وغيرها. إذا كان إنشاء البرهان يتطلب أكثر من 1-2 جيجابايت من الذاكرة، فإن معظم الأجهزة المحمولة لن تتمكن من تشغيلها.
ملاحظتان مهمتان:
حتى لو كانت الحوسبة بمقياس كبير (تتطلب تنفيذًا أصلاً يستغرق عشرات تريليونات دورة CPU) ، يجب أن تحافظ أنظمة الإثبات على حد أقصى من الذاكرة بحجم 2 جيجابايت ، وإلا سيتم تقييدها.
إذا تم تحقيق بطء شديد في السرعة، فمن السهل جدًا الحفاظ على حد أقصى للذاكرة بحجم 2 غيغابايت. لذلك، لجعل مرحلة الذاكرة 1 ذات معنى، يجب أن يتم الوصول إلى مرحلة السرعة 1 ضمن حدود الذاكرة بحجم 2 غيغابايت.
المرحلة 2 الذاكرة
في ظل ظروف أقل من 200 ميغابايت تحقيق المرحلة 1 من السرعة (عشر مرات أفضل من المرحلة 1 في الذاكرة).
لماذا تم تقليلها إلى 200 ميغابايت؟ تفكير في سيناريو خارج سلسلة الكتل : عند زيارتك لموقع ويب محمي ببروتوكول HTTPS ، سيتم تنزيل شهادات المصادقة والتشفير. إذا قام الموقع بإرسال براهين zk هذه بدلاً من الشهادات ، فقد تحتاج المواقع الكبيرة إلى إنشاء ملايين البراهين كل ثانية. إذا كان كل برهان يتطلب 2 غيغابايت من الذاكرة ، فإن الاحتياجات إلى الموارد الحسابية ستصل إلى مستوى PB ، وهو أمر غير عملي بالطبع. لذلك ، فإن تقليل استخدام الذاكرة بشكل أكبر يعد أمرًا حيويًا لتطبيقات غير سلسلة الكتل.
الترجمة المسبقة: الأميال الأخيرة، هل هي عصا؟
الترجمة المسبقة تشير إلى نظام قيود SNARK محسن خصيصًا لوظائف محددة (مثل التجزئة ، والتوقيع بالمنحنى البيضاوي). في Ethereum ، يمكن للترجمة المسبقة تقليل تكلفة التحقق من التجزئة والتوقيع ، ولكن الاعتماد المفرط على الترجمة المسبقة لا يمكن أن يعزز حقا كفاءة SNARK الأساسية.
مشكلة مُعَدَّة مسبقًا
1. لا يزال بطيئًا: حتى مع استخدام تجهيزات الهاش والتوقيع المسبقة، يظل zkVM يعاني من مشكلة كفاءة النظام الأساسي للإثبات داخل وخارج سلسلة الكتل.
2. الثغرات الأمنية : إذا لم يتم التحقق الشكلي من التجهيز المسبق للكتابة اليدوية ، فإنه من المرجح بشكل كبير وجود ثغرات ، مما قد يؤدي إلى فشل أمني كارثي.
3. تجربة المطور غير جيدة: حاليًا ، يحتاج العديد من zkVM إلى كتابة نظام القيود يدويًا من قبل المطورين ، على غرار طريقة البرمجة في الستينيات من القرن الماضي ، مما يؤثر سلبًا على تجربة التطوير.
4. الاختبار الأساسي المضلل: إذا كان اعتماد اختبار أساسي على تحسين معين مُعد مسبقًا، فقد يوجه الناس انتباههم نحو تحسين القيود اليدوية للنظام، بدلاً من تعزيز تصميم SNARK نفسه.
5. تكلفة الإدخال/الإخراج وعدم وجود وصول إلى الذاكرة العشوائية على الرغم من أن الإعداد المسبق يمكن أن يعزز أداء المهام الكثيفة للتشفير، إلا أنه قد لا يكون قادرًا على تقديم تسريع معنوي لأحمال عمل متنوعة أكثر، لأنها تولد تكاليف كبيرة عند تقديم الإدخال/الإخراج، ولا يمكنها استخدام الذاكرة العشوائية.
حتى في بيئة سلسلة الكتل، ستواجه تحديات مختلفة في حال تجاوزت مثل هذا L1 الفردية مثل Ethereum (على سبيل المثال، إذا كنت ترغب في إنشاء سلسلة من الجسور العابرة للسلسلة)، ستواجه تحديات مختلفة في وظائف التجزئة وبرامج التوقيع. لحل هذه المشكلة، يجب إجراء ترجمة مسبقة باستمرار، وهو أمر لا يمكن توسيعه ويشكل مخاطر أمنية هائلة.
أؤمن حقًا بأن البرمجة المُسبقة ما زالت مهمة للغاية على المدى الطويل، ولكن فقط عندما يتم توليدها تلقائيًا وتمريرها بالتحقق الرسمي. بهذه الطريقة، يمكننا الحفاظ على ميزة تجربة المطورين لـ zkVM، مع تجنب المخاطر الأمنية الكارثية. يتم تعكس هذه الوجهة نظر في المرحلة 3.
الجدول الزمني المتوقع
أتوقع أن تصل أقلية zkVM في وقت لاحق من هذا العام إلى المرحلة 1 السرعة والمرحلة 1 الذاكرة. أعتقد أننا يمكن أيضًا تحقيق المرحلة 2 السرعة خلال السنتين القادمتين، لكن ليس واضحًا حاليًا ما إذا كان بإمكاننا تحقيق هذا الهدف دون وجود مسار بحث جديد.
أتوقع أن يستغرق الأطوار المتبقية (مرحلة السرعة 3 ومرحلة الذاكرة 2) عدة سنوات للوصول إلى الاتفاق.
على الرغم من أن هذا المقال يفصل بين مراحل أمان zkVM وأدائها، إلا أن كلاهما ليسا مستقلين تمامًا. مع استمرار اكتشاف الثغرات في zkVM، أتوقع أن تؤدي إصلاحات بعض هذه الثغرات بشكل لا مفر منه إلى انخفاض كبير في الأداء. لذلك، يجب أن تُعتبر نتائج اختبار الأداء لـ zkVM مؤقتة حتى تصل zkVM إلى المرحلة الأمنية 2.
يتمتع zkVM بإمكانات هائلة في نشر البراهين المعرفية الصفرية بشكل حقيقي، ولكنها في الوقت الحالي تزال في مراحلها الأولية - مليئة بالتحديات الأمنية وتعاني من عقبات أداء خطيرة. يجعل الترويج السوقي والتسويق من الصعب قياس التقدم الحقيقي. من خلال علامات أمان وأداء محددة، آمل أن أقدم خارطة طريق تمكن من تفسير الغموض. سنصل في النهاية إلى الهدف، ولكن هذا يتطلب الوقت والجهد المتواصل في مجال البحث والهندسة.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
a16z: استكشاف طريق آمن وفعال لـ zkVM
المؤلف: Justin Thaler المصدر: a16z الترجمة: شان أوبا، Golden Finance
يهدف Zero Knowledge Virtual Machines (zkVMs) إلى "جعل SNARKs مشهورة"، مما يتيح لأي شخص، حتى من ليس لديه معرفة متخصصة بـ SNARKs، إثبات أنهم قاموا بتشغيل برنامج معين بشكل صحيح على مدخل محدد (أو برهان). إيجابياتها الأساسية تكمن في تجربة المطور، لكن zkVMs الحالية تواجه تحديات كبيرة فيما يتعلق بـ الأمان و الأداء. إذا كانت zkVMs ترغب في تحقيق وعودها، يجب على المصممين التغلب على هذه العقبات. سيستكشف هذا المقال مراحل تطور zkVM وقد تستغرق العملية بأكملها سنوات للانتهاء - لا تصدق أي شخص يقول إن هذا يمكن تحقيقه بسرعة.
التحديات التي تواجهها
من حيث الأمان، تعتبر zkVMs مشروعًا برمجيًا معقدًا للغاية ولا يزال مليئًا بالثغرات.
من حيث الأداء، من الممكن أن يكون إثبات تنفيذ برنامج بشكل صحيح أبطأ بمقدار عشرات الآلاف من المرات من التشغيل الأصلي، مما يجعل تنفيذ معظم التطبيقات في العالم الحقيقي غير عملي حاليًا.
على الرغم من ذلك، لا يزال العديد من الأصوات في صناعة سلسلة الكتل يروجون لـ zkVMs يمكن نشرها على الفور، حتى أن بعض المشاريع قامت بدفع تكاليف حوسبة باهظة، لإنشاء دليل المعرفة الصفري لأنشطة السلسلة الجانبية. ومع ذلك، نظرًا لوجود العديد من الثغرات في zkVMs، فإن هذه الممارسة في الواقع ليست سوى نوع من التمويه المكلف، يجعل النظام يبدو وكأنه محمي بواسطة SNARK، على الرغم من أنه في الواقع يعتمد إما على التحكم في الإذن أو بشكل أسوأ—تعرض لمخاطر الهجوم.
الحقيقة هي أننا لسنوات عديدة بعيدة عن بناء zkVM الآمن والفعال حقًا. يقدم هذا المقال سلسلة من الأهداف المحددة والمرحلية لمساعدتنا في تتبع التقدم الحقيقي لـ zkVM والتخفيف من التضخيم، وتوجيه اهتمام المجتمع نحو الاختراقات التقنية الحقيقية.
مرحلة تطوير الأمان
الخلفية
الـ SNARK المعتمدة على zkVMs عادة ما تحتوي على مكونين أساسيين:
إثبات الآلة العصرية التفاعلي للعقد (PIOP): يستخدم لإثبات إطار الإثبات التفاعلي للعديد من (أو القيود المشتقة من العديد).
مخطط الالتزام بالمتعددات (Polynomial Commitment Scheme، PCS): يضمن أن جهاز الإثبات لا يمكنه تزوير نتائج تقييم متعددات دون اكتشافه.
عن طريق ترميز مسارات التنفيذ الفعالة كنظام قيد، يضمن zkVM استخدام صحيح لسجلات الجهاز الظاهري والذاكرة، ثم يستخدم SNARK لإثبات رضا هذه القيود.
في نظام معقد مثل هذا، الطريقة الوحيدة لضمان عدم وجود ثغرات في zkVM هي التحقق الشكلي. وفيما يلي مراحل أمان zkVM المختلفة، حيث يركز المرحلة الأولى على صحة البروتوكول، بينما تركز المرحلتان الثانية والثالثة على صحة التنفيذ.
المرحلة الأولى: البروتوكول الصحيح
إذا كان zkVM يستخدم التكرار، فيجب التحقق من PIOP وخطط الالتزام والأنظمة الملزمة التي تتعلق بها خلال عملية التكرار، وإلا لا يمكن اعتبار هذه المرحلة الفرعية كمكتملة.
المرحلة 2 من الأمان: تنفيذ محقق صحيح
تتطلب هذه المرحلة التحقق الرسمي من تنفيذ zkVM التحقق (مثل Rust، Solidity وما إلى ذلك)، لضمان توافقه مع البروتوكول الذي تم التحقق منه بالفعل في المرحلة الأولى. إكمال هذه المرحلة يعني أن تنفيذ zkVM متماشٍ مع التصميم النظري، وليس فقط بروتوكول أمني على الورق، أو مواصفة غير فعالة مكتوبة بلغة Lean وما شابها.
لماذا تركز فقط على المحققين ولا تولي اهتمامًا بالمثبتين هناك سببان رئيسيان: أولاً، ضمان صحة المحقق، يمكن أن يضمن استكمالية نظام إثبات zkVM (أي: ضمان عدم تعرض المحقق للخداع لقبول إثبات خاطئ). ثانيًا، تنفيذ محقق zkVM أبسط بمقدار أكثر من تنفيذ المثبت، وسهولة ضمان صحة المحقق في الفترة القصيرة أكبر.
المرحلة الثالثة من الأمان: تحقيق المثبت الصحيح
يتطلب هذه المرحلة التحقق الرسمي من تنفيذ zkVM البروف، لضمان قدرته على إنشاء بشكل صحيح دليل النظام المعتمد الذي تم التحقق منه في المراحل الأولى والثانية. هدف هذه المرحلة هو الاكتمال، أي: لن يتوقف أي نظام يستخدم zkVM بسبب عدم القدرة على إثبات جملة قانونية معينة. إذا كان يتطلب zkVM أن يكون له خاصية المعرفة الصفرية، فيجب توفير التحقق الرسمي لضمان عدم تسرب أي معلومات حول الشهادة.
الجدول الزمني المتوقع
المرحلة 1: التقدم يمكننا توقع تحقيق بعض التقدم العام المقبل (على سبيل المثال، ZKLib هو جهد مثل هذا). ولكن لن يتوفر zkVM يمكن أن يلبي متطلبات المرحلة 1 تمامًا على الأقل لمدة عامين.
المرحلة 2 والمرحلة 3 : يمكن تقدم هذه المراحل مع بعض جوانب المرحلة 1 في نفس الوقت. على سبيل المثال، أثبتت بعض الفرق أن تنفيذ محقق Plonk يتطابق مع بروتوكول الورقة (على الرغم من أن البروتوكول في الورقة قد لم يتم التحقق منه بالكامل). على الرغم من ذلك، أتوقع أن لن يتمكن أي zkVM من الوصول إلى المرحلة 3 في غضون أربع سنوات - ربما حتى أطول من ذلك.
ملاحظات مهمة: Fiat-Shamir الأمان والبايت كود الموثق
أحد المشاكل الرئيسية للتعقيد هو أن أمان تحويل فيات-شامير ما زالت هناك مشكلات بحث غير محلولة. يُعتبر الجميع Fiat-Shamir وجهاز التنبؤ العشوائي آمنين تمامًا في جميع مراحل الأمان الثلاثة ، ولكن في الواقع قد تحتوي الباراديغم بأكمله على ثغرات. ويرجع ذلك إلى الاختلاف بين نموذج جهاز التنبؤ العشوائي المثالي ووظيفة التجزئة التي تستخدم في الواقع.
في أسوأ الحالات، قد يتم اكتشاف أن نظامًا قد وصل إلى مرحلة الأمان 2 قد يكون غير آمن تمامًا بسبب مشاكل ذات صلة بفيات-شامير. هذا يستحق اهتمامنا الكبير والبحث المستمر. قد نحتاج إلى تعديل ذات صلة بفيات-شامير نفسه، لتعزيز الدفاع عن هذه الثغرات.
نظام لا يستخدم التكرار أكثر أمانًا نظريًا، لأن بعض الهجمات المعروفة تشمل دوائر تشبه تلك المستخدمة في البراهين المتكررة. ومع ذلك، هذا المخاطر لا يزال مشكلة أساسية غير محلولة.
مشكلة أخرى تحتاج إلى اهتمام هي أنه حتى إذا ثبتت zkVM أن برنامج حسابي (الذي يحدده البايت كود) قد تم تنفيذه بشكل صحيح، فإذا كان هناك عيوب في البايت كود نفسه، فإن قيمة هذا الإثبات محدودة للغاية. لذلك، تعتمد فعالية zkVM إلى حد كبير على كيفية إنشاء بايت كود يمر بالتحقق الشكلي، وهذا التحدي ضخم للغاية، وخارج نطاق مناقشة هذه المقالة.
حول أمان مقاوم للكم
في السنوات الخمس القادمة على الأقل (ربما أكثر)، لن تكون أجهزة الكمبيوتر الكمية تهديدًا كبيرًا، بينما الثغرات في البرمجيات هي مسألة حيوية. لذلك، يجب أن يكون التركيز الأساسي حاليًا على تحقيق أهداف الأمان والأداء المذكورة في هذا المقال. إذا كان بإمكان SNARKs غير المقاومة للكمية تحقيق هذه الأهداف بشكل أسرع، فيجب علينا أن نعطي الأولوية لاستخدامها. عندما تتعقب SNARKs المقاومة للكمية التطورات، أو يظهر دليل على قرب ظهور أجهزة كمية تشكل تهديدًا فعليًا، يمكننا التفكير في التبديل.
مستوى الأمان الخاص بالتحديد
100-bit الأمان الكلاسيكي هو الحد الأدنى لأي SNARK المستخدم لحماية الأصول القيمة (لكن لا يزال هناك بعض الأنظمة التي لا تصل إلى هذا المستوى المنخفض). ومع ذلك، لا ينبغي قبول ذلك، وتتطلب ممارسات التشفير القياسية عادةً مستوى أمان 128-bit على الأقل. إذا كانت أداء SNARK يفي حقًا بالمعايير، فلا ينبغي أن نخفض مستوى الأمان من أجل تحسين الأداء.
مرحلة الأداء
الوضع الحالي
حالياً، يبلغ تكلفة حوسبة البروفر في zkVM حوالي مليون مرة من التنفيذ الأصلي. بمعنى آخر، إذا كان يتطلب تنفيذ البرنامج الأصلي X دورة للمعالج، فإن إنشاء برهان التنفيذ الصحيح يتطلب حوالي X × 1،000،000 دورة للمعالج. هذا هو الحال كان قبل سنة واليوم لا زال كذلك (على الرغم من وجود بعض الالتباسات).
بعض المصطلحات الشائعة في الصناعة قد تؤدي إلى الإرباك، مثل:
تكلفة إنشاء دليل لشبكة Ethereum الرئيسية بأقل من مليون دولار سنويًا.
"لقد تقربنا كثيرًا من تحقيق إنتاج بيانات الكتل في إيثيريوم بشكل حيني، فقط بحاجة لعدد قليل من وحدات GPU."
"zkVM الجديد لدينا أسرع بمقدار 1000 مرة من الإصدار السابق."
ومع ذلك، قد تكون هذه الادعاءات مضللة في حالة عدم وجود سياق:
• أسرع بمقدار 1000 مرة من الإصدار السابق zkVM ، ومع ذلك قد يكون بطيئًا للغاية ، وهذا يوضح أكثر كيف كانت سيئة في الماضي بدلاً من كيف جيدة الآن.
• قد تزيد قدرة الحوسبة على شبكة Ethereum الرئيسية بمقدار 10 أضعاف في المستقبل، مما سيجعل أداء zkVM الحالي بعيدًا كل البعد عن تلبية الطلب.
• ما يُسَمّى "شبه الزمن الحقيقي" في إنشاء البراهين، لا يزال بطيئًا جدًا في العديد من تطبيقات سلسلة الكتل (على سبيل المثال، يبقى وقت Optmism للكتلة 2 ثانية، أسرع بكثير من 12 ثانية لإثيريوم).
• “العمل المستمر لعدة عشرات من وحدات GPU على مدار الساعة طوال الوقت” لا يمكن أن يوفر ضمان النشاط الكافي.
• وعادة ما تكون أوقات إنشاء هذه البراهين موجهة نحو حجم البراهين الذي يزيد عن 1 ميجابايت، وهذا يعتبر كبيرًا جدًا بالنسبة للعديد من التطبيقات.
• "تكلفة أقل من مليون دولار سنويًا" هي فقط بسبب تنفيذ عقد الإيثيريوم الكامل يقدر بحوالي 25 دولارًا سنويًا فقط.
بالنسبة لسيناريوهات التطبيق خارج سلسلة الكتل، يبدو أن تكلفة هذه الحسابات مرتفعة للغاية. بغض النظر عن الحوسبة المتوازية أو الأمثلة الهندسية، لا يمكن تعويض تكلفة الحسابات الضخمة هذه.
يجب أن يكون الهدف الأساسي الذي نحدده: ألا يتجاوز الأداء التكلفة الأصلية بمعدل 100,000 مرة. ومع ذلك، هذه تظل الخطوة الأولى فقط. إذا كنا بحاجة إلى تحقيق تطبيقات كبيرة حقًا على نطاق واسع، فقد نحتاج إلى خفض التكلفة إلى 10,000 مرة أو أقل من الأداء الأصلي.
قياس الأداء
أداء SNARK مكون من ثلاثة أجزاء رئيسية:
كفاءة النظام الأساسي للإثبات الثابت.
التحسينات الخاصة بالتطبيقات المحددة (مثل الترجمة المسبقة).
الهندسة وتسريع الأجهزة (مثل وحدة معالجة الرسومات GPU، مجال بوابة البرمجة المنطقية FPGA أو وحدة المعالجة المركزية متعددة النوى).
على الرغم من أن (2) و (3) حاسمان للنشر الفعلي، إلا أنهما قابلان للتطبيق على أي نظام إثبات، وبالتالي قد لا تعكس بالضرورة تحسينات التكاليف الأساسية. على سبيل المثال، يمكن بسهولة إضافة تسريع GPU والترجمة المسبقة لـ zkEVM لزيادة السرعة بنسبة 50 مرة مقارنة بالاعتماد البسيط على وحدة المعالجة المركزية - وهذا قد يجعل نظامًا فعالًا منخفض الكفاءة يبدو أفضل من نظام آخر غير مُحسن بنفس الطريقة.
لذلك ، تركز هذه المقالة على قياس الأداء الأساسي ل SNARKs بدون أجهزة مخصصة وتجميع مسبق. هذا على النقيض من طرق المقارنة المعيارية الحالية ، والتي عادة ما تجمع بين العوامل الثلاثة في "قيمة سكانية" واحدة. إنه مثل الحكم على الماس من خلال تلميع الوقت ، بدلا من تقييم وضوحه المتأصل.
هدفنا هو عزل تكاليف نظام الإثبات العامة الأساسية وتقليل عتبة الدخول للتقنيات التي لم يتم دراستها بعمق بعد، ومساعدة المجتمع في التركيز على التقدم الحقيقي في تصميم نظام الإثبات من خلال إزالة العوائق.
مرحلة الأداء
فيما يلي خمس مراحل أداء قدمتها. أولاً، نحتاج إلى تخفيض كبير في تكاليف المثبت على وحدة المعالجة المركزية، قبل أن نتمكن من الاعتماد بشكل أكبر على الأجهزة لتقليل التكاليف. في الوقت نفسه، يجب تحسين استخدام الذاكرة أيضًا.
في جميع المراحل، لا ينبغي للمطورين تعديل الشفرة من أجل أداء zkVM. تجربة المطور هي الفائدة الأساسية لـ zkVM. إذا تم التضحية بـ DevEx لتحقيق معايير الأداء، فإن ذلك ليس فقداناً للهدف من اختبار الأداء فقط، بل يتعارض أيضًا مع الهدف الرئيسي لـ zkVM.
تركز هذه المؤشرات بشكل أساسي على تكلفة الدليل. ومع ذلك، إذا سمحنا بـ زيادة تكلفة المحقق بشكل غير محدود (أي حجم دليل أو وقت تحقق غير محدود)، فيمكن لأي مؤشر للدليل أن يتوافق بسهولة. لذا، لتلبية متطلبات المراحل التالية، يجب تحديد حجم الدليل الأقصى وأقصى وقت للتحقق في نفس الوقت.
المرحلة 1: 'تكلفة التحقق الغير تافهة المعقولة'
• حجم الإثبات: يجب أن يكون أقل من حجم الإثبات.
• وقت التحقق : يجب ألا يكون سرعة التحقق من البرهان أبطأ من تنفيذ البرنامج الأصلي (أي أبطأ من تنفيذ الحساب مباشرة).
هذه هي متطلبات الحد الأدنى للبساطة ، للتأكد من أن حجم الإثبات ووقت التحقق لن يكونا أسوأ من إرسال الشهادات مباشرة إلى المحقق والسماح له بالتحقق مباشرة.
المرحلة 2 وما فوق
• أقصى حجم للدليل: 256 كيلوبايت.
• أقصى وقت للتحقق : 16 مللي ثانية.
تم تعيين هذه الحدود بشكل فضفاض بشكل متعمد لتلبية التكنولوجيا الجديدة للإثبات السريعة، حتى لو كانت تترتب عنها تكاليف تحقق أعلى. في الوقت نفسه، يستبعد هذه الحدود الأدلة التي تكلفة ارتفاعها إلى درجة أنه لا يوجد مشروع يرغب في استخدامها على سلسلة الكتل.
المرحلة 1 من السرعة
يجب ألا يكون دليل الخط المفرد أبطأ من التنفيذ الأصلي بأكثر من 100,000 مرة (مناسب لعدة تطبيقات وليس فقط إثبات كتلة Ethereum) ويجب ألا يعتمد على الإعداد المسبق.
بشكل محدد، يفترض أن معالج RISC-V على كمبيوتر محمول حديث يعمل بسرعة تقدر بحوالي 30 مليار دورة في الثانية، فإذا تم التوصل إلى المرحلة 1، فهذا يعني أن الكمبيوتر المحمول يمكنه إنتاج الإثبات بسرعة 30,000 دورة RISC-V في الثانية (متسلسلة)
يجب أن تلبي تكلفة المحقق معيار "تكلفة التحقق الغير تافهة المعقولة" المعرفة مسبقا.
المرحلة 2 من السرعة
يجب ألا يكون إثبات السرعة أبطأ من التنفيذ الأصلي بأكثر من 10،000 مرة.
أو بالأحرى، يمكن أن يتم تلبية هذه المرحلة من خلال FPGA (حتى ASIC) بسبب قيود الـ CPU و GPU الحالية على بعض أساليب SNARK الواعدة (خاصة SNARK في مجال البيانات الثنائية).
حساب عدد نوى RISC-V المحاكية بسرعة الأصلي FPGA.
حساب ونمذجة وإثبات عدد الـ FPGA اللازمة لتنفيذ RISC-V (ما يقارب الزمن الحقيقي).
إذا كانت كمية (2) لا تتجاوز 10،000 مرة (1) ، فسيتم تحقيق المرحلة 2.
• حجم الإثبات: الحد الأقصى 256 كيلو بايت.
• وقت التحقق : 16 مللي ثانية كحد أقصى على وحدة المعالجة المركزية القياسية.
المرحلة 3 السرعة
حقق النفقات العامة للإثبات في حدود 1000× أعلى مرحلة السرعة 2 (لمجموعة كبيرة من التطبيقات) ويجب استخدام التجميع المسبق للتوليف التلقائي والتحقق الرسمي. بشكل أساسي ، يتم تخصيص مجموعة تعليمات كل برنامج ديناميكيا لتسريع توليد الإثبات ، ولكن يجب أن تكون سهلة الاستخدام والتحقق منها رسميا. (راجع القسم التالي حول سبب كون التجميع المسبق سيفا ذا حدين ، ولماذا لا يعد التجميع المسبق "بخط اليد" نهجا مستداما.) ）
المرحلة 1 الخاصة بالذاكرة
في ظل أقل من 2 GB من الذاكرة للوصول إلى مرحلة السرعة 1 وفي نفس الوقت تلبية متطلبات علم الصفر. تعد هذه المرحلة حاسمة لـ الأجهزة المحمولة أو المتصفحات وتفتح الباب أمام العديد من حالات استخدام zkVM على العميل. على سبيل المثال، يُستخدم الهواتف الذكية لـ خصوصية الموقع، وثائق الهوية وغيرها. إذا كان إنشاء البرهان يتطلب أكثر من 1-2 جيجابايت من الذاكرة، فإن معظم الأجهزة المحمولة لن تتمكن من تشغيلها.
ملاحظتان مهمتان:
حتى لو كانت الحوسبة بمقياس كبير (تتطلب تنفيذًا أصلاً يستغرق عشرات تريليونات دورة CPU) ، يجب أن تحافظ أنظمة الإثبات على حد أقصى من الذاكرة بحجم 2 جيجابايت ، وإلا سيتم تقييدها.
إذا تم تحقيق بطء شديد في السرعة، فمن السهل جدًا الحفاظ على حد أقصى للذاكرة بحجم 2 غيغابايت. لذلك، لجعل مرحلة الذاكرة 1 ذات معنى، يجب أن يتم الوصول إلى مرحلة السرعة 1 ضمن حدود الذاكرة بحجم 2 غيغابايت.
المرحلة 2 الذاكرة
في ظل ظروف أقل من 200 ميغابايت تحقيق المرحلة 1 من السرعة (عشر مرات أفضل من المرحلة 1 في الذاكرة).
لماذا تم تقليلها إلى 200 ميغابايت؟ تفكير في سيناريو خارج سلسلة الكتل : عند زيارتك لموقع ويب محمي ببروتوكول HTTPS ، سيتم تنزيل شهادات المصادقة والتشفير. إذا قام الموقع بإرسال براهين zk هذه بدلاً من الشهادات ، فقد تحتاج المواقع الكبيرة إلى إنشاء ملايين البراهين كل ثانية. إذا كان كل برهان يتطلب 2 غيغابايت من الذاكرة ، فإن الاحتياجات إلى الموارد الحسابية ستصل إلى مستوى PB ، وهو أمر غير عملي بالطبع. لذلك ، فإن تقليل استخدام الذاكرة بشكل أكبر يعد أمرًا حيويًا لتطبيقات غير سلسلة الكتل.
الترجمة المسبقة: الأميال الأخيرة، هل هي عصا؟
الترجمة المسبقة تشير إلى نظام قيود SNARK محسن خصيصًا لوظائف محددة (مثل التجزئة ، والتوقيع بالمنحنى البيضاوي). في Ethereum ، يمكن للترجمة المسبقة تقليل تكلفة التحقق من التجزئة والتوقيع ، ولكن الاعتماد المفرط على الترجمة المسبقة لا يمكن أن يعزز حقا كفاءة SNARK الأساسية.
مشكلة مُعَدَّة مسبقًا
1. لا يزال بطيئًا: حتى مع استخدام تجهيزات الهاش والتوقيع المسبقة، يظل zkVM يعاني من مشكلة كفاءة النظام الأساسي للإثبات داخل وخارج سلسلة الكتل.
2. الثغرات الأمنية : إذا لم يتم التحقق الشكلي من التجهيز المسبق للكتابة اليدوية ، فإنه من المرجح بشكل كبير وجود ثغرات ، مما قد يؤدي إلى فشل أمني كارثي.
3. تجربة المطور غير جيدة: حاليًا ، يحتاج العديد من zkVM إلى كتابة نظام القيود يدويًا من قبل المطورين ، على غرار طريقة البرمجة في الستينيات من القرن الماضي ، مما يؤثر سلبًا على تجربة التطوير.
4. الاختبار الأساسي المضلل: إذا كان اعتماد اختبار أساسي على تحسين معين مُعد مسبقًا، فقد يوجه الناس انتباههم نحو تحسين القيود اليدوية للنظام، بدلاً من تعزيز تصميم SNARK نفسه.
5. تكلفة الإدخال/الإخراج وعدم وجود وصول إلى الذاكرة العشوائية على الرغم من أن الإعداد المسبق يمكن أن يعزز أداء المهام الكثيفة للتشفير، إلا أنه قد لا يكون قادرًا على تقديم تسريع معنوي لأحمال عمل متنوعة أكثر، لأنها تولد تكاليف كبيرة عند تقديم الإدخال/الإخراج، ولا يمكنها استخدام الذاكرة العشوائية.
حتى في بيئة سلسلة الكتل، ستواجه تحديات مختلفة في حال تجاوزت مثل هذا L1 الفردية مثل Ethereum (على سبيل المثال، إذا كنت ترغب في إنشاء سلسلة من الجسور العابرة للسلسلة)، ستواجه تحديات مختلفة في وظائف التجزئة وبرامج التوقيع. لحل هذه المشكلة، يجب إجراء ترجمة مسبقة باستمرار، وهو أمر لا يمكن توسيعه ويشكل مخاطر أمنية هائلة.
أؤمن حقًا بأن البرمجة المُسبقة ما زالت مهمة للغاية على المدى الطويل، ولكن فقط عندما يتم توليدها تلقائيًا وتمريرها بالتحقق الرسمي. بهذه الطريقة، يمكننا الحفاظ على ميزة تجربة المطورين لـ zkVM، مع تجنب المخاطر الأمنية الكارثية. يتم تعكس هذه الوجهة نظر في المرحلة 3.
الجدول الزمني المتوقع
أتوقع أن تصل أقلية zkVM في وقت لاحق من هذا العام إلى المرحلة 1 السرعة والمرحلة 1 الذاكرة. أعتقد أننا يمكن أيضًا تحقيق المرحلة 2 السرعة خلال السنتين القادمتين، لكن ليس واضحًا حاليًا ما إذا كان بإمكاننا تحقيق هذا الهدف دون وجود مسار بحث جديد.
أتوقع أن يستغرق الأطوار المتبقية (مرحلة السرعة 3 ومرحلة الذاكرة 2) عدة سنوات للوصول إلى الاتفاق.
على الرغم من أن هذا المقال يفصل بين مراحل أمان zkVM وأدائها، إلا أن كلاهما ليسا مستقلين تمامًا. مع استمرار اكتشاف الثغرات في zkVM، أتوقع أن تؤدي إصلاحات بعض هذه الثغرات بشكل لا مفر منه إلى انخفاض كبير في الأداء. لذلك، يجب أن تُعتبر نتائج اختبار الأداء لـ zkVM مؤقتة حتى تصل zkVM إلى المرحلة الأمنية 2.
يتمتع zkVM بإمكانات هائلة في نشر البراهين المعرفية الصفرية بشكل حقيقي، ولكنها في الوقت الحالي تزال في مراحلها الأولية - مليئة بالتحديات الأمنية وتعاني من عقبات أداء خطيرة. يجعل الترويج السوقي والتسويق من الصعب قياس التقدم الحقيقي. من خلال علامات أمان وأداء محددة، آمل أن أقدم خارطة طريق تمكن من تفسير الغموض. سنصل في النهاية إلى الهدف، ولكن هذا يتطلب الوقت والجهد المتواصل في مجال البحث والهندسة.