باگ جفت‌سازی OpenVM فقط یک وصله نیست؛ درسی درباره soundness اثبات است

مرز نادیده‌گرفته‌شده در بررسی جفت‌سازی

نسخه امنیتی 1.7.0 OpenVM سه مشکل را برطرف کرد؛ از جمله یک نقص soundness در MemoryMerkleAir و دو مشکل در wrapper وریفایر Solidity. اما آموزنده‌ترین مورد در یک هشدار جداگانه درباره کتابخانه مهمان openvm-pairing توضیح داده شد: نبودِ بررسی زیرمیدان می‌توانست به یک prover متقلب اجازه دهد بررسی جفت‌سازی نامعتبر را موفق نشان دهد.

تابع آسیب‌پذیر try_honest_pairing_check از بهینه‌سازی‌ای مبتنی بر یک قضیه درباره بررسی‌های جفت‌سازی استفاده می‌کند. این بهینه‌سازی یک ضریب مقیاس در Fp12 وارد می‌کند. طبق هشدار، پیاده‌سازی بررسی نمی‌کرد که این ضریب به زیرمیدان مناسب تعلق داشته باشد. چون یکی از شرط‌های قضیه در کد enforce نشده بود، prover می‌توانست یک hint مخرب ارائه کند و بررسی جبری مورد انتظار را دور بزند.

پیامد عملی برای برنامه‌هایی که به این helper متکی هستند جدی است. در هشدار آمده که یک hint نادرست می‌تواند باعث شود هر بررسی جفت‌سازی پذیرفته شود. این مسئله نشت حریم خصوصی یا افت کارایی نیست؛ شکست در صحت است، درست در نقطه‌ای که از سیستم اثبات انتظار می‌رود محاسبه نادرست را رد کند.

چرا این موضوع برای سازندگان zkVM مهم است

سیستم‌های ZK اغلب بخشی از کار پرهزینه را به hintها، جدول‌های lookup، پیش‌محاسبه یا routineهای تخصصی کتابخانه مهمان منتقل می‌کنند. این روش‌ها proving را سریع‌تر می‌کنند، اما سطح بررسی دوم ایجاد می‌کنند. مدار باید hint را به اندازه کافی محدود کند تا بهینه‌سازی با بررسی ریاضی اصلی هم‌ارز بماند.

پرونده OpenVM یک الگوی مفید برای بازبینی ارائه می‌دهد. ابتدا قضیه‌ای را که در حال پیاده‌سازی است بررسی کنید، همه شروط آن را فهرست کنید و مشخص کنید هر شرط در مدار، کد مهمان یا wrapper وریفایر enforce می‌شود. اگر شرطی به دلیل «معمولاً درست بودن» حذف شده است، باید نشان داده شود که این حذف برای همه منحنی‌ها و قالب‌های ورودی پشتیبانی‌شده امن است.

همین دقت در مرز Solidity نیز لازم است. یادداشت‌های نسخه 1.7.0 OpenVM از رفع یک تداخل selector در wrapper وریفایر و رد کردن encodingهای غیر canonical برای scalarهای BN254 نیز خبر می‌دهند. این‌ها باگ‌های متفاوتی هستند، اما همگی یک واقعیت مهندسی را نشان می‌دهند: soundness اثبات به کل مسیر، از ورودی مهمان تا وریفایر آن‌چین، وابسته است.

توسعه‌دهندگان چه کاری انجام دهند؟

پروژه‌هایی که از openvm-pairing استفاده می‌کنند باید بررسی کنند وابستگی آن‌ها دست‌کم نسخه 1.6.0 باشد؛ این همان نسخه‌ای است که در هشدار به‌عنوان نسخه اصلاح‌شده معرفی شده است. تیم‌ها همچنین باید قراردادهای وریفایر تولیدشده و هر بهینه‌سازی سفارشی جفت‌سازی را audit کنند و نسخه zkVM را به‌تنهایی تضمین امنیت کامل ندانند.

این مشکل کاربران کتابخانه مهمان openvm-pairing در نسخه‌های پایین‌تر از 1.6.0 را تحت‌تأثیر قرار می‌دهد؛ منابع موجود نشان نمی‌دهند که همه اثبات‌ها یا همه برنامه‌های OpenVM آسیب‌پذیر بوده‌اند. این تمایز هنگام اعلام ریسک مهم است: یافته برای integration آسیب‌دیده بحرانی است، اما مدرکی نیست که همه برنامه‌های OpenVM اثبات‌های unsound تولید می‌کنند.

درس گسترده‌تر ساده است: در مهندسی ZK، بهینه‌سازی بخشی از خود سیستم اثبات است. بررسی‌های حذف‌شده جزئیات پیاده‌سازی نیستند؛ آن‌ها فرض‌هایی هستند که باید صریح، محدود و آزموده شوند.