Carteras inteligentes y abstracción de cuentas: ERC-4337

Las billeteras de contratos inteligentes y la abstracción de cuentas trasladan la actividad de las billeteras de Ethereum de reglas de transacción eoa fijas a un pipeline programable donde se simula una UserOperation, se le asigna un precio y solo más tarde se convierte en una transacción en cadena por un bundler.

ERC-4337 es el diseño dominante de capa de aplicación para esto, y la verdadera clave es entender los nuevos intermediarios, APIs y modos de falla en lugar de memorizar características de UX.

Puntos clave

• ERC-4337 reemplaza el objeto de transacción normal con una UserOperation que se encuentra en un mempool separado hasta que un bundler la incluye en la cadena a través de handleOps de EntryPoint.
• Los bundlers son enrutadores de selección y ejecución, no relays pasivos, porque simulan operaciones, gestionan el riesgo de spam y eligen qué agrupar.
• ERC-7769 estandariza los métodos JSON-RPC wallet↔bundler como eth_sendUserOperation y eth_getUserOperationReceipt, lo que permite la portabilidad de bundlers y un mejor seguimiento de recibos.
• La abstracción de cuentascrea nuevas superficies de DoS y costos de computación, por lo que las reglas de validación, los sistemas de reputación y el endurecimiento de producción como el bloqueo de endpoints debug_* se convierten en parte del modelo de seguridad.

Cómo las billeteras de contratos inteligentes difieren de las EOAs

Dos tipos de “cuentas” diferentes aparecen en unEthereumpantalla: un eoa que firma una transacción directamente, y una cuenta de contrato que solo hace algo cuando se ejecuta el código. Unacontrato inteligentecartera hace que esa cuenta de contrato sea la cartera principal, por lo que las verificaciones de firma, las reglas de nonce y la lógica de ejecución se vuelven programables.

Ese es el núcleo de la abstracción de cuentas, y se encuentra dentro del mapa más amplio de tipos de carteras de criptomonedas explicado: la “cartera” ya no es solo un par de claves y un contador de nonce.

La consecuencia inmediata es que las características de la cartera dejan de estar codificadas de forma rígida en las reglas de eoa del protocolo. Una cuenta inteligente puede aceptar diferentes esquemas de firma, hacer cumplir políticas de gasto o restringir acciones detrás de múltiples condiciones porque la validación es código.

De ahí provienen características como la recuperación social y la categoría más amplia de carteras sin semilla y de recuperación social. El detalle importante es que estas características son posteriores al modelo de ejecución, no al modelo en sí.

En Ethereum, el camino dominante hacia la abstracción de cuentas es ERC-4337, que se enmarca explícitamente como un cambio a nivel de aplicación en lugar de un cambio en la capa de consenso. Ese enmarcado importa porque implica una nueva cadena de suministro de transacciones en lugar de una reescritura del protocolo.

La “acción de cartera” ya no es sinónimo de “una transacción transmitida al mempool público.” Se convierte en un objeto de intención que necesita un agente de inclusión.

Esa capa de agente de inclusión es donde la mayoría de las explicaciones se vuelven vagas. El modelo mental útil no es “una transacción normal con pasos adicionales.” El modelo útil es “un mercado de transacciones paralelo” con su propio mempool, sus propios enrutadores y sus propias restricciones operativas.

El flujo de operación de usuario de ERC-4337

Una UserOperation no aterriza en la cadena por sí sola. Vive fuera de la cadena hasta que un agrupador decide que vale la pena convertirla en una transacción en la cadena.

Las definiciones de ERC-7769 hacen que la secuencia sea explícita: en los flujos de ERC-4337, las transacciones de usuario son reemplazadas por objetos UserOperation, y un agrupador recoge una o más UserOperations y las envía al contrato EntryPoint en una sola llamada handleOps.

Ese pipeline tiene un orden limpio de eventos:

1. La cartera construye una UserOperation que codifica lo que el usuario quiere hacer y cómo se cubrirán las tarifas. 2. La UserOperation se envía a un nodo de mempool de UserOperation que la valida y la simula antes de aceptarla. 3. Un agrupador selecciona UserOperations aceptadas, las empaqueta y envía una transacción en la cadena que llama a EntryPoint.handleOps. 4.

EntryPoint ejecuta las operaciones, y la cadena produce un recibo de transacción normal para el paquete más los resultados por UserOperation.

La tesis del "mercado paralelo" aparece en el paso 3. La inclusión y el precio ya no son puramente el problema del usuario de establecer maxFeePerGas y esperar. El bundler asume el costo de cómputo y el riesgo de selección.

Por eso, algunos desarrolladores argumentan que el valor clave de ERC-4337 es un mercado de tarifas descentralizado para las operaciones de los usuarios que ingresan a las billeteras de contratos inteligentes, no solo una mejor experiencia de usuario.

Aquí es donde "la abstracción de cuentas explicada" tiende a equivocarse. El objeto que el usuario firma no está garantizado que se convierta en una transacción. El usuario puede hacer todo correctamente y aún así no ser incluido si los agrupadores no lo recogen, si la simulación falla o si la operación expira.

La postura adecuada de UX es tratar el hash de UserOperation como el identificador principal de seguimiento hasta la inclusión, y luego mapearlo al hash de la transacción del paquete después del hecho.

API y herramientas de billetera a empaquetador

ERC-4337 solo se vuelve utilizable a gran escala cuando las billeteras pueden comunicarse con los agrupadores de manera estandarizada. Eso es lo que añade ERC-7769: una superficie JSON-RPC que refleja la ergonomía de la presentación de transacciones normal de Ethereum y la búsqueda de recibos, pero para UserOperations.

Los métodos centrales que define ERC-7769 son aquellos que cambian las decisiones de integración diarias:

1. eth_sendUserOperation envía una UserOperation al mempool de UserOperation. El cliente la valida y la simula, y solo debe devolver un userOpHash si pasó la simulación y fue aceptada en el pool. 2. eth_estimateUserOperationGas estimagascampos para un UserOperation, ignorando la firma para fines de estimación. 3.

eth_getUserOperationByHash permite a una billetera consultar si una operación está pendiente, incluida o desconocida, y devuelve metadatos de inclusión como blockNumber y transactionHash cuando están disponibles. 4. eth_getUserOperationReceipt devuelve un recibo por operación una vez incluida, incluyendo actualGasCost, actualGasUsed y una bandera de éxito, mientras también devuelve el TransactionReceipt del paquete. 5.

eth_supportedEntryPoints informa a la billetera qué direcciones de EntryPoint soporta el bundler, que es la primera verificación de portabilidad que debe realizar un backend de billetera.

Esta es la historia de la infraestructura silenciosa: la estandarización es lo que hace posible un mercado competitivo de bundlers. Si una billetera habla ERC-7769, puede intercambiar backends de bundler sin reescribir toda su lógica de envío y seguimiento. Eso esdescentralización por interfaz, no por eslogan.

ERC-7769 también establece una línea dura entre las pruebas y la producción. Define debug_ métodos para el desarrollo y pruebas de compatibilidad, y especifica que estos métodos debug_ JSON-RPC deben ser bloqueados en servidores de producción. Eso no es etiqueta. Es parte del modelo de seguridad para cualquiera que opere infraestructura pública de AA.

ERC-7769 también hace referencia explícita al soporte de eip 7702 en el objeto UserOperation en redes donde está activado, a través de una tupla eip7702Auth. Las fuentes proporcionadas no determinan el alcance final de eip 7702 o el estado de activación en las redes, pero el trabajo de interfaz en ERC-7769 señala que la plomería de billetera↔bundler está siendo diseñada para acomodar esa dirección.

Seguridad de mempool, simulación y riesgos de DoS

La simulación es el centro de costos que hace que la abstracción de cuentas se sienta como ejecutar un motor de emparejamiento en lugar de una caja RPC pasiva. ERC-7769 es directo al respecto: operar un nodo ERC-4337 público en producción es intensivo en computación y puede ser un objetivo de DoS. Ese es el intercambio por tener un mempool de UserOperation separado donde los nodos deben validar y simular antes de aceptar operaciones.

La superficie de DoS es estructural. Un actor malicioso puede enviar operaciones que son baratas de enviar pero costosas de simular, obligando a los bundlers y nodos de mempool a consumir recursos computacionales.

ERC-7769 señala mitigaciones a través de las reglas de validación de ERC-7562 y mecanismos de reputación, que están diseñados para evitar que los nodos acepten UserOperations maliciosamente elaboradas y para rastrear la reputación de los participantes.

La insistencia del mismo documento en bloquear debug_* en producción es otra mitigación práctica, porque los puntos finales de depuración pueden exponer comportamientos de restablecimiento de estado y agrupamiento forzado que son útiles en pruebas y peligrosos en internet abierto.

ERC-5189 existe porque la salud del mempool es la parte difícil, y ataca el problema desde un ángulo diferente. Propone la abstracción de cuentas a través de una estructura Operation y contratos de “endorser”, evitando explícitamente nuevos tipos de transacciones en la capa de consenso mientras se mantiene compatible con billeteras de contratos inteligentes existentes.

El trabajo del endorser es ayudar a los bundlers a filtrar “buenas operaciones” de “malas operaciones” en un mempool de operaciones dedicado.

El mecanismo clave en ERC-5189 es que el endorser devuelve información de preparación más información de dependencia. Esa señalización de dependencia le dice a los bundlers qué cambios de estado deberían desencadenar una reevaluación, lo que es una forma de mantener un mempool de pudriéndose con operaciones que ya no son válidas.

ERC-5189 aún no escapa a la restricción central: los bundlers deben simular la ejecución fuera de la cadena antes de la inclusión, y los operadores de mempool pueden prohibir a los endorsers que se comporten mal. El diseño está negociando el mismo intercambio entre apertura y resistencia al spam, solo que con una plomería diferente.

Caminos en competencia para la abstracción de cuentas

Los desarrolladores de Ethereum no están debatiendo si las billeteras de contratos inteligentes son útiles. Están debatiendo qué camino se convierte en el predeterminado a largo plazo y qué compensaciones son aceptables.

Una línea de falla visible es EIP-3074 frente a ERC-4337, con argumentos de que 3074 podría ofrecer mejoras inmediatas en la experiencia del usuario, mientras que el grupo de 4337 enfatiza propiedades como la resistencia a la censura y, crucialmente, el mercado de tarifas descentralizado para las operaciones de los usuarios.

Ese debate es importante para los constructores porque cambia lo que significa 'infraestructura de billetera'. ERC-4337 empuja la complejidad hacia un mercado de transacciones paralelo: UserOperations, agrupadores, EntryPoint, reglas de simulación, sistemas de reputación y ahora RPC estandarizado a través de ERC-7769.

Ese stack puede evolucionar sin un fork de protocolo duro, pero también crea nuevos intermediarios cuyos incentivos y tiempo de actividad se convierten en parte de la experiencia del usuario.

La otra razón por la que existen múltiples propuestas es que 'la abstracción de cuentas' es un término general. Algunas propuestas se centran en la presentación de intenciones y los mercados de inclusión. Otras se enfocan en cómo hacer que las cuentas de contrato se sientan como EOAs sin forzar a cada billetera a actualizarse.

El objetivo de compatibilidad de ERC-5189 es explícito: apoyar las implementaciones existentes de billeteras de contratos inteligentes sin requerir que cada instancia de billetera sea actualizada manualmente.

Las fuentes también señalan eip 7702 como una dirección más nueva introducida en mayo de 2024 por Vitalik Buterin y otros, enmarcada como una solución a las limitaciones del enfoque a nivel de aplicación.

El material proporcionado no incluye los detalles de especificación de eip 7702, por lo que la única conclusión responsable es la conciencia del alcance: el ecosistema está construyendo interfaces, como el tuple opcional eip7702Auth de ERC-7769, que anticipan cambios.

Conceptos erróneos comunes sobre las billeteras de contratos inteligentes y la abstracción de cuentas

“La abstracción de cuentas es una actualización de protocolo que cambia las cuentas de Ethereum.” ERC-4337 se enmarca a nivel de aplicación, lo que significa que no cambia cómo el protocolo de Ethereum en sí ve las cuentas. El protocolo sigue viendo EOAs y cuentas de contrato. La abstracción se construye mediante contratos más infraestructura fuera de la cadena.

“Los agrupadores son solo retransmisores.” Un retransmisor reenvía una transacción. Un agrupador ejecuta validación y simulación, elige qué UserOperations aceptar y las empaqueta en una llamada handleOps a EntryPoint. Ese rol de selección es la razón por la cual los agrupadores heredan la exposición a DoS y por la cual los mecanismos de reputación y filtrado aparecen en los estándares.

“AA se trata principalmente de recuperación social y claves de sesión.” Esas son características de billetera que se vuelven más fáciles cuando la validación es programable, y la recuperación social es un ejemplo común. El diferenciador que cambia la estructura del mercado es el pipeline UserOperation + agrupador + EntryPoint y el mempool separado que implica.

“El seguimiento funciona como hashes de tx normales.” ERC-7769 agrega explícitamente métodos por hash y de recibo para UserOperations porque la semántica de hash de tx no se aplica hasta que un agrupador incluye la operación. Las billeteras que tratan la presentación como final enviarán estados pendientes rotos y un manejo de fallos confuso.

La Toma

He visto equipos lanzar "UX de cuenta inteligente" que se veían impresionantes en las demostraciones y luego se desmoronaron bajo carga porque trataron ERC-4337 como una transacción normal disfrazada. El costoso error es ignorar la capa de inclusión. Una UserOperation es una orden en un lugar separado, y solo se convierte en una transacción de cadena cuando un bundler decide enrutarla a través de EntryPoint.handleOps.

Si hay una postura que ahorra tiempo, es construir alrededor de la plomería: métodos ERC-7769 para el seguimiento de envío y recepción, estados pendientes explícitos y portabilidad de bundler a través de eth_supportedEntryPoints. En el lado de la infraestructura, he visto a personas exponer puntos finales debug_* en servidores públicos y actuar sorprendidos cuando son abusados. ERC-7769 lo señala por una razón. La abstracción de cuentas es un mercado de transacciones paralelo, y los mercados atraen flujos adversariales.

Fuentes

• Propuestas de Mejora de Ethereum
• Propuestas de Mejora de Ethereum
• Desencadenado
• blockcryptowriter.medium.com