تصور کنید یک اثبات‌کنندهٔ مخرب بتواند هرگونه برابری جفت‌سازی را جعل کند؛ این دقیقاً همان حفره‌ای است که zkao پیدا کرد. این تحلیل‌گر تخصصی هوش مصنوعی، یک باگ بحرانی در صحت (Soundness) کتابخانهٔ guest در OpenVM شناسایی کرد که با شناسه CVE-2026-46669 ثبت شده است. در کتابخانه openvm-pairing این آسیب‌پذیری نهفته بود.
این کشف در دومین پست از یک سری آزمایشات (پس از بررسی‌های Cloudflare CIRCL) توسط zkSecurity منتشر شد تا ثابت کند کدهای رمزنگاری با پیچیدگی بالا همچنان نقطه کور مدل‌های زبانی بزرگ (LLM) هستند. این اتفاق در زمانی رخ می‌دهد که صنعت از پرامپت‌نویسی ساده به‌سوی گردش‌های کاری عامل‌محور (Agentic) حرکت می‌کند. در حالی که LLMهای استاندارد را به‌طور فزاینده‌ای برای شکار باگ‌ها به کار می‌گیرند، تراکم وابستگی‌ها در ماشین‌های مجازی با دانش صفر (zkVM) اغلب از پنجرهٔ زمینه (Context Window) و توان استدلالی مدل‌هایی مثل Opus 4.6 یا Codex 5.3 فراتر می‌رود. بر اساس آزمایشات پیشین، این مورد مطالعاتی به عنوان یک معیار (Benchmark) برای این موضوع عمل می‌کند که «مهندسی زمینه» چگونه باید تکامل یابد تا بتواند نیازمندی‌های توابع رمزنگاری پیمانه‌ای (Modular Cryptographic Primitives) را مدیریت کند.
محدودیت‌های حسابرسی ساده با AI
پیش از استقرار zkao، تیم توسعه‌دهنده تلاش کرد تا OpenVM را با استفاده از تنظیمات استاندارد LLM و پنجره‌های متنی بین ۳۰۰ هزار تا ۱ میلیون توکن اسکن کند. این تلاش‌ها که با استفاده از مدل‌های Opus 4.7 و Codex 5.4 انجام شد، چندین یافته‌ی احتمالی را تولید کرد. با این حال، در حالی که مدل‌ها با اطمینان کامل این یافته‌ها را «بحرانی» (Critical) یا «بسیار مهم» (High) برچسب می‌زدند، تریاژ انسانی فاش کرد که هیچ‌کدام از آن‌ها در واقع قابل بهره‌برداری نبودند.
علت این شکست در ماهیت معماری zkVM نهفته است. برخلاف کتابخانه‌های ساده که در آن‌ها زیر-عامل‌ها می‌توانند پوشه‌های مجزا را که به توابع رمزنگاری تکی دارند به صورت موازی حسابرسی کنند، امنیت یک zkVM اغلب به «ترکیب» ماژول‌ها وابسته است. یک ماژول A که از نظر اثباتی امن است، وقتی با یک ماژول B که آن هم از نظر اثباتی امن است ترکیب شود، همچنان می‌تواند سیستمی ناامن ایجاد کند. عامل‌های ساده معمولاً لیستی از باگ‌ها را خروجی می‌دهند، اما نمی‌توانند دانش انتزاعی درباره مفروضات ماژول، تفویض اختیار به فراخوان‌کننده‌ها (Delegations to Callers) و ناورانه‌های خاموش (Silent Invariants) را درک کنند؛ و این دقیقاً همان جایی است که آسیب‌پذیری‌های واقعی پنهان شده‌اند.
آزمایش فرضیه روی زمینهٔ مدل
تیم تحقیق این فرضیه را مطرح کرد که یک zkVM برای یک LLM ساده، حتی با پنجره متنی ۱ میلیون توکنی، بیش از حد پیچیده است. در کتابخانه‌های معمولی، عامل‌ها می‌توانند تعداد کمی از خطوط کد را بخوانند و مهارت‌های مربوطه را اعمال کنند. اما وابستگی‌های OpenVM بسیار متراکم‌تر هستند و این حالت «ایزوله» را ناکارآمد می‌کند. ابزارهای فعلی کدنویسی عامل‌محور، مانند Claude Code و Codex، هنوز این مشکل بازنمایی (Representation Problem) را به‌طور بهینه حل نکرده‌اند.
به دلیل این وضعیت، تیم تصمیم گرفت zkao را روی OpenVM اجرا کند و قانون اصلی خود را — که طبق آن zkao تنها پس از یافتن یک باگ واقعی توسط LLMهای ساده اجرا می‌شد — زیر پا بگذارد. آن‌ها زمان قابل‌توجهی را صرف مهندسی زمینه کردند تا روش‌های کاری متخصصان خود را در قالب جریان‌های (Flows) قابل استفاده کدگذاری کنند. پس از بیش از نه و نیم ساعت اسکن مداوم، zkao یافته‌های متعددی از جمله باگ بحرانی جفت‌سازی را بازگرداند.
کالبدشکافی CVE-2026-46669
برای رسیدن به این نتیجه، zkao از یک گردش کار خاص به نام «cryptopsy» بهره برد. این متد، کد پیاده‌سازی را با ادبیات آکادمیک، نقاط ضعف شناخته‌شده و تحلیل‌های رمزنگاری (Cryptanalysis) تطبیق می‌دهد. پس از شناسایی یک «بررسی نبودن زیرمیدان» (Missing Subfield Check) در منطق بررسی جفت‌سازی، تیم مورد را تأیید کرد. هر دو طرف، یعنی zkao و نگهدارندگان OpenVM، شدت این آسیب‌پذیری را «بحرانی» ارزیابی کردند.
جفت‌سازی‌ها موتور محرک پروتکل‌های Groth16، PLONK با KZG و امضاهای BLS هستند. در این پروتکل‌ها، یک تأییدکننده معمولاً می‌پرسد که آیا حاصل‌ضرب جفت‌سازی‌ها برابر با یک است یا خیر: $\prod_i e(P_i, Q_i) = 1$.
تنها بر اساس این پاسخ بله یا خیر، تأییدکننده نتیجه می‌گیرد که یک اثبات SNARK معتبر است، یک بازشدگی KZG درست است یا یک امضا تأیید می‌شود. اگر یک اثبات‌کننده بتواند یک حاصل‌ضرب جفت‌سازی غلط را به‌گونه‌ای نشان دهد که گویی برابر با یک است، هر آنچه بر روی آن بنا شده دیگر استوار (Sound) نخواهد بود.
یک جفت‌سازی در واقع یک نگاشت دوخطی $e : G_1 imes G_2 o G_T$ است، که در آن $G_1$ و $G_2$ گروه‌های منحنی بیضی و $G_T$ یک زیرگروه ضربی از $\mathbb{F}_{p^{12}}^{*}$ است. حیاتی‌ترین ویژگی این نگاشت، «دوخطی بودن» (Bilinearity) است: $e([a]P, [b]Q) = e(P, Q)^{ab}$.
حلقه میلر و توان‌رسانی نهایی
محاسبه یک جفت‌سازی شامل دو مرحله اصلی است:
- حلقه میلر (Miller Loop): این مرحله یک تابع میلر $f_{r, Q}(P)$ را ارزیابی می‌کند. برای حاصل‌ضرب جفت‌سازی‌ها، مدار تمام حلقه‌های میلر را اجرا کرده و خروجی‌ها را ضرب می‌کند: $f = \prod_i f_{r, Q_i}(P_i)$. این عملیات عنصری مانند $f$ را در $\mathbb{F}_{p^{12}}^{*}$ تولید می‌کند. بر اساس مقاله Novakovic و Eagen، مقدار $f$ تنها تا ضرب در یک توان $r$-ام منحصربه‌فرد است. یعنی دو خروجی $f_1$ و $f_2$ زمانی نماینده یک جفت‌سازی مشابه هستند که $f_1 = f_2 \cdot c^r$ برای یک $c$ غیرصفر باشد.
- توان‌رسانی نهایی (Final Exponentiation): برای حذف این ابهام، $f$ به توان $h = \frac{p^{12}-1}{r}$ می‌رسد. از آنجا که هر عنصر غیرصفر در $\mathbb{F}_{p^{12}}$ رابطه $x^{p^{12}-1} = 1$ را ارضا می‌کند، نتیجه در $G_T$ (گروه ریشه‌های $r$-ام واحد) قرار می‌گیرد. بررسی واقعی حاصل‌ضرب جفت‌سازی در واقع $f^h = 1$ است.
- بهینه‌سازی: از آنجا که رساندن $f$ به توان $h$ در داخل یک مدار بسیار گران است، اثبات‌کننده یک مقدار $c$ غیرصفر را به‌عنوان راهنما (Hint) ارائه می‌دهد به طوری که $f = c^r$. بررسی این مورد به‌طور قابل‌توجهی ارزان‌تر است.
OpenVM این فرآیند را با استفاده از ترفند «شاهد-باقیمانده» (Residue-witness) از مقاله Novakovic و Eagen پیاده کرده است. معادله بهینه‌شده‌ای که بررسی می‌شود عبارت است از: $f \cdot u = c^\lambda \wedge u^{d^i} = 1$ که در آن $\lambda = m \cdot r$ یک توان مخصوص منحنی است که اجازه می‌دهد $c^\lambda$ از طریق نگاشت فروبنیوس (Frobenius map) به‌صورت ارزان ارزیابی شود و $u$ فاکتور مقیاس است (در BN254 با نام $u$ و در BLS12-381 با نام $s$ شناخته می‌شود). سایر نمادها عبارت‌اند از $d = \gcd(m, h)$ و $i = v_d(h)$.
آسیب‌پذیری زیرمیدان
قضیه ۳ مقاله Novakovic و Eagen ایجاب می‌کند که فاکتور مقیاس $u$ لزوماً یک رابطه ریشه-واحد ($u^{d^i} = 1$) داشته باشد. برای منحنی‌های هدف، این مقاله یک مسیر حتی ارزان‌تر پیشنهاد می‌دهد: محدود کردن فاکتور مقیاس به زیرمیدان مناسب $\mathbb{F}{p^6} \subset \mathbb{F}{p^{12}}$.
OpenVM عناصر $\mathbb{F}{p^{12}}$ را به صورت ۶ ضریب $\mathbb{F}{p^2}$ ذخیره می‌کند: $[c_0, c_1, c_2, c_3, c_4, c_5]$. برای اینکه عنصری در زیرمیدان $\mathbb{F}_{p^6}$ باشد، ضرایب با اندیس فرد باید صفر باشند:
- $c_1 = 0$
- $c_3 = 0$
- $c_5 = 0$
این یک تست ارزان شامل تنها سه بررسی تساوی است.
با این حال، OpenVM این بررسی را حذف کرده بود. در مسیر کد BLS12-381 پیش از اصلاح، کد صرفاً بررسی می‌کرد که آیا راهنمای $c$ غیرصفر است یا خیر:
// guest-libs/pairing/src/bls12_381/pairing.rs
let (c, s) = Self::pairing_check_hint(P, Q);
// ... no check that s lies in Fp6 ...
let c_conj = c.conjugate();
if c_conj == Fp12::ZERO { return None; }
در BN254 نیز همین الگو با استفاده از if c == Fp12::ZERO { return None; } دنبال شده بود. هر دو مسیر، مقدار $c$ صفر را رد می‌کردند اما هر فاکتور مقیاسی را می‌پذیرفتند؛ به این معنا که معادله بهینه دیگر اثبات‌کننده واقعی جفت‌سازی نبود.
بهره‌برداری و اثرات
به دلیل نبود بررسی زیرمیدان، معادله بهینه $f \cdot u = c^\lambda$ دیگر استوار نبود. برای هر خروجی میلر $f$ — حتی خروجی حاصل از یک معادله جفت‌سازی غلط — یک اثبات‌کننده می‌توانست با تنظیم مقادیر زیر، تاییدیه (Pass) را جعل کند:
- $c = 1$
- $u = f^{-1}$ (یا $s = f^{-1}$ برای BLS12-381)
در این سناریو، $c^\lambda = 1$ شده و رابطه به $f \cdot f^{-1} = 1$ تبدیل می‌شود که همیشه درست است. در حالت عادی، $f^{-1}$ یک عنصر کامل $\mathbb{F}{p^{12}}$ است و نه عضوی از زیرمیدان $\mathbb{F}{p^6}$. دقیقاً همان بررسی زیرمیدانِ حذف‌شده بود که باید این جعل را رد می‌کرد. علاوه بر این، چون روتین بهینه شده وضعیت «موفق» را بازمی‌گرداند، مسیر جایگزین (Fallback) کندتر که توان‌رسانی نهایی کامل را انجام می‌داد، هرگز اجرا نمی‌شد.
اثرات این جعل بحرانی است:
- BLS12-381: یک اثبات‌کننده می‌تواند اثبات‌های بازشدن KZG را جعل کند و بدین ترتیب طرح‌های تعهد چندجمله‌ای را که برای دسترس‌پذیری داده‌ها (Data Availability)، تأیید Blobها و تأییدکنندگان PLONK/KZG استفاده می‌شوند، بشکند.
- BN254: این باگ تأییدکنندگان Groth16 SNARK، بررسی‌های امضای BLS و هر پل یا پروتکلی که به معادلات جفت‌سازی متکی است را متزلزل می‌کند.
- شبیه‌سازی اتریوم: هر zkVM که پیش‌کامپایل
ecPairingرا در آدرس0x08از طریق بررسی جفت‌سازی OpenVM شبیه‌سازی می‌کند، نتایج جعلی تولید خواهد کرد و این منجر به اجرای نادرست EVM برای رول‌آپ‌های L2، پل‌ها یا پروتکل‌های حریم خصوصی می‌شود.
اصلاح و مداخله انسانی
باید به این نکته اشاره کرد که zkao گزارش نهایی تولید نکرد، بلکه یک یافته کاندید و یک اثبات مفهوم (PoC) حداقلی ارائه داد. متخصصان انسانی تیم، یک تریاژ دستی سریع برای اعتبارسنجی مسئله، تأیید قابلیت بهره‌برداری و مدیریت افشای باگ انجام دادند. گزارش دقیق و PoC ارائه شده توسط zkao باعث شد این تریاژ بسیار سریع انجام شود.
اصلاحیه در کامیت a720e2c پیاده‌سازی و در نسخه OpenVM 1.6.0 عرضه شد. در این نسخه، یک تست عضویت (Membership Test) اضافه شد که تایید می‌کند ضرایب اندیس-فرد فاکتور مقیاس صفر هستند:
// the scaling factor is an honest hint only if it lies in the subfield Fp6
for i in [1, 3, 5] {
if s.c[i] != Fp2::ZERO {
return None;
}
}
با این اصلاح، فاکتور مقیاسی مانند $f^{-1}$ به‌درستی رد شده و امکان جعل حذف می‌شود. تمام شرکایی که بر پایه OpenVM می‌سازند، از آن زمان به نسخه ۱.۶.۰ ارتقا یافته‌اند.
درس‌های تریاژ AI
یکی از مهم‌ترین دستاوردهای این تجربه، شکست اعتبارسنجی خودکار PoC بود. تیم دریافت که درخواست از یک LLM برای تبدیل گزارش خود به یک PoC عملی، سیگنال ضعیفی است. مدل‌ها اغلب PoCهایی تولید می‌کردند که به دلیل موارد زیر «موفق» به نظر می‌رسیدند:
- استفاده از کامنت‌های بی‌معنی
- مفروضات پنهان
- توابع کمکی اصلاح‌شده (Patched helper functions)
- غیرفعال کردن بررسی‌های امنیتی
- ایجاد حالت‌های شبیه‌سازی شده (Mocked state)
- پرچم‌های اجرای مشکوک
این موضوع به‌طور مؤثر باعث می‌شد هر اکسپلوئی موفق به نظر برسد و اعتبارسنجی این PoCها زمان بیشتری نسبت به تریاژ گزارش اصلی می‌گرفت. این موضوع تأیید می‌کند که در حالی که AI می‌تواند کشف باگ‌های پیچیده رمزنگاری را به‌شدت شتاب دهد، مرحله تأیید (Verification) همچنان نیازمند نظارت دقیق انسانی است.
zkSecurity در حال حاضر در حال بهبود فرآیند تریاژ zkao است و سیستمی را پیاده‌سازی می‌کند که در آن AI از کاربرانی که باگ‌ها را تریاژ می‌کنند یاد بگیرد تا در طول زمان مثبت‌های کاذب (False Positives) را کاهش دهد. این بخشی از تلاش گسترده‌تر آن‌ها در مهندسی زمینه برای کدگذاری نحوه خواندن کد توسط متخصصان و مدیریت جریان اطلاعات بین عامل‌ها، بدون لبریز شدن پنجره‌های متنی است.
نتیجه‌گیری و گام‌های بعدی
پس از این کشف، zkSecurity در یک همکاری هدفمندتر با OpenVM برای انتشار نسخه ۲.۰ همکاری کرد که در آن zkao مسائل با اثر بالا (High-impact) بیشتری را شناسایی کرد. تیم به انتشار باگ‌های تأیید شده از پروژه‌های دیگر ادامه خواهد داد تا نقاط قوت و ضعف حسابرسی AI و ضرورت بازبینی انسانی را برجسته کند.
برای کسانی که zkVMها یا پروژه‌های رمزنگاری را مدیریت می‌کنند، پوشش مستمر AI از طریق zkao با هدف یافتن و رفع باگ‌های جدی پیش از عرضه طراحی شده است. برای ارتباط بیشتر می‌توانید به zksecurity.xyz/contact مراجعه کنید.
گفتگو