zkAPI پرداخت API را به یک قابلیت نشستِ مبتنی بر اثبات دانش صفر تبدیل می‌کند

بنیاد اتریوم و پروژه Open Anonymity، zkAPI را معرفی کرده‌اند؛ پروتکلی آزمایشی برای پرداخت هزینه APIهای مبتنی بر مصرف، بدون آشکار کردن هویت پرداخت‌کننده هر درخواست. این سامانه اکنون روی شبکه اصلی اتریوم فعال است و ابتدا برای استنتاج هوش مصنوعی ارائه شده، اما طراحی آن برای RPC، تولید تصویر، پهنای باند و دیگر خدمات قیمت‌گذاری‌شده بر اساس مصرف نیز قابل استفاده معرفی شده است.

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

پیاده‌سازی، مسیر پرداخت را از مسیر درخواست جدا می‌کند. کلاینت محلی، مجوز را به سرور zkAPI ثابت می‌کند و سرور یک کلید API کوتاه‌عمر با سقف مصرف صادر می‌کند. در حالت کلید اجرایی، دستگاه کاربر درخواست‌ها را مستقیماً به ارائه‌دهنده می‌فرستد. پس از پایان عمر کلید، اطلاعات مصرف امضاشده برای تسویه هزینه واقعی استفاده می‌شود، نه سقف رزروشده. مخزن پروژه از ترکیبی شامل Groth16 روی BN254، هش‌سازی Poseidon، تعهدات وابسته به یادداشت و درخت مرکل ۳۲سطحی مستند می‌کند.

نکته مهم‌تر برای توسعه‌دهندگان، همین جداسازی است، نه صرفاً دموی هوش مصنوعی. یک برنامه ICP که به سرویس خارجیِ مبتنی بر مصرف متصل می‌شود، در اصل می‌تواند «مجوز خرج‌کردن تا یک مقدار مشخص» را به‌صورت یک قابلیت نشستِ دارای اثبات مدل کند، به‌جای آن‌که هر درخواست را به یک حساب پایدار متصل کند. بااین‌حال، برنامه همچنان به وریفایر مناسب، سرویس تسویه و طراحی مدیریت کلید نیاز دارد؛ zkAPI یکپارچه‌سازی ICP ارائه نمی‌کند و این نتیجه‌گیری معماری است، نه قابلیت منتشرشده برای ICP.

یک مرز مهم حریم خصوصی وجود دارد. zkAPI پیوند میان پرداخت و مصرف را قطع می‌کند، اما خود درخواست را ناشناس نمی‌کند. ارائه‌دهنده همچنان می‌تواند promptها و پاسخ‌ها را ببیند، فراداده شبکه کاربر ممکن است قابل مشاهده بماند و زمان‌بندی یا محتوای تکراری می‌تواند نشست‌ها را به هم مرتبط کند. بنیاد اتریوم نیز ناشناس‌سازی شبکه و محرمانگی محتوا را دو لایه جداگانه توصیف می‌کند.

درس عملی برای توسعه‌دهندگان ICP این است که سه پرسش مستقل را مدل کنند: چه کسی مجاز به خرج‌کردن است، کدام سرویس payload را دریافت می‌کند، و چه کسی می‌تواند صورتحساب را تطبیق دهد. اثبات‌های دانش صفر می‌توانند پرسش اول و سوم را از دومی جدا کنند، اما فقط زمانی که کلید نشست، رسید مصرف، محافظت در برابر replay و مسیر بازیابی، همگی به‌عنوان وضعیت پروتکل طراحی شوند. این مرز معماری قابل انتقال است؛ اما استقرار فعلی zkAPI هنوز یک مؤلفه ICP نیست.