Serie para principiantes en Web3: ERC8004: Esta narrativa de Web3+AI te permitirá disfrutar de una deliciosa comida para llevar

ERC8004 es una especificación de protocolo en Ethereum que define un conjunto de estándares para que los agentes puedan establecer relaciones de confianza basadas en la cadena de bloques, fusionando la narrativa de A2A (Agent to Agent) con la narrativa de Web3. En este artículo, exploremos cómo funciona esta gran narrativa de Web3+AI.

La dirección del protocolo fue creada en agosto y todavía está en fase de revisión. Aquí analizaremos qué problema resuelve este protocolo, explicaremos de manera sencilla los estándares del protocolo y, por último, imaginaremos el significado de este protocolo. La lectura completa dura aproximadamente 15 minutos, ¡no olvides guardarlo!

El problema que resuelve

Primero, veamos qué intenta solucionar este protocolo:

En pocas palabras, resolver el problema de confianza durante el proceso A2A (Agente llama a Agente). Por ejemplo, tengo un asistente de IA llamado 小 A, que es un agente inteligente. Le pido que me encargue un pedido de comida confiable. Pero mi agente no es experto en esto (después de todo, coordinar con repartidores y comerciantes es un gran trabajo, y un pequeño asistente de IA no soporta eso), ¿qué hago entonces?

En ese momento, puedo buscar ayuda en otros agentes inteligentes.

Entonces surge la pregunta: ¿cómo puede mi agente encontrar otro agente confiable para ayudar? ¿Falta alguna institución de confianza? En realidad, los humanos también lo hacen así, a través de plataformas como Taobao, que actúan como instituciones de confianza centralizadas. Pero las instituciones centralizadas tienen sus limitaciones, y en la era de los agentes inteligentes, este problema se vuelve aún más evidente. Para que los agentes sean eficientes, no pueden depender siempre de acudir a centros de confianza; si no, acabarían retrasando a la IA. Incluso usando instituciones centralizadas para verificar, también es necesario buscar instituciones de confianza basadas en IA o que operen de manera descentralizada, para maximizar la eficiencia de la IA.

Por eso, si pudiéramos tener datos confiables y descentralizados que me ayuden a encontrar agentes confiables, la eficiencia sería mucho mayor. Y así nace el protocolo 8004.

¿No te parece muy razonable? Ahora, veamos cómo está diseñado ERC8004 basándose en esta lógica.

Análisis de la solución específica del protocolo

Esta parte explica la solución técnica del protocolo; sin embargo, no entraremos en detalles sobre los contratos y parámetros específicos de la especificación, para que todos puedan entenderlo de manera sencilla. Los detalles están en la documentación del estándar del protocolo. Basándonos en el contenido del protocolo, explicaremos de forma comprensible cómo este protocolo resuelve los problemas planteados anteriormente.

Desde un punto de vista técnico, ERC8004 básicamente define las interfaces de tres tipos de contratos:

Identity Registry, Registro de identidad. Basado en ERC721 (Token no fungible, es decir, NFT), para registrar agentes. Cada agente es en realidad un NFT, y con este NFT se puede acceder a la información relevante del agente.

Reputation Registry, Registro de reputación.

Validation Registry, Registro de validación.

En resumen, estos tres contratos pueden entenderse como tres instituciones que operan en la cadena de bloques.

Primera institución: un agente abre una cuenta, similar a abrir un restaurante.

Segunda institución: se encarga de recopilar calificaciones para estos agentes, parecido a plataformas como Dianping o Gaode.

Tercera institución: es una organización de investigación independiente que verifica la información, similar a agencias de inspección, salud pública, etc.

🌐 Un flujo de trabajo concreto

Usando el ejemplo de pedir comida, supongamos que quieres que el asistente de IA 「小 A」 te ayude a pedir comida sin aceite de ganso:

Buscar colaborador: 「小 A」 primero consulta el Registro de identidad para buscar un buen restaurante 「小 B」 y revisar sus evaluaciones anteriores.

Construir confianza inicial: luego, 「小 A」 revisa el Registro de reputación para ver qué calificaciones ha recibido 「小 B」 y decide si contratarlo.

Ejecución y verificación: si la comida es muy importante, 「小 A」 o tú pueden contratar a un verificador independiente 「小 C」 desde el Registro de validación. 「小 C」 verificará si los informes de 「小 B」 son precisos y cumplen con los requisitos, y hará públicos los resultados.

Pago y retroalimentación: tú pagas a 「小 A」 a través del protocolo x402 (un mecanismo de recibos que conecta pagos en cadena y actividades fuera de la cadena; puedes revisar nuestro artículo anterior sobre x402). 「小 A」 paga a 「小 B」 y 「小 C」. Finalmente, dejas una buena valoración para 「小 A」 y 「小 B」. Todos estos pagos y acciones fortalecerán o afectarán su reputación en los registros respectivos.

En resumen, ERC-8004 mediante la interacción de estos tres contratos crea un entorno de colaboración descentralizado y confiable para los asistentes de IA, permitiéndoles intercambiar servicios y valor de manera libre y segura, similar a cómo los humanos operan en el mercado.

Registro de identidad

Este contrato es básicamente un contrato NFT, que incluye transferencias y otras funciones de ERC721, pero también amplía la definición del metadato del NFT:

Aquí puedes especificar el nombre del agente, la imagen, la descripción y la dirección del endpoint correspondiente.

Además, define métodos de registro como «register», además de algunos eventos (el estándar ERC721 no especifica un método de acuñación, por lo que este método se considera parte de ERC8004).

Registro de reputación

Este contrato, al ser desplegado, requiere que le pases la dirección del contrato del NFT mediante el constructor, es decir, está asociado de manera única con un registro de identidad.

Define varios métodos:

giveFeedback, para calificar, permite puntuar los NFT en el registro de identidad con una puntuación de 0 a 100 (agentId es el TokenID del NFT). Para llamar a este método, necesitas un parámetro «feedbackAuth», que es una firma del agente al aceptar la tarea.

revokeFeedback, para revocar una calificación.

appendResponse, para agregar respuestas adicionales (con un formato requerido), como una dirección offline + un hash para la verificación.

También hay métodos de lectura para consultar las calificaciones.

El formato para información adicional debe cumplir con:

Registro de validación

Al igual que el registro de reputación, este contrato también requiere la dirección del registro provincial asociado, que es el único vínculo con un registro de identidad. Este contrato necesita ser llamado por el propietario del agente (el dueño del NFT), e incluye métodos como:

validationRequest, para solicitar validación.

validationResponse, para responder a la validación.

Los detalles específicos no se explicarán aquí; en esencia, ERC8004 define tres contratos estándar que permiten crear un sistema transparente y descentralizado de evaluación de agentes en la cadena, ayudando a los agentes a encontrar mejores colaboradores y ofreciendo una solución de confianza en Web3 para A2A.

Nuestra práctica

Basándonos en el diseño de ERC-8004, en las redes Pharos y Jovay hemos desarrollado capacidades de servicio confiable (Trustless) orientadas a Web3, que ayudan a los usuarios a gestionar la «Identidad Confiable Agent DID» en el mundo Web3. Además, hemos ampliado estas capacidades con verificaciones TEE/ZK de nivel financiero y planeamos soportar futuras validaciones más seguras, orientadas a transacciones automáticas en escenarios financieros.

Perspectivas futuras

Aunque parece prometedor, también enfrenta desafíos. Sin embargo, los desafíos representan oportunidades. Veamos qué oportunidades podrían surgir en el futuro.

Primero, aunque los datos en la cadena son transparentes e inalterables, garantizar que los datos en la cadena sean verdaderos y confiables sigue siendo un problema. Eventualmente, podrían aparecer verificadores confiables en la cadena, que en realidad representan las autoridades detrás. Los verificadores confiables pueden ofrecer información más fiable mediante datos históricos en la cadena, por ejemplo, si usas una cuenta nueva para dejar malas calificaciones, seguramente tu reputación se verá afectada.

Siguiendo esta lógica, hay muchas cosas que se pueden hacer alrededor de este protocolo:

Puedes crear un servicio dedicado a ofrecer servicios en la cadena para asistentes inteligentes. Por ejemplo, puedo ayudarte a desplegar un contrato para tu agente, que pueda realizar varias operaciones basadas en este protocolo. Puedo ofrecer este servicio mediante un MCP.

Puedes crear una calle gastronómica en la cadena, donde todos registren sus agentes inteligentes, por ejemplo, abriendo una tienda de pollo frito (robots IA en forma de pollo frito), y cobrar una tarifa de registro. Es similar a ENS (Ethereum Name Service). En realidad, ENS es solo un registro, solo hay que ampliarlo.

Puedes crear una clasificación de restaurantes de alta gama en la cadena (como Michelin) para evaluar y calificar a otros, y cobrar una pequeña tarifa por ello.

En resumen, todo lo que se hacía offline en el pasado se puede trasladar a la cadena, y los agentes podrán trabajar en el mundo de la cadena en el futuro.

¿Crees que es confiable? Al menos, a mí me parece bastante interesante.

Este artículo fue escrito por Fisher de ZAN Team (@zan_team en X y @yudao1024 en X).