توضیح‌نامه‌ی ۰۳

راستی‌آزمایی روی زنجیره: ۲۵۶ بایت و یک جفت‌سازی چه می‌خرند

معما

قرارداد هوشمندی که آرای ما را می‌پذیرد روی راریمو L2 زندگی می‌کند. باید در یک تراکنش واحد تصمیم بگیرد آیا یک کاربر:

• یک گذرنامه‌ی ایرانی یا INID واقعی دارد،
• قبلن به این پیشنهاد رای نداده،
• به‌اندازه‌ی کافی سن دارد و شهروند ایران است،

…همه‌ی این‌ها بدون این‌که هرگز سند را ببیند.

رویکرد ساده‌انگارانه — بازمحاسبه‌ی کل بررسی امضای گذرنامه درون قرارداد هوشمند — ناممکن است. این کار نیاز به اجرای میلیون‌ها عمل حسابی روی زنجیره دارد، با هزینه‌ی صدها دلار به ازای هر رای.

به‌جای آن، قرارداد یک بررسی کوچک انجام می‌دهد که جایگزین کل محاسبه می‌شود. آن بررسی کوچک همان چیزی است که هویت ZK را عملی می‌کند.

کاربر چه چیزی آپلود می‌کند

تلفن کار سنگین را انجام می‌دهد. سه چیز تولید می‌کند:

این تمام چیزی است که زنجیره از کاربر می‌بیند. نه نام، نه شماره‌ی گذرنامه، نه امضا. فقط یک اثبات + یک فهرست با اندازه‌ی ثابت از اعداد + یک برچسب.

قرارداد چه می‌کند — در پنج خط

function verify(circuitID, proof, publicSignals) {
    VerifyingKey vk = circuitRegistry[circuitID];     // lookup
    require(publicSignals.icaoRoot == currentRoot);   // sanity check
    require(!nullifierUsed[publicSignals.nullifier]); // anti-replay
    require(groth16Verify(vk, proof, publicSignals)); // THE math step
    nullifierUsed[publicSignals.nullifier] = true;
}

همه چیز بایگانی است جز خط چهارم. آن خط چهارم همان دلیلی است که هر چیزی در این سیستم کار می‌کند.

خط چهارم: groth16Verify واقعن چه می‌کند

یک اثبات Groth16 از سه نقطه‌ی منحنی بیضوی تشکیل شده:

• A روی منحنی G1 (~ ۶۴ بایت)
• B روی منحنی G2 (~ ۱۲۸ بایت)
• C روی منحنی G1 (~ ۶۴ بایت)

کلید راستی‌آزمایی (یک‌بار به ازای هر مدار متعهد می‌شود) به قرارداد می‌دهد:

• دو نقطه‌ی ثابت α و β
• یک نقطه‌ی ثابت γ
• یک نقطه‌ی ثابت δ
• یک نقطه به ازای هر سیگنال عمومی، با نام IC₀، IC₁، …

قرارداد یک ترکیب خطی روی سیگنال‌های عمومی محاسبه می‌کند:

ICₚ = IC₀ + s₁·IC₁ + s₂·IC₂ + … + sₙ·ICₙ

…و سپس یک معادله‌ی واحد را بررسی می‌کند که شامل یک جفت‌سازی است — یک عمل خاص روی نقاط منحنی بیضوی که با e(·, ·) نوشته می‌شود:

e(A, B) == e(α, β) · e(ICₚ, γ) · e(C, δ)

اگر این معادله برقرار باشد، اثبات معتبر است. اگر نباشد، نیست. هیچ حالت میانی نیست، و هیچ چیز دیگری برای بررسی نیست.

این تک‌معادله از نظر ریاضی معادل با راستی‌آزمایی هر ضرب و جمع است که اثبات‌گر ادعا کرده انجام داده. نسبت فشرده‌سازی شگفت‌انگیز است: میلیون‌ها قید روی سمت اثبات‌گر در یک بررسی جفت‌سازی روی سمت راستی‌آزما فرومی‌ریزد. این قلب «succinct» در zk-SNARK است.

چرا EVM می‌تواند این را در میلی‌ثانیه انجام دهد

زنجیره‌های سازگار با اتریوم یک نشانی ویژه — 0x08 — دارند که عمل جفت‌سازی BN254 را در کد بومی انجام می‌دهد، نه در EVM تفسیری. این یک قرارداد precompiled نامیده می‌شود. فراخوانی آن مقدار ثابتی gas می‌خواهد (~ ۱۲۰k برای جفت‌سازی + ~ ۶k به ازای هر سیگنال عمومی). روی راریمو L2 با ~ ۰٫۰۰۱ دلار به ازای هر تراکنش، این به‌خوبی زیر یک سنت به ازای هر راستی‌آزمایی است.

بدون precompile، راستی‌آزمایی ZK روی زنجیره از نظر اقتصادی شدنی نبود. راریمو L2، مانند اتریوم و هر L2 مهم، این را دارد. این همان عنصر اولیه‌ای است که میکسرهای سبک tornado، رول‌آپ‌های Aztec و زنجیره‌های zk-EVM را قدرت می‌دهد؛ ما در حال استفاده‌ی دوباره از دهه‌ها مهندسی رمزنگاری هستیم، نه اختراع آن.

عدم‌تقارن: اثبات‌گر در مقابل راستی‌آزما

اعداد زیر برای مدار ثبت‌نام ما (~ ۵ میلیون قید) معمول‌اند:

این عدم‌تقارن کل هدف است. تلفن کاری متناسب با مدار انجام می‌دهد (میلیون‌ها عمل)؛ زنجیره کاری با زمان ثابت بدون توجه به پیچیدگی مدار. یک بررسی گذرنامه با ۵ میلیون قید و یک بررسی با ۵ میلیارد قید، هر دو در حدود همان ۳ میلی‌ثانیه راستی‌آزمایی می‌شوند.

چرا به ثبت مدار نیاز داریم

یک کلید راستی‌آزمایی Groth16 فقط برای دقیقن یک مدار کار می‌کند. اسناد و الگوریتم‌های امضای مختلف به مدارهای مختلف نیاز دارند:

هر شناسه‌ی مدار به یک کلید راستی‌آزمایی متمایز نگاشت می‌شود. sso-svc ما یک ثبت از این کلیدها نگه می‌دارد؛ کیف پول به سرویس می‌گوید از کدام مدار استفاده کرده، و سرویس کلید درست را انتخاب می‌کند. افزودن یک کلاس سند جدید یک تغییر پیکربندی است، نه تغییر کد.

سیگنال‌های عمومی چه چیزی را افشا می‌کنند — و چه نمی‌کنند

قرارداد سیگنال‌های عمومی را به‌عنوان اعداد با موقعیت ثابت می‌خواند. برای مدار query INID اینها ۲۳ مقدارند؛ برای مدار گذرنامه، ۲۴. نگاشت مشخص برای یک ثبت‌نام INID:

هیچ فیلدی برای نام، شماره‌ی سند، هش عکس، تاریخ تولد یا تاریخ انقضا وجود ندارد. آن مقادیر در اثبات شرکت می‌کنند اما از سوی مدار مصرف می‌شوند — هرگز در سیگنال‌های عمومی یا روی زنجیره ظاهر نمی‌شوند. اثبات‌های دانش‌صفر را ببینید برای این‌که چرا این یک تضمین ریاضی است، نه یک خط‌مشی.

Nullifierها: قرارداد چگونه «یک رای به ازای هر شخص» را اعمال می‌کند

یک nullifier قطعی است: همان راز + همان event_id همیشه همان nullifier را تولید می‌کند. اما همچنین یک‌طرفه است: با داشتن nullifier، هیچ‌کس نمی‌تواند راز را بازیابی کند یا آن را به هویت کاربر پیوند بزند.

قرارداد به‌سادگی هر nullifier را که دیده ثبت می‌کند. یک اثبات دوم از همان شخص روی همان پیشنهاد همان nullifier را تولید می‌کند؛ قرارداد آن را رد می‌کند.

در رویدادهای مختلف، همان شخص nullifierهای متفاوت تولید می‌کند — طراحانه. این همان چیزی است که سیستم را بین رویدادها ناشناس می‌کند: هیچ‌کس نمی‌تواند رای شما به پیشنهاد #۴۲ را به رای شما به پیشنهاد #۴۳ پیوند بزند، با وجود این‌که هر دو معتبرند.

چه چیزی هنوز می‌تواند روی زنجیره خراب شود

فهرست صادقانه:

هیچ‌کدام از این‌ها شکست رمزنگارانهی خود اثبات نیست. همه خطرات عملیاتی اجرای قرارداد هستند، و با فرایند و حاکمیت قابل رفع‌اند — که موضوع M6 است.

واژه‌نامه

بعدی

زنجیره‌ی اعتماد گذرنامه — داده‌ی موجود در اثبات واقعن از کجا می‌آید، چرا به آن اعتماد می‌کنیم، و در برابر چه چیزی نمی‌توانیم محافظت کنیم اگر کلید صادرکننده به خطر بیفتد.