a16z: رویکرد مرحله‌ای برای پیاده‌سازی امن و کارآمد zkVM (مطلبی ضروری برای توسعه‌دهندگان)

عنوان اصلی: مسیر zkVMهای امن و کارآمد: چگونه پیشرفت را دنبال کنیم

نویسنده اصلی: a16z crypto

ترجمه اصلی: Golem، Odaily Planet Daily Golem

zkVM (ماشین مجازی دانش صفر) وعده می‌دهد که «SNARKها را فراگیر کند» و به هر کسی (حتی بدون تخصص ویژه در SNARK) امکان دهد ثابت کند برنامه‌ای را با ورودی مشخص (یا شاهد) به‌درستی اجرا کرده است. مزیت اصلی آن‌ها تجربه توسعه‌دهندگی است، اما در حال حاضر با چالش‌های چشمگیر امنیتی و عملکردی روبه‌رو هستند. برای تحقق چشم‌انداز zkVM، طراحان باید بر این چالش‌ها غلبه کنند. در این مقاله، مراحل احتمالی توسعه zkVM را ترسیم می‌کنم؛ فرایندی که تکمیل آن چندین سال طول خواهد کشید.

چالش‌ها

از نظر امنیت، zkVM یک پروژه نرم‌افزاری بسیار پیچیده است که هنوز آسیب‌پذیری‌های فراوانی دارد. از نظر عملکرد، سرعت اثبات درستی اجرای برنامه می‌تواند چندین مرتبه بزرگی کمتر از اجرای بومی باشد و در نتیجه، استقرار آن را در دنیای واقعی برای بیشتر برنامه‌ها غیرعملی کند.

با وجود این چالش‌های دنیای واقعی، بیشتر شرکت‌های صنعت بلاک‌چین zkVM را آماده استقرار فوری معرفی می‌کنند. در واقع، برخی پروژه‌ها برای تولید اثبات فعالیت‌های آن‌چین، هزینه‌های محاسباتی چشمگیری پرداخته‌اند. با این حال، از آنجا که zkVM هنوز بی‌نقص نیست، این کار صرفاً روشی پرهزینه برای وانمود کردن به محافظت سیستم با SNARK است؛ در حالی که در واقعیت، سیستم یا با مجوز محافظت می‌شود یا، بدتر از آن، در برابر حملات آسیب‌پذیر است.

هنوز چند سال با دستیابی به zkVM امن و پربازده فاصله داریم. این مقاله مجموعه‌ای از اهداف مشخص و مرحله‌ای را برای پیگیری پیشرفت zkVM پیشنهاد می‌کند؛ اهدافی که می‌توانند هیاهو را کنار بزنند و به جامعه کمک کنند بر پیشرفت واقعی تمرکز کند.

مرحله امنیت

zkVMهای مبتنی بر SNARK معمولاً دو مؤلفه اصلی دارند:

· اثبات تعاملی اوراکل چندجمله‌ای (PIOP): برای اثبات گزاره‌هایی درباره چندجمله‌ای‌ها (یا قیود به‌دست‌آمده از آن‌ها) در چارچوب اثبات تعاملی استفاده می‌شود.

· طرح تعهد چندجمله‌ای (PCS): تضمین می‌کند که اثبات‌گر نتواند درباره ارزیابی چندجمله‌ای‌ها دروغ بگوید، بی‌آنکه این کار آشکار شود.

zkVM اساساً اجرای کارآمد را به یک سیستم قید تبدیل می‌کند؛ به‌طور کلی، یعنی ماشین مجازی را ملزم می‌کند از ثبات‌ها و حافظه به‌درستی استفاده کند. سپس SNARKها را به کار می‌گیرد تا ثابت کند این قیود برقرارند.

اطمینان از بی‌خطا بودن سیستم‌های پیچیده‌ای مانند zkVM از طریق راستی‌آزمایی صوری انجام می‌شود. در ادامه، مراحل امنیتی را بررسی می‌کنیم. مرحله ۱ بر پروتکل صحیح تمرکز دارد، در حالی که مراحل ۲ و ۳ بر پیاده‌سازی صحیح متمرکز هستند.

مرحله امنیتی ۱: پروتکل صحیح

۱. اثبات راستی‌آزمایی صوریِ قابل‌اعتماد بودن PIOP؛

۲. اثبات راستی‌آزمایی صوریِ کارآمد بودن PCS تحت فرض‌های رمزنگاری مشخص یا مدل‌های ایده‌آل؛

۳. در صورت استفاده از Fiat-Shamir، اثبات راستی‌آزمایی صوریِ امن بودن استدلال فشرده‌ای که از ترکیب PIOP و PCS به دست می‌آید، در مدل اوراکل تصادفی (و در صورت لزوم، با تقویت فرض‌های رمزنگاری دیگر)؛

۴. اثبات راستی‌آزمایی صوریِ معادل بودن سیستم قیدی که PIOP به کار می‌برد با معناشناسی VM؛

۵. گرد هم آوردن همه اجزای بالا در یک اثبات SNARK امن و یکپارچه که به‌صورت صوری راستی‌آزمایی شده باشد و اجرای هر برنامه‌ای را که بایت‌کد VM مشخص می‌کند، اثبات کند. اگر هدف پروتکل دستیابی به ویژگی‌های دانش صفر باشد، این ویژگی نیز باید به‌صورت صوری راستی‌آزمایی شود تا از افشای اطلاعات حساس درباره شاهدها جلوگیری شود.

هشدار درباره بازگشت‌پذیری: اگر zkVM از بازگشت‌پذیری استفاده می‌کند، برای کامل شدن این مرحله باید تمام PIOPها، طرح‌های تعهد و سیستم‌های قیدی که در هر بخش از فرایند بازگشت‌پذیری دخیل هستند، راستی‌آزمایی شوند.

مرحله امنیتی ۲: پیاده‌سازی صحیح اعتبارسنج

پیاده‌سازی اعتبارسنج zkVM (با استفاده از Rust، Solidity و غیره) باید به‌صورت صوری راستی‌آزمایی شود تا مطابقت آن با پروتکلی که در مرحله ۱ اعتبارسنجی شده است، تأیید شود. دستیابی به این هدف تضمین می‌کند که پروتکل پیاده‌سازی‌شده معتبر است (و صرفاً یک طرح روی کاغذ یا مشخصاتی ناکارآمد، برای مثال نوشته‌شده با Lean، نیست).

دو دلیل وجود دارد که چرا مرحله ۲ فقط به پیاده‌سازی اعتبارسنج مربوط است، نه اثبات‌گر. اول، اطمینان از استفاده صحیح از اعتبارسنج برای تضمین قابلیت اعتماد کافی است (یعنی تضمین می‌کند اعتبارسنج هیچ گزاره نادرستی را درست تلقی نکند). دوم، پیاده‌سازی اعتبارسنج zkVM بیش از یک مرتبه بزرگی ساده‌تر از پیاده‌سازی اثبات‌گر است.

مرحله امنیتی ۳: پیاده‌سازی صحیح اثبات‌گر

پیاده‌سازی واقعی اثبات‌گر zkVM باید سیستم اثبات مرحله ۱ و ۲ را به‌درستی تولید کند؛ یعنی به راستی‌آزمایی صوری برسد. این کار کامل بودن را تضمین می‌کند؛ یعنی هیچ سیستمی که از zkVM استفاده می‌کند، با گزاره‌هایی که قابل اثبات نیستند «گیر» نخواهد کرد. اگر هدف اثبات‌گر دستیابی به دانش صفر باشد، این ویژگی باید به‌صورت صوری راستی‌آزمایی شود.

زمان‌بندی مورد انتظار

· پیشرفت مرحله ۱: می‌توانیم انتظار پیشرفت تدریجی را در سال آینده داشته باشیم (برای مثال، ZKLib). با این حال، دست‌کم دو سال طول می‌کشد تا هر zkVM بتواند الزامات مرحله ۱ را به‌طور کامل برآورده کند؛

· مرحله ۲ و مرحله ۳: این مراحل می‌توانند هم‌زمان با برخی جنبه‌های مرحله ۱ پیش بروند. برای مثال، بعضی تیم‌ها پیش‌تر نشان داده‌اند که پیاده‌سازی اثبات‌گر Plonk با پروتکل مقاله مطابقت دارد (هرچند ممکن است خود پروتکل ارائه‌شده در مقاله هنوز به‌طور کامل اعتبارسنجی نشده باشد). با این حال، انتظار دارم هیچ zkVMای در کمتر از چهار سال به مرحله ۳ نرسد و ممکن است این کار حتی بیشتر طول بکشد.

نکات کلیدی: امنیت Fiat-Shamir و بایت‌کد راستی‌آزمایی‌شده

یکی از عوامل پیچیده‌کننده اصلی، مسائل پژوهشی حل‌نشده درباره امنیت تبدیل Fiat-Shamir است. هر سه مرحله، Fiat-Shamir و اوراکل تصادفی را بخشی از امنیت نفوذناپذیر خود در نظر می‌گیرند، اما در واقع ممکن است کل این الگو آسیب‌پذیر باشد. دلیل آن ایده‌آل‌سازی بیش از حد اوراکل تصادفی و تفاوت آن با توابع هش عملی است. در بدترین حالت، ممکن است بعداً مشخص شود سیستمی که به مرحله ۲ رسیده، به‌دلیل مشکلات Fiat-Shamir کاملاً ناامن است. این موضوع نگرانی‌های جدی و پژوهش‌های مستمری را در پی داشته است. شاید لازم باشد خود تبدیل را تغییر دهیم تا این آسیب‌پذیری‌ها را بهتر کاهش دهیم.

سیستم‌های غیر بازگشتی از نظر نظری مقاوم‌ترند، زیرا برخی حملات شناخته‌شده به مدارهایی مربوط می‌شوند که مشابه مدارهای مورد استفاده در اثبات‌های بازگشتی هستند.

نکته دیگری که باید در نظر داشت این است که اگر خود بایت‌کد ایراد داشته باشد، حتی اگر اثبات اجرای صحیح یک برنامه رایانه‌ای (که از طریق بایت‌کد مشخص شده) با موفقیت انجام شود، ارزش آن محدود خواهد بود. بنابراین، کاربردی بودن zkVM تا حد زیادی به روش تولید بایت‌کدِ راستی‌آزمایی‌شده به‌صورت صوری بستگی دارد؛ چالشی بزرگ که فراتر از محدوده این مقاله است.

درباره امنیت پساکوانتومی

دست‌کم در پنج سال آینده (و شاید بیشتر)، رایانش کوانتومی تهدیدی جدی نخواهد بود، در حالی که آسیب‌پذیری‌ها خطری برای بقا محسوب می‌شوند. بنابراین، تمرکز اصلی در حال حاضر باید بر برآورده کردن مراحل امنیت و عملکردی باشد که در این مقاله مطرح شده‌اند. اگر بتوانیم این الزامات امنیتی را با SNARKهای غیرمقاوم در برابر رایانش کوانتومی سریع‌تر محقق کنیم، باید همین کار را انجام دهیم تا زمانی که SNARKهای پساکوانتومی به آن‌ها برسند یا نگرانی‌های جدی درباره رایانش کوانتومیِ مرتبط با رمزنگاری مطرح شود.

وضعیت عملکرد zkVM

در حال حاضر، ضریب سربار اثبات‌گر zkVM نزدیک به ۱٬۰۰۰٬۰۰۰ برابر هزینه اجرای بومی است. اگر اجرای برنامه‌ای X چرخه طول بکشد، هزینه اثبات اجرای صحیح آن تقریباً برابر با X ضرب‌در ۱٬۰۰۰٬۰۰۰ چرخه CPU است. وضعیت یک سال پیش همین بود و امروز هم تغییری نکرده است.

روایت‌های رایج معمولاً این سربار را به شکلی توصیف می‌کنند که پذیرفتنی به نظر می‌رسد. برای مثال:

· «هزینه تولید اثبات برای تمام تراکنش‌های شبکه اصلی اتریوم در طول یک سال، کمتر از یک میلیون دلار است.»

· «تقریباً می‌توانیم با استفاده از خوشه‌ای شامل چند ده GPU، اثبات‌های بلوک اتریوم را در لحظه تولید کنیم.»

· «جدیدترین zkVM ما ۱٬۰۰۰ برابر سریع‌تر از نسخه قبلی است.»

این اظهارات از نظر فنی درست‌اند، اما بدون زمینه مناسب می‌توانند گمراه‌کننده باشند. برای مثال:

· این نسخه ۱٬۰۰۰ برابر سریع‌تر از نسخه قدیمی zkVM است، اما سرعت مطلق آن هنوز بسیار پایین است. این موضوع بیشتر نشان می‌دهد شرایط چقدر بد بوده‌اند، نه اینکه چقدر خوب شده‌اند.

· پیشنهادهایی برای افزایش بار محاسباتی شبکه اصلی اتریوم به میزان ۱۰ برابر مطرح شده است. این کار عملکرد فعلی zkVM را کندتر می‌کند.

· چیزی که از آن با عنوان «اثبات تقریباً آنی بلوک‌های اتریوم» یاد می‌شود، هنوز بسیار کندتر از نیاز بسیاری از برنامه‌های بلاک‌چینی است (برای نمونه، زمان بلوک Optmism دو ثانیه است که بسیار سریع‌تر از زمان بلوک ۱۲ ثانیه‌ای اتریوم است).

· «خوشه‌ای شامل چند ده GPU که همیشه بدون نقص کار می‌کند» نمی‌تواند تضمین زنده‌بودن قابل‌قبولی ارائه دهد.

· هزینه کمتر از یک میلیون دلار در سال برای اثبات تمام فعالیت‌های شبکه اصلی اتریوم، نشان می‌دهد که یک فول‌نود اتریوم برای انجام محاسبات فقط باید حدود ⁦$25⁩ در سال هزینه کند.

برای برنامه‌های خارج از بلاک‌چین، چنین سرباری به‌وضوح بیش از حد بالاست. هیچ میزان موازی‌سازی یا مهندسی نمی‌تواند این سربار عظیم را جبران کند. باید به‌عنوان معیاری پایه در نظر بگیریم که کندی zkVM در مقایسه با اجرای بومی از ۱۰۰٬۰۰۰ برابر بیشتر نشود؛ حتی اگر این فقط گام نخست باشد. برای پذیرش واقعاً فراگیر، ممکن است لازم باشد سربار به حدود ۱۰٬۰۰۰ برابر یا کمتر برسد.

اندازه‌گیری عملکرد

عملکرد SNARK سه مؤلفه اصلی دارد:

· کارایی ذاتی سیستم اثبات زیربنایی.

· بهینه‌سازی‌های اختصاصی برنامه (برای مثال، پیش‌کامپایل).

· مهندسی و شتاب‌دهی سخت‌افزاری (برای مثال، GPU، FPGA یا CPU چند‌هسته‌ای).

دو مورد آخر برای استقرار در دنیای واقعی اهمیت زیادی دارند، اما معمولاً برای هر سیستم اثباتی کاربرد دارند و بنابراین لزوماً نشان‌دهنده سربار زیربنایی نیستند. برای مثال، افزودن شتاب‌دهی GPU و پیش‌کامپایل به zkEVM می‌تواند به‌سادگی سرعت را ۵۰ برابر کند؛ بسیار سریع‌تر از رویکردی که صرفاً بر CPU و بدون پیش‌کامپایل متکی است. این میزان برای برتر به نظر رسیدن سیستمی که ذاتاً کارایی کمتری دارد نسبت به سیستمی که به همین شکل بهینه نشده، کافی است.

بنابراین، تمرکز ادامه بحث بر عملکرد SNARK بدون سخت‌افزار تخصصی و پیش‌کامپایل است. این با روش ارزیابی فعلی متفاوت است؛ روشی که اغلب هر سه عامل را در یک «عدد تیترشده» ادغام می‌کند. این کار مانند آن است که ارزش یک الماس را بر اساس مدت زمان صیقل‌دادن آن بسنجیم، نه شفافیت ذاتی‌اش. هدف ما حذف سربار ذاتی یک سیستم اثبات عمومی است تا به جامعه کمک کنیم متغیرهای مخدوش‌کننده را کنار بگذارد و بر پیشرفت واقعی در طراحی سیستم اثبات تمرکز کند.

مراحل عملکرد

در ادامه، پنج نقطه عطف برای دستیابی به عملکرد را می‌بینید. ابتدا باید سربار اعتبارسنج روی CPU را چندین مرتبه بزرگی کاهش دهیم. تنها پس از آن باید بر کاهش بیشتر از طریق سخت‌افزار تمرکز کنیم. همچنین باید میزان حافظه افزایش یابد.

در تمام مراحل زیر، توسعه‌دهندگان نباید برای دستیابی به عملکرد لازم مجبور به پیاده‌سازی کد اختصاصی zkVM باشند. تجربه توسعه‌دهندگی یکی از مزیت‌های اصلی zkVM است. قربانی کردن DevEx برای رسیدن به معیارهای عملکرد، با ذات خود zkVM در تضاد خواهد بود.

این معیارها بر هزینه اثبات‌گر تمرکز دارند. اما اگر اجازه داده شود هزینه اعتبارسنج نامحدود باشد (یعنی محدودیتی بر اندازه اثبات یا زمان راستی‌آزمایی وجود نداشته باشد)، دستیابی به هر معیار اثبات‌گر به‌سادگی ممکن خواهد بود. بنابراین، برای پایبندی سیستم‌ها به مراحل توصیف‌شده، باید حداکثر اندازه اثبات و زمان راستی‌آزمایی مشخص شود.

الزامات عملکرد

الزام مرحله ۱: «هزینه راستی‌آزمایی معقول و غیربدیهی»:

· اندازه اثبات: اندازه اثبات باید از اندازه شاهد کوچک‌تر باشد.

· زمان راستی‌آزمایی: سرعت راستی‌آزمایی اثبات نباید از اجرای بومی برنامه (یعنی انجام محاسبات بدون اثبات درستی) کمتر باشد.

این‌ها حداقل الزامات موجز هستند. تضمین می‌کنند که اندازه اثبات و زمان راستی‌آزمایی بدتر از فرستادن شاهد به اعتبارسنج و بررسی مستقیم درستی آن توسط اعتبارسنج نباشد.

الزامات مرحله ۲ و مراحل بعد:

· حداکثر اندازه اثبات: ۲۵۶ KB.

· حداکثر زمان راستی‌آزمایی: ۱۶ میلی‌ثانیه.

این آستانه‌ها عمداً بالا تعیین شده‌اند تا فناوری‌های جدید و سریع اثبات را که ممکن است هزینه‌های راستی‌آزمایی بیشتری داشته باشند، پوشش دهند. در عین حال، اثبات‌های بسیار پرهزینه‌ای را که کمتر پروژه‌ای حاضر است روی بلاک‌چین بگنجاند، کنار می‌گذارند.

مرحله سرعت ۱

اثبات تک‌رشته‌ای باید حداکثر ⁦100,000⁩ برابر کندتر از اجرای بومی باشد؛ این معیار باید در طیفی از برنامه‌ها (نه فقط اثبات‌های بلوک اتریوم) و بدون اتکا به پیش‌کامپایل‌ها سنجیده شود.

به‌طور مشخص، پردازشی RISC-V را در نظر بگیرید که روی یک لپ‌تاپ امروزی با سرعت حدود ⁦30B⁩ چرخه در ثانیه اجرا می‌شود. دستیابی به مرحله ۱ یعنی بتوانید روی همان لپ‌تاپ (در حالت تک‌رشته‌ای) با سرعت تقریبی ۳۰٬۰۰۰ چرخه RISC-V در ثانیه اثبات تولید کنید. با این حال، هزینه راستی‌آزمایی باید مطابق توضیح بالا «معقول اما غیربدیهی» باشد.

مرحله سرعت ۲

اثبات تک‌رشته‌ای باید حداکثر ⁦10,000⁩ برابر کندتر از اجرای بومی باشد.

روش جایگزین این است که، از آنجا که برخی فنون امیدوارکننده SNARK (به‌ویژه آن‌هایی که بر میدان‌های دودویی مبتنی‌اند) با محدودیت CPUها و GPUهای فعلی مواجه هستند، این مرحله را با مقایسه با FPGA (یا حتی ASIC) پشت سر بگذارید:

تعداد هسته‌های RISC-V که FPGA می‌تواند به‌صورت بومی شبیه‌سازی کند؛

تعداد FPGAهای موردنیاز برای شبیه‌سازی و اثبات اجرای RISC-V در زمان تقریباً واقعی.

اگر مقدار دوم حداکثر ⁦10,000⁩ برابر بیشتر از مقدار اول باشد، واجد شرایط مرحله ۲ هستید. روی یک CPU استاندارد، اندازه اثبات باید حداکثر ⁦256⁩ KB و زمان اعتبارسنج باید حداکثر ⁦16⁩ میلی‌ثانیه باشد.

مرحله سرعت ۳

علاوه بر دستیابی به مرحله سرعت ۲، می‌توانید از پیاده‌سازی‌های پیش‌کامپایل‌شده‌ای استفاده کنید که به‌طور خودکار سنتز و به‌صورت صوری راستی‌آزمایی شده‌اند و هزینه اثبات آن‌ها کمتر از ۱٬۰۰۰ برابر است (و برای طیف گسترده‌ای از برنامه‌ها مناسب‌اند). اساساً می‌توانید مجموعه دستورالعمل‌ها را برای هر برنامه به‌صورت پویا سفارشی کنید تا اثبات را سرعت ببخشید؛ اما این کار باید به روشی آسان برای استفاده و راستی‌آزمایی‌شده به‌صورت صوری انجام شود.

مرحله حافظه ۱

سرعت مرحله ۱ باید در حالی به دست آید که اثبات‌گر کمتر از ۲ GB حافظه مصرف می‌کند (و هم‌زمان به دانش صفر دست می‌یابد).

این موضوع برای بسیاری از دستگاه‌های همراه یا مرورگرها حیاتی است و کاربردهای بی‌شماری برای zkVM سمت کلاینت فراهم می‌کند. اثبات‌های سمت کلاینت اهمیت دارند، زیرا تلفن‌های ما ارتباط پیوسته‌مان با دنیای واقعی هستند: آن‌ها مکان، اعتبارنامه‌ها و موارد دیگر را دنبال می‌کنند. اگر تولید یک اثبات بیش از ۱-۲ GB حافظه بخواهد، برای بیشتر دستگاه‌های همراه امروزی بسیار زیاد است. باید دو نکته را روشن کرد:

· محدودیت فضای ۲ GB برای گزاره‌های بزرگ اعمال می‌شود (گزاره‌هایی که برای اجرای محلی به تریلیون‌ها چرخه CPU نیاز دارند). سیستم‌های اثباتی که فقط برای گزاره‌های کوچک محدودیت فضا در نظر می‌گیرند، کاربرد گسترده‌ای ندارند.

· اگر اثبات‌گر بسیار کند باشد، به‌سادگی می‌توان مصرف حافظه آن را کمتر از ۲ GB نگه داشت. بنابراین، برای اینکه مرحله ۱ حافظه معنادار باشد، لازم است سرعت مرحله ۱ در همین محدودیت ۲ GB فضا محقق شود.

مرحله حافظه ۲

سرعت مرحله ۱ با مصرف حافظه کمتر از ۲۰۰ MB محقق می‌شود (۱۰ برابر بهتر از مرحله حافظه ۱).

چرا باید مصرف حافظه را به کمتر از ۲ GB رساند؟ مثالی خارج از بلاک‌چین را در نظر بگیرید: هر بار که از طریق HTTPS به وب‌سایتی سر می‌زنید، گواهی‌نامه‌ای برای شناسایی و رمزنگاری دانلود می‌کنید. وب‌سایت می‌تواند به‌جای آن، همراه این گواهی‌نامه‌ها اثبات‌های zk ارسال کند. یک وب‌سایت بزرگ ممکن است میلیون‌ها اثبات در ثانیه صادر کند. اگر تولید هر اثبات به ۲ GB حافظه نیاز داشته باشد، در مجموع به RAM در مقیاس PB نیاز خواهد بود. کاهش بیشتر مصرف حافظه برای استقرارهای خارج از بلاک‌چین حیاتی است.

پیش‌کامپایل‌ها: آخرین گام یا عصا؟

در طراحی zkVM، پیش‌کامپایل‌ها SNARKهای تخصصی (یا سیستم‌های قیدی) هستند که برای کارکردهای خاصی مانند هش‌کردن Keccak/SHA برای امضاهای دیجیتال یا عملیات گروه منحنی بیضوی طراحی شده‌اند. در اتریوم (جایی که بخش عمده کارهای سنگین شامل هش‌کردن Merkle و بررسی امضاست)، برخی پیش‌کامپایل‌های دست‌ساز می‌توانند هزینه‌های اعتبارسنج را کاهش دهند. با این حال، تکیه بر آن‌ها به‌عنوان عصا اجازه نمی‌دهد SNARKها به هدف موردنظرشان برسند. دلایل آن عبارت‌اند از:

· هنوز برای بیشتر برنامه‌ها (چه درون بلاک‌چین و چه خارج از آن) بسیار کند است: حتی با وجود پیش‌کامپایل‌های هش و امضا، zkVM فعلی به‌دلیل ناکارآمدی سیستم اثبات اصلی، همچنان بسیار کند است (هم در محیط‌های بلاک‌چینی و هم خارج از آن).

· نقص‌های امنیتی: پیش‌کامپایل‌های دست‌نویسی‌شده‌ای که به‌صورت صوری راستی‌آزمایی نشده‌اند، تقریباً به‌طور قطع پر از باگ هستند و ممکن است به نقص‌های امنیتی فاجعه‌بار منجر شوند.

· تجربه توسعه‌دهندگی ضعیف: در بیشتر zkVMهای امروزی، افزودن یک پیش‌کامپایل جدید به معنای نوشتن دستی یک سیستم قیدی برای هر قابلیت است؛ یعنی عملاً بازگشت به روال کاری دهه ۱۹۶۰. حتی با وجود پیش‌کامپایل‌های فعلی، توسعه‌دهندگان باید کد را بازنویسی کنند تا هر پیش‌کامپایل را فراخوانی کنند. باید امنیت و تجربه توسعه‌دهندگی را بهینه کنیم، نه اینکه هر دو را برای دستیابی به افزایش‌های تدریجی عملکرد قربانی کنیم. چنین کاری فقط نشان می‌دهد عملکرد هنوز به ظرفیت واقعی خود نرسیده است.

· سربار ورودی/خروجی و نبود RAM: پیش‌کامپایل‌ها می‌توانند عملکرد کارهای سنگین رمزنگاری را بهبود دهند، اما ممکن است برای بارهای کاری متنوع‌تر شتاب قابل‌توجهی فراهم نکنند؛ زیرا هنگام رسیدگی به ورودی/خروجی سربار چشمگیری دارند و نمی‌توانند از RAM استفاده کنند. حتی در محیط بلاک‌چین، به‌محض اینکه از یک L1 مانند اتریوم فراتر بروید (برای مثال، اگر بخواهید مجموعه‌ای از پل‌های میان‌زنجیره‌ای بسازید)، با توابع هش و طرح‌های امضای متفاوتی روبه‌رو می‌شوید. تکرار پیاده‌سازی پیش‌کامپایل‌ها برای یک مسئله، مقیاس‌پذیر نیست و خطرهای امنیتی چشمگیری ایجاد می‌کند.

به همه این دلایل، وظیفه اصلی ما باید افزایش کارایی zkVM زیربنایی باشد. فناوری‌ای که بهترین zkVM را تولید می‌کند، بهترین پیش‌کامپایل‌ها را هم خواهد ساخت. باور دارم پیش‌کامپایل‌ها در بلندمدت همچنان حیاتی خواهند بود، اما فقط به شرطی که به‌صورت خودکار سنتز و به‌طور صوری راستی‌آزمایی شوند. به این ترتیب، می‌توانیم مزیت تجربه توسعه‌دهندگی zkVM را حفظ کنیم و در عین حال از خطرهای امنیتی فاجعه‌بار جلوگیری کنیم. این دیدگاه در مرحله سرعت ۳ منعکس شده است.

زمان‌بندی مورد انتظار

انتظار دارم چند zkVM در اواخر امسال به مرحله سرعت ۱ و مرحله حافظه ۱ برسند. همچنین پیش‌بینی می‌کنم مرحله سرعت ۲ طی دو سال آینده محقق شود، هرچند در حال حاضر مشخص نیست بتوانیم بدون ایده‌های جدیدی که هنوز پدیدار نشده‌اند به این هدف برسیم یا نه. پیش‌بینی می‌کنم تکمیل مراحل باقی‌مانده (مرحله سرعت ۳ و مرحله حافظه ۲) چند سال دیگر زمان ببرد.

جمع‌بندی

در این مقاله، مراحل امنیت و عملکرد zkVM را جداگانه ترسیم کردم، اما این جنبه‌های zkVM کاملاً مستقل از یکدیگر نیستند. با کشف آسیب‌پذیری‌های بیشتر در zkVM، انتظار می‌رود برخی از آن‌ها فقط با پرداخت هزینه افت چشمگیر عملکرد برطرف شوند. تا زمانی که zkVM به مرحله امنیتی ۲ نرسیده است، باید به بهبود عملکرد اولویت کمتری داد.

zkVM وعده می‌دهد اثبات‌های دانش صفر را واقعاً در دسترس همگان قرار دهد، اما هنوز در ابتدای راه است و با چالش‌های امنیتی و سربار عملکردی چشمگیری روبه‌روست. هیاهو و بازاریابی ارزیابی پیشرفت واقعی را دشوار می‌کنند. این نقشه راه با ترسیم نقاط عطف روشن برای امنیت و عملکرد، می‌کوشد مسیری رو به جلو و عاری از حواس‌پرتی ارائه دهد. به اهداف خواهیم رسید، اما این کار به زمان و تلاشی پیوسته نیاز دارد.

پیوند مقاله اصلی