Серия для новичков в Web3: ERC8004: эта история о Web3+AI поможет вам заказать свежую еду на вынос

ERC8004 — это протокол на базе Ethereum, определяющий набор стандартов, позволяющих агентам устанавливать доверительные отношения на блокчейне, объединяя повествование A2A (Agent to Agent) с Web3. В этой статье мы рассмотрим, какая логика лежит в основе этого Web3+AI большого нарратива.

Адрес протокола 8月 создан, находится на стадии рецензирования. В статье мы разберем, какую проблему решает этот протокол, простым языком объясним его стандарты, а в конце пофантазируем о его значении. Время чтения примерно 15 минут, рекомендуем сохранить.

Проблема, которую решает протокол

Давайте сначала посмотрим, какую проблему пытается решить этот протокол:

Проще говоря, он решает проблему доверия в процессе A2A (агент вызывает агента), например, у меня есть AI-ассистент по имени 小 A, он — агент, я хочу, чтобы он заказал для меня надежную доставку еды. Но мой агент не умеет этого делать (ведь связаться с курьером и магазином — это целая задача, маленький AI-ассистент не поддержит). Что делать?

В этом случае можно обратиться за помощью к другим агентам.

Возникает вопрос: как мой агент найдет другого надежного агента для помощи? Необходим ли доверительный институт? Люди тоже используют централизованные доверительные системы, например, Taobao. Но централизованные системы имеют свои ограничения, и в эпоху агентов эта проблема становится еще более очевидной. Чтобы агент был эффективен, он не может постоянно обращаться к централизованным институтам, что может тормозить развитие AI. Даже при использовании централизованных систем для верификации, важно искать доверительные институты, основанные на AI или децентрализованные, чтобы раскрыть потенциал AI.

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

Звучит логично. А теперь посмотрим, как именно спроектирован ERC8004 на основе этой логики.

Анализ конкретных решений протокола

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

С технической точки зрения, ERC8004 — это определение интерфейсов трех типов контрактов:

Identity Registry — реестр идентичностей. Основан на ERC721 (незаменяемые токены, NFT), используется для регистрации агентов. Каждый агент — это NFT, через него можно получить информацию о агенте.

Reputation Registry — реестр репутации.

Validation Registry — реестр верификации.

Проще говоря, эти три типа контрактов можно представить как три организации, работающие в блокчейне.

Первая организация: агент создает аккаунт, как ресторан.

Вторая: собирает оценки для агентов, как отзывы на Dianping или Amap.

Третья: независимая проверяющая организация, например, контроль качества или санитарный надзор.

🌐 Конкретный рабочий сценарий

Рассмотрим пример заказа еды через 小 A, чтобы понять, как это работает:

Поиск партнера: 小 A сначала обращается к реестру идентичностей, ищет хорошо оцененного доставщика 小 B и проверяет его отзывы.

Построение доверия: затем 小 A проверяет репутационный реестр, смотрит оценки других партнеров, решает, нанимать ли 小 B.

Исполнение и проверка: если заказ важен, 小 A или вы можете нанять независимого проверяющего 小 C из реестра верификации. 小 C проверит, насколько отчеты 小 B точны и соответствуют требованиям, и опубликует результаты.

Оплата и обратная связь: вы платите 小 A через протокол x402 (механизм связки платежей на цепочке и оффчейне, подробнее в нашей статье о x402). 小 A платит 小 B и 小 C. В конце вы оставляете положительный отзыв о 小 A и 小 B, а все платежи и отзывы влияют на их репутацию в реестрах.

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

Реестр идентичностей

Этот контракт — по сути, NFT-контракт, включает стандартные функции ERC721, такие как передача, но расширяет метаданные NFT:

Здесь указывается название агента, изображение, описание и адрес порта.

Также определены методы регистрации «register» и связанные события (стандартный ERC721 не содержит метода mint, поэтому этот метод — часть ERC8004).

Реестр репутации

Этот контракт при развертывании принимает адрес контракта NFT через конструктор, то есть он связан с одним конкретным реестром идентичностей.

Определены методы:

giveFeedback — оставить отзыв, оценить NFT в реестре (agentId — это TokenID NFT). Для вызова нужен подпись «feedbackAuth», которая подписана агентом при принятии задания.

revokeFeedback — отменить отзыв.

appendResponse — добавить дополнительную информацию (с определенным форматом), например, оффлайн-адрес и хэш для проверки.

Также есть методы для чтения информации о рейтингах.

Формат дополнительных данных:

Верификационный реестр

Аналогично реестру репутации, при создании требует адрес контракта провинциального реестра, связанного с этим реестром идентичностей. Этот контракт вызывается владельцем агента (Owner NFT) и содержит методы:

validationRequest — запросить верификацию.

validationResponse — ответить на запрос.

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

Наш опыт

На базе ERC-8004 мы реализовали в сетях Pharos и Jovay возможности доверительных сервисов Web3, позволяющие пользователям создавать «доверенные идентификаторы Agent DID». Также мы расширили их финансово-усиленными возможностями TEE/ZK-верификации, в будущем планируем поддержку более безопасных сценариев, например, для автоматизированных торговых операций в финансовой сфере.

Будущее

Звучит многообещающе, но также сопряжено с вызовами. Вызовы — это и возможности. Рассмотрим, что может открыться в будущем.

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

Исходя из этого, возможностей для развития протокола очень много:

Можно создать сервис, который предоставляет услуги по размещению агентов на цепочке. Например, я могу помочь вашему агенту развернуть контракт, основанный на этом протоколе. Или предложить такой сервис через MCP.

Можно создать децентрализованный рынок еды, где все регистрируют своих агентов. Например, я открыл ресторан с AI-роботом для жарки курицы, и он регистрируется на такой платформе. Если платформа популярна, она сможет взимать регистрационный сбор. Аналогично Ethereum Name Service (ENS), который можно считать реестром, расширенным под нужды.

Можно создать децентрализованный рейтинг ресторанов или других сервисов, например, Michelin, за оценки и отзывы, за небольшую плату.

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

Как вам кажется, это надежно? Лично мне кажется, это очень интересно.

Эта статья написана командой ZAN (X аккаунт @zan_team) и Fisher (X аккаунт @yudao1024).