ERC-8004: что это за стандарт и как он создаёт инфраструктуру доверия для AI-агентов

ERC-8004 - это предложение стандарта Ethereum для обнаружения AI-агентов, регистрации их идентичности и публикации сигналов репутации и проверки результатов. Его архитектура включает три блокчейн-реестра: Identity Registry, Reputation Registry и Validation Registry. Они позволяют приложениям находить агентов разных организаций и оценивать их на основании доступных данных.

Официальное название предложения - Trustless Agents. Под «trustless» здесь понимается возможность взаимодействовать без заранее установленного доверия к контрагенту. Насколько надёжен конкретный агент, приложение определяет через выбранную модель оценки: отзывы клиентов, независимые проверки или другие подтверждения.

По состоянию на 13 октября 2026 года на странице Ethereum Improvement Proposals ERC-8004 обозначен как Draft. Поэтому далее речь идёт о текущем проекте стандарта; интерфейсы могут измениться. В репозитории команды уже опубликованы реализации и адреса Identity Registry и Reputation Registry для ряда сетей, а раздел Validation Registry отмечен как находящийся в активной доработке. [1][2]

Зачем AI-агентам нужен ERC-8004

AI-агент может искать данные, вызывать инструменты, заказывать вычисления и передавать задачи другому агенту. Внутри одной компании доверие обычно обеспечивается инфраструктурой владельца: доступы выдаёт администратор, сервисы проходят внутреннюю проверку, а ответственность закрепляется договором.

В открытой среде этот механизм работает хуже. Агент, которому нужна внешняя аналитика, должен выбрать исполнителя, проверить его адрес сервиса, понять историю взаимодействий и определить, достаточно ли надёжен результат для конкретной задачи.

Доступный API показывает, что к сервису можно обратиться. Описание возможностей объясняет, что исполнитель обещает сделать. Для решения о сотрудничестве дополнительно нужны ответы: кто управляет этой идентичностью, какие отзывы заслуживают внимания и кто проверял выполненную работу.

ERC-8004 предлагает общий формат для этих данных. Идентичность связывает агента с реестром и регистрационным файлом. Репутация собирает обратную связь. Валидация позволяет фиксировать результаты внешних проверок. Прикладная система использует эти сведения, чтобы принять решение о взаимодействии. [1]

Как работает ERC-8004: архитектура трёх реестров

Блокчейн хранит идентификаторы, отдельные показатели и ссылки на дополнительные материалы. Сам агент, его модель, API и подробные результаты могут работать вне блокчейна. Такая архитектура позволяет использовать общие реестры, сохраняя свободу выбора среды выполнения. [1]

‍

Схема 1. От идентичности агента к решению о взаимодействии

flowchart TD
    I["Реестр идентификации"] -->|"agentURI"| F["Регистрационный JSON-файл"]
    F -->|"Адрес сервиса"| A["ИИ-агент вне блокчейна"]
    I -->|"Идентификатор"| P["Политика выбора агентов"]
    R["Реестр репутации"] -->|"Отзывы и показатели"| P
    V["Реестр проверок"] -->|"Результаты проверок"| P
    P -->|"Разрешить взаимодействие"| A
  

Политика выбора агента - компонент приложения, предложенный в этой схеме. ERC-8004 задаёт доступные сигналы, а продукт определяет критерии: каких авторов отзывов учитывать, какие проверки требовать и какие задачи разрешать.

Identity Registry: как устроена идентичность AI-агента

Identity Registry использует ERC-721 — стандарт невзаимозаменяемых токенов. При регистрации агенту присваивается agentId, соответствующий tokenId. Владелец токена управляет зарегистрированной идентичностью и может передать её другому адресу. [1]

Полная ссылка на агента состоит из двух частей:

• agentRegistry — пространство имён, идентификатор сети и адрес реестра;
• agentId — номер агента внутри этого реестра.

Для EVM-сети формат реестра выглядит как eip155:{chainId}:{identityRegistry}. Один номер agentId без сети и адреса контракта недостаточен: в разных реестрах могут существовать агенты с одинаковыми номерами. [1]

Использование ERC-721 даёт совместимость с инструментами для NFT и существующей моделью владения. Регистрация при этом подтверждает запись и управление ею; она не доказывает качество модели или достоверность заявленных возможностей.

Что находится в регистрационном файле

Поле agentURI указывает на JSON с описанием агента. Спецификация допускает HTTPS, IPFS и data: URI. Файл содержит название, описание, изображение, список сервисов и ссылки на регистрации. Среди сервисов могут быть MCP endpoint и A2A Agent Card. [1]

Ниже — учебный пример с демонстрационными адресами, а не конфигурация действующего сервиса:

flowchart TD
    I["Реестр идентификации"] -->|"agentURI"| F["Регистрационный JSON-файл"]
    F -->|"Адрес сервиса"| A["ИИ-агент вне блокчейна"]
    I -->|"Идентификатор"| P["Политика выбора агентов"]
    R["Реестр репутации"] -->|"Отзывы и показатели"| P
    V["Реестр проверок"] -->|"Результаты проверок"| P
    P -->|"Разрешить взаимодействие"| A
  

Обнаружив такую запись, клиент может получить адрес сервиса и затем проверить, подходит ли агент под его требования. Поля active и supportedTrust описывают опубликованную конфигурацию; для подтверждения доступности и заявленных механизмов приложению нужны дополнительные проверки.

Как агент связывается с кошельком

Спецификация отдельно управляет зарезервированным полем agentWallet — адресом получения платежей. При регистрации оно получает адрес владельца. Для назначения нового кошелька требуется подтверждение контроля: подпись EIP-712 для обычного адреса или проверка ERC-1271 для смарт-контрактного кошелька. [1]

При передаче токена agentWallet очищается, и новый владелец должен заново подтвердить нужный адрес. Это помогает избежать сохранения платёжного адреса предыдущего владельца после передачи идентичности. Сам порядок оплаты сервисов ERC-8004 не задаёт.

Reputation Registry: как формируется репутация AI-агентов

Reputation Registry стандартизирует публикацию обратной связи. Запись содержит числовой показатель, точность десятичного представления и может дополняться тегами, адресом сервиса, ссылкой на подробный файл и его хешем. [1]

Основные числовые поля:

• value — знаковое целое число типа int128;
• valueDecimals — количество десятичных разрядов от 0 до 18.

Например, value = 9977 и valueDecimals = 2 представляют число 99,77. Значение показателя определяется контекстом. С тегом uptime это может быть доступность в процентах; с тегом responseTime — задержка, для которой нужно согласовать единицу измерения. [1]

Это гибкий формат, но он требует дисциплины на уровне продукта. Чтобы сравнить двух агентов, приложение должно сопоставлять одинаковые метрики, единицы измерения и периоды наблюдения. Усреднение доступности, рейтинга и времени ответа не создаёт содержательной оценки.

Почему отзывы в блокчейне не гарантируют честный рейтинг

Спецификация запрещает владельцу агента и его одобренным операторам оставлять отзыв о собственной идентичности. Однако дополнительные адреса всё равно могут использоваться для накрутки. ERC-8004 прямо указывает на риск Sybil-атак, когда один участник создаёт множество адресов и изображает независимых клиентов. [1]

Поэтому в предлагаемой архитектуре рейтинг следует рассчитывать с учётом происхождения отзывов. Продукт может учитывать выбранных клиентов, подтверждённые взаимодействия, давность записи и релевантность метрики. Это прикладные способы оценки, которые команда должна реализовать отдельно.

Текущий интерфейс getSummary требует непустой список clientAddresses. Тем самым вызывающая сторона явно определяет, чьи отзывы участвуют в агрегировании. Запись платежа может дополнить контекст, но сам факт оплаты не доказывает независимость клиента или качество услуги. [1]

Validation Registry: как проверяются результаты работы агента

Validation Registry описывает интерфейс для фиксации запросов на проверку и ответов выбранного валидатора. В текущем проекте владелец или оператор агента вызывает validationRequest, передавая адрес валидатора, идентификатор агента, ссылку на материалы и хеш запроса. [1]

Назначенный валидатор публикует ответ через validationResponse. Значение response находится в диапазоне от 0 до 100. Его можно использовать как бинарный результат — например, 0 или 100 — либо как шкалу, смысл которой определяется конкретной системой проверки. Это значение само по себе не является вероятностью правильности результата. [1]

Схема 2. Запрос и фиксация независимой проверки

‍

Схема показывает модель из текущего проекта спецификации. Получение событий, загрузку материалов и сам алгоритм проверки обеспечивает инфраструктура валидатора.

Среди возможных подходов стандарт перечисляет повторное выполнение с экономическим обеспечением, zkML и TEE. Реестр предоставляет интерфейс для публикации результатов; правила вознаграждения, штрафов и обеспечения работы валидаторов находятся за его пределами. [1]

Для разработчика принципиально определить предмет проверки. Подтверждение выполнения определённого кода, проверка вычисления и оценка полезности ответа решают разные задачи. Даже корректно выполненная программа может использовать неподходящие исходные данные.

Раздел валидации продолжает изменяться. Перед интеграцией необходимо сверить проект стандарта, ABI и возможности выбранного развёрнутого контракта. [2]

Чем ERC-8004 отличается от MCP, A2A, x402 и ERC-4337

Эти технологии относятся к разным частям агентной инфраструктуры. Их можно объединить в одном продукте, но наличие одной из них не означает, что остальные уже реализованы.

Роли MCP и A2A описаны в мотивации ERC-8004. x402 использует HTTP 402 для сообщения платёжных требований и программной оплаты. ERC-4337 описывает обработку UserOperation, включая участие bundler и контракта EntryPoint. [1][3][4]

ERC-8004 и x402: выбор исполнителя и оплата сервиса

Возможная интеграция выглядит так: клиент находит агента, оценивает его историю, обращается к платному сервису и оплачивает запрос через x402. После выполнения клиент публикует отзыв и при необходимости добавляет информацию о платеже.

Это сценарий приложения, а не обязательная последовательность ERC-8004. Стандарт не требует x402 и не предусматривает автоматического escrow, возврата средств или разрешения споров. Такие механизмы нужно проектировать отдельно. [1][3]

ERC-8004 и ERC-4337: идентичность и исполнение операций

ERC-8004 позволяет связать сервис с зарегистрированной идентичностью. ERC-4337 предоставляет инфраструктуру для операций смарт-аккаунтов. Если агенту разрешено совершать транзакции, правила доступа, лимиты и подтверждения задаются логикой кошелька и приложения.

Само наличие ERC-4337 не устанавливает безопасный бюджет для агента. Команда должна отдельно определить разрешённые действия, ограничения и условия подтверждения. [4]

Пример архитектуры: AI-агент покупает аналитические данные

Представим продукт, в котором агент формирует отчёт о ликвидности и получает данные у внешнего поставщика. Это иллюстративный сценарий интеграции, не описание действующего проекта.

Клиент ищет исполнителей через каталог, получает ссылки на регистрации и проверяет адреса сервисов. Затем оценивает отзывы выбранных клиентов, допустимую давность данных и наличие нужных проверок. После выбора поставщика обращается к API; если ресурс платный, может использовать x402.

Результат проходит прикладные проверки: соответствует ли формат требованиям, актуальны ли данные и совпадает ли охват с заданием. Для более ответственной задачи продукт может добавить внешнего валидатора. Лишь после этого данные используются в отчёте.

Схема 3. Сигналы доверия в прикладном процессе

‍

В этой архитектуре каталог, оценка исполнителя и проверка по требованиям — компоненты продукта. ERC-8004 предоставляет стандартизированные записи, которые они используют. Оплата через x402 может сопровождать обращение к API и остаётся отдельным процессом.

Как внедрить ERC-8004 в продукт

Интеграцию стоит начинать с задачи доверия: кого приложение должно находить, по каким критериям выбирать и какие последствия имеет ошибка. Для каталога инструментов и агента, которому разрешены операции с активами, понадобятся разные требования.

1. Выбрать сеть и реализацию реестров. Проверить адреса, ABI, версию контрактов и права обновления. Статус Draft делает фиксацию конкретной версии особенно важной для воспроизводимой интеграции.

2. Зарегистрировать агента и опубликовать описание. Настроить agentURI, сервисные адреса и подтверждённый кошелёк, если он нужен. Предусмотреть доступность файла и управление изменениями.

3. Построить каталог и индексирование. Обрабатывать события регистрации, изменения URI, передачи владения и отзывов. Индексатор должен учитывать реорганизации блокчейна, повторную обработку событий и восстановление состояния.

4. Определить смысл репутационных метрик. Зафиксировать теги, единицы, периоды измерения и правила выбора авторов отзывов. Решить, как учитывать отзыв, который клиент отозвал.

5. Выбрать модель проверки результатов. Определить проверяемые свойства, валидаторов, время ожидания и поведение при отсутствии ответа. Нужный контракт и механизм проверки могут потребовать отдельной разработки.

6. Настроить доступы и наблюдаемость. Ограничить операции агента, отслеживать смену владельца и endpoint, фиксировать ошибки и стоимость обращений.

Этот порядок — инженерная рекомендация для интеграции. Стандарт определяет интерфейсы реестров; требования к эксплуатации и безопасности продукта остаются ответственностью команды.

Ограничения ERC-8004, которые нужно учитывать

Регистрация не подтверждает заявленные возможности. Агент может публиковать описание, которому его работа не соответствует. Спецификация прямо оговаривает этот предел. [1]

Хеш подтверждает целостность материала. Совпадение хеша показывает, что проверяется определённый набор данных. Для оценки достоверности содержимого нужен отдельный метод.

Репутация зависит от источников и контекста. Публичные отзывы могут быть накручены, а показатели без общего определения плохо сопоставимы. Нужно оценивать происхождение сигнала и его отношение к задаче. [1]

Внешние файлы и сервисы могут быть недоступны. Ссылка в блокчейне сохраняется, но HTTPS-сервер может перестать отвечать. Для IPFS нужно отдельно обеспечить хранение и доступность данных.

Владелец и конфигурация могут измениться. В предлагаемой модели продукта разумно учитывать смену владельца, модели или сервисного адреса при интерпретации старых отзывов.

Регистрация в нескольких сетях не создаёт автоматического общего рейтинга. Стандарт допускает несколько регистраций и работу агента в других сетях. Объединение записей и сигналов требует логики приложения. [1]

Эти ограничения определяют объём разработки: реестры дают общую основу, а надёжность взаимодействия зависит от того, как продукт проверяет и использует их данные.

Где ERC-8004 может быть полезен

Маркетплейсы AI-агентов. Единый формат идентичности и отзывов позволяет строить каталоги, сравнивать исполнителей по конкретным задачам и предоставлять историю взаимодействий.

Платные API и поставщики данных. Регистрационный файл может связывать сервис с идентичностью, а отзывы — отражать доступность, задержку или качество данных. x402 можно добавить как отдельный способ оплаты.

Мультиагентные системы. При обращении к исполнителям разных организаций общий слой записей помогает применять одинаковую политику выбора и проверки.

Агенты для работы с блокчейном. Публичные сигналы могут поддерживать выбор аналитических или исполнительных сервисов. Для операций с активами дополнительно нужны ограничения кошелька и контроль исполнения.

Это возможные продуктовые применения архитектуры, а не утверждение о доказанной эффективности стандарта в каждом сценарии.

Разработка инфраструктуры AI-агентов с ERC-8004

Ценность ERC-8004 для продукта — общий формат, который связывает идентичность исполнителя, историю обратной связи и результаты проверок. На этой основе можно строить каталоги и системы взаимодействия агентов с едиными правилами оценки.

Для внедрения нужны реестры или интеграция с существующими контрактами, индексатор, управление метаданными, политика репутации и подходящий механизм проверки. Если агент оплачивает ресурсы или совершает транзакции, к архитектуре добавляются платёжная инфраструктура и ограничения кошелька.

Источники

1. ERC-8004: Trustless Agents — официальная спецификация. Статус и интерфейсы проверены 13 октября 2026 года.
2. ERC-8004 Contracts — репозиторий команды. Реализации, опубликованные адреса и примечание о доработке Validation Registry.
3. x402 — официальная документация.
4. ERC-4337: Account Abstraction Using Alt Mempool — официальная спецификация.

‍