Автор: Сяобай
Данная статья является оригинальной публикацией автора. Мнения, выраженные в статье, принадлежат исключительно автору. Редакция ETHPanda отредактировала и структурировала материал.
Когда AI-агент попадает в блокчейн, вопрос уже не в том, "может ли он общаться".
Он может подписывать транзакции, получать платежи, инициировать транзакции, развертывать контракты, управлять кошельками, вызывать API и даже сотрудничать с другими агентами для выполнения задач. В этот момент пользователей волнует не красивое имя агента, а:
Насколько надежен этот агент?
Чистый ли у него кошелек? Действительно ли существуют связанные с ним контракты? Есть ли риски у его веб-сайта и API? Является ли размещаемый им медиаконтент подделкой? Есть ли очевидные уязвимости в его коде на Solidity? Не подвергался ли он уже атакам?
Именно на эти вопросы проверки нацелен ERC-8126.
Проще говоря, ERC-8126 — это слой верификации для AI-агентов. Он строится поверх агентской регистрации (identity registration) ERC-8004, позволяя независимым поставщикам проверок (verification providers) выполнять многоуровневую верификацию для одного и того же агентского идентификатора и превращать результаты в сигналы о рисках, которые могут потребляться кошельками, маркетплейсами, приложениями и другими агентами.
Его цель не в том, чтобы доказать, что какой-либо агент навсегда заслуживает доверия, а в стандартизации "как проверить агента, как выразить результаты проверки и как другим системам считывать эти результаты".
Наличие идентичности не равно доверию
ERC-8004 решает проблему идентичности агента.
Можно понимать это так: сначала AI-агент получает регистрируемую, обнаруживаемую и индексируемую идентичность в блокчейне. Эта идентичность соответствует agentId и через метаданные описывает такую информацию об агенте, как название, кошельки, конечные точки (endpoints), веб-сайт, адреса контрактов и т.д.
Но сама по себе идентичность не означает доверия.
Вредоносный агент тоже может зарегистрировать идентичность. Фишинговый агент тоже может составить красивый набор метаданных. То, что агент сегодня работает нормально, не гарантирует, что завтра его конечная точка не будет захвачена. То, что у агента есть аватар, официальный сайт, адрес кошелька, еще не означает, что его контракты безопасны, кошельки чисты, а контент подлинный.
Таким образом, ERC-8004 скорее отвечает на вопрос:
Кто этот агент?
А ERC-8126 задает следующий вопрос:
Стоит ли с ним взаимодействовать?
Как ERC-8126 проводит верификацию?
Во-первых, запрос на верификацию ссылается на agentId из Реестра идентичностей ERC-8004 (ERC-8004 Identity Registry). Затем поставщик проверок (verification provider) считывает соответствующие метаданные по этому agentId, анализирует из них информацию о кошельках, контрактах, веб-сайтах, конечных точках, медиаконтенте и т.д., и в итоге генерирует оценку риска и доказательство проверки (proof).
Этот процесс можно разбить на четыре шага:
- AI-агент сначала регистрирует свою идентичность через ERC-8004.
- Поставщик ERC-8126 считывает agentId и метаданные этого агента.
- Поставщик выполняет многоуровневую проверку агента.
- Результаты проверки в виде оценки риска (risk score), доказательства (proof), аттестации (attestation) и т.д. потребляются кошельками, маркетплейсами, dApp или другими агентами.
Ключевой момент здесь: ERC-8126 не вводит единственный "официальный орган сертификации".
Он скорее похож на открытый рынок поставщиков проверок (verification providers). Разные поставщики могут использовать свои методы для проверки безопасности, но выводят результаты в стандартизированном формате. Так кошельки, маркетплейсы агентов, рынки задач и другие приложения смогут считывать эти сигналы кроссплатформенно.
Это шаг вперед по сравнению с "самостоятельными заявлениями проекта о своей безопасности": он разбивает суждение о доверии на сигналы, которые могут быть проверены, записаны и считаны третьими сторонами.
Пять уровней верификации: рассматриваем агента по частям
ERC-8126 в основном определяет пять типов проверок, охватывающих несколько наиболее проблемных аспектов агента после его выхода в блокчейн: контракты, медиа, код, веб-сайт и кошелек. Он стандартизирует тип проверки, выражение результатов и потребительские интерфейсы, а не превращает каждый метод проверки безопасности в единственный официальный метод аудита. Разные поставщики проверок по-прежнему могут использовать собственные процессы обнаружения и модели рисков.
ETV: Проверка токенов / контрактов (Token / Contract Verification)
ETV проверяет токены или контракты, связанные с агентом.
Если в метаданных агента указан contractAddress, поставщик проверит, действительно ли по этому адресу в соответствующей сети есть код контракта, существуют ли очевидные риски, или это просто случайный фальшивый адрес.
Для пользователя ETV отвечает на вопрос:
Существуют ли на самом деле активы или контракты в блокчейне, с которыми, как утверждает агент, он связан?
Потому что как только агент начинает получать платежи, выпускать токены, заниматься стейкингом, выполнять стратегии, лежащие в основе контракты перестают быть просто украшением — это места, с которыми реально будут взаимодействовать средства пользователей.
MCV: Проверка медиаконтента (Media Content Verification)
MCV проверяет медиаконтент, используемый агентом, например аватары, изображения, фирменные материалы, скриншоты подтверждения и т.д.
На первый взгляд, это не кажется ключевой проблемой, но в сценариях с AI-агентами это очень важно. Фальшивый агент может использовать чужой логотип проекта, подделывать официальные скриншоты и даже создавать ощущение поддержки с помощью изображений, сгенерированных ИИ.
MCV проверяет источник контента, целостность, следы изменений, водяные знаки, подписи и другую информацию.
Он отвечает на вопрос:
Не были ли подделаны или изменены материалы, которые этот агент показывает пользователям?
SCV: Проверка кода на Solidity (Solidity Code Verification)
SCV проверяет связанный с агентом код на Solidity или безопасность контрактов.
Если метаданные содержат информацию о соответствующем коде или контракте, поставщик может проверить наличие распространенных рисков, таких как reentrancy, проблемы с правами доступа, опасные вызовы, векторы атак через flash-займы и т.д.
SCV может снизить некоторые распространенные риски контрактов, но это не эквивалент полного ручного аудита.
Это скорее стандартизированная точка входа для проверки безопасности контрактов. Наличие SCV не означает абсолютной безопасности контракта; это указывает на то, что код или контракт этого агента прошел проверку определенного поставщика, и были сгенерированы потребительские сигналы о рисках.
WAV: Проверка веб-приложений (Web Application Verification)
WAV проверяет веб-сайт, API и конечные точки агента.
У многих агентов, даже имеющих идентичность в блокчейне, реальные точки взаимодействия все еще находятся вне его — например, официальный сайт, API, MCP server, A2A endpoint или панель управления (dashboard).
Проблемы в этих местах могут быть не менее рискованными, чем в контрактах. При просроченном сертификате сайта пользователь может стать жертвой атаки "человек посередине"; при захвате API агент может выполнять ошибочные команды; при внедрении вредоносного скрипта во фронтенд пользователь может подписать опасную транзакцию.
WAV отвечает на вопрос:
Безопасны ли веб-входы и конечные точки служб этого агента?
WV: Проверка кошелька (Wallet Verification)
WV проверяет риски кошелька агента.
Он проверяет, есть ли у этого кошелька история транзакций, не является ли он только что созданной пустышкой, связан ли он с адресами высокого риска, фишинговыми адресами, адресами злоумышленников или другими объектами из баз данных threat intelligence.
WV отвечает на вопрос:
Чиста ли запись о поведении этого агента в блокчейне?
Единый показатель риска: чтобы кошельки и приложения могли действительно его использовать
ERC-8126 преобразует результаты проверки в показатель риска (risk score) от 0 до 100.
Чем ниже балл, тем ниже риск; чем выше балл, тем выше риск.
- 0-20: Низкий риск
- 21-40: Умеренный риск
- 41-60: Повышенный риск
- 61-80: Высокий риск
- 81-100: Критический риск
Продуктовая цель этого дизайна очевидна.
Кошельки не могут требовать от обычных пользователей каждый раз читать полный отчет о безопасности. Маркетплейсам тоже не подходит сортировка исключительно на основе самоописаний проектов. Единый показатель риска может стать входными данными для продуктовой стратегии.
Например:
- При слишком высоком показателе риска кошелек может предупредить или заблокировать взаимодействие.
- При отсутствии результатов проверки маркетплейс может снизить вес отображения.
- При аномальных рисках кошелька рынок задач может ограничить прием заказов.
- При высоком риске веб-конечной точки фронтенд может предупредить пользователей о необходимости осторожного доступа.
Однако один общий балл не может отражать всю картину.
Риски контрактов, кошельков, веб-сайтов, медиа — это изначально разные типы рисков. Более качественный продуктовый дизайн — одновременно показывать общий балл и баллы по категориям, чтобы пользователь знал, в чем конкретно проблема.
PDV и ZKP: Доказательство прохождения проверки не равно раскрытию всех деталей
Верификация агента затрагивает много конфиденциальной информации.
Например, исходный код, конфигурация инфраструктуры, отчеты безопасности, приватные логи, профиль кошелька и т.д. Если раскрыть все это, можно, наоборот, увеличить поверхность для атак.
Поэтому ERC-8126 вводит PDV и ZKP.
PDV — это проверка приватных данных (Private Data Verification), ZKP — доказательство с нулевым разглашением (Zero-Knowledge Proof). Их роль: позволить агенту доказать, что он прошел определенную проверку, не раскрывая при этом все базовые детали.
Можно понимать это так:
Внешний мир видит "прошел проверку, каков показатель риска, где proof", а не полные внутренние материалы по безопасности.
Это делает ERC-8126 больше похожим на верифицируемую сводку due diligence, а не на расклад всех данных на всеобщее обозрение.
ERC-8004 / ERC-8126 / ERC-8183: Идентичность, верификация, транзакции
Если разделить экономику AI-агентов на три уровня, можно понять это так. Здесь необходимо пояснить статус: ERC-8126 достиг статуса Final, в то время как ERC-8004 и ERC-8183 все еще находятся на стадии Draft. Поэтому эти три протокола правильнее воспринимать как формирующееся направление инфраструктуры, а не как полностью сложившийся стек протоколов.
- ERC-8004: Идентичность (Identity) — дает агенту идентичность, возможность регистрации и обнаружения.
- ERC-8126: Верификация (Verification) — делает сигналы безопасности и рисков агента верифицируемыми и потребляемыми.
- ERC-8183: Коммерция (Commerce) — позволяет агенту принимать задачи, отправлять результаты, входить в процессы эскроу и расчетов.
Проще говоря:
- ERC-8004 отвечает: Кто ты?
- ERC-8126 отвечает: Надежен ли ты?
- ERC-8183 отвечает: Можешь ли ты работать, получать оплату, производить расчеты?
Вместе эти три протокола формируют довольно четкую нарративную линию для экономики агентов:
Сначала идентичность, затем верификация, и только после этого легче вступать в транзакции и расчеты.
Эти отношения можно описать чуть детальнее. ERC-8126 действительно строится поверх ERC-8004; ERC-8183 и ERC-8126 скорее естественным образом дополняют друг друга, а не имеют жесткой связи.
Другими словами, протоколы коммерции агентов, такие как ERC-8183, могут естественным образом потреблять сигналы верификации ERC-8126 — например, проверять показатель риска агента перед принятием задачи, проверять proof перед выплатой средств оценщиком (evaluator). Но это скорее направление для инженерной комбинации, а не жесткая зависимость ERC-8183 от ERC-8126.
Что это значит для разработчиков?
Если рассматривать AI-агентов только с точки зрения рыночного нарратива, обсуждение легко застревает на токенах, запуске, маркетплейсах и активности торгов. Но для тех, кто действительно хочет создавать продукты для агентов, интеграции для кошельков, сети задач или инфраструктуру протоколов, более критичный вопрос: кто берет на себя стоимость доверия, когда агент начинает управлять активами, вызывать сервисы, отправлять результаты, сотрудничать с другими агентами?
Раньше эти издержки в основном перекладывались на пользователей. Пользователи сами оценивали надежность проекта, сами проверяли, проходил ли контракт аудит, сами проверяли чистоту кошельков, сами распознавали поддельные сайты и в конечном итоге сами несли последствия обмана или неудачного взаимодействия.
Ценность ERC-8126 в том, что он пытается разбить эти суждения на стандартизированные, композируемые, считываемые продуктами сигналы верификации.
Он не устранит риски и не гарантирует, что какой-либо агент будет всегда заслуживать доверия. Но если эти сигналы верификации будут приняты большим количеством кошельков, маркетплейсов, dApp и сетей агентов, многие продуктовые решения смогут перестать полагаться исключительно на самоописание проектов.
Конкретнее:
Для кошельков показатель риска (risk score) может стать входными данными для контроля рисков до совершения транзакции и предупреждений.
Для маркетплейсов агентов результаты верификации могут влиять на сортировку, фильтрацию, вес отображения и маркировку рисков.
Для приложений AI x ETH это может стать проверкой безопасности перед подключением агента.
Для взаимодействия между агентами (agent-to-agent) это может помочь агенту отсеять явно высокорисковые объекты перед сотрудничеством.
В этом и заключается причина, по которой ERC-8126 заслуживает внимания: это не очередной ERC с концепцией ИИ, а попытка продвинуть агентов в блокчейне от "регистрируемости" к "верифицируемости и управляемости рисками".
Это все еще стандарт, а не уже работающая сеть
На эту часть можно взглянуть под другим углом.
ERC-8126 определяет стандартные интерфейсы и фреймворк верификации. Он описывает, как можно проводить проверку и как выражать результаты, но это не означает, что сейчас уже существует зрелая публичная сеть верификации, унифицированно работающая в разных кошельках, маркетплейсах и сетях.
Из текущей спецификации уже ясно несколько вещей:
- ERC-8126 определяет стандартный процесс верификации агентов.
- Он требует, чтобы верификация привязывалась к agentId из ERC-8004.
- Он охватывает пять категорий рисков: токены/контракты, медиа, Solidity, веб, кошельки.
- Он поддерживает оценку рисков, proof и аттестацию (attestation).
- Он предоставляет основу для потребления сигналов верификации кошельками, маркетплейсами, dApp.
Чтобы эти возможности действительно заработали, зависит от того, сколько поставщиков, кошельков, маркетплейсов и приложений впоследствии захотят их принять. Другими словами, сейчас это не состояние, описываемое ниже:
- Все кошельки уже интегрированы.
- Все маркетплейсы агентов уже внедрили его.
- Все поставщики используют полностью идентичные стандарты оценки.
- Вся индустрия уже сформировала зрелую сеть верификации (verification network).
- ZKP и показатели риска уже полностью унифицированы в производственной среде.
Проще говоря:
ERC-8126 сначала стандартизировал язык верификации для AI-агентов. Чтобы стать публичным уровнем доверия, ему еще потребуется подключение поставщиков, кошельков, маркетплейсов и приложений.
Заключение
После выхода AI-агентов в блокчейн-экономику, идентичность — это только начало, за которым последует более практичный вопрос: можно ли их верифицировать.
ERC-8004 дает агенту идентичность. ERC-8126 делает риски, стоящие за этой идентичностью, верифицируемыми. ERC-8183 же дает агенту возможность использовать эти сигналы верификации в сценариях задач, эскроу и расчетов.
Таким образом, смысл ERC-8126 не в выдаче агенту значка "вечно заслуживающий доверия", а в стандартизации более реалистичного вопроса:
Когда AI-агенту нужно войти в процессы работы с кошельками, маркетплейсами, сетевыми задачами и транзакциями в блокчейне, как мы должны его проверять? Как должны выражаться результаты проверки? И как другие системы должны потреблять эти результаты?
Возможно, именно этот слой доверия необходимо дополнить в экономике AI-агентов на следующем этапе.
Справочные материалы
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan
