Title: Пояснення X402: нативні HTTP-мікроплатежі для ШІ-агентів

Специфікація X402 повторно використовує стандартний статус HTTP 402 Payment Required, щоб перетворити звичайний виклик API на ончейн-мікроплатіж. Тепер ШІ-агенти можуть самостійно оплачувати запити до LLM або потоки даних без участі людини, а постачальники послуг можуть стягувати плату за кожен запит, не розробляючи власну систему виставлення рахунків.

Чому ШІ-агентам потрібен платіжний протокол

Автономні агенти поєднують між собою мовні моделі, інструменти вебпошуку та пропрієтарні джерела даних. Кожне таке поєднання має свою ціну — плата за кожен токен моделі або плата за кожен виклик API ринкових даних. Сучасні бізнес-моделі покладаються на API-ключі, прив'язані до підписочних акаунтів, ручне поповнення кредитів або виставлення рахунків постфактум. Ці методи порушують принцип «без участі людини», закладений в автономних агентах, і створюють додаткові операційні витрати для постачальників.

X402 пропонує компромісний варіант: потік запит-відповідь, який виглядає як будь-який інший HTTP-виклик, але з вбудованим етапом оплати, що фіксується в публічному блокчейні. Єдина вимога полягає в тому, щоб клієнт міг підписати та транслювати транзакцію в тому блокчейні, який вказує сервер.

Детальний опис процесу узгодження (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) – навіть дешеві мережі стягують плату за газ; платежі менше $0.001 можуть бути економічно недоцільними.
  • Складність – агенти повинні вміти обробляти невдалі транзакції та реорганізації ланцюгів (chain reorganizations); надійна логіка повторних спроб є обов'язковою.
  • Безпека – nonce запобігає атакам повторного відтворення, але агентам все одно потрібно захищати приватні ключі та уникати їх повторного використання в непов'язаних сервісах.