Разбор X402: нативные HTTP-микроплатежи для ИИ-агентов

Спецификация X402 повторно использует стандартный статус HTTP 402 Payment Required, чтобы превратить обычный API-вызов в микроплатеж в блокчейне (on-chain). Теперь ИИ-агенты могут самостоятельно оплачивать запросы к LLM или потоки данных без участия человека, а провайдеры могут взимать плату за каждый запрос, не создавая при этом кастомную систему выставления счетов.

Почему ИИ-агентам нужен протокол оплаты

Автономные агенты объединяют языковые модели, инструменты веб-поиска и проприетарные источники данных. Каждое такое звено стоит денег: это может быть оплата за каждый токен модели или плата за каждый вызов API рыночных данных. Современные бизнес-модели опираются на API-ключи, привязанные к подписным аккаунтам, ручное пополнение баланса или постоплатную систему биллинга. Эти методы нарушают принцип «без участия человека», заложенный в автономных агентах, и создают операционные издержки для провайдеров.

X402 предлагает компромисс: цикл «запрос-ответ», который выглядит как любой другой HTTP-вызов, но со встроенным этапом оплаты, фиксируемым в публичном блокчейне. Единственное требование — клиент должен иметь возможность подписать и отправить транзакцию в той сети, которую укажет сервер.

Подробное описание процесса (handshake) X402

  1. Первичный запрос — агент отправляет обычный GET или POST на платный эндпоинт. Специальные заголовки не требуются.
  2. Сервер отвечает статусом 402 — ответ содержит статус 402 и JSON-тело со списком следующих полей:
    • amount — ожидаемая сумма оплаты в минимальной единице токена;
    • token — адрес контракта ERC-20 (или эквивалентного);
    • chain — идентификатор блокчейна, в котором должна быть зафиксирована оплата;
    • необязательный nonce — уникальное значение для защиты от атак повторного воспроизведения (replay attacks).
  3. Клиент подготавливает платеж — агент проверяет адрес токена и сеть на соответствие своей политике (например, разрешены только доверенные сети). Затем он создает транзакцию для перевода необходимой суммы на указанный сервером адрес, подписывает её своим закрытым ключом и отправляет в сеть.
  4. Отправка хеша платежа — как только хеш транзакции становится доступен, клиент повторяет исходный запрос, на этот раз добавляя заголовок X-Payment, содержащий этот хеш. Полезная нагрузка (payload) остается неизменной.
  5. Сервер проверяет транзакцию в блокчейне — сервер ищет в блокчейне подтвержденный перевод, соответствующий сумме, токену, сети и nonce. Если совпадение найдено, он возвращает запрашиваемые данные со статусом 200 OK.

Любая библиотека HTTP-клиента, поддерживающая пользовательские заголовки и способная вызывать SDK блокчейна, может выполнить эти шаги. Новый транспортный протокол или кастомный сокетный слой не требуются.

Особенности, которые следует учитывать

  • Задержка (Latency) — подтверждение в публичном блокчейне требует времени.
  • Затраты на газ — даже в дешевых сетях требуется оплата газа; платежи менее $0.001 могут быть экономически невыгодными.
  • Сложность — агенты должны уметь обрабатывать неудачные транзакции и реорганизации цепочек (chain reorganizations); наличие надежной логики повторных попыток (retry logic) обязательно.
  • Безопасность — nonce защищает от атак повторного воспроизведения, но агентам всё равно необходимо обеспечивать сохранность закрытых ключей и избегать их использования в несвязанных сервисах.