С развертыванием стандарта ERC-8004 (Trustless Agents) в основной сети Ethereum управление идентификацией и репутацией AI Agent вступило в новую, верифицируемую и доверительную фазу. Этот стандарт предоставляет агентам проверяемую в блокчейне «систему идентификации» через три основных реестра: реестр идентификации, реестр репутации и реестр проверки. В этой статье, с точки зрения аудита безопасности и с учетом технических деталей ERC-8004, анализируются ключевые моменты риска для каждого реестра, предоставляя практическое руководство по аудиту для разработчиков и аудиторов.
Технические детали и ключевые моменты аудита
Ключевым моментом ERC-8004 являются его три реестра (Registry):
1. Реестр идентификации (Identity Registry)
Минимальный ончейн-идентификатор на основе ERC-721 с расширением URIStorage, который разрешается в регистрационный файл агента, предоставляя каждому агенту переносимый, устойчивый к цензуре идентификатор.
В архитектуре ERC-8004 реестр идентификации построен на основе ERC-721 и расширяет функциональность URIStorage. Другими словами, каждый агент в блокчейне соответствует уникальному NFT, который называется AgentID.
Когда разработчик создает агента, он вызывает функцию register контракта реестра, чтобы отчеканить новый AgentID. Этот токен привязывает tokenURI, указывающий на JSON-файл, хранящийся вне блокчейна — так называемый «регистрационный файл агента». Регистрационный файл должен строго соответствовать спецификации и обычно включает три типа основного содержимого:
- Основная информация, например, название, описание, URL аватара;
- Конечные точки сервиса, то есть сетевые адреса, по которым можно получить доступ к агенту, поддерживающие различные протоколы, такие как HTTP, WebSocket, Libp2p, A2A, MCP;
- Заявления о возможностях, то есть список задач, которые агент может выполнять, например, генерация изображений, арбитражные сделки или аудит кода.
Одних только самозаявлений явно недостаточно для установления доверия, поэтому ERC-8004 вводит механизм проверки домена. Агент должен разместить подписанный файл на заявленном домене по пути /.well-known/agent-card.json. Ончейн-реестр проверяет эту ссылку, тем самым привязывая ончейн AgentID к соответствующему DNS-домену. Значение этого шага заключается в предотвращении фишинговых атак и атак под чужим именем; агент не может произвольно заявлять, что он принадлежит определенному домену, он должен криптографической подписью доказывать право контроля.
Ключевые моменты аудита:
● Проверить контроль доступа к функции setTokenURI, убедиться, что обновление URI разрешено только владельцу агента или авторизованной роли (например, onlyOwnerAfterMint).
● Проверить, поддерживает ли URI неизменяемые схемы хранения (например, IPFS, Arweave). Если используются централизованные HTTP-ссылки, необходимо оценить безопасность контроля над доменом для предотвращения захвата DNS.
● Проверить корректность формата URI, избегая исключений в контракте из-за нулевых указателей или недействительных URI.
● Убедиться, что контракт строго выполняет проверку криптографической подписи (например, EIP-712) при проверке подписи домена, чтобы предотвратить подделку подписи или атаки повторного воспроизведения.
● Проверить механизм истечения срока действия доказательства владения доменом, чтобы предотвратить повторное использование долгосрочно действительных подписей.
● Убедиться, что процесс разрешения домена не зависит от централизованного оракула, избегая единой точки отказа или манипуляций.
2. Реестр репутации (Reputation Registry)
Стандартный интерфейс для публикации и получения сигналов обратной связи. Оценка и агрегация происходят как ончейн (композируемость), так и оффчейн (сложные алгоритмы), что позволяет реализовать экосистему профессиональных сервисов, таких как оценка агентов, аудиторские сети и страховые пулы.
Используется для оценки и обратной связи о зарегистрированных AI Agent. Простая отправка отзывов происходит в блокчейне, оффчейн возможны сложные расширения, агрегация, после чего данные возвращаются в блокчейн.
ERC-8004 также может предотвращать злонамеренное накручивание рейтинга с помощью механизма «Привязки доказательства оплаты» (Payment-Proof Linking). Когда агент A завершает оценку агента B, он вызывает функцию giveFeedback. Эта функция принимает не только оценку (0-100) и хэш комментария, но также позволяет передавать поле paymentProof, обычно это хэш транзакции x402. Это делает стоимость накрутки оценок крайне высокой, значительно снижая вероятность Sybil-атак. В конечном итоге система естественным образом будет поощрять стабильных и качественных агентов.
Ключевые моменты аудита:
● Убедиться, что функция giveFeedback требует обязательного параметра paymentProof, и проверить, является ли этот параметр действительным хэшем транзакции x402 (или соответствующим другим стандартам). Следует обеспечить, чтобы доказательство оплаты нельзя было использовать повторно (например, записывать использованные хэши), предотвращая множественные оценки по одному платежу.
● Проверить, ограничивается ли диапазон оценок (0-100) на уровне контракта, чтобы избежать нарушения логики агрегации из-за оценок вне границ.
● Оценить устойчивость оффчейн-алгоритмов агрегации к манипуляциям: например, используется ли медиана, обрезка экстремальных значений или взвешенное среднее, наказывается ли аномальное поведение (например, большое количество оценок за короткое время).
● Проверить, являются ли условия конфискации (slashing) четкими и проверяемыми, например, зависят ли они от ончейн-доказательств или отправки доказательств мошенничества сторонним оракулом.
● Убедиться, что логика конфискации не содержит централизованных привилегий (например, администратор может произвольно конфисковать стейкинг), условия запуска конфискации должны полностью автоматически выполняться смарт-контрактом.
● Протестировать период блокировки и условия вывода стейкинга, чтобы предотвратить срочный вывод средств агентом перед лицом конфискации.
3. Реестр проверки (Validation Registry)
Универсальный хук для запроса и записи проверок независимыми валидаторами (например, zkML валидатор, TEE oracle, доверенный судья).
Репутация отражает прошлое, но в сценариях с высоким риском (например, управление крупными суммами средств) одной истории недостаточно. Реестр проверки позволяет агенту передавать результаты на проверку третьей стороне или автоматизированной системе, можно использовать такие методы, как повторное выполнение безопасного вывода с стейкингом, zkML валидатор или TEE оракул для проверки или отклонения запроса.
Первая модель — это криптоэкономическая проверка, основанная на безопасном дизайне теории игр. Агент должен внести стейкинг в реестр на определенное количество нативных токенов или стейблкоинов. Если агент не выполнит обязательства или предоставит ошибочный результат, сеть валидаторов может предоставить доказательство мошенничества, запустив автоматическую конфискацию его стейкинга смарт-контрактом. Эта модель подходит для задач, где результат легко проверить, но процесс вычисления непрозрачен, например, сбор данных или простые API-сервисы.
Вторая модель — криптографическая проверка, основанная на безопасном дизайне математических принципов. Аутентификация TEE (Trusted Execution Environment) позволяет агенту работать в защищенной аппаратной среде, такой как Intel SGX или AWS Nitro. Реестр проверки может хранить и проверять отчеты удаленной аутентификации от оборудования, доказывая, что код, запущенный агентом, действительно является конкретной версией, которая не была изменена.
zkML ( zero-knowledge machine learning) — это другой способ криптографической проверки. Агент при отправке результата вывода одновременно отправляет доказательство с нулевым разглашением (zero-knowledge proof). Это доказательство может быть проверено ончейн-контрактом верификации с очень низкой стоимостью, математически гарантируя, что этот вывод действительно был получен конкретной моделью (например, Llama-3-70B) на конкретных входных данных. Это предотвращает атаки «подмены модели», когда поставщик услуг заявляет об использовании высококлассной модели, но на самом деле использует низкоуровневую модель для экономии затрат.
Ключевые моменты аудита
Для криптоэкономической проверки необходимо:
● Проверить окно отправки доказательства мошенничества: предоставляется ли валидаторам достаточно времени для обнаружения и отправки доказательства? Слишком короткое окно может пропустить злонамеренное поведение, слишком длинное приводит к длительной блокировке средств.
● Проверить логику арбитража доказательства мошенничества: зависит ли она от набора валидаторов с мультиподписью? Если да, необходимо проверить степень децентрализации выбора валидаторов и настройки порога; если арбитраж полностью ончейн, необходимо убедиться, что основа для арбитража (например, ончейн-проверяемый результат) существует и недвусмысленна.
● Убедиться, что сумма стейкинга соответствует риску, предотвращая злонамеренные действия с низкой стоимостью (например, слишком маленький стейкинг, где выгода от злоупотребления намного превышает потери).
Для аутентификации TEE необходимо:
● Проверить, проверяет ли контракт актуальность доказательства TEE (например, включает ли временную метку или высоту блока), чтобы предотвратить принятие просроченных доказательств.
● Проверить, включает ли содержание доказательства хэш кода агента, дайджест ввода-вывода,确保 доказательство привязано к конкретной задаче, избегая повторного использования между задачами.
● Оценить, зависит ли логика проверки доказательства TEE от внешнего оракула (например, Intel IAS). Если зависит, необходимо провести аудит безопасности и децентрализации оракула.
Для zkML проверки необходимо:
● Подтвердить, что контракт интегрирует проверенную zk-библиотеку верификации (например, SnarkVerifier) и правильно настроен с верификационным ключом для конкретной системы доказательств (например, Groth16, PLONK).
● Проверить, ограничивает ли контракт верификации применимость доказательства к определенным моделям и диапазону входных данных, чтобы предотвратить атаки подмены модели (например, доказательство сгенерировано для маленькой модели, но заявлено как вывод большой модели).
● Оценить степень децентрализации генерации доказательств: зависит ли она от единственного доказывающего? Если существует несколько доказывающих, необходимо разработать механизм консенсуса для предотвращения злонамеренных доказывающих.
Заключение
ERC-8004 предоставляет стандарт для установления доверия к AI Agent, и его безопасность является ключевой для всей экосистемы ончейн-агентов. Работа по аудиту безопасности требует глубокого понимания замысла设计和 и потенциальных рисков трех реестров. Кроме того, нельзя игнорировать сложность взаимодействия между контрактами и обычные уязвимости. Необходимо обеспечить, чтобы всесторонний и строгий аудит гарантировал, что ERC-8004 действительно выполнит свое «доверительное»承诺 и заложит безопасный фундамент для будущего автономных агентов.
