آکیتا، راستی‌آزمایی ZK را به مسئله مدیریت پارامترهای راه‌اندازی تبدیل می‌کند

لیرزیرو در ۹ سپتامبر آکیتا را به‌عنوان یک طرح تعهد چندجمله‌ای مبتنی بر شبکه‌های بلوری برای اثبات‌های دانش صفر مقاوم در برابر رایانش کوانتومی معرفی کرد. نخستین استقرار مهم آن در Jolt، ماشین مجازی دانش صفر RISC-V که با همکاری a16z crypto توسعه یافته، انجام می‌شود.

خبر اصلی، این جابه‌جایی رمزنگاری است: آکیتا لایه تعهد قبلی Jolt یعنی Dory را که به رمزنگاری منحنی بیضوی متکی بود، با ساختاری مبتنی بر فرض شبکه‌ای Module-SIS جایگزین می‌کند. نویسندگان می‌گویند آکیتا راه‌اندازی شفاف دارد و امنیت ۱۲۸بیتی را بر پایه این فرض هدف می‌گیرد.

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

این موضوع برای توسعه‌دهندگان ICP که به راستی‌آزمایی اثبات درون کانتینر یا در کنار کانتینر فکر می‌کنند مهم است. یک یکپارچه‌سازی عملی باید دست‌کم به این پرسش‌ها پاسخ دهد:

• راستی‌آزما دقیقاً کدام خانواده پارامتر و پروفایل امنیتی آکیتا را می‌پذیرد؟
• مصنوعات راه‌اندازی کجا نگهداری می‌شوند و هش آن‌ها چگونه تثبیت می‌شود؟
• آیا راستی‌آزمای Wasm می‌تواند اثبات‌های خراب یا مصنوعات ناسازگار را بدون panic و بدون عبور از محدودیت منابع رد کند؟
• هنگام تغییر prover، verifier، زمان‌بندی یا قالب سریال‌سازی، ارتقا چگونه هماهنگ می‌شود؟

مخزن عمومی Rust آکیتا همین مسیر را نشان می‌دهد. این پروژه نقش‌های prover و verifier را جدا می‌کند، کاتالوگ‌های زمان‌بندی اعتبارسنجی‌شده را مستند می‌سازد و برای انتخاب زمان‌بندی از یک digest در سطح اثبات استفاده می‌کند؛ بنابراین خود اثبات نمی‌تواند زمان‌بندی دلخواهی را تحمیل کند. برای یک استقرار ICP، این الگو از کپی‌کردن یک عدد بنچمارک مهم‌تر است: پارامترهای پروتکل را در مالکیت برنامه نگه دارید، پیش از راستی‌آزمایی اعتبارشان را بررسی کنید و نسخه مصنوع پذیرفته‌شده را صریح کنید.

ادعاهای عملکردی قابل توجه‌اند، اما باید با احتیاط خوانده شوند. لیرزیرو از اثبات‌های ۶۵ تا ۸۰ کیلوبایتی، اثبات‌سازی ۲ تا ۳ برابر سریع‌تر از پیاده‌سازی فعلی Jolt و تقریباً نصف‌شدن مصرف حافظه خبر می‌دهد. مقاله همراه نیز برای Jolt با آکیتا، در اندازه‌های برنامه بررسی‌شده، افزایش سرعت prover بین ۱٫۳ تا ۲٫۲ برابر و افزایش سرعت verifier بین ۲٫۲ تا ۷٫۴ برابر نسبت به Jolt با Dory گزارش می‌کند؛ اندازه همه اثبات‌ها نیز کمتر از ۱۰۰ کیلوبایت بوده است. این ارقام از بنچمارک‌های خود پروژه به‌دست آمده‌اند و ممیزی مستقل نیستند؛ بنابراین سازندگان ICP باید پیش از تصمیم معماری، آن‌ها را روی Wasm و سخت‌افزار هدف بازتولید کنند.

یک مرز حریم خصوصی نیز نباید مبهم شود. اعلامیه a16z، Lattice Jolt را مقاوم در برابر کوانتوم معرفی می‌کند و می‌گوید مقاله‌ای تکمیلی برای افزودن دانش صفر در راه است. بنابراین آکیتا فعلاً یک لایه تعهد مقاوم در برابر کوانتوم را نشان می‌دهد؛ خود آکیتا به‌تنهایی ثابت نمی‌کند که همه قابلیت‌های لازم برای کاربردهای خصوصی تکمیل شده‌اند.

نتیجه فوری روشن است: وقتی یک primitive دانش صفر به سمت استقرار می‌رود، زنجیره تأمین verifier بخشی از مدل امنیتی می‌شود. برای سازندگان ICP، مصنوعات پارامتر، هش‌ها، بودجه منابع و قواعد ارتقا باید به اندازه معادلات اثبات با دقت بررسی شوند.