Website ↗Telegram ↗Twitter ↗

Account Abstraction - Estándares y Relayers

Autor - Lorena - Abr '25

ERC-4337: del modelo EOA a las Smart Contract Wallets

Con este estándar, llega una nueva forma de pensar las wallets: más seguras, programables y fáciles de usar. En este artículo se pone en contexto qué es Account Abstraction y cómo funciona desde adentro. Así también, se destaca a las Smart Contract Wallets, los relayers y cómo ERC-4337 hace posible el prescindir de cambios a nivel protocolo para dar lugar a las Smart Contract Wallets.

EOAs (Externally Owned Accounts)

El tipo de cuenta más común en Ethereum es aquella que está controlada por una clave privada, la típica wallet que tienes, por ejemplo, en Metamask. A esta clave privada se la conoce como EOA (Externally Owned Account). Una transacción firmada y validada por una EOA es incluida en la red de Ethereum.

En este gráfico vemos que una vez generado el par de claves (pública y privada), la clave pública pasa a ser el address del usuario que a su vez, forma parte de la instrucción de enviar 1 ETH a otra address. Se genera una firma que se chequea y valida mediante algún validador de la red de Ethereum para ser incluido posteriormente en un bloque.

Este chequeo y validación consiste en ver que la firma se haya generado a partir de una clave privada asociada a una address de usuario, lo que implica que siempre se debe tener un control total de la clave privada. No se puede perder acceso a ella ni tampoco exponerla.

Es aquí donde se genera la problemática principal. El usuario necesita esforzarse en conocer y entender cómo funcionan las cuentas en Ethereum. Por ende, no se logra una adopción considerable de una multitud de productos Web3.

Account Abstraction y las Smart Contract Wallets

Para entender mejor la motivación del ERC-4337, revisemos los primeros pasos de Account Abstraction a partir de la introducción a las Smart Contract Wallets. Las SCW permiten aplicar lógicas arbitrarias de validación de transacciones. En el paradigma original de las SCW, un usuario cuenta con dos addresses en Ethereum:

  • La EOA para firmar y pagar los fees por cada transacción

  • La SCW en donde se almacenan los fondos

En este punto, el usuario aún envía transacciones a través la EOA, con una firma chequeada por un validador previamente. Pero ahora, se agrega el detalle de que la transacción es un llamado a una función contenida en la SCW.

Ese llamado es el que propicia la validación arbitraria de la transacción. En donde se puede implementar seguridad con múltiples claves u otras características.

¿Cómo es que se generan las instrucciones y credenciales para el usuario?

EIP-712

Este es uno de los estándares de hashing de datos y firmas más común para ello. Esta propuesta buscó mejorar la usabilidad de las firmas de mensajes off-chain que luego debían pasar a usarse on-chain. Sobre todo porque los mensajes off-chain ahorran gas y reducen el número de transacciones en la blockchain.

Previo a su implementación, casi no había contexto/información para el usuario sobre lo que debe firmar. Propuso un esquema para codificar datos con mayor contexto, en conjunto con su estructura, lo que permite desplegar esos datos de forma más amigable al momento de que el usuario apruebe la firma o la rechace.

EIP-3074

En el 2020, la EIP-3074 se presentó como una mejora para permitir que las EOAs deleguen su control a un contrato inteligente que lo respalde. Lo que haría posible generar estas cuentas con características de contratos inteligentes para que puedan operar a nombre de la EOA del usuario. Así, el usuario final no se haría responsable de gestionar todas las claves privadas de los contratos inteligentes.

Esta EIP reconoce más abiertamente la dificultad de implementar AA a nivel más bajo y core del protocolo. Por lo que implementar AA bajo esta EIP, brindaría a los desarrolladores un framework flexible para construir nuevos esquemas de transacciones para las EOAs.

Los Relayers

Que el usuario necesite de una EOA adicional con ETH para pagar fees añade una complejidad que perjudica la experiencia de uso, sobre todo si hablamos de usuarios “no expertos”. Para poder abstraer la necesidad de pagar por fees, se añade al relayer.

El usuario solamente necesita especificar sus credenciales e instrucciones para la transacción. Mientras que el relayer los empaqueta dentro de una sola transacción en Ethereum para después mandarlo a la red. El pago del fee se puede gestionar de una de estas maneras:

  • Se subsidian mediante el relayer

  • Se “reembolsa” el valor del fee al relayer mediante el balance de la SCW u otra cuenta “sponsor”

Los credenciales del usuario se validan con lógica arbitraria de parte de la SCW, preservando su característica self-custodial: únicamente el usuario puede inicializar una transacción.

ERC-4337 para la descentralización de los relays

Hasta este punto, la introducción de los relayers como parte del diseño de Account Abstraction tiene algunos detalles que lo dejan con limitaciones y potenciales puntos de falla:

  • La transacción del usuario se empaqueta en una transacción que hace un llamado a la SCW

  • Cada transacción en el relay debería tener al menos un overhead de gas por valor de 21000

  • No hay un estándar específico que defina cómo sería compensado ese relayer por cubrir el pago de los fees

  • Las wallets acostumbran a implementar servicios de relayers centralizados. Lo cual da pie a posibles censuras y riesgos de único punto de falla

Aquí es donde aparece el ERC-4337 para descentralizar al relayer gracias a la participación de la red de bundlers:

Características esenciales y esquema de funcionamiento

En vez de modificar la lógica de la capa de consenso, se replica la funcionalidad de la mempool de transacciones en un sistema de alto nivel.

Los usuarios envían objetos UserOperationque éstos a su vez, juntan los intents de los usuarios con las firmas y otros datos para verificación. Ya sean los block builders o bundlers que usen servicios como Flashbots, éstos pueden agrupar varios objetos UserOperation y ese conjunto se convierte en una bundle transaction (transacción empaquetada) que después es incluido en un bloque de la chain de Ethereum.

El bundler paga el fee por la transacción empaquetada con ETH y es recompensado a través de los fees pagados por las ejecuciones de los distintos objetos UserOperation.

Una UserOperation parece una transacción. Básicamente, es una estructura ABI que incluye a algunos de los siguientes campos:

  • sender: la wallet que realiza la operación

  • nonce y signature: parámetros que pasan por la función de verificación por parte de la wallet para que éste pueda verificar la operación

  • initCode: un código para crear la wallet si es que la misma aún no existe

  • callData: datos con los que se deben llamar a la wallet para el paso de ejecución

En el ERC-4337, una wallet es un contrato inteligente y requiere de dos funciones:

  • validateUserOp: que toma a un UserOperation como parámetro de input. Esta función verifica el nonce y la signature en el UserOperation, paga el fee e incrementa el valor del nonce si es que la verificación es exitosa. Lanzará una excepción si es que falla dicha verificación.

  • Una función de ejecución que interpreta la calldata como una instrucción dirigida a la wallet para tomar acción. La manera en que esta función interpreta la calldata y lo que hace como resultado de esto es completamente a criterio de cada uno. Sin embargo, lo que se espera es realizar el parsing de la calldata como instrucción dirigida a la wallet para realizar una o más llamadas.

Para simplificar la lógica de las wallets, gran parte de la complejidad de los contratos inteligentes no se da en la wallet, sino en un contrato de tipo global llamado entry point. La función validateUserOp y otras funciones de ejecución son controlados por require(msg.sender == ENTRY_POINT) , por lo que solamente un entry point confiable puede provocar que la wallet realice ciertas acciones o pagar fees.

El entry point solamente hace un llamado arbitrario a la wallet después de ejecutar un validateUserOp con un UserOperation que lleva consigo el calldata ya validado exitosamente. Esto es suficiente para proteger a las wallets de ataques. Así mismo, el entry point es responsable de crear una wallet utilizando el initCode proveído anteriormente si es que no existe aún.

Existen algunas restricciones que los mempool nodoes y bundlers necesitan para reforzar respecto a lo que el validateUserOp puede hacer:

  • La ejecución del validateUserOp no puede leer o escribir almacenamiento de otros contratos

  • No puede utilizar opcodes de entorno como el TIMESTAMP

  • No puede hacer llamado a otros contratos a no ser que esos otros puedan auto-destruirse.

¿Por qué todo esto es necesario? Para asegurar que una ejecución simulada de validateUserOp, utilizado por bundlers y mempool nodes de UserOperations para verificar que un determinado UserOperation está okay para ser incluido en el bloque o no, tenga el mismo efecto que si sea incluido en un bloque futuro directamente.

Evolución del Flujo de Transacciones en Ethereum

El gráfico que se muestra a continuación, ilustra de manera práctica de qué manera el ERC-4337 añade una capa más al Flujo de Transacciones en Ethereum. Para tenerlo presente, es una adaptación y traducción al español de un original de blocknative.

El concepto de User Intent Layer baja un poco más a tierra a Account Abstraction. Ésto, en el sentido de que se pone en evidencia que se añade una capa más y por ende, una serie de validaciones y ejecuciones más antes de la validación final que resulta en la transacción en la cadena.

Por un lado, puede aparentar un grado adicional de complejidad. Con la implementación de el ERC-4337 aún no se logra eliminar las acciones del lado del EOA para dar protagonismo “exclusivo” a las cuentas basadas en contratos inteligentes. Pero por el otro, se considera como una de las implementaciones de Account Abstraction más funcionales en general, sobre todo porque no requiere de un hard fork al protocolo de Ethereum.

Para saber más del concepto de User Intent Layer, pueden referirse a este post en X.

Mitos sobre Account Abstraction

El nivel de adopción de el ERC-4337 sigue creciendo. Así también, ciertos mitos y malas interpretaciones que se considera que vale la pena aclarar. John Rising, co-founder de Stackup_fi, compiló varios mitos sobre AA con los cuales podríamos habernos cruzado a lo largo de su descubrimiento.

Se destacan a algunos de ellos:

Mito #1

El 4337 es un EIP (Ethereum Improvement Proposal)

Falso. Así como se ha comentado en secciones anteriores de este escrito, el 4337 no requiere de cambios a nivel protocolo en la chain de Ethereum. En consecuencia, su implementación es permissionless en cualquier chain que sea compatible con la EVM (Ethereum Virtual Machine).

Mito #2

El 4337 no es AA porque una trx no se inicializa a partir de cualquier policy de autorización

Falso. El ERC-4337 como tal, da permiso a cualquier policy de autorización para inicializar transacciones. Desde Zero-Knowledge Proofs hasta pagos recurrentes por parte de procesadoras como Visa que no necesiten de firmas…cualquiera de estas policies pueden hacer uso de AA.

Mito #3

La EIP-3074 es una alternativa a el ERC-4337

Falso. Ambos tienen propósitos diferentes pero es posible implementar ambas.

Es importante enfatizar que la EIP-3074 permite que una EOA delegue el control a un smart contract. Esto es posible si y sólo si, se introducen cambios en el protocolo de Ethereum.

Por otro lado, el ERC-4337 actúa como una gran mejora para convertir a las cuentas de Ethereum en SCW (cuentas inteligentes).

Account Abstraction va más allá de una mejora técnica, es un cambio de enfoque en cómo interactuamos con Ethereum. La manera de consumir aplicaciones en crypto avanza a pasos agigantados y el ERC-4337 funciona como uno de los gateways más efectivos para potenciar la verdadera adopción masiva. La transición del modelo EOA hacia Smart Contract Wallets se proyecta como algo que sucederá de manera progresiva. No queda duda de que estamos ante un ecosistema que se vuelve cada vez más potente y modular.

Cierre

Account Abstraction va más allá de una mejora técnica, es un cambio de enfoque en cómo interactuamos con Ethereum. La manera de consumir aplicaciones en crypto avanza a pasos agigantados y el ERC-4337 funciona como uno de los gateways más efectivos para potenciar la verdadera adopción masiva. La transición del modelo EOA hacia Smart Contract Wallets se proyecta como algo que sucederá de manera progresiva. No queda duda de que estamos ante un ecosistema que se vuelve cada vez más potente y modular.

Recursos

PreviousAccount AbstractionNextIntents y AA

Last updated