ABI گمشده ZK؛ چرا فرادادهٔ اثبات به زیرساخت تبدیل می‌شود

سامانه‌های دانش صفر در اثبات یک محاسبه توانمندند، اما نرم‌افزار هنوز باید بداند آن اثبات دقیقاً چه معنایی دارد: کدام مدار آن را ساخته است؟ کدام ورودی‌های عمومی آشکارند؟ کدام کلید راستی‌آزمایی باید دریافت شود؟ و اگر مدار تغییر کند چه اتفاقی می‌افتد؟

ERC-8084، که هنوز یک استاندارد پیشنهادی اتریوم است، این خلأ یکپارچه‌سازی را با رابطی برای فراداده به نام ZKMeta هدف می‌گیرد. فیلدهای پیشنهادی آن شناسهٔ سامانهٔ اثبات، شناسهٔ مدار، نسخهٔ مدار، هش و URI طرح ورودی‌های عمومی، و URI کلید راستی‌آزمایی را آشکار می‌کنند. این پیشنهاد عمداً مستقل از قالب است: برای سامانه‌هایی مانند Groth16، Plonk، Halo2، STARK و zkVM شناسه‌هایی ارائه می‌کند، اما ریاضیات تولید اثبات را استاندارد نمی‌کند.

این تمایز مهم است. همان‌طور که ABI به ابزارها می‌گوید فراخوانی قرارداد را چگونه تفسیر کنند، ZKMeta می‌خواهد توصیفی مشترک از رابط اثبات در اختیار کیف‌پول‌ها، کاوشگرها، relayerها، بازارهای تولید اثبات و ابزارهای امنیتی بگذارد. کاوشگر می‌تواند با استفاده از schema سیگنال‌های عمومی معنادار را به‌جای بایت خام نمایش دهد. بازار تولید اثبات می‌تواند مصنوعات مدار موردنیاز را کشف کند. ابزار امنیتی نیز می‌تواند نسخهٔ مدار را زیر نظر بگیرد و تغییرات غیرمنتظره را علامت‌گذاری کند.

این پیشنهاد یکپارچگی را بخشی از فرایند کشف می‌داند. ابزارها باید هش بازگردانده‌شده از قرارداد را با schema دریافت‌شده مقایسه کنند. همچنین استفاده از ذخیره‌سازی content-addressed، یا لینک‌های HTTPS دارای هش محتوا برای schema و کلیدهای راستی‌آزمایی توصیه می‌شود. افزون بر این، رویداد CircuitMetadataUpdated باید هم‌زمان با قابل مشاهده‌شدن فرادادهٔ جدید منتشر شود تا احتمال race condition در indexerها کاهش یابد.

نشانه‌ای جدیدتر از پیش‌نویس اینترنتی مستقل «قرارداد راستی‌آزمایی خارجی برای تصمیم‌های مجوزدهی عامل‌ها» می‌آید که در ۲۱ ژوئیهٔ ۲۰۲۶ منتشر شده است. طراحی EVC استاندارد ZK نیست، اما اجازه می‌دهد اثبات‌های دانش صفر درون مرزی مستقل از نوع سامانهٔ راستی‌آزمایی قرار گیرند. میزبان یک بستهٔ اثبات مبهم را به راستی‌آزمایی‌کنندهٔ خارجی می‌فرستد و نتیجه‌ای محدود و مشخص، یعنی اجازه یا رد، دریافت می‌کند. timeout، خروجی malformed و راستی‌آزمایی ناموفق نیز در مدل fail-closed مدیریت می‌شوند.

این دو سند در کنار هم یک تفکیک معماری مفید را پیشنهاد می‌کنند: ZKMeta توضیح می‌دهد اثبات چیست و EVC توضیح می‌دهد یک سامانه چگونه نتیجهٔ راستی‌آزمایی را ایمن مصرف کند. این برداشت، استنباطی از دو پیشنهاد است و رابطه‌ای رسمی میان آن‌ها محسوب نمی‌شود. بااین‌حال، جهت مشترک روشن است: پذیرش ZK بیش‌ازپیش به رابط‌های عملیاتی پیرامون رمزنگاری وابسته می‌شود؛ از schema و نسخه‌بندی تا یکپارچگی کلید، رویدادها و رفتار هنگام خطا.

این caveat مهم است: ERC-8084 هنوز draft است و EVC نیز یک Internet-Draft مستقل و اطلاعاتی است، نه استاندارد پذیرفته‌شدهٔ IETF. بنابراین هیچ‌کدام تضمین سازگاری نیستند. درس فوری برای سازندگان ساده‌تر است: فرادادهٔ اثبات را صریح کنید، داده‌ای را که نرم‌افزار دریافت می‌کند هش کنید، تغییرات قیود را نسخه‌بندی کنید و راستی‌آزمایی‌کننده را طوری طراحی کنید که وقتی فرادادهٔ پیرامونی قابل اعتماد نیست، به‌شکل ایمن متوقف شود.