الطريق إلى zkVMs الآمنة والفعالة: كيفية تتبع التقدم
المؤلف الأصلي: a16z كريبتو
ترجمة المصدر: Golem، Odaily 星球日报
zkVM (الجهاز الظاهري الخالي من المعرفة) يعد بـ 'جعل SNARK شائعًا'، مما يسمح لأي شخص (حتى أولئك الذين ليس لديهم معرفة مهنية في SNARK) بإثبات أنهم قاموا بتشغيل أي برنامج معين بشكل صحيح على إدخال (أو شهادة) معين. تكمن ميزتها الأساسية في تجربة المطورين، لكنها تواجه تحديات هائلة حالياً في الأمان والأداء. من أجل تحقيق رؤية zkVM والوفاء بالوعود، يجب على مصممي النظام التغلب على هذه التحديات. في هذه المقالة، أذكر مراحل تطوير zkVM المحتملة، والتي ستحتاج إلى سنوات لإكمالها.
تحدي
من الناحية الأمنية، zkVM هو مشروع برمجيات معقد للغاية ولا يزال مليء بالثغرات. من الناحية الأداء، قد تكون سرعة تأكيد تنفيذ البرنامج الصحيح أبطأ بمرات عديدة من التشغيل المحلي، مما يجعل معظم التطبيقات غير قادرة حاليًا على النشر في العالم الحقيقي.
على الرغم من وجود تحديات الواقع هذه، إلا أن معظم شركات صناعة سلسلة الكتل تصور zkVM كما يمكن نشره على الفور. في الواقع، دفعت بعض المشاريع تكلفة حسابية كبيرة بالفعل لإنشاء دليل على النشاط على السلسلة. ولكن بسبب عدم اكتمال zkVM بعد، هذه هي فقط طريقة مكلفة لتظاهر بأن النظام محمي بواسطة SNARK، عند الحقيقة فإنه إما محمي بالإذن أو، الأسوأ من ذلك، عرضة للهجوم.
لدينا عدة سنوات قبل تحقيق zkVM آمن وذو أداء عالٍ. يقدم هذا المقال سلسلة من الأهداف المحددة المرحلية لتتبع تقدم zkVM - هذه الأهداف يمكن أن تزيل التضخيم وتساعد المجتمع على التركيز على التقدم الحقيقي.
مرحلة الأمان
الـ zkVM القائم على SNARK عادة ما يتضمن مكونين رئيسيين:
· إثبات أوراق العمل التفاعلية لشهادة أوراكل متعددة الحدود (PIOP): يستخدم لإثبات إطار الإثبات التفاعلي للبيانات حول المتعددة الحدود (أو القيود المستمدة منها).
· حزمة التعهد العديدية (PCS): تضمن أن المثبت لا يمكنه أن يكذب على تقييم الحزمة دون اكتشافه.
zkVM في الأساس يحول تتبع التنفيذ الفعال إلى نظام قيد - مما يعني بشكل عام أنها تجبر الجهاز الظاهري على استخدام السجلات والذاكرة بشكل صحيح - ثم يطبق SNARK لإثبات أن هذه القيود تمت مراعاتها.
ضمان عدم وجود أخطاء في نظام معقد مثل zkVM هو عن طريق التحقق الرسمي. إليك تقسيم مراحل الأمان. المرحلة 1 تركز على البروتوكول الصحيح، بينما تركز المرحلة 2 والمرحلة 3 على التنفيذ الصحيح.
المرحلة الأمنية 1: البروتوكول الصحيح
1، تحقق رسمي من موثوقية PIOP؛
2، يتم التحقق من شكل الإثبات الملزم لـ PCS في بعض النماذج الرمزية أو النماذج الأيديالية.
3، إذا تم استخدام Fiat-Shamir، فإن إثبات الشهادة الموجز الذي تم الحصول عليه من خلال PIOP وPCS آمن في نموذج النبوءة العشوائية بموجب إثبات رسمي (مع تعزيزه حسب الحاجة باستخدام فرضيات تشفير أخرى)؛
4، يعادل نظام القيود المستخدم في PIOP تحقق صحة شكل الدليل الدلالي لـ VM؛
5، وصل جميع هذه الأجزاء المذكورة أعلاه بشكل كامل كـ "لصق" واحد موحد، وتحقق صحة الأدلة الحماية (SNARK) الموجودة لتشغيل أي برنامج محدد من خلال بايتات التعليمات الافتراضية للآلة الظاهرية. إذا كان البروتوكول ينوي تحقيق الخصوصية التامة، فيجب أيضًا التحقق من صحة هذه الخاصية بشكل رسمي لضمان عدم تسرب المعلومات الحساسة حول الشهود.
تحذير الارتداد: إذا كان zkVM يستخدم الارتداد، يجب التحقق من كل PIOP وبرنامج التعهد ونظام القيود المتعلق بأي مكان في هذا الارتداد قبل أن يعتبر هذا المرحلة مكتملة.
المرحلة الثانية: تنفيذ محقق صحيح
تأكد من تطابق التنفيذ الفعلي لتحقق zkVM Validator (باستخدام Rust و Solidity وما إلى ذلك) مع بروتوكول التحقق من المرحلة 1. يمكن تحقيق ذلك لضمان أن البروتوكول المنفذ هو منطقي (وليس مجرد تصميم على الورق، أو مواصفة غير فعالة مكتوبة بواسطة Lean وما إلى ذلك).
السببان الرئيسيان للتركيز في المرحلة 2 على تنفيذ القارن (وليس البرهان) هما جانبان. أولاً، فإن استخدام القارن بشكل صحيح يكفي لضمان الموثوقية (أي ضمان أن القارن لا يمكنه الاعتماد على أي بيانات زائفة كونها حقيقية في الواقع). وثانياً، تكون تنفيذات قارن zkVM أبسط بدرجة واحدة من تنفيذات prover.
المرحلة الثالثة من الأمان: تنفيذ البرهان الصحيح
تم تنفيذ برنامج تجزئة zkVM بشكل صحيح لإنشاء برهان لنظام برهان مرحلة 1 ومرحلة 2، أي الحصول على التحقق الرسمي. هذا يضمن النزاهة، أي أن أي نظام يستخدم zkVM لن يتعطل بسبب بيانات غير قابلة للإثبات. إذا كان برنامج البرهان يهدف إلى تنفيذ المعرفة الصفرية، فإنه يجب التحقق الرسمي من هذا الخاصية.
الجدول الزمني المتوقع
· المرحلة 1: النتقلات: يمكننا التوقع بأن نحقق تقدما تدريجيا العام المقبل (مثل ZKLib). لكن على الأقل لن يكون هناك zkVM قادر على تلبية متطلبات المرحلة 1 تماما خلال عامين على الأقل؛
· المراحل 2 و 3: يمكن تقدم هذه المراحل مع بعض جوانب المرحلة 1 في نفس الوقت. على سبيل المثال، أثبتت بعض الفرق أن تنفيذ جهاز التحقق Plonk يتطابق مع بروتوكول الورقة (على الرغم من أن البروتوكول في الورقة قد لم يتم التحقق منه بالكامل). على الرغم من ذلك، أتوقع أن لن يصل أي zkVM إلى المرحلة 3 في أقل من أربع سنوات - وربما أكثر.
أحد العوامل المعقدة الرئيسية هو وجود مشكلات بحث غير محلولة حول أمان تحويل Fiat-Shamir. يُعتبر Fiat-Shamir وآلة النبوءة العشوائية جزءًا من أمانها لا يمكن اختراقها في جميع المراحل الثلاث، ولكن في الواقع قد تحتوي هذه النماذج بأكملها على ثغرات. يعود ذلك إلى تفاوت كبير بين آلة النبوءة العشوائية المثالية ووظيفة التجزئة التي تُستخدم فعليًا. في أسوأ الحالات، قد يتم اكتشاف نظام الذي وصل إلى المرحلة 2 بسبب مشكلة Fiat-Shamir كونه غير آمن تمامًا لاحقًا، مما أثار مخاوف جدية وبحث مستمر. قد نحتاج إلى تعديل التحويل نفسه لتعزيز الحماية ضد مثل هذه الثغرات.
نظام بدون عودية أكثر استقرارًا نظريًا، لأن بعض الدوائر التي يتعامل معها بعض الهجمات المعروفة تشبه الدوائر المستخدمة في البراهين العودية.
شيء آخر يستحق الاهتمام هو أنه إذا كانت البايت كود نفسه به عيوب، فإن القيمة محدودة حتى إذا تم تشغيل برنامج الكمبيوتر بشكل صحيح (عن طريق تحديد البايت كود). ولذلك، يعتمد إمكانية استخدام zkVM إلى حد كبير على الطريقة التي يتم فيها إنشاء البايت كود للتحقق الشكلي - وهذا تحدي كبير يتجاوز نطاق هذه المقالة.
حول أمان العصر بعد الكم
على الأقل خلال الخمس سنوات القادمة (وقد تستمر لفترة أطول)، لن يشكل الحاسوب الكمّي تهديداً كبيراً، بينما الثغرات هي نوع من مخاطر البقاء. لذلك، يجب أن يكون التركيز الرئيسي الآن على تلبية مراحل الأمان والأداء المدرجة في هذا المقال. إذا كنا قادرين على استخدام SNARK الغير كمّي لتلبية هذه المتطلبات الأمنية بشكل أسرع، فيجب علينا أن نفعل ذلك، حتى يتم اللحاق بـ SNARK الكمّي لاحقًا، أو حتى يصبح الناس قلقين بشكل كبير من ظهور أجهزة الحاسوب الكمّي المتعلقة بالتشفير.
حالة أداء zkVM
حاليًا، يبلغ معامل التكلفة الذي يولده جهاز البرهان zkVM ما يقارب 1000000 مرة تكلفة التنفيذ الأصلية. إذا احتاج البرنامج إلى X دورة للتشغيل، فإن تكلفة تنفيذ البرهان الصحيح تقدر بحوالي X مضروبًا في 1000000 دورة للمعالج. كانت هذه هي الحالة قبل عام، وتظل اليوم كذلك.
السرد الشائع غالبًا ما يصف هذه التكاليف بطريقة تبدو قابلة للقبول من الناحية السمعية. على سبيل المثال:
· "تكلفة إنتاج البراهين على شبكة الإيثيريوم الرئيسية أقل من مليون دولار سنويًا."
يمكننا تقريبًا استخدام مجموعة من عشرات وحدات GPU لإنشاء بلوكات إثيريوم الدليلية في الوقت الحقيقي.
·"zkVM الجديد لدينا أسرع بمقدار 1000 مرة من سابقه."
على الرغم من أن هذه الادعاءات دقيقة من الناحية التقنية، إلا أنها قد تؤدي إلى الإرباك إذا لم يكن هناك خلفية مناسبة. على سبيل المثال:
· تسريع zkVM الجديد بمقدار 1000 مرة، لكن السرعة المطلقة لا تزال بطيئة للغاية. هذا يشير بشكل أكبر إلى مدى سوء الأمور بدلاً من مدى جيدها.
· تم اقتراح زيادة حجم الحسابات التي تتم معالجتها على شبكة Ethereum الرئيسية بمقدار 10 أضعاف، مما سيجعل أداء zkVM الحالي أبطأ.
ما يُقال عن 'إثبات تقريبي للكتل في إيثريوم بالزمن الفعلي' لا يزال أبطأ بكثير مما يتطلبه العديد من تطبيقات سلسلة الكتل (على سبيل المثال، يعتبر زمن الكتل في Optimism 2 ثانية، أسرع بكثير من زمن كتلة إيثريوم البالغ 12 ثانية).
· يمكن أن يكون تشغيل عدة بطاقات GPU دون أخطاء غير قابل للقبول لضمان النشاط.
· إن إنفاق أقل من مليون دولار سنويًا لإثبات أن جميع الأنشطة على شبكة الإيثيريوم الرئيسية تعكس حقيقة أنه يتعين فقط إنفاق حوالي 25 دولارًا سنويًا على تشغيل الحواسيب للقيام بالحسابات.
بالنسبة لتطبيقات خارج سلسلة الكتل، فإن تكلفة ذلك مرتفعة بشكل واضح. لا يمكن لأي توازن أو هندسة معاكسة تكلفة هائلة مثل هذه. يجب أن نعتبر سرعة zkVM بنسبة للتنفيذ المحلي لا تقل عن 100،000 مرة كمعيار أساسي - حتى لو كان هذا هو الخطوة الأولى فقط. قد يكون الاعتماد الرئيسي الحقيقي يتطلب تكلفة تقترب من 10،000 مرة أو أقل.
كيفية قياس الأداء
أداء SNARK يتألف من ثلاثة مكونات رئيسية:
· كفاءة النظام الأساسي للإثبات الداخلي.
تحسين محدد للتطبيق (مثل الترميز المسبق).
· الهندسة وتسريع الأجهزة (مثل وحدة معالجة الرسومات GPU أو FPGA أو وحدة المعالجة المتعددة النواة CPU).
على الرغم من أن كل من العاملين الأخيرين حيويان لنشر العملية الفعلية، إلا أنهما عادة ما يكونان مناسبين لأي نظام إثبات، وبالتالي قد لا تعكس بالضرورة التكاليف الأساسية. على سبيل المثال، يمكن بسهولة تحقيق تسارع بنسبة 50 مرة من خلال إضافة تسريع GPU والتعاريف المسبقة في zkEVM، وهذا يجعلها أسرع بكثير من الطريقة الخالية من التعاريف المسبقة والمعتمدة على وحدة المعالجة المركزية فقط - بما يكفي لجعل النظام الذي يعتمد أساسًا على كفاءة منخفضة يبدو أفضل من النظام الذي لم يتم تنقيته بنفس الطريقة.
لذلك ، يركز ما يلي على أداء SNARKs بدون أجهزة متخصصة وتجميع مسبق. هذا على النقيض من طرق القياس الحالية ، والتي عادة ما تلخص العوامل الثلاثة في "رقم رئيسي" واحد. هذا يعادل الحكم على قيمة الماس بناء على المدة التي تم صقلها بدلا من نقاءها الجوهري. هدفنا هو القضاء على النفقات العامة المتأصلة في نظام الإثبات العالمي - لمساعدة المجتمع على التخلص من الارتباك والتركيز على التقدم الحقيقي في إثبات تصميم النظام.
مرحلة الأداء
هناك 5 معلماً في تحقيق الأداء. أولاً، يجب تقليل تكلفة البرهان على وحدة المعالجة المركزية بعدة مرات. فقط عندها ينبغي التركيز على تقليلها بشكل أكبر من خلال الأجهزة. يجب أيضاً زيادة معدل استخدام الذاكرة.
في جميع المراحل التالية، لا يلزم المطورون تخصيص الكود وفقًا لإعدادات zkVM لتحقيق الأداء المطلوب. تجربة المطورين هي الفائدة الرئيسية لـ zkVM. التضحية بتجربة المطورين من أجل تحقيق معايير الأداء تتنافى مع معنى zkVM نفسها.
تركز هذه المؤشرات على تكلفة الحامل. ومع ذلك، إذا سمح بتكلفة الحامل غير المحدودة (أي لا يوجد حد أقصى لحجم البرهان أو وقت التحقق)، يمكن بسهولة تحقيق أي مؤشر لحامل. لذلك، يجب تحديد حد أقصى لحجم البرهان ووقت التحقق لتلبية النظام في المرحلة المشار إليها.
الأداء المطلوب
مرحلة 1: 'تكلفة التحقق العقلانية وغير العادية' :
· الحجم الإثبات: يجب أن يكون حجم الإثبات أصغر من حجم الشهادة.
· وقت التحقق: يجب ألا يتجاوز سرعة إثبات التحقق سرعة تشغيل الجهاز المضيف (أي تنفيذ الحساب دون إثبات صحة).
هذه هي الحد الأدنى من متطلبات البساطة. تضمن أن حجم الإثبات ووقت التحقق لن يكونا أسوأ من إرسال الشاهد إلى المحققين والسماح للمحققين بالتحقق مباشرة من صحتها.
المرحلة 2 وما باعدها:
· الحد الأقصى لحجم البرهان: 256 كيلوبايت.
· أقصى وقت التحقق: 16 ميلي ثانية.
تم تخصيص هذه القيم الحدية عن عمد بزيادة ، لتكيف مع تكنولوجيا الإثبات السريعة الجديدة التي قد تجلب تكاليف تحقق أعلى. في الوقت نفسه ، تستبعد الإثبات المكلف بشكل كبير ، لدرجة أن نادرًا ما تكون العمليات على استعداد لتضمينها في سلسلة الكتل.
المرحلة 1 من السرعة
يجب أن يكون إثبات الخط الواحد أبطأ بكثير من التنفيذ المحلي بحد أقصى مائة ألف مرة، ويجب أن يتم قياس ذلك في سلسلة من التطبيقات (ليس فقط إثبات كتل إيثريوم) دون الاعتماد على التجهيز المسبق.
على وجه التحديد ، تخيل عملية RISC-V تعمل بحوالي 3 مليارات دورة في الثانية على جهاز كمبيوتر محمول حديث. يعني تحقيق المرحلة 1 أنه يمكنك إثبات حوالي 30،000 دورة RISC-V في الثانية (أحادية الخيط) على نفس الكمبيوتر المحمول. ومع ذلك، يجب أن تكون تكلفة التحقق "معقولة وغير تافهة" كما ذكر سابقا.
المرحلة 2 السرعة
يجب أن يكون إثبات الخط الواحد بطيئًا بحد أقصى عشرة آلاف مرة من التنفيذ المحلي.
أو بسبب عرقلة بعض أساليب SNARK الواعدة (خاصة تلك القائمة على الحقول الثنائية) بسبب وحدات المعالجة المركزية ووحدات معالجة الرسومات الحالية، يمكنك النظر في استخدام FPGA (أو حتى ASIC) بدلاً من ذلك.
FPGA يمكن أن تحاكي عدد النوى RISC-V بسرعة الجهاز الأصلية؛
تحاكي وتثبت (تقريبا) العدد اللازم من FPGA لتنفيذ RISC-V بشكل (ما يقرب من) فوري.
إذا كان العامل الأخير ضعف الأول بحد أقصى 10،000 مرة، فستكون مؤهلاً للانتقال إلى المرحلة الثانية. على وحدة المعالجة المركزية القياسية، يجب أن يكون حجم البرهان كحد أقصى 256 كيلوبايت، ويجب أن يكون وقت المحقق كحد أقصى 16 ميلليثانية.
مرحلة السرعة 3
بالإضافة إلى الوصول إلى المرحلة 2 بسرعة، يمكن أيضًا استخدام التركيب التلقائي والتحقق من الشكل لتحقيق تكاليف الإثبات أقل من 1000 مرة (مناسب لتطبيقات واسعة النطاق). في الجوهر، يمكن تخصيص مجموعة التعليمات الديناميكية لكل برنامج لتسريع عملية الإثبات، ولكن يجب أن يتم ذلك بطريقة سهلة الاستخدام والتحقق من الشكل.
المرحلة 1 من الذاكرة
تم تحقيق سرعة المرحلة 1 عندما كانت الذاكرة المطلوبة للبروفر أقل من 2 غيغابايت (مع تحقيق الصفر معرفة).
هذا مهم للعديد من الأجهزة المحمولة أو المتصفحات، وبالتالي فإنه يفتح العديد من حالات استخدام zkVM للعملاء. إن الإثبات العميل أمر مهم لأن هواتفنا هي وسيلتنا المستمرة للتواصل مع العالم الحقيقي: إنها تتتبع موقعنا وبطاقات الاعتماد وما إلى ذلك. إذا كان إنشاء الإثبات يتطلب أكثر من 1-2 جيجابايت من الذاكرة، فهذا كثير جدًا بالنسبة لمعظم أجهزة الجوال في الوقت الحالي. هناك حاجة لتوضيح نقطتين:
· تطبق حدود مساحة 2 جيجابايت على البيانات الكبيرة (التي تتطلب ملايين من دورات وحدة المعالجة المركزية لتشغيلها محليًا). نظام إثبات حدود المساحة المطبق فقط على البيانات الصغيرة يفتقر إلى قدرة تطبيق شاملة.
إذا كان جهاز الإثبات بطيئًا للغاية ، فمن السهل جدًا الاحتفاظ بذاكرة جهاز الإثبات داخل 2 جيجابايت. لذلك ، من أجل جعل مرحلة الذاكرة 1 أقل بساطة ، طلبت تحقيق سرعة المرحلة 1 ضمن حدود 2 جيجابايت.
المرحلة الثانية من الذاكرة
سُرعة المرحلة 1 تم تحقيقها عندما كان استخدام الذاكرة أقل من 200 ميجابايت (أفضل بمقدار 10 مرات من مرحلة 1 من الذاكرة).
لماذا تقلل إلى أقل من 2 جيجابايت؟ فكر في مثال خارج عن سياق البلوكتشين: في كل مرة تقوم فيها بزيارة موقع عبر HTTPS، ستقوم بتنزيل شهادة للتحقق من الهوية والتشفير. بدلاً من ذلك، يمكن للموقع إرسال براهين zk التي تحتوي على هذه الشهادات. يمكن أن يصدر المواقع الكبيرة ملايين من مثل هذه البراهين في الثانية. إذا كانت كل برهان يتطلب 2 جيجابايت من الذاكرة للإنشاء، فإن إجمالي الذاكرة المطلوبة سيكون بيتابايتي. تخفيض استخدام الذاكرة بشكل أكبر أمر حيوي للنشر خارج سياق البلوكتشين.
الترجمة: هل الأخيرة ما زالت عصا؟
في تصميم zkVM، يشير البرنامج المسبق إلى SNARK المخصص المصمم خصيصًا لوظيفة معينة، مثل تجزئة Keccak/SHA للتوقيع الرقمي أو عمليات مجموعة المنحنيات البيضاوية. في Ethereum (حيث ينطوي معظم العمل الشاق على تحقق تجزئة Merkle والتحقق من التوقيع)، يمكن لبعض البرامج المسبقة التي تم إنشاؤها يدويًا تقليل تكلفة المثبت. ومع ذلك، الاعتماد عليها كعكاز لا يمكن أن يجعل SNARK يحقق الأهداف المطلوبة منها. الأسباب على النحو التالي:
· بالنسبة لمعظم التطبيقات (داخل وخارج سلسلة الكتل) ، فهي لا تزال بطيئة جدًا: حتى مع استخدام التجهيز المسبق للتجزئة والتوقيع ، يظل zkVM الحالي بطيئًا للغاية (سواء داخل بيئة سلسلة الكتل أو خارجها) بسبب كفاءة النظام الأساسي المنخفضة للبرهان.
**· خطأ أمان: ** يكاد البرمجة المسبقة اليدوية غير المعتمدة بشكل رسمي تكاد تكون مليئة بالأخطاء، مما قد يؤدي إلى فشل أمان كارثي.
**· تجربة تطوير البرمجيات غير مرضية: ** في معظم zkVMs الحالية، إضافة تجهيز جديد يعني كتابة نظام مقيد يدوي لكل وظيفة - في الأساس، العودة إلى سير العمل بنمط الستينيات. حتى عند استخدام التجهيز الموجود، يجب على مطوري البرامج إعادة بناء الشيفرة لاستدعاء كل تجهيز. يجب أن نحسن من التوازن بين الأمان وتجربة تطوير البرمجيات، بدلاً من التضحية بكلاهما من أجل تحقيق أداء تكميلي. هذا فقط يثبت أن الأداء لم يصل إلى المستوى المطلوب.
· تكاليف I/O دون ذاكرة وRAM: على الرغم من أن البرمجة المسبقة يمكن أن تعزز أداء المهام العملية الثقيلة التشفيرية، إلا أنها قد لا توفر تسريعًا ذا معنى لمجموعة أوسع من أعباء العمل المتنوعة، لأنها تنتج تكاليف كبيرة أثناء تبادل الإدخال/الإخراج، ولا يمكنها استخدام RAM. حتى في بيئة سلسلة الكتل، ستواجه تحديات جديدة مثل استخدام وظائف تجزئة هاش وبرامج توقيع مختلفة كلما تجاوزت شبكة مثل Ethereum المستوى الأول الفردي (على سبيل المثال، إذا كنت ترغب في بناء سلسلة من الجسور بين الشبكات). إجراء البرمجة المسبقة مرارًا وتكرارًا لنفس المشكلة لا يمكن أن يوسع النطاق ويشكل مخاطر أمنية هائلة.
لهذه الأسباب جميعها، يجب أن يكون أولويتنا الرئيسية هي تحسين كفاءة zkVM الأساسية. تقنية أفضل لـ zkVM ستنتج أيضًا أفضل برمجيات مُعدة مُسبقًا. أنا حقًا أعتقد أن البرمجيات المُعدة مُسبقًا ستظل مهمة في المدى البعيد، ولكن الشرط الأساسي هو أن يتم توليفها تلقائيًا والتحقق من صحتها رسميًا. بهذه الطريقة، يمكن الاحتفاظ بميزة تجربة مُطوّري zkVM، وفي الوقت نفسه تجنب المخاطر الأمنية الكارثية. يتم تعكس هذه الرؤية في مرحلة السرعة 3.
الجدول الزمني المتوقع
أتوقع أن تحقق zkVM القليلة في وقت لاحق من هذا العام مرحلة السرعة 1 ومرحلة الذاكرة 1. أعتقد أننا سنحقق أيضًا مرحلة السرعة 2 في السنوات القادمة ، لكن ليس من الواضح حاليًا ما إذا كان بإمكاننا تحقيق هذا الهدف بدون بعض الأفكار الجديدة التي لم تظهر بعد. أتوقع أن تستغرق المراحل المتبقية (السرعة 3 والذاكرة 2) بضع سنوات لتحقيقها.
تلخيص
على الرغم من أنني حددت بشكل منفصل أمان zkVM ومراحل الأداء في هذه المقالة، إلا أن هذه الجوانب من zkVM ليست مستقلة تمامًا. مع اكتشاف المزيد من الثغرات في zkVM، من المتوقع أن تكون بعض الثغرات قابلة للإصلاح فقط عندما ينخفض الأداء بشكل كبير. يجب تأجيل الأداء حتى يتم الوصول إلى مرحلة الأمان 2 في zkVM.
يعتبر zkVM الأمل في تعميم البراهين الصفرية المعرفة، لكنها لا تزال في مراحلها الأولى - مليئة بالتحديات الأمنية والتكاليف الأدائية الضخمة. يجعل الترويج والتسويق الصعب تقييم التقدم الحقيقي. من خلال توضيح العلامات البارزة الواضحة من الناحية الأمنية والأدائية، نأمل في توفير خارطة طريق تقضي على الإرباك. سنحقق الأهداف، ولكن هذا يتطلب وقتًا وجهدًا مستمرًا.
رابط المقال الأصلي
：
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
a16z: كيفية تحقيق zkVM الآمن والفعال مرحليا (يجب أن يراها المطورون)
zkVM (الجهاز الظاهري الخالي من المعرفة) يعد بـ 'جعل SNARK شائعًا'، مما يسمح لأي شخص (حتى أولئك الذين ليس لديهم معرفة مهنية في SNARK) بإثبات أنهم قاموا بتشغيل أي برنامج معين بشكل صحيح على إدخال (أو شهادة) معين. تكمن ميزتها الأساسية في تجربة المطورين، لكنها تواجه تحديات هائلة حالياً في الأمان والأداء. من أجل تحقيق رؤية zkVM والوفاء بالوعود، يجب على مصممي النظام التغلب على هذه التحديات. في هذه المقالة، أذكر مراحل تطوير zkVM المحتملة، والتي ستحتاج إلى سنوات لإكمالها.
تحدي
من الناحية الأمنية، zkVM هو مشروع برمجيات معقد للغاية ولا يزال مليء بالثغرات. من الناحية الأداء، قد تكون سرعة تأكيد تنفيذ البرنامج الصحيح أبطأ بمرات عديدة من التشغيل المحلي، مما يجعل معظم التطبيقات غير قادرة حاليًا على النشر في العالم الحقيقي.
على الرغم من وجود تحديات الواقع هذه، إلا أن معظم شركات صناعة سلسلة الكتل تصور zkVM كما يمكن نشره على الفور. في الواقع، دفعت بعض المشاريع تكلفة حسابية كبيرة بالفعل لإنشاء دليل على النشاط على السلسلة. ولكن بسبب عدم اكتمال zkVM بعد، هذه هي فقط طريقة مكلفة لتظاهر بأن النظام محمي بواسطة SNARK، عند الحقيقة فإنه إما محمي بالإذن أو، الأسوأ من ذلك، عرضة للهجوم.
لدينا عدة سنوات قبل تحقيق zkVM آمن وذو أداء عالٍ. يقدم هذا المقال سلسلة من الأهداف المحددة المرحلية لتتبع تقدم zkVM - هذه الأهداف يمكن أن تزيل التضخيم وتساعد المجتمع على التركيز على التقدم الحقيقي.
مرحلة الأمان
الـ zkVM القائم على SNARK عادة ما يتضمن مكونين رئيسيين:
· إثبات أوراق العمل التفاعلية لشهادة أوراكل متعددة الحدود (PIOP): يستخدم لإثبات إطار الإثبات التفاعلي للبيانات حول المتعددة الحدود (أو القيود المستمدة منها).
· حزمة التعهد العديدية (PCS): تضمن أن المثبت لا يمكنه أن يكذب على تقييم الحزمة دون اكتشافه.
zkVM في الأساس يحول تتبع التنفيذ الفعال إلى نظام قيد - مما يعني بشكل عام أنها تجبر الجهاز الظاهري على استخدام السجلات والذاكرة بشكل صحيح - ثم يطبق SNARK لإثبات أن هذه القيود تمت مراعاتها.
ضمان عدم وجود أخطاء في نظام معقد مثل zkVM هو عن طريق التحقق الرسمي. إليك تقسيم مراحل الأمان. المرحلة 1 تركز على البروتوكول الصحيح، بينما تركز المرحلة 2 والمرحلة 3 على التنفيذ الصحيح.
المرحلة الأمنية 1: البروتوكول الصحيح
1، تحقق رسمي من موثوقية PIOP؛
2، يتم التحقق من شكل الإثبات الملزم لـ PCS في بعض النماذج الرمزية أو النماذج الأيديالية.
3، إذا تم استخدام Fiat-Shamir، فإن إثبات الشهادة الموجز الذي تم الحصول عليه من خلال PIOP وPCS آمن في نموذج النبوءة العشوائية بموجب إثبات رسمي (مع تعزيزه حسب الحاجة باستخدام فرضيات تشفير أخرى)؛
4، يعادل نظام القيود المستخدم في PIOP تحقق صحة شكل الدليل الدلالي لـ VM؛
5، وصل جميع هذه الأجزاء المذكورة أعلاه بشكل كامل كـ "لصق" واحد موحد، وتحقق صحة الأدلة الحماية (SNARK) الموجودة لتشغيل أي برنامج محدد من خلال بايتات التعليمات الافتراضية للآلة الظاهرية. إذا كان البروتوكول ينوي تحقيق الخصوصية التامة، فيجب أيضًا التحقق من صحة هذه الخاصية بشكل رسمي لضمان عدم تسرب المعلومات الحساسة حول الشهود.
تحذير الارتداد: إذا كان zkVM يستخدم الارتداد، يجب التحقق من كل PIOP وبرنامج التعهد ونظام القيود المتعلق بأي مكان في هذا الارتداد قبل أن يعتبر هذا المرحلة مكتملة.
المرحلة الثانية: تنفيذ محقق صحيح
تأكد من تطابق التنفيذ الفعلي لتحقق zkVM Validator (باستخدام Rust و Solidity وما إلى ذلك) مع بروتوكول التحقق من المرحلة 1. يمكن تحقيق ذلك لضمان أن البروتوكول المنفذ هو منطقي (وليس مجرد تصميم على الورق، أو مواصفة غير فعالة مكتوبة بواسطة Lean وما إلى ذلك).
السببان الرئيسيان للتركيز في المرحلة 2 على تنفيذ القارن (وليس البرهان) هما جانبان. أولاً، فإن استخدام القارن بشكل صحيح يكفي لضمان الموثوقية (أي ضمان أن القارن لا يمكنه الاعتماد على أي بيانات زائفة كونها حقيقية في الواقع). وثانياً، تكون تنفيذات قارن zkVM أبسط بدرجة واحدة من تنفيذات prover.
المرحلة الثالثة من الأمان: تنفيذ البرهان الصحيح
تم تنفيذ برنامج تجزئة zkVM بشكل صحيح لإنشاء برهان لنظام برهان مرحلة 1 ومرحلة 2، أي الحصول على التحقق الرسمي. هذا يضمن النزاهة، أي أن أي نظام يستخدم zkVM لن يتعطل بسبب بيانات غير قابلة للإثبات. إذا كان برنامج البرهان يهدف إلى تنفيذ المعرفة الصفرية، فإنه يجب التحقق الرسمي من هذا الخاصية.
الجدول الزمني المتوقع
· المرحلة 1: النتقلات: يمكننا التوقع بأن نحقق تقدما تدريجيا العام المقبل (مثل ZKLib). لكن على الأقل لن يكون هناك zkVM قادر على تلبية متطلبات المرحلة 1 تماما خلال عامين على الأقل؛
· المراحل 2 و 3: يمكن تقدم هذه المراحل مع بعض جوانب المرحلة 1 في نفس الوقت. على سبيل المثال، أثبتت بعض الفرق أن تنفيذ جهاز التحقق Plonk يتطابق مع بروتوكول الورقة (على الرغم من أن البروتوكول في الورقة قد لم يتم التحقق منه بالكامل). على الرغم من ذلك، أتوقع أن لن يصل أي zkVM إلى المرحلة 3 في أقل من أربع سنوات - وربما أكثر.
النقاط المهمة: Fiat-Shamir الأمان والبايت كود الموثق
أحد العوامل المعقدة الرئيسية هو وجود مشكلات بحث غير محلولة حول أمان تحويل Fiat-Shamir. يُعتبر Fiat-Shamir وآلة النبوءة العشوائية جزءًا من أمانها لا يمكن اختراقها في جميع المراحل الثلاث، ولكن في الواقع قد تحتوي هذه النماذج بأكملها على ثغرات. يعود ذلك إلى تفاوت كبير بين آلة النبوءة العشوائية المثالية ووظيفة التجزئة التي تُستخدم فعليًا. في أسوأ الحالات، قد يتم اكتشاف نظام الذي وصل إلى المرحلة 2 بسبب مشكلة Fiat-Shamir كونه غير آمن تمامًا لاحقًا، مما أثار مخاوف جدية وبحث مستمر. قد نحتاج إلى تعديل التحويل نفسه لتعزيز الحماية ضد مثل هذه الثغرات.
نظام بدون عودية أكثر استقرارًا نظريًا، لأن بعض الدوائر التي يتعامل معها بعض الهجمات المعروفة تشبه الدوائر المستخدمة في البراهين العودية.
شيء آخر يستحق الاهتمام هو أنه إذا كانت البايت كود نفسه به عيوب، فإن القيمة محدودة حتى إذا تم تشغيل برنامج الكمبيوتر بشكل صحيح (عن طريق تحديد البايت كود). ولذلك، يعتمد إمكانية استخدام zkVM إلى حد كبير على الطريقة التي يتم فيها إنشاء البايت كود للتحقق الشكلي - وهذا تحدي كبير يتجاوز نطاق هذه المقالة.
حول أمان العصر بعد الكم
على الأقل خلال الخمس سنوات القادمة (وقد تستمر لفترة أطول)، لن يشكل الحاسوب الكمّي تهديداً كبيراً، بينما الثغرات هي نوع من مخاطر البقاء. لذلك، يجب أن يكون التركيز الرئيسي الآن على تلبية مراحل الأمان والأداء المدرجة في هذا المقال. إذا كنا قادرين على استخدام SNARK الغير كمّي لتلبية هذه المتطلبات الأمنية بشكل أسرع، فيجب علينا أن نفعل ذلك، حتى يتم اللحاق بـ SNARK الكمّي لاحقًا، أو حتى يصبح الناس قلقين بشكل كبير من ظهور أجهزة الحاسوب الكمّي المتعلقة بالتشفير.
حالة أداء zkVM
حاليًا، يبلغ معامل التكلفة الذي يولده جهاز البرهان zkVM ما يقارب 1000000 مرة تكلفة التنفيذ الأصلية. إذا احتاج البرنامج إلى X دورة للتشغيل، فإن تكلفة تنفيذ البرهان الصحيح تقدر بحوالي X مضروبًا في 1000000 دورة للمعالج. كانت هذه هي الحالة قبل عام، وتظل اليوم كذلك.
السرد الشائع غالبًا ما يصف هذه التكاليف بطريقة تبدو قابلة للقبول من الناحية السمعية. على سبيل المثال:
· "تكلفة إنتاج البراهين على شبكة الإيثيريوم الرئيسية أقل من مليون دولار سنويًا."
يمكننا تقريبًا استخدام مجموعة من عشرات وحدات GPU لإنشاء بلوكات إثيريوم الدليلية في الوقت الحقيقي.
·"zkVM الجديد لدينا أسرع بمقدار 1000 مرة من سابقه."
على الرغم من أن هذه الادعاءات دقيقة من الناحية التقنية، إلا أنها قد تؤدي إلى الإرباك إذا لم يكن هناك خلفية مناسبة. على سبيل المثال:
· تسريع zkVM الجديد بمقدار 1000 مرة، لكن السرعة المطلقة لا تزال بطيئة للغاية. هذا يشير بشكل أكبر إلى مدى سوء الأمور بدلاً من مدى جيدها.
· تم اقتراح زيادة حجم الحسابات التي تتم معالجتها على شبكة Ethereum الرئيسية بمقدار 10 أضعاف، مما سيجعل أداء zkVM الحالي أبطأ.
ما يُقال عن 'إثبات تقريبي للكتل في إيثريوم بالزمن الفعلي' لا يزال أبطأ بكثير مما يتطلبه العديد من تطبيقات سلسلة الكتل (على سبيل المثال، يعتبر زمن الكتل في Optimism 2 ثانية، أسرع بكثير من زمن كتلة إيثريوم البالغ 12 ثانية).
· يمكن أن يكون تشغيل عدة بطاقات GPU دون أخطاء غير قابل للقبول لضمان النشاط.
· إن إنفاق أقل من مليون دولار سنويًا لإثبات أن جميع الأنشطة على شبكة الإيثيريوم الرئيسية تعكس حقيقة أنه يتعين فقط إنفاق حوالي 25 دولارًا سنويًا على تشغيل الحواسيب للقيام بالحسابات.
بالنسبة لتطبيقات خارج سلسلة الكتل، فإن تكلفة ذلك مرتفعة بشكل واضح. لا يمكن لأي توازن أو هندسة معاكسة تكلفة هائلة مثل هذه. يجب أن نعتبر سرعة zkVM بنسبة للتنفيذ المحلي لا تقل عن 100،000 مرة كمعيار أساسي - حتى لو كان هذا هو الخطوة الأولى فقط. قد يكون الاعتماد الرئيسي الحقيقي يتطلب تكلفة تقترب من 10،000 مرة أو أقل.
كيفية قياس الأداء
أداء SNARK يتألف من ثلاثة مكونات رئيسية:
· كفاءة النظام الأساسي للإثبات الداخلي.
تحسين محدد للتطبيق (مثل الترميز المسبق).
· الهندسة وتسريع الأجهزة (مثل وحدة معالجة الرسومات GPU أو FPGA أو وحدة المعالجة المتعددة النواة CPU).
على الرغم من أن كل من العاملين الأخيرين حيويان لنشر العملية الفعلية، إلا أنهما عادة ما يكونان مناسبين لأي نظام إثبات، وبالتالي قد لا تعكس بالضرورة التكاليف الأساسية. على سبيل المثال، يمكن بسهولة تحقيق تسارع بنسبة 50 مرة من خلال إضافة تسريع GPU والتعاريف المسبقة في zkEVM، وهذا يجعلها أسرع بكثير من الطريقة الخالية من التعاريف المسبقة والمعتمدة على وحدة المعالجة المركزية فقط - بما يكفي لجعل النظام الذي يعتمد أساسًا على كفاءة منخفضة يبدو أفضل من النظام الذي لم يتم تنقيته بنفس الطريقة.
لذلك ، يركز ما يلي على أداء SNARKs بدون أجهزة متخصصة وتجميع مسبق. هذا على النقيض من طرق القياس الحالية ، والتي عادة ما تلخص العوامل الثلاثة في "رقم رئيسي" واحد. هذا يعادل الحكم على قيمة الماس بناء على المدة التي تم صقلها بدلا من نقاءها الجوهري. هدفنا هو القضاء على النفقات العامة المتأصلة في نظام الإثبات العالمي - لمساعدة المجتمع على التخلص من الارتباك والتركيز على التقدم الحقيقي في إثبات تصميم النظام.
مرحلة الأداء
هناك 5 معلماً في تحقيق الأداء. أولاً، يجب تقليل تكلفة البرهان على وحدة المعالجة المركزية بعدة مرات. فقط عندها ينبغي التركيز على تقليلها بشكل أكبر من خلال الأجهزة. يجب أيضاً زيادة معدل استخدام الذاكرة.
في جميع المراحل التالية، لا يلزم المطورون تخصيص الكود وفقًا لإعدادات zkVM لتحقيق الأداء المطلوب. تجربة المطورين هي الفائدة الرئيسية لـ zkVM. التضحية بتجربة المطورين من أجل تحقيق معايير الأداء تتنافى مع معنى zkVM نفسها.
تركز هذه المؤشرات على تكلفة الحامل. ومع ذلك، إذا سمح بتكلفة الحامل غير المحدودة (أي لا يوجد حد أقصى لحجم البرهان أو وقت التحقق)، يمكن بسهولة تحقيق أي مؤشر لحامل. لذلك، يجب تحديد حد أقصى لحجم البرهان ووقت التحقق لتلبية النظام في المرحلة المشار إليها.
الأداء المطلوب
مرحلة 1: 'تكلفة التحقق العقلانية وغير العادية' :
· الحجم الإثبات: يجب أن يكون حجم الإثبات أصغر من حجم الشهادة.
· وقت التحقق: يجب ألا يتجاوز سرعة إثبات التحقق سرعة تشغيل الجهاز المضيف (أي تنفيذ الحساب دون إثبات صحة).
هذه هي الحد الأدنى من متطلبات البساطة. تضمن أن حجم الإثبات ووقت التحقق لن يكونا أسوأ من إرسال الشاهد إلى المحققين والسماح للمحققين بالتحقق مباشرة من صحتها.
المرحلة 2 وما باعدها:
· الحد الأقصى لحجم البرهان: 256 كيلوبايت.
· أقصى وقت التحقق: 16 ميلي ثانية.
تم تخصيص هذه القيم الحدية عن عمد بزيادة ، لتكيف مع تكنولوجيا الإثبات السريعة الجديدة التي قد تجلب تكاليف تحقق أعلى. في الوقت نفسه ، تستبعد الإثبات المكلف بشكل كبير ، لدرجة أن نادرًا ما تكون العمليات على استعداد لتضمينها في سلسلة الكتل.
المرحلة 1 من السرعة
يجب أن يكون إثبات الخط الواحد أبطأ بكثير من التنفيذ المحلي بحد أقصى مائة ألف مرة، ويجب أن يتم قياس ذلك في سلسلة من التطبيقات (ليس فقط إثبات كتل إيثريوم) دون الاعتماد على التجهيز المسبق.
على وجه التحديد ، تخيل عملية RISC-V تعمل بحوالي 3 مليارات دورة في الثانية على جهاز كمبيوتر محمول حديث. يعني تحقيق المرحلة 1 أنه يمكنك إثبات حوالي 30،000 دورة RISC-V في الثانية (أحادية الخيط) على نفس الكمبيوتر المحمول. ومع ذلك، يجب أن تكون تكلفة التحقق "معقولة وغير تافهة" كما ذكر سابقا.
المرحلة 2 السرعة
يجب أن يكون إثبات الخط الواحد بطيئًا بحد أقصى عشرة آلاف مرة من التنفيذ المحلي.
أو بسبب عرقلة بعض أساليب SNARK الواعدة (خاصة تلك القائمة على الحقول الثنائية) بسبب وحدات المعالجة المركزية ووحدات معالجة الرسومات الحالية، يمكنك النظر في استخدام FPGA (أو حتى ASIC) بدلاً من ذلك.
FPGA يمكن أن تحاكي عدد النوى RISC-V بسرعة الجهاز الأصلية؛
تحاكي وتثبت (تقريبا) العدد اللازم من FPGA لتنفيذ RISC-V بشكل (ما يقرب من) فوري.
إذا كان العامل الأخير ضعف الأول بحد أقصى 10،000 مرة، فستكون مؤهلاً للانتقال إلى المرحلة الثانية. على وحدة المعالجة المركزية القياسية، يجب أن يكون حجم البرهان كحد أقصى 256 كيلوبايت، ويجب أن يكون وقت المحقق كحد أقصى 16 ميلليثانية.
مرحلة السرعة 3
بالإضافة إلى الوصول إلى المرحلة 2 بسرعة، يمكن أيضًا استخدام التركيب التلقائي والتحقق من الشكل لتحقيق تكاليف الإثبات أقل من 1000 مرة (مناسب لتطبيقات واسعة النطاق). في الجوهر، يمكن تخصيص مجموعة التعليمات الديناميكية لكل برنامج لتسريع عملية الإثبات، ولكن يجب أن يتم ذلك بطريقة سهلة الاستخدام والتحقق من الشكل.
المرحلة 1 من الذاكرة
تم تحقيق سرعة المرحلة 1 عندما كانت الذاكرة المطلوبة للبروفر أقل من 2 غيغابايت (مع تحقيق الصفر معرفة).
هذا مهم للعديد من الأجهزة المحمولة أو المتصفحات، وبالتالي فإنه يفتح العديد من حالات استخدام zkVM للعملاء. إن الإثبات العميل أمر مهم لأن هواتفنا هي وسيلتنا المستمرة للتواصل مع العالم الحقيقي: إنها تتتبع موقعنا وبطاقات الاعتماد وما إلى ذلك. إذا كان إنشاء الإثبات يتطلب أكثر من 1-2 جيجابايت من الذاكرة، فهذا كثير جدًا بالنسبة لمعظم أجهزة الجوال في الوقت الحالي. هناك حاجة لتوضيح نقطتين:
· تطبق حدود مساحة 2 جيجابايت على البيانات الكبيرة (التي تتطلب ملايين من دورات وحدة المعالجة المركزية لتشغيلها محليًا). نظام إثبات حدود المساحة المطبق فقط على البيانات الصغيرة يفتقر إلى قدرة تطبيق شاملة.
إذا كان جهاز الإثبات بطيئًا للغاية ، فمن السهل جدًا الاحتفاظ بذاكرة جهاز الإثبات داخل 2 جيجابايت. لذلك ، من أجل جعل مرحلة الذاكرة 1 أقل بساطة ، طلبت تحقيق سرعة المرحلة 1 ضمن حدود 2 جيجابايت.
المرحلة الثانية من الذاكرة
سُرعة المرحلة 1 تم تحقيقها عندما كان استخدام الذاكرة أقل من 200 ميجابايت (أفضل بمقدار 10 مرات من مرحلة 1 من الذاكرة).
لماذا تقلل إلى أقل من 2 جيجابايت؟ فكر في مثال خارج عن سياق البلوكتشين: في كل مرة تقوم فيها بزيارة موقع عبر HTTPS، ستقوم بتنزيل شهادة للتحقق من الهوية والتشفير. بدلاً من ذلك، يمكن للموقع إرسال براهين zk التي تحتوي على هذه الشهادات. يمكن أن يصدر المواقع الكبيرة ملايين من مثل هذه البراهين في الثانية. إذا كانت كل برهان يتطلب 2 جيجابايت من الذاكرة للإنشاء، فإن إجمالي الذاكرة المطلوبة سيكون بيتابايتي. تخفيض استخدام الذاكرة بشكل أكبر أمر حيوي للنشر خارج سياق البلوكتشين.
الترجمة: هل الأخيرة ما زالت عصا؟
في تصميم zkVM، يشير البرنامج المسبق إلى SNARK المخصص المصمم خصيصًا لوظيفة معينة، مثل تجزئة Keccak/SHA للتوقيع الرقمي أو عمليات مجموعة المنحنيات البيضاوية. في Ethereum (حيث ينطوي معظم العمل الشاق على تحقق تجزئة Merkle والتحقق من التوقيع)، يمكن لبعض البرامج المسبقة التي تم إنشاؤها يدويًا تقليل تكلفة المثبت. ومع ذلك، الاعتماد عليها كعكاز لا يمكن أن يجعل SNARK يحقق الأهداف المطلوبة منها. الأسباب على النحو التالي:
· بالنسبة لمعظم التطبيقات (داخل وخارج سلسلة الكتل) ، فهي لا تزال بطيئة جدًا: حتى مع استخدام التجهيز المسبق للتجزئة والتوقيع ، يظل zkVM الحالي بطيئًا للغاية (سواء داخل بيئة سلسلة الكتل أو خارجها) بسبب كفاءة النظام الأساسي المنخفضة للبرهان.
**· خطأ أمان: ** يكاد البرمجة المسبقة اليدوية غير المعتمدة بشكل رسمي تكاد تكون مليئة بالأخطاء، مما قد يؤدي إلى فشل أمان كارثي.
**· تجربة تطوير البرمجيات غير مرضية: ** في معظم zkVMs الحالية، إضافة تجهيز جديد يعني كتابة نظام مقيد يدوي لكل وظيفة - في الأساس، العودة إلى سير العمل بنمط الستينيات. حتى عند استخدام التجهيز الموجود، يجب على مطوري البرامج إعادة بناء الشيفرة لاستدعاء كل تجهيز. يجب أن نحسن من التوازن بين الأمان وتجربة تطوير البرمجيات، بدلاً من التضحية بكلاهما من أجل تحقيق أداء تكميلي. هذا فقط يثبت أن الأداء لم يصل إلى المستوى المطلوب.
· تكاليف I/O دون ذاكرة وRAM: على الرغم من أن البرمجة المسبقة يمكن أن تعزز أداء المهام العملية الثقيلة التشفيرية، إلا أنها قد لا توفر تسريعًا ذا معنى لمجموعة أوسع من أعباء العمل المتنوعة، لأنها تنتج تكاليف كبيرة أثناء تبادل الإدخال/الإخراج، ولا يمكنها استخدام RAM. حتى في بيئة سلسلة الكتل، ستواجه تحديات جديدة مثل استخدام وظائف تجزئة هاش وبرامج توقيع مختلفة كلما تجاوزت شبكة مثل Ethereum المستوى الأول الفردي (على سبيل المثال، إذا كنت ترغب في بناء سلسلة من الجسور بين الشبكات). إجراء البرمجة المسبقة مرارًا وتكرارًا لنفس المشكلة لا يمكن أن يوسع النطاق ويشكل مخاطر أمنية هائلة.
لهذه الأسباب جميعها، يجب أن يكون أولويتنا الرئيسية هي تحسين كفاءة zkVM الأساسية. تقنية أفضل لـ zkVM ستنتج أيضًا أفضل برمجيات مُعدة مُسبقًا. أنا حقًا أعتقد أن البرمجيات المُعدة مُسبقًا ستظل مهمة في المدى البعيد، ولكن الشرط الأساسي هو أن يتم توليفها تلقائيًا والتحقق من صحتها رسميًا. بهذه الطريقة، يمكن الاحتفاظ بميزة تجربة مُطوّري zkVM، وفي الوقت نفسه تجنب المخاطر الأمنية الكارثية. يتم تعكس هذه الرؤية في مرحلة السرعة 3.
الجدول الزمني المتوقع
أتوقع أن تحقق zkVM القليلة في وقت لاحق من هذا العام مرحلة السرعة 1 ومرحلة الذاكرة 1. أعتقد أننا سنحقق أيضًا مرحلة السرعة 2 في السنوات القادمة ، لكن ليس من الواضح حاليًا ما إذا كان بإمكاننا تحقيق هذا الهدف بدون بعض الأفكار الجديدة التي لم تظهر بعد. أتوقع أن تستغرق المراحل المتبقية (السرعة 3 والذاكرة 2) بضع سنوات لتحقيقها.
تلخيص
على الرغم من أنني حددت بشكل منفصل أمان zkVM ومراحل الأداء في هذه المقالة، إلا أن هذه الجوانب من zkVM ليست مستقلة تمامًا. مع اكتشاف المزيد من الثغرات في zkVM، من المتوقع أن تكون بعض الثغرات قابلة للإصلاح فقط عندما ينخفض الأداء بشكل كبير. يجب تأجيل الأداء حتى يتم الوصول إلى مرحلة الأمان 2 في zkVM.
يعتبر zkVM الأمل في تعميم البراهين الصفرية المعرفة، لكنها لا تزال في مراحلها الأولى - مليئة بالتحديات الأمنية والتكاليف الأدائية الضخمة. يجعل الترويج والتسويق الصعب تقييم التقدم الحقيقي. من خلال توضيح العلامات البارزة الواضحة من الناحية الأمنية والأدائية، نأمل في توفير خارطة طريق تقضي على الإرباك. سنحقق الأهداف، ولكن هذا يتطلب وقتًا وجهدًا مستمرًا.
رابط المقال الأصلي
：