خانه جدید Longfellow پرسش زنجیره تأمین ZK را تغییر می‌دهد

گوگل Longfellow ZK را وارد گفت‌وگوی متفاوتی درباره امنیت کرده است. این شرکت در ۲ سپتامبر اعلام کرد که کتابخانه را به اتحادیه رمزنگاری پساکوانتومی (PQCA)، طرحی زیرمجموعه Linux Foundation Europe، اهدا می‌کند. گوگل می‌گوید هدف، ایجاد سرپرستی باز و مستقل از فروشنده برای کتابخانه‌ای است که برای کاربردهای هویت دیجیتالِ حافظ حریم خصوصی طراحی شده است.

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

منابع عمومی فعلی Longfellow مرز پیاده‌سازی را روشن می‌کنند. مخزن GitHub پروژه را یک کتابخانه دانش صفر برای پروتکل‌های هویتی معرفی می‌کند و مجوز Apache-2.0 را نشان می‌دهد. دستورهای ساخت آن به مؤلفه‌هایی مانند CMake، Clang، OpenSSL، zstd، GoogleTest و Google Benchmark وابسته است. مخزن همچنین به بازبینی‌های امنیتی مستقل اشاره می‌کند و آزمون‌ها و benchmarkها را ارائه می‌دهد. برای سازنده ICP، این جزئیات عملی هستند: یک سرویس یا verifier متصل به canister باید revision دقیق منبع، toolchain، پروفایل مدار و بردارهای راستی‌آزمایی مورد حسابرسی را pin کند.

Internet-Draft منتشرشده در ۳ سپتامبر، لایه مهم دیگری را اضافه می‌کند. این سند Longfellow را یک استدلال دانش صفرِ غیرتعاملی و فشرده توصیف می‌کند که از MPC-in-the-head، تعهدهای Ligero و sumcheck ساخته شده است. سند بر طراحی‌ای تمرکز دارد که به common reference string نیاز ندارد و می‌تواند بر پایه تابع hash مقاوم در برابر برخورد ساخته شود؛ همچنین یک profile مشخص با SHA-256 تعریف می‌کند. در سند، ترکیب‌های پارامتری پشتیبانی‌شده‌ای نیز آمده‌اند که طبق جدیدترین تحلیل همان سند، برای تأمین دست‌کم ۱۱۵ بیت امنیت در نظر گرفته شده‌اند.

این گزاره‌ها ورودی‌های مهندسی مفیدی هستند، نه تضمین‌های دائمی. یک verifier مستقر روی ICP نباید نتیجه بگیرد که «پساکوانتومی» بودن یعنی همه credentialها، امضاها، مسیرهای انتقال یا walletهای پیرامونی نیز پساکوانتومی هستند. ممکن است سامانه اثبات از گزاره‌ای درباره یک credential امضاشده با ECDSA محافظت کند، در حالی که خود طرح امضا در برابر حملات کوانتومی آینده آسیب‌پذیر باقی بماند. بنابراین ادعای امنیت باید به یک profile و مدل تهدید دقیق تعلق داشته باشد.

درس فوری این است که سرپرستی را بخشی از رابط رمزنگاری بدانیم. پیش از ادغام verifier مبتنی بر Longfellow، تیم‌ها باید موارد زیر را ثبت کنند:

• commit و release tag مخزن؛
• profile مدار و پارامترها؛
• قواعد hash، transcript و سریال‌سازی؛
• نسخه‌های toolchain و وابستگی‌ها؛
• بردارهای آزمون استفاده‌شده برای پذیرش؛ و
• اختیار ارتقا و روش rollback.

اعلامیه گوگل مدل موردنظر برای سرپرستی مستقل از فروشنده را توضیح می‌دهد، اما منشور نگه‌داری، فرایند حکمرانی انتشار یا جدول زمانی انتقال را مشخص نمی‌کند. این جزئیات عملیاتی همچنان پرسش‌های باز هستند. سند IETF نیز یک work in progress است و هشدار می‌دهد که Internet-Draftها ممکن است به‌روزرسانی، جایگزین یا منسوخ شوند.

برای توسعه‌دهندگان ICP، زاویه جدید همین است: خطر بعدی فقط این نیست که proof امروز verify شود. مسئله این است که آیا verifier ارتقایافته، profile مدار تغییرکرده و پیاده‌سازی مستقل همچنان فردا همان معنا را دارند یا نه. سرپرستی باز می‌تواند این چشم‌انداز را بهتر کند—اما فقط زمانی که integrationها این فرض‌ها را صریح و قابل‌آزمون کنند.