لایهٔ سازگاری از راه رسید: اتریوم برای zkVMها یک نقطهٔ شروع مشترک میسازد
استانداردهای zkVM نسخهٔ ۰ اتریوم یکی از گلوگاههای کمتر دیدهشده اما تعیینکنندهٔ فناوری ZK را هدف میگیرند: سازگاری میان برنامههای مهمان، موتورهای اثبات و کلاینتهای اجرا. پیشنهاد همراه EIP-8025 نیز نشان میدهد این سازگاری چگونه میتواند به اعتبارسنجی بدون حالتِ اثباتهای اجرا در لایهٔ اجماع منجر شود.

مهندسی دانش صفر اغلب به شکل رقابت میان سیستمهای اثبات روایت میشود. اما کار تازهٔ اتریوم نشان میدهد رقابت دیگری نیز به همان اندازه مهم است: آیا zkVMهای مختلف میتوانند به اندازهای از مرز نرمافزاری مشترک برسند که به زیرساختی قابلجایگزینی تبدیل شوند؟
تیم zkEVM اتریوم در ۱۶ فوریه، استانداردهای zkVM نسخهٔ ۰ را منتشر کرد؛ بستهای سهقسمتی برای سازگاری میان zkVMهای سازگار با RISC-V. این بسته RV64IM بههمراه افزونهٔ Zicclsm را بهعنوان مبنای مشترک مجموعهدستورها تعیین میکند، یک رابط C برای پیشکامپایلهای zkVM تعریف میکند و رابط C دیگری برای ورودیهای خصوصی و خروجیهای عمومی استاندارد میسازد.
هدف عملی، مرز میان برنامهٔ مهمان و ماشینی است که آن را اثبات میکند. تیمهای کلاینت اجرا باید بتوانند منطق فراخوانی پیشکامپایلها و ورودی/خروجی را یکبار بنویسند و سپس بدون بازنویسی گسترده، موتورهای مختلف zkVM را آزمایش کنند. البته فرمت باینری جهانشمول هنوز وجود ندارد: خود اعلامیه تصریح میکند که برنامههای مهمان همچنان برای هر zkVM به کامپایل و لینک مجدد نیاز دارند. قابلیت حمل فعلی در سطح منطق اجرا و رابطهاست، نه هنوز در سطح خروجی نهایی.
این تفاوت برای سازندگان مهم است. استانداردها میتوانند تکرار کاری در یکپارچهسازی را کاهش دهند، اما چیدمان حافظه، رفتار کامپایلر، هزینهٔ اثبات و فرضهای رمزنگاریِ مخصوص هر backend را حذف نمیکنند. انتخاب Zicclsm نیز یک مصالحه است: دسترسیهای نامتراز به حافظه درست باقی میمانند، اما ممکن است کندتر باشند. بنابراین در محیط اثبات، یک سازوکار سازگاری کوچک میتواند به متغیری عملکردی تبدیل شود که باید اندازهگیری شود، نه اینکه نادیده گرفته شود.
نیمهٔ دوم ماجرا EIP-8025 است؛ پیشنهادی در وضعیت پیشنویس برای اثباتهای اختیاری اجرا. این پیشنهاد مسیری برای آگاهی کلاینت اجماع از اثبات ایجاد میکند: یک proof node خارجی برای payload اجرا اثبات میسازد، کلاینت اجماع از طریق proof engine با آن ارتباط میگیرد و همتاها اثباتهای امضاشده را از طریق موضوع gossip جدیدی به نام execution_proof تبادل میکنند. اعتبارسنج میتواند اثبات را بدون در اختیار داشتن کل وضعیت لایهٔ اجرا بررسی کند و در نتیجه، هزینهٔ بررسی payload بالقوه از gas limit و اندازهٔ وضعیت مستقل شود.
این پیشنهاد عمداً محتاطانه است. EIP-8025 اختیاری است، قوانین اعتبار اجماع را تغییر نمیدهد و اثبات معتبر را در کنار اجرای دوبارهٔ payload بهعنوان سیگنال اضافی در نظر میگیرد. اثباتها همچنین با سقف پیشنهادی ۴۰۰ کیلوبایت محدود میشوند و برای هر payload حداکثر چهار نوع اثبات در نظر گرفته شده است؛ یعنی سقف نظری ترافیک در حال پرواز ۱٫۶ مگابایت در هر slot خواهد بود. این پارامترها، پیشنهاد را به آزمایشی عملیاتی برای سنجش تأخیر اثبات، پهنای باند، توان verifier و تنوع prover تبدیل میکنند، نه جایگزینی نهایی برای اجرا.
استانداردها و EIP در کنار هم یک لایهٔ تازهٔ زیرساخت ZK را نشان میدهند. استانداردهای نسخهٔ ۰ سمت برنامهٔ مهمان را کمتر اختصاصی میکنند؛ EIP-8025 نیز سمت شبکه را بدون حیاتیکردن فوری اثباتها برای اجماع، آمادهٔ دریافت آنها میکند. اگر آزمایش موفق باشد، رقابت zkVMها ممکن است از جذب یکپارچهسازیهای سفارشی به سمت اقتصاد اثبات، پایداری، قابلیت ممیزی و سازگاری backendها حرکت کند.
اما این محدودیت اساسی است: بستهٔ سازگاری نسخهٔ ۰ است و قرار است تغییر کند، و EIP-8025 نیز هنوز پیشنویس است. نقشهٔ راه حریم خصوصی اتریوم هم زمانبندیها را هدف میداند، نه تضمین. فرصت نزدیک برای توسعهدهندگان، آزمایش است: رابطهای مشترک را پیادهسازی کنند، موارد شکست را اندازه بگیرند و هر نتیجهٔ عملکردی یا امنیتی را دادهای برای نسخهٔ بعد بدانند، نه وعدهای که نشان دهد پشتهٔ ZK اتریوم همین حالا نهایی شده است.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.


