آکیتا هزینهٔ تأیید در ZK پساکوانتومی را از مسیر بحرانی خارج می‌کند

یک primitive جدید در حوزهٔ ZK می‌خواهد یکی از کم‌تر دیده‌شده‌ترین هزینه‌های اثبات پساکوانتومی، یعنی تأیید، را هدف بگیرد. LayerZero در ۹ سپتامبر Akita را معرفی کرد؛ طرحی برای تعهد چندجمله‌ای مبتنی بر شبکه‌های کریپتوگرافی که برای سامانه‌های دانش صفر با فرض‌های مقاوم در برابر رایانش کوانتومی طراحی شده است، بدون آن‌که الزاماً به اثبات‌های بسیار بزرگ تن بدهند.

تعهدهای چندجمله‌ای در لایهٔ زیرین بسیاری از سامانه‌های اثبات قرار دارند. آن‌ها به اثبات‌گر اجازه می‌دهند به یک چندجمله‌ای مرتبط با محاسبه متعهد شود و بعداً ارزیابی‌های آن را اثبات کند. مقالهٔ Akita استدلال می‌کند که رویکردهای مبتنی بر شبکهٔ موجود معمولاً فقط دو مورد از سه هدف عملیاتی را هم‌زمان به‌دست می‌آورند: اثبات فشرده، تأیید سریع، و امنیت مبتنی بر فرض‌های استانداردی مانند Module-SIS. Akita برای پرداختن به هر سه هدف طراحی شده است.

ایدهٔ معماری اصلی آن، انتقال بخشی از کار setup به خارج از مسیر تأیید است. به‌جای آن‌که تأییدکننده همهٔ ماتریس‌های عمومی setup را مستقیماً پردازش کند، Akita این ماتریس‌ها را از قبل متعهد می‌کند و محاسبهٔ مربوط به setup را در برابر همان تعهدها اثبات می‌کند. مقاله این روش را راهی برای کاهش کار تأییدکننده، همراه با حفظ اندازهٔ لگاریتمی اثبات، توصیف می‌کند. Akita همچنین از بازکردن‌های دسته‌ای، اثبات‌سازی توزیع‌شده، و برنامه‌ریز آفلاین برای انتخاب پارامترها بر اساس اهداف هزینهٔ قابل تنظیم پشتیبانی می‌کند.

اعداد منتشرشده قابل توجه‌اند، اما باید آن‌ها را نتایج پژوهشی دانست، نه تضمین مستقل. مقاله اثبات‌هایی با اندازهٔ ۶۱ تا ۷۰ کیلوبایت و تأییدی ۱۰ تا ۹۴ برابر سریع‌تر از سامانهٔ lattice-based مقایسه‌شده، یعنی Greyhound، در سطح امنیتی ادعاشدهٔ یکسان گزارش می‌کند. در اتصال به Jolt نیز نویسندگان بهبود ۱٫۳ تا ۲٫۲ برابری در سرعت اثبات‌سازی و ۲٫۲ تا ۷٫۴ برابری در سرعت تأیید نسبت به Jolt با Dory گزارش کرده‌اند؛ در برنامه‌های ارزیابی‌شده، همهٔ اثبات‌ها کوچک‌تر از ۱۰۰ کیلوبایت باقی مانده‌اند.

برای توسعه‌دهندگان ICP و دیگر سازندگان برنامه، نکتهٔ مهم این نیست که Akita همین حالا آمادهٔ ورود مستقیم به یک canister است. نکته این است که انتخاب‌های proof system بیش از پیش یک بودجهٔ جداگانه برای تأیید آشکار می‌کنند. طراحی‌ای که توان عملیاتی اثبات‌سازی را بهتر کند اما تأیید را پرهزینه باقی بگذارد، همچنان می‌تواند تأیید روی زنجیره، تأیید در مرورگر، یا بررسی اثبات میان چند سرویس را محدود کند. اثبات فشرده مفید است، اما هزینهٔ آماده‌سازی و بررسی ساختار تعهد ممکن است تعیین کند که اثبات با تأخیر و ظرفیت محاسباتی واقعی برنامه سازگار هست یا نه.

یک مرز بلوغ نیز وجود دارد. Akita به‌عنوان primitive متن‌بازی معرفی شده که نخستین استقرار مهم آن برای Jolt در نظر گرفته شده است؛ بااین‌حال، مخزن Jolt فعلاً آن را alpha و نامناسب برای استفادهٔ production توصیف می‌کند. این اعلامیه وجود یکپارچه‌سازی با ICP، ممیزی امنیتی مستقل، یا آمادگی production را ثابت نمی‌کند. سازندگان باید این موارد را جداگانه بررسی کنند و پیش از استفاده از پیاده‌سازی به‌عنوان زیرساخت، به آن‌ها تکیه نکنند.

نتیجهٔ عملی این است که باید کل مسیر تأیید را اندازه‌گیری کرد، نه فقط تولید اثبات را. در هر گردش‌کار ZK که قرار است با ICP ارتباط داشته باشد، اندازهٔ اثبات، زمان تأیید، حافظه، فرض‌های پارامتری، نحوهٔ مدیریت setup و نسخهٔ دقیق پیاده‌سازی را ثبت کنید. سهم Akita یادآوری می‌کند که مهندسی ZK پساکوانتومی فقط مهاجرت فرض‌های رمزنگاری نیست؛ یک مسئلهٔ سامانه‌ای نیز هست که در آن بار تأییدکننده باید طراحی، اندازه‌گیری و محدود شود.