وقتی اتریوم لایهٔ راستی‌آزمایی را جذب می‌کند: چرخش زیرساخت ZK در Aligned

تصمیم زیرساختی

Aligned در ۲۱ ژوئیهٔ ۲۰۲۶ اعلام کرد که لایهٔ Proof Verification خود را کنار می‌گذارد و دیگر وظیفه‌ای به آن ارسال نمی‌کند. این شرکت کاربران را به Proof Aggregation Service هدایت می‌کند؛ سرویسی که به گفتهٔ Aligned، امنیتی هم‌سطح اتریوم را به ارث می‌برد.

این تصمیم دربارهٔ یک آزمایش کوچک نیست. Aligned می‌گوید این لایه در طول عمر خود بیش از ۱۳۶ هزار اثبات را راستی‌آزمایی کرده، ۵۹ اپراتور داشته، از سیستم‌هایی مانند Groth16، Plonk، SP1، RISC Zero و Circom پشتیبانی کرده و در زمان راه‌اندازی به حدود ۲۱۰۰ گس برای هر اثبات رسیده است.

چرا مزیت لایهٔ میانی کاهش یافت؟

Aligned سه تغییر را عامل این تصمیم می‌داند: سیستم‌های تولید و تجمیع اثبات بهتر شده‌اند و نیاز به راستی‌آزمایی ارزان در یک لایهٔ مستقل کمتر شده است؛ نقشهٔ راه اتریوم به سمت پشتیبانی بومی از ZK حرکت می‌کند؛ و بر اساس روایت Aligned از تقاضای مشتریان، توسعه‌دهندگان امنیت اتریوم را به تأخیر بسیار پایین ترجیح داده‌اند.

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

تجمیع می‌تواند تعداد اثبات‌هایی را که باید به اتریوم برسند کاهش دهد و در عین حال لنگر تسویهٔ قدرتمندتری حفظ کند. اما ممکن است دربارهٔ دسته‌بندی، تأخیر، بازیابی خطا و دسترس‌پذیری سرویس، ملاحظات تازه‌ای ایجاد کند. بنابراین توسعه‌دهندگان باید تجمیع را یک مرز معماری بدانند، نه جایگزینی کاملاً یکسان که عملکرد و فرض‌های اعتماد آن خودبه‌خود برابر باشد.

اثر نقشهٔ راه اتریوم

نقشهٔ راه فعلی حریم خصوصی اتریوم، اثبات‌های اختیاری اجرای تراکنش و درخت‌های Verkle را به‌عنوان اهداف ارتقای Hegotá معرفی می‌کند و اثبات‌های اجرای مبتنی بر zkVM را بخشی از مسیر راستی‌آزمایی ارزان‌تر و محاسبات خصوصی می‌داند. این جهت‌گیری برای ارائه‌دهندگان میان‌افزار یک پیام راهبردی دارد: زیرساختی که مسیر اثبات بومی اتریوم را تکمیل کند، احتمالاً آیندهٔ پایدارتری از زیرساختی دارد که فقط هزینه‌های فعلی را جبران می‌کند.

با این حال، اهداف نقشهٔ راه اتریوم هنوز قطعی نیستند و ممکن است در نتیجهٔ حاکمیت یا پژوهش تغییر کنند. این عدم قطعیت هنگام انتخاب وابستگی‌های چندساله برای تولید یا راستی‌آزمایی اثبات اهمیت دارد.

یک ممیزی عملی برای تیم‌های ZK

پیش از استفاده از یک سرویس راستی‌آزمایی، تیم‌ها باید چهار فرض را ثبت کنند: نتیجه در نهایت توسط کدام زنجیره امن می‌شود، اثبات‌ها به‌صورت جداگانه بررسی می‌شوند یا تجمیع می‌شوند، در زمان قطعی سرویس چه رخ می‌دهد و کدام تضمین‌های تأخیر قراردادی هستند، نه صرفاً ادعاهای عملکردی. چرخش Aligned یادآوری می‌کند که خود لایهٔ راستی‌آزمایی نیز می‌تواند تغییر کند.

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