Cómo funcionan los registros ERC-8004: identidad y…

Cómo funcionan los registros ERC-8004 es a través de un pipeline de tres libros: un AgentID ERC-721 apunta a un archivo de registro fuera de la cadena, mientras que registros separados de Reputación y Validación registran señales de confianza compactas de 0 a 100 con punteros de evidencia.

El diseño no coloca la "verdad del agente" en la cadena, estandariza dónde buscar (identidad), quién puede hablar (reputación autorizada) y cómo valorar la garantía (validación) para la identidad del agente 8004.

Puntos Clave

• ERC-8004 define tres registros ligeros en la cadena: Identidad, Reputación y Validación.
• El Registro de Identidad utiliza un AgentID ERC-721 cuyo tokenURI apunta a un archivo de registro de agentes fuera de la cadena que enumera puntos finales e identificadores como A2A, MCP, ENS y direcciones de billetera.
• El Registro de Reputación registra señales de retroalimentación portátiles de 0 a 100 con etiquetas opcionales y fuera de la cadena.enlaces, y una guía para desarrolladores describe una puerta de enlace feedbackAuth firmada por un agente para reducir el spam arbitrario.
• El Registro de Validación registra llamadas de validationRequest y respuestas de validadores de 0 a 100, permitiendo a las aplicaciones intercambiar en staking, pruebas zkML o TEE.atestacionessin cambiar el descubrimiento.

Los registros ERC-8004 y su propósito

Los registros ERC-8004 son contratos inteligentesque almacenan registros estandarizados y emiten eventos para que otras aplicaciones puedan consultar la identidad del agente y señales de confianza sin negociar esquemas personalizados.

El movimiento central del estándar es dividir la “confianza” en tres superficies distintas: un registro de identidad para descubrimiento, un registro de reputación para comentarios de usuarios y un registro de validación para verificaciones de terceros. Esa separación es la razón por la cual los registros ERC-8004 se mantienen livianos en la cadena mientras siguen siendo composables entre aplicaciones.

El modelo mental útil es un archivo de crédito en la cadena para agentes autónomos.El Registro de Identidad es el número de cuenta y la información de enrutamiento, no la puntuación de crédito. La Reputación y la Validación son dos libros contables diferentes de señales compactas de 0 a 100, cada uno permitido para llevar etiquetas y punteros a evidencia fuera de la cadena.

Este es el patrón del registro de validación de reputación de identidad: mantener la cadena como el índice canónico y ancla de integridad, y mantener los detalles desordenados fuera de la cadena.

ERC-8004 se describe como una Propuesta de Mejora de Ethereumen estado de borrador y en revisión por pares. La guía principal lista la fecha de creación como el 13 de agosto de 2025 y nombra a los coautores Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google) y Erik Reppel (Coinbase).

Esa postura de borrador es importante porque las interfaces están destinadas a ser lo suficientemente estables para la experimentación, pero los constructores deben esperar que los detalles a nivel de campo evolucionen.

El tema más amplio es la identidad del agente, y la tesis de ERC-8004 es intencionadamente estrecha: no pretende probar las capacidades de un agente en la cadena. Estandariza dónde residen esas afirmaciones (registro de tokenURI), cómo se publica la retroalimentación de una manera que es más difícil de inundar (autorización) y cómo se puede adquirir una garantía independiente cuando aumentan las apuestas (validación).

Cómo funciona el registro de identidad

El ciclo de vida del Registro de Identidad es corto en la cadena y largo fuera de la cadena. En la cadena, el mecanismo es un ERC-721 con almacenamiento URI: acuñar un token AgentID único, establecer su tokenURI y confiar en el estándar.NFTindexación y eventos para el descubrimiento.

Fuera de la cadena, el tokenURI se resuelve en un archivo de registro de agente que actúa como un documento de configuración vivo sobre cómo alcanzar e interpretar al agente.

Un flujo concreto se ve así:

1. Un operador de agente acuña un AgentID ERC-721 en el registro de identidad y establece tokenURI. 2. Los indexadores y aplicaciones observan los eventos del registro y enumeran los AgentIDs de la misma manera en que enumerarían los NFTs. 3. La aplicación obtiene tokenURI y lee el archivo de registro de agente fuera de la cadena para conocer los puntos finales e identificadores.

La fuente principal describe que el archivo de registro contiene puntos finales e identificadores como A2A, MCP, ENS y direcciones de billetera. Esa es la carga útil operativa. Si una aplicación está tratando de dirigir una tarea a un agente, el registro de identidad le proporciona el puntero canónico al "dónde hablar conmigo" y el paquete de "qué identificadores reclamo" del agente.

Aquí es donde la mayoría de las integraciones se ven sorprendidas. El token ERC-721 no le dice a una aplicación si el archivo de registro fuera de la cadena cambió silenciosamente, si un endpoint dejó de funcionar o si un nombre de ENS fue redirigido. Tratar el contenido de tokenURI como configuración de producción es la postura correcta: versionarlo, fijarlo a almacenamiento dirigido por contenido cuando sea posible y alertar sobre cambios. La parte en la cadena es intencionalmente aburrida, y ese es el punto.

Los objetos requeridos aparecen aquí de manera natural: el registro de identidad es el contrato, el AgentID es el token ERC-721, y la tarjeta del agente es lo que muchos front ends renderizarán a partir de tokenURI más cualquier validación en caché y resúmenes de reputación.

Cómo se registran las señales de reputación

La reputación en erc 8004 está diseñada para ser portátil pero no permissionless. El Registro de Reputación proporciona una interfaz estándar para publicar y recuperar señales de retroalimentación, y la fuente principal enmarca esas señales como puntuaciones de 0 a 100 con etiquetas opcionales y enlaces a datos de retroalimentación detallados fuera de la cadena. La cadena almacena la señal compacta.

El enlace fuera de la cadena lleva la narrativa, recibos y cualquier contexto que una aplicación quiera mostrar a un humano.

La mecánica clave que evita que el registro de reputación se convierta en una pared de spam no negociable es la autorización. Un recorrido orientado a desarrolladores describe la presentación de reputación como un proceso que requiere autorización emitida por el agente a través de un feedbackAuth firmado.

La idea es simple: el agente preautoriza a una contraparte específica para dejar comentarios, de modo que direcciones aleatorias no puedan lanzar reseñas negativas a gran escala sin haber interactuado nunca.

Una secuencia típica es:

1. El agente acepta una tarea y emite una autorización de retroalimentación al cliente. 2. El cliente envía retroalimentación al registro de reputación con puntuación (0–100), etiquetas opcionales, URI y hash fuera de la cadena opcionales, y el feedbackAuth. 3. Las aplicaciones y agregadores leen eventos de retroalimentación en la cadena y calculan sus propios resúmenes, mientras obtienen detalles fuera de la cadena solo cuando es necesario.

La guía principal también señala un ticket de admisión más limpio para reseñas de "uso real": pruebas de pago x402. Hace referencia explícita al código de estado HTTP "402 Payment Required" como parte del enmarcado de x402, y describe el uso de pruebas de pago para que solo los clientes que pagan puedan dejar reseñas.

Esa es una composición ajustada: puertas de pago que pueden hablar, el registro almacena la señal mínima de 0 a 100, y el enlace de evidencia puede contener el recibo.

Nada de esto elimina el comportamiento Sybil. La fuente principal reconoce que la preautorización solo mitiga parcialmente el spam y que los ataques Sybil siguen siendo posibles, razón por la cual muchas implementaciones aún ponderarán a los revisores, mantendrán la reputación de los revisores o impondrán costos económicos en otros lugares.

Cómo funcionan las solicitudes y respuestas de validación

La validación es el registro donde las aplicaciones compran riesgo. El Registro de Validación admite la solicitud y el registro de verificaciones independientes de validadores, y la fuente principal describe una función validationRequest más respuestas de validadores puntuadas de 0 a 100.

Ese rango de 0 a 100 es deliberadamente flexible: una aplicación puede tratarlo como aprobado o fallido, o como un espectro donde diferentes validadores tienen diferentes umbrales.

El flujo es un patrón de solicitud-respuesta:

1. Un agente o consumidor llama a validationRequest para pedir a un validador que verifique alguna afirmación o resultado. 2. Un validador realiza su verificación utilizando la tecnología de garantía que soporte. 3. El validador publica una respuesta con una puntuación de 0 a 100 y puede adjuntar evidencia fuera de la cadena a través de URIs y hashes.

La importante elección de diseño es que el registro no codifica de forma rígida un único método de verificación. Las fuentes discuten múltiples mecanismos, incluyendo staking criptoeconómico, pruebas zkML y TEE.oráculoso atestaciones. Muchos despliegues pueden verificar atestaciones fuera de la cadena y luego publicar el resultado en la cadena, manteniendo la cadena como la capa de liquidación para "lo que se afirmó" y "quién lo dijo".

Aquí es donde la tesis aparece en una pantalla: ERC-8004 no convierte la confianza en una insignia binaria. Estandariza cómo un consumidor descubre al agente, y luego permite que el consumidor ajuste la garantía según el riesgo. El enrutamiento de bajo riesgo puede apoyarse en señales de reputación. Las acciones de riesgo medio pueden requerir validación respaldada por participación.

Las acciones de alto riesgo pueden exigir verificación criptográfica como atestaciones TEE o pruebas zkML, con el registro actuando como el lugar canónico para encontrar las respuestas más recientes.

Uniendo los registros de manera segura

Una integración segura compone los tres registros en una decisión de confianza escalonada en lugar de promediar todo en un único "puntaje de confianza". La identidad es la capa de búsqueda, la reputación es un historial portátil de contrapartes que hablan sobre resultados, y la validación es una compra explícita de garantía para un reclamo específico. Tratarles como números intercambiables es cómo las aplicaciones terminan confiando en lo incorrecto.

Un modelo de control práctico se mapea claramente a los modelos de confianza descritos en la guía principal:

1. Baja inversión: utiliza identidad más reputación para descubrimiento y enrutamiento. La aplicación lee tokenURI, verifica los campos de la tarjeta de agente que le interesan y utiliza señales de reputación como filtro. 2. Inversión media: requiere validación criptoeconómica. La aplicación solo avanza cuando la respuesta de un validador cumple con su umbral, y puede preferir validadores que publiquen resultados respaldados por participación.

3. Alta inversión: requiere verificación criptográfica. La aplicación exige atestaciones TEE o pruebas zkML, con el registro de validación almacenando la respuesta de 0 a 100 y punteros de evidencia.

El borde afilado es la deriva fuera de la cadena. El tokenURI del registro de identidad puede apuntar a un archivo de registro fuera de la cadena que cambia con el tiempo, y la cadena no advertirá a un consumidor que los puntos finales, identificadores o opciones de confianza publicitadas se han movido.

La versionado y el fijado de ese archivo, además de monitorear cambios, no son opcionales si el agente está realizando cualquier acción que toque fondos o datos sensibles.

La inmutabilidad también tiene sus desventajas. La fuente principal señala que los punteros y hashes en la cadena no pueden ser eliminados, lo cual es excelente paraauditoríasenderos y brutal para esquemas descuidados. Diseñar formatos de registro y retroalimentación teniendo en cuenta la revocación y la sustitución es importante porque el ecosistema acumulará migas de pan permanentes.

Este también es el lugar adecuado para corregir los conceptos erróneos comunes. ERC-8004 no coloca las capacidades del agente en la cadena. Almacena IDs, puntuaciones y punteros. Una única puntuación de reputación no equivale a confianza porque la Reputación y la Validación son libros de contabilidad diferentes destinados a diferentes niveles de riesgo.

La autorización como feedbackAuth reduce el spam arbitrario, pero no resuelve los ataques Sybil por sí sola. Esa es la verdadera forma de erc 8004 y cómo funciona cuando una aplicación intenta tomar una decisión con capital en juego, y es por eso que la identidad del agente 8004 se trata mejor como un canal que puedes ajustar.

La Perspectiva

He visto equipos construir paneles de "confianza del agente" que colapsan todo en un solo número, y luego actúan sorprendidos cuando el número les falla. El error costoso es promediar la Reputación y la Validación como si fueran lo mismo.activoNo lo son. La reputación es una historia de contrapartes autorizadas hablando.

La validación es un producto de aseguramiento con precio vinculado a un reclamo específico, con la tecnología de aseguramiento variando desde staking hasta zkML y atestaciones TEE.

Si una integración va a fallar, generalmente falla en la costura aburrida: tokenURI apunta a un archivo de registro fuera de la cadena, y ese archivo se desvía. El AgentID ERC-721 permanece igual, la interfaz de usuario sigue mostrando la misma tarjeta de agente, y los puntos finales o identificadores cambian silenciosamente por debajo. Por eso, la capa de identidad en ERC-8004 es intencionalmente simple. El trabajo consiste en monitorear a qué apunta y aumentar la validación cuando el nivel de riesgo lo exige.

Fuentes

• Aprender con Backpack
• Medio (Siddhant)