Saltar al contenido principal

3 publicaciones etiquetados con "ERC-4337"

Ver Todas las Etiquetas

Dos Vías para un Ethereum más Amigable: Cuentas Inteligentes ERC‑4337 + ERC‑4804 URLs Web3

· 9 min de lectura
Dora Noda
Software Engineer

TL;DR

Ethereum acaba de obtener dos primitivas poderosas que llevan la experiencia de usuario más allá de las frases semilla y las dapps marcables, hacia “experiencias en cadena clicables”.

  • ERC-4337 trae abstracción de cuentas al Ethereum actual sin cambios en el protocolo base. Esto hace que funciones como cuentas de contrato inteligente, patrocinio de gas, llamadas agrupadas y autenticación al estilo de passkey sean nativas de las carteras.
  • ERC-4804 introduce URLs web3:// — enlaces legibles por humanos que se resuelven directamente en llamadas de lectura a contratos y pueden incluso renderizar HTML o SVG en cadena, todo sin un servidor web tradicional como intermediario. Piensa en ello como “HTTP para el EVM”.

Cuando se usan juntos, ERC-4337 maneja las acciones, mientras que ERC-4804 maneja las direcciones. Esta combinación permite compartir un enlace que extrae verificablemente su interfaz de usuario de un contrato inteligente. Cuando el usuario está listo para actuar, el flujo pasa a una cuenta inteligente que puede patrocinar el gas y agrupar varios pasos en un solo clic sin fisuras.


Por Qué Importa Ahora

No es solo un futuro teórico; estas tecnologías están en vivo y ganando tracción significativa. ERC-4337 ya está escalado y probado en producción. El contrato canónico EntryPoint se desplegó en la mainnet de Ethereum el 1 de marzo de 2023 y desde entonces ha impulsado decenas de millones de cuentas de contrato inteligente y procesado más de 100 millones de operaciones de usuario.

Simultáneamente, el protocolo base está convergiendo con estas ideas. La actualización Pectra, lanzada en mayo de 2025, incluyó EIP-7702, que permite que las cuentas externas estándar (EOA) se comporten temporalmente como cuentas inteligentes. Esto complementa a ERC-4337 al facilitar la transición para usuarios existentes, en lugar de reemplazar el estándar.

En el frente de direccionamiento, web3:// ya está formalizado. ERC-4804 especifica exactamente cómo una URL se traduce en una llamada EVM, y web3 ha sido listado por IANA como un esquema URI provisional. Las herramientas y pasarelas necesarias para hacer prácticas estas URLs ya están disponibles, convirtiendo datos en cadena en recursos compartibles y enlazables.


Introducción: ERC-4337 en una Página

En su esencia, ERC-4337 introduce una vía de transacción paralela a Ethereum, construida para flexibilidad. En lugar de transacciones tradicionales, los usuarios envían objetos UserOperation a un mempool alternativo. Estos objetos describen lo que la cuenta quiere hacer. Nodos especializados llamados “Bundlers” recogen estas operaciones y las ejecutan a través de un contrato global EntryPoint.

Esto habilita tres componentes clave:

  1. Cuentas de Contrato Inteligente (SCAs): Estas cuentas contienen su propia lógica. Definen qué hace válida una transacción, permitiendo esquemas de firma personalizados (como passkeys o multisig), claves de sesión para juegos, límites de gasto y mecanismos de recuperación social. La cuenta, no la red, impone las reglas.
  2. Paymasters: Estos contratos especiales pueden patrocinar las tarifas de gas para los usuarios o permitirles pagar con tokens ERC‑20. Esta es la clave para desbloquear una incorporación real de “sin ETH en la cartera” y crear experiencias de un solo clic al agrupar múltiples llamadas en una única operación.
  3. Seguridad DoS y Reglas: El mempool público de ERC‑4337 está protegido por reglas de validación off‑chain estandarizadas (definidas en ERC‑7562) que evitan que los Bundlers desperdicien recursos en operaciones destinadas a fallar. Si bien pueden existir mempools alternativos para casos de uso especializados, estas reglas compartidas mantienen el ecosistema coherente y seguro.

Modelo mental: ERC‑4337 convierte las carteras en aplicaciones programables. En lugar de solo firmar transacciones crudas, los usuarios envían “intenciones” que el código de su cuenta valida y el contrato EntryPoint ejecuta — de forma segura y atómica.


Introducción: ERC-4804 en una Página

ERC‑4804 ofrece un mapeo simple y directo de una URL web3:// a una llamada solo de lectura en EVM. La gramática de la URL es intuitiva: web3://<nombre-o-dirección>[:chainId]/<método>/<arg0>?returns=(tipos). Los nombres pueden resolverse mediante sistemas como ENS, y los argumentos se tipan automáticamente según el ABI del contrato.

Algunos ejemplos:

  • web3://uniswap.eth/ llamaría al contrato en la dirección uniswap.eth con calldata vacío.
  • web3://.../balanceOf/vitalik.eth?returns=(uint256) codificaría en ABI una llamada a la función balanceOf con la dirección de Vitalik y devolvería un resultado JSON tipado correctamente.

Crucialmente, este estándar es actualmente para llamadas solo de lectura (equivalentes a funciones view de Solidity). Cualquier acción que cambie el estado sigue requiriendo una transacción — justo donde entran ERC‑4337 o EIP‑7702. Con web3 registrado como esquema URI provisional en IANA, el camino está abierto para soporte nativo en navegadores y clientes, aunque por ahora a menudo depende de extensiones o pasarelas.

Modelo mental: ERC‑4804 convierte recursos en cadena en objetos web enlazables. “Compartir esta vista de contrato como URL” se vuelve tan natural como compartir un enlace a un panel de control.


Juntos: “Experiencias En Cadena Clicables”

Combinar estos dos estándares desbloquea un patrón poderoso para construir aplicaciones descentralizadas hoy.

Primero, entregas una UI verificable vía web3://. En lugar de alojar tu frontend en un servidor centralizado como S3, puedes almacenar una interfaz HTML o SVG mínima directamente en cadena. Un enlace como web3://app.eth/render permite al cliente resolver la URL y renderizar la UI directamente desde el contrato, asegurando que el usuario vea exactamente lo que el código dicta.

Desde esa interfaz verificable, puedes disparar una acción de un solo clic vía ERC‑4337. Un botón “Mint” o “Subscribe” puede compilar una UserOperation que un paymaster patrocina. El usuario aprueba con una passkey o un simple prompt biométrico, y el contrato EntryPoint ejecuta una llamada agrupada que despliega su cuenta inteligente (si es su primera vez) y completa la acción deseada en un solo paso atómico.

Esto crea una transferencia profunda de enlace. La UI puede incrustar enlaces basados en intención que son manejados directamente por la cartera del usuario, eliminando la necesidad de enviarlos a un sitio externo que pueda no ser de confianza. El contenido es el contrato, y la acción es la cuenta.

Esto habilita:

  • Pruebas sin gas y onboarding “just works”: Los nuevos usuarios no necesitan adquirir ETH para comenzar. Tu aplicación puede patrocinar sus primeras interacciones, reduciendo drásticamente la fricción.
  • Estado compartible: Un enlace web3:// es una consulta al estado de la blockchain. Perfecto para dashboards, pruebas de propiedad o cualquier contenido que deba ser verificablemente a prueba de manipulaciones.
  • Flujos amigables para agentes: Los agentes de IA pueden obtener estado verificable vía URLs web3:// y enviar intenciones transaccionales a través de ERC‑4337 usando claves de sesión limitadas, todo sin scraping de pantalla frágil o manejo inseguro de claves privadas.

Notas de Diseño para Constructores

Al implementar estos estándares, hay algunas decisiones arquitectónicas a considerar. Para ERC‑4337, es aconsejable comenzar con plantillas mínimas de cuentas inteligentes y añadir capacidades mediante módulos guardados para mantener la lógica de validación central simple y segura. Tu política de paymaster debe ser robusta, con límites claros en el gas patrocinado y listas blancas de métodos aprobados para prevenir ataques de griefing.

Para ERC‑4804, prioriza enlaces legibles usando nombres ENS. Sé explícito con el chainId para evitar ambigüedades e incluye el parámetro returns=(…) para asegurar que los clientes reciban respuestas tipadas y predecibles. Aunque puedes renderizar UI completas, suele ser mejor mantener HTML/SVG en cadena al mínimo, usándolos como shells verificables que pueden obtener activos más pesados de almacenamiento descentralizado como IPFS.

Finalmente, recuerda que EIP‑7702 y ERC‑4337 trabajan juntos, no en contra. Con EIP‑7702 activo en la actualización Pectra, los usuarios de EOAs existentes pueden delegar acciones a lógica de contrato sin desplegar una cuenta inteligente completa. Las herramientas del ecosistema de abstracción de cuentas ya se están alineando para soportar esto, suavizando la ruta de migración para todos.


Seguridad, Realidad y Limitaciones

Aunque potentes, estos sistemas tienen compensaciones. El contrato EntryPoint es un punto de estrangulamiento central por diseño; simplifica el modelo de seguridad pero también concentra riesgo. Siempre utiliza versiones auditadas y canónicas. Las reglas de validación del mempool de ERC‑7562 son una convención social, no una regla impuesta on‑chain, así que no asumas que todo mempool alternativo ofrece la misma resistencia a censura o protección DoS.

Además, web3:// sigue madurando. Sigue siendo un estándar de solo lectura, y cualquier operación de escritura requiere una transacción. Si bien el protocolo es descentralizado, las pasarelas y clientes que resuelven estas URLs pueden ser puntos potenciales de falla o censura. La verdadera “desbloqueabilidad” dependerá de un soporte nativo amplio en clientes.


Un Plano Concreto

Imagina que quieres construir un club de membresía impulsado por NFT con una UI verificable y un proceso de unión de un solo clic. Así podrías implementarlo este trimestre:

  1. Compartir la UI: Distribuye un enlace como web3://club.eth/home. Cuando un usuario lo abre, su cliente resuelve la URL, llama al contrato y renderiza una UI en cadena que muestra la lista de miembros permitidos y el precio de mint.
  2. Unión de Un Solo Clic: El usuario pulsa un botón “Unirse”. Su cartera compila una UserOperation de ERC‑4337 patrocinada por tu paymaster. Esta única operación agrupa tres llamadas: desplegar la cuenta inteligente del usuario (si no la tiene), pagar la tarifa de mint y registrar sus datos de perfil.
  3. Recibo Verificable: Tras la confirmación de la transacción, al usuario se le muestra una vista de confirmación que es otro enlace web3://, como web3://club.eth/receipt/<tokenId>, creando un vínculo permanente en cadena a su prueba de membresía.

El Gran Panorama

Estos dos estándares señalan un cambio fundamental en cómo construimos sobre Ethereum. Las cuentas se están convirtiendo en software. ERC‑4337 y EIP‑7702 están transformando la “UX de la cartera” en un espacio para verdadera innovación de producto, yendo más allá de las lecciones sobre gestión de claves. Al mismo tiempo, los enlaces se están convirtiendo en consultas. ERC‑4804 devuelve la URL como un primitivo para direccionar hechos verificables en cadena, no solo los frontends que los proxy.

Juntos, acortan la brecha entre lo que los usuarios hacen clic y lo que los contratos ejecutan. Esa brecha antes estaba llena por servidores web centralizados y suposiciones de confianza. Ahora puede ser cubierta por rutas de código verificables y mempools abiertos y sin permisos.

Si construyes aplicaciones cripto de consumo, esta es tu oportunidad de hacer que el primer minuto del usuario sea encantador. Comparte un enlace, muestra la verdad, patrocina la primera acción y mantén a tus usuarios dentro de un bucle verificable. Las vías están aquí — ahora es momento de lanzar las experiencias.

La Revolución de las Carteras: Navegando los Tres Caminos de la Abstracción de Cuentas

· 6 min de lectura
Dora Noda
Software Engineer

Durante años, el mundo cripto ha estado limitado por un problema crítico de usabilidad: la cartera. Las carteras tradicionales, conocidas como Cuentas Externamente Poseídas (EOA), son implacables. Una sola frase semilla perdida significa que tus fondos se van para siempre. Cada acción requiere una firma y las tarifas de gas deben pagarse con el token nativo de la cadena. Esta experiencia torpe y de alto riesgo es una barrera importante para la adopción masiva.

Entra Abstracción de Cuentas (AA), un cambio de paradigma que redefinirá cómo interactuamos con la cadena de bloques. En esencia, AA transforma la cuenta del usuario en un contrato inteligente programable, desbloqueando funciones como recuperación social, transacciones con un clic y pagos de gas flexibles.

El camino hacia este futuro más inteligente se está desarrollando a lo largo de tres rutas distintas: el probado ERC-4337, el eficiente Native AA y el muy esperado EIP-7702. Analicemos qué significa cada enfoque para desarrolladores y usuarios.


💡 Ruta 1: El Pionero — ERC-4337

ERC-4337 fue el avance que llevó la abstracción de cuentas a Ethereum y a las cadenas EVM sin modificar el protocolo central. Piensa en ello como una capa inteligente añadida sobre el sistema existente.

Introduce un nuevo flujo de transacciones que involucra:

  • UserOperations: Un nuevo objeto que representa la intención del usuario (p. ej., “intercambiar 100 USDC por ETH”).
  • Bundlers: Actores fuera de la cadena que recogen UserOperations, los agrupan y los envían a la red.
  • EntryPoint: Un contrato inteligente global que valida y ejecuta las operaciones agrupadas.

Lo Bueno:

  • Compatibilidad Universal: Puede desplegarse en cualquier cadena EVM.
  • Flexibilidad: Permite funciones avanzadas como claves de sesión para juegos, seguridad multfirmas y patrocinio de gas mediante Paymasters.

El Compromiso:

  • Complejidad y Coste: Introduce una sobrecarga de infraestructura significativa (ejecución de Bundlers) y tiene los costos de gas más altos de los tres enfoques, ya que cada operación pasa por la lógica adicional de EntryPoint. Por eso, su adopción se ha concentrado principalmente en L2s de bajo costo como Base y Polygon.

ERC-4337 abrió el camino para que otras soluciones AA pudieran funcionar. Demostró la demanda y sentó las bases para una experiencia Web3 más intuitiva.


🚀 Ruta 2: El Ideal Integrado — Native Account Abstraction

Si ERC-4337 es un complemento, Native AA construye funciones inteligentes directamente en la base de la cadena. Cadenas como zkSync Era y Starknet fueron diseñadas desde cero con AA como principio central. En estas redes, cada cuenta es un contrato inteligente.

Lo Bueno:

  • Eficiencia: Al integrar la lógica AA en el protocolo, se eliminan capas extra, lo que genera costos de gas significativamente menores en comparación con ERC-4337.
  • Simplicidad para los Desarrolladores: No es necesario gestionar Bundlers ni un mempool separado. El flujo de transacciones se asemeja mucho al de una operación estándar.

El Compromiso:

  • Fragmentación del Ecosistema: Native AA es específico de cada cadena. Una cuenta en zkSync es distinta de una cuenta en Starknet, y ninguna es nativa de Ethereum mainnet. Esto crea una experiencia fragmentada para usuarios y desarrolladores que operan en múltiples cadenas.

Native AA nos muestra el “juego final” en términos de eficiencia, pero su adopción está ligada al crecimiento de los ecosistemas que la alojan.


🌉 Ruta 3: El Puente Pragmático — EIP-7702

Programado para incluirse en la actualización “Pectra” de Ethereum en 2025, EIP-7702 es un cambio de juego diseñado para llevar funciones AA a la masa de usuarios de EOAs existentes. Adopta un enfoque híbrido: permite que una EOA delegue temporalmente su autoridad a un contrato inteligente para una única transacción.

Piensa en ello como otorgar superpoderes temporales a tu EOA. No necesitas migrar fondos ni cambiar tu dirección. Tu cartera simplemente añade una autorización a la transacción, permitiendo ejecutar operaciones agrupadas (p. ej., aprobar + intercambiar con un clic) o recibir patrocinio de gas.

Lo Bueno:

  • Compatibilidad Retroactiva: Funciona con los miles de millones de dólares asegurados por EOAs actuales. No se requiere migración.
  • Baja Complejidad: Utiliza el pool de transacciones estándar, eliminando la necesidad de Bundlers y simplificando drásticamente la infraestructura.
  • Catalizador de Adopción Masiva: Al hacer que funciones inteligentes estén al alcance de cualquier usuario de Ethereum de la noche a la mañana, podría acelerar rápidamente la adopción de mejores patrones de UX.

El Compromiso:

  • No es “AA Completa”: EIP-7702 no resuelve la gestión de claves de la propia EOA. Si pierdes tu clave privada, sigues sin suerte. Se trata más de mejorar las capacidades de transacción que de rehacer la seguridad de la cuenta.

Comparación Directa: Un Análisis Claro

CaracterísticaERC-4337 (El Pionero)Native AA (El Ideal)EIP-7702 (El Puente)
Idea CentralSistema de contrato inteligente externo vía BundlersCuentas inteligentes a nivel de protocoloEOA delega temporalmente a un contrato inteligente
Costo de GasMás alto (por la sobrecarga de EntryPoint)Bajo (optimizado por el protocolo)Moderado (pequeña sobrecarga en una transacción de agrupado)
InfraestructuraAlta (requiere Bundlers, Paymasters)Baja (gestionada por los validadores de la cadena)Mínima (usa la infraestructura de transacciones existente)
Caso de Uso PrincipalAA flexible en cualquier cadena EVM, especialmente L2AA altamente eficiente en L2s diseñadas para elloMejora de EOAs existentes con funciones inteligentes
Ideal Para…Carteras de juegos, dApps que necesiten onboarding sin gas ahoraProyectos construidos exclusivamente en zkSync/StarknetLlevar agrupamiento y patrocinio de gas al usuario mainstream

El Futuro es Convergente y Centrado en el Usuario

Estas tres rutas no son mutuamente excluyentes; están convergiendo hacia un futuro donde la cartera deja de ser un punto de fricción.

  1. La Recuperación Social se Vuelve Estándar 🛡️: La era de “claves perdidas, fondos perdidos” está terminando. AA permite la recuperación basada en guardianes, haciendo que la auto‑custodia sea tan segura y indulgente como una cuenta bancaria tradicional.
  2. UX de Juegos Rediseñada 🎮: Las claves de sesión permitirán una jugabilidad fluida sin constantes ventanas de “aprobar transacción”, logrando que los juegos Web3 se sientan como los juegos Web2.
  3. Carteras como Plataformas Programables: Las carteras se volverán modulares. Los usuarios podrán añadir un “módulo DeFi” para farming automatizado o un “módulo de seguridad” que requiera 2FA para transferencias grandes.

Para desarrolladores y proveedores de infraestructura como Blockeden.xyz, esta evolución es increíblemente emocionante. La complejidad de Bundlers, Paymasters y los distintos estándares AA crea una gran oportunidad para ofrecer infraestructura robusta, fiable y abstracta. El objetivo es una experiencia unificada donde el desarrollador pueda integrar fácilmente funciones AA, y la cartera utilice inteligentemente ERC-4337, Native AA o EIP-7702 bajo el capó, según lo que soporte la cadena.

La cartera finalmente recibe la actualización que merece. La transición de EOAs estáticas a cuentas inteligentes dinámicas no es solo una mejora—es la revolución que hará que Web3 sea accesible y segura para el próximo billón de usuarios.

ERC-4337: Revolucionando Ethereum con Abstracción de Cuentas

· 4 min de lectura
Dora Noda
Software Engineer

¡Hola y bienvenidos de nuevo a nuestro blog de blockchain! Hoy nos sumergiremos en una nueva propuesta emocionante llamada ERC-4337, que introduce la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. En su lugar, esta propuesta se basa en infraestructura de capa superior para lograr sus objetivos. Exploremos lo que ERC-4337 tiene para ofrecer y cómo aborda las limitaciones del ecosistema actual de Ethereum.

¿Qué es ERC-4337?

ERC-4337 es una propuesta que introduce la abstracción de cuentas en Ethereum mediante el uso de un mempool separado y un nuevo tipo de objeto pseudo‑transacción llamado UserOperation. Los usuarios envían objetos UserOperation al mempool alternativo, donde una clase especial de actores llamados bundlers los empaquetan en una transacción que realiza una llamada handleOps a un contrato dedicado. Estas transacciones se incluyen luego en un bloque.

La propuesta busca lograr varios objetivos:

  1. Permitir a los usuarios utilizar carteras de contratos inteligentes con lógica de verificación arbitraria como sus cuentas principales.
  2. Eliminar por completo la necesidad de que los usuarios tengan cuentas externas (EOAs).
  3. Garantizar la descentralización permitiendo que cualquier bundler participe en el proceso de inclusión de operaciones de usuario con abstracción de cuentas.
  4. Permitir que toda la actividad ocurra a través de un mempool público, eliminando la necesidad de que los usuarios conozcan direcciones de comunicación directa de actores específicos.
  5. Evitar suposiciones de confianza sobre los bundlers.
  6. Evitar requerir cambios en el consenso de Ethereum para una adopción más rápida.
  7. Soportar otros casos de uso como aplicaciones que preservan la privacidad, multi‑operaciones atómicas, pagar tarifas de transacción con tokens ERC‑20 y transacciones patrocinadas por desarrolladores.

Compatibilidad hacia atrás

Dado que ERC-4337 no modifica la capa de consenso, no existen problemas directos de compatibilidad hacia atrás para Ethereum. Sin embargo, las cuentas anteriores a ERC-4337 no son fácilmente compatibles con el nuevo sistema porque carecen de la función validateUserOp necesaria. Esto puede solucionarse creando una cuenta compatible con ERC-4337 que re‑implemente la lógica de verificación como un wrapper y configurándola como el remitente de operaciones de confianza de la cuenta original.

Implementación de referencia

Para quienes estén interesados en profundizar en los detalles técnicos de ERC-4337, hay una implementación de referencia disponible en https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Consideraciones de seguridad

El contrato de punto de entrada para ERC-4337 debe ser auditado exhaustivamente y verificado formalmente, ya que sirve como punto central de confianza para todo el sistema. Si bien este enfoque reduce la carga de auditoría y verificación formal para cuentas individuales, concentra el riesgo de seguridad en el contrato de punto de entrada, que debe ser verificado de manera robusta.

La verificación debe cubrir dos afirmaciones principales:

  1. Seguridad contra secuestros arbitrarios: el punto de entrada solo llama a una cuenta de forma genérica si la función validateUserOp de esa cuenta específica ha pasado.
  2. Seguridad contra el drenaje de tarifas: si el punto de entrada llama a validateUserOp y pasa, también debe realizar la llamada genérica con calldata igual a op.calldata.

Conclusión

ERC-4337 es una propuesta emocionante que busca introducir la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. Al utilizar infraestructura de capa superior, abre nuevas posibilidades para la descentralización, la flexibilidad y diversos casos de uso. Aunque existen consideraciones de seguridad que abordar, esta propuesta tiene el potencial de mejorar significativamente el ecosistema de Ethereum y la experiencia del usuario.