تبیین X402: ریزپرداخت‌های بومی HTTP برای عامل‌های هوش مصنوعی

مشخصات X402 از وضعیت استاندارد HTTP 402 Payment Required برای تبدیل یک فراخوانی API معمولی به یک ریزپرداخت درون‌زنجیره‌ای (on-chain) استفاده می‌کند. اکنون عامل‌های هوش مصنوعی می‌توانند هزینه‌های مربوط به پرس‌وجوهای LLM یا فیدهای داده را بدون دخالت انسان تسویه کنند، و ارائه‌دهندگان نیز می‌توانند بدون نیاز به ساخت یک سیستم صدور فاکتور اختصاصی، به ازای هر درخواست هزینه دریافت کنند.

چرا عامل‌های هوش مصنوعی به یک پروتکل پرداخت نیاز دارند

عامل‌های خودمختار، مدل‌های زبانی، ابزارهای جستجوی وب و منابع داده اختصاصی را به هم متصل می‌کنند. هر اتصال هزینه‌ای دارد؛ از هزینه‌های مبتنی بر توکن برای یک مدل گرفته تا هزینه‌های مبتنی بر هر فراخوانی برای یک API داده‌های بازار. مدل‌های کسب‌وکار امروزی بر کلیدهای API متصل به حساب‌های اشتراکی، شارژ دستی اعتبار یا صورت‌حساب‌های پس از انجام کار متکی هستند. این روش‌ها وعده‌ی «بدون نیاز به انسان» در عامل‌های خودمختار را نقض کرده و بار عملیاتی اضافی را به ارائه‌دهندگان تحمیل می‌کنند.

X402 یک راه حل میانی ارائه می‌دهد: یک جریان درخواست-پاسخ که شبیه به هر فراخوانی HTTP دیگری است، اما با یک مرحله پرداخت داخلی که در یک بلاک‌چین عمومی ثبت می‌شود. تنها شرط این است که کلاینت بتواند یک تراکنش را در زنجیره‌ای که سرور مشخص کرده است، امضا و منتشر (broadcast) کند.

جزئیات فرآیند دست‌دادن (handshake) در X402

  1. درخواست اولیه – عامل یک درخواست معمولی GET یا POST به یک نقطه پایانی (endpoint) پولی ارسال می‌کند. به هدرهای خاصی نیاز نیست.
  2. پاسخ سرور با کد 402 – پاسخ شامل وضعیت 402 و یک بدنه JSON است که موارد زیر را فهرست می‌کند:
    • amount – هزینه‌ای که سرور انتظار دارد، به کوچک‌ترین واحد توکن؛
    • token – آدرس قرارداد ERC-20 (یا معادل آن)؛
    • chain – شناسه بلاک‌چینی که پرداخت باید در آن ثبت شود؛
    • nonce اختیاری – یک مقدار منحصربه‌فرد که از حملات بازپخش (replay attacks) جلوگیری می‌کند.
  3. آماده‌سازی پرداخت توسط کلاینت – عامل، آدرس توکن و زنجیره را با سیاست‌های خود (مثلاً فقط زنجیره‌های مورد اعتماد) تطبیق می‌دهد. سپس تراکنشی ایجاد می‌کند که مبلغ مورد نیاز را به آدرس ارائه‌شده توسط سرور منتقل می‌کند، آن را با کلید خصوصی خود امضا کرده و منتشر می‌کند.
  4. ارسال هش پرداخت – زمانی که هش تراکنش در دسترس قرار گرفت، کلاینت درخواست اصلی را تکرار می‌کند، اما این بار یک هدر X-Payment شامل آن هش را اضافه می‌کند. محتوای اصلی (payload) بدون تغییر باقی می‌ماند.
  5. تأیید درون‌زنجیره‌ای توسط سرور – سرور در بلاک‌چین به دنبال یک انتقال تأییدشده می‌گردد که با مبلغ، توکن، زنجیره و nonce مطابقت داشته باشد. اگر تطابق پیدا کرد، داده‌های درخواستی را با وضعیت 200 OK بازمی‌گرداند.

هر کتابخانه کلاینت HTTP که از هدرهای سفارشی پشتیبانی کند و بتواند یک SDK بلاک‌چین را فراخوانی کند، می‌تواند این مراحل را انجام دهد. به هیچ پروتکل انتقال جدید یا لایه سوکت سفارشی نیاز نیست.

ملاحظات و سبک‌سنگین کردن‌ها

  • تأخیر (Latency) – تأیید در زنجیره‌های عمومی باعث ایجاد تأخیر می‌شود.
  • هزینه‌های گاز (Gas costs) – حتی زنجیره‌های ارزان نیز کارمزد گاز دریافت می‌کنند؛ پرداخت‌های زیر ۰.۰۰۱ دلار ممکن است مقرون‌به‌صرفه نباشند.
  • پیچیدگی – عامل‌ها باید تراکنش‌های ناموفق و بازسازماندهی‌های زنجیره (chain reorganizations) را مدیریت کنند؛ داشتن منطق تلاش مجدد (retry logic) قدرتمند الزامی است.
  • امنیت – مقدار nonce از حملات بازپخش جلوگیری می‌کند، اما عامل‌ها همچنان باید از کلیدهای خصوصی خود محافظت کنند و از استفاده مجدد از آن‌ها در سرویس‌های غیرمرتبط خودداری نمایند.