La abstracción de cuentas está de moda ya que finalmente se ha desplegado en el mainnet de Ethereum la implementación del ERC-4337 que la desarrolla y que la hace disponible para todo el ecosistema que es compatible con Ethereum.

La abstracción de cuentas promete mejorar mucho la experiencia de usuario para relacionarse con el blockchain y las aplicaciones distribuidas que se construyen encima. Muchos lo consideran un paso (de gigante) necesario hacia la tan ansiada adopción masiva por el público general.

Aunque aporta muchas innovaciones, quizá la más destacada es que va a permitir la creación de wallets mucho más sencillos de usar en el que los usuarios van a poder olvidarse de claves criptográficas y podrán interactuar con los mismos mecanismos y conceptos que ya le son familiares del mundo de la Web 2 (passwords, recuperación de claves, 2FA biométricos en dispositivo móvil, etcétera).

Tabla de contenidos

¿Por qué lo necesitamos?

Para entender por qué es necesaria la "abstracción de cuentas" y qué significa y cómo la implementa el ERC-4337, hemos de entender primero el status quo anterior al despligue de esta actualización.

En Ethereum existen dos tipos de cuentas:

  1. cuentas de propiedad externa o EOAs por sus siglas en inglés (Externally Owned Accounts) que pueden ser controladas por cualquiera que disponga de la clave privada asociada y
  2. cuentas que contienen smart contracts y por tanto código que puede ejecutar el blockchain.

Ambos tipos de cuentas pueden:

  • almacenar, recibir y enviar ETH y otros tókenes,
  • interactuar con otros smart contracts.

Se diferencian en que:

  • las EOAs no tienen coste de creación mientras que las cuentas de smart contracts sí ya que ocupan espacio en el blockchain (es decir, hay que pagar ETHs por desplegar un smart contract),
  • las EOAs pueden iniciar transacciones mientras que las cuentas de smart contracts no; en otras palabras el blockchain no puede iniciar transacciones por sí mismo y siempre necesita que el iniciador sea una EOA (que generalmente es un humano desde su wallet),
  • las transacciones entre diferents EOAs sólo pueden utilizarse para intercambiar ETHs o tókenes mientras que transacciones entre diferentes smart contracts, además de lo anterior, pueden ejecutar código arbitrario.

Este modelo tiene pues las siguientes implicaciones:

  • cualquier transacción ha de iniciarse mediante una EOA,
  • el inicio de esta transacción requiere la posesión de la clave privada asociada a la EOA,
  • la EOA no puede codificar ninguna lógica adicional, sólo puede hacer dos cosas:
    • transferir activos (ETH o tókenes) a otra cuenta,
    • delegar la ejecución a un smart contract que implemente alguna lógica.

Por tanto como humano que quiere almacenar sus criptoactivos o iniciar transacciones has de disponer de una EOA y custodiar su clave privada en un wallet.

¿Por qué esta arquitectura no funciona para la adopción masiva del blockchain?

  • Sólo existe una clave, si no la custodias bien, la pierdes o te la roban adiós a tus fondos.
    • No existen mecanismos para cambiar la clave.
    • No existen mecanismos de recuperación de clave.
  • No existen acceso granular: o tienes acceso a todo o no tienes acceso a nada.
    • No existe multisig o roles.
    • No se puden establecer políticas de gasto para establecer diferentes medidas de seguridad en función de límites (por ejemplo, requerir dos firmas a partir de cierta cantidad)
  • El coste de cada transacción debe ser cubierto por la misma cuenta.
    • Eso implica que un usuario que quiera utilizar una aplicación en el blockchain además de dar de alta un wallet tiene que incorporar (comprar) criptomonedas.
    • Se pierde la privacidad porque es posible ver en el blockchain la transferencia de los fondos requeridos desde otra cuenta.
  • Las DApps (aplicaciones descentralizadas) no tienen flexibilidad porque es imposible:
    • agrupar transacciones en batches o
    • implementar automatizaciones como pagos recurrentes u operaciones que se activan en función de determinados eventos.

¿Qué es la abstracción de cuentas?

“Abstracción de cuenta” es un término confuso para el público general porque fue elegido por los desarrolladores desde el punto de vista del protocolo de Ethereum y no del usuario. Veremos después qué es lo que se abstrae para el protocolo. Desde el punto de vista del usuario tiene mucho más sentido hablar de smart accounts.

Los smart accounts prometen solucionar todos los problemas presentados en el apartado anterior y dibujan el camino hacia la adopción masiva. Podemos conceptualizar estas cuentas como una fusión entre las EOA y los smart contracts. Tienen tres características fundamentales:

  1. eliminan la necesidad de la clave privada para iniciar una transacción (a diferencia de las EOA),
  2. pueden implementar lógica arbitraria para implementar diferentes casos de uso (a diferencia de las EOA) y
  3. pueden iniciar transacciones (a diferencia de las cuentas de smart contract).

El cambio es revolucionario porque cualquier cosa que puede hacerse con un smart contract puede hacerse con una de estas cuentas, lo que permite la creación de wallets sofisticados y diversos.

La discusión técnica sobre cómo implementar la abstracción de cuentas en Ethereum se ha producido en el contexto del ERC–4337 (los ERC definen el proceso, especificaciones y requerimientos técnicos sobre nuevas funcionalidades a desplegar en Ethereum por su comunidad de desarrollo).

¿Qué es lo que las smart accounts abstraen para el protocolo de Ethereum según el ERC–4337?:

  • La autenticación y la autorización: el desarrollador del wallet puede elegir qué mecanismos quiere implementar de cara a los usuarios finales, sin requerir necesariamente del uso de claves criptográficas, y pudiendo definir niveles de acceso y perfiles arbitrarios.
  • El pago de las transacciones: no es necesario que el usuario del wallet sea el que tenga que pagar por los costes del uso del blockchain sino que puede delegar ese pago a cualquier otro smart contract. De esta manera las aplicaciones que usan el blockchain pueden pagar por sus usuarios y, por ejemplo, cobrar a los usuarios finales en monedas fiat (en euros o dólares) por los conceptos que estimen oportunos y desvinculados del uso específico que haga la aplicación del blockchain.
  • La ejecución, lo que permite la implementación de batching (agregación) de transacciones o automatización de procesos.

¿Cómo y cuándo?

Una de las restricciones que imponía el EIP–4337 era no modificar el protocolo de consenso de Ethereum y por ello la solución adoptada ha consistido en desplegar la funcionalidad como un conjunto de smart contracts (que se pueden ver en esta dirección del mainnet). Esta aproximación permite además que cualquier otro blockchain compatible con Ethereum (a nivel de EVM) también pueda hacer uso de la implementación.

Efectivamente, la funcionalidad ya está desplegada. El anuncio se produjo el 1 de marzo del 2023 en el contexto de la WalletCon de Denver de la mano de Yoav Weiss, investigador de seguridad de la Ethereum Fundation. Puedes ver su charla en YouTube, que además es un gran recurso divulgativo para entender todos estos conceptos.

El perfil “oficial” del ERC-4337 en Twitter se hacía eco:

¿A qué nuevas funcionalidades se abre la puerta?

A lo largo del artículo ya he ido exponiendo algunas de las funcionalidades que este nuevo estándar habilita. Los agrupo y completo aquí a modo de resumen:

  • Wallets con mecanismos de autenticación y autorización más conocidos por el público general:
    • sin necesidad de custodiar claves criptográficas,
    • uso de passwords y sistemas 2FA más habituales (biometría con dispositivos móviles, logins de un solo acceso, aplicaciones de autenticación, etc.),
    • sistemas de recuperación de claves en caso de pérdida incluyendo social recovery,
    • políticas de expiración de claves que requieran la actualización o sustitución de sistemas de acceso,
    • acceso multiusuario,
    • perfiles de acceso con difirentes privilegios
  • Programación de pagos automáticos y recurrentes.
    • Incluye, por ejemplo, trading automátio cuando se den ciertas condiciones en el mercado definidas por el usuario en el propio wallet sin depender de un exchange (y por tanto manteniendo la custodia de los activos hasta el momento de la transacción).
  • Pagos patrocinados de manera que no es el usuario (dueño del wallet) el que paga el coste de ejecución de las transacciones de Ethereum.
  • Pagos al protocolo mediante tókenes ERC-20 y no sólo con ETH.
  • Límites o restricciones a las cantidades transferidas en función de diferentes políticas como cantidades máximas, límites temporales u otras.
  • Batching: múltiples transacciones de usuario en una única transacción de protocolo para ahorro de costes u otros beneficios.
  • Claves de sesión. Cuando estás interactuando con una aplicación descentralizada, lo más habitual es que ésta tenga que interactuar con el blockchain en diferentes momentos. Con los wallets actuales cada una de estas interacciones requiere que el usuario firme con su clave privada, haciendo la interacción tediosa y poco fluida. Las claves de sesión son claves temporales que se crean para relacionarse con esa aplicación y firmar por el usuario sin requerir su intervención en cada interacción.

Y en definitiva cualquier cosa que los desarrolladores de wallets y aplicaciones descentralizadas pueden implementar con un smart contract.

Retos y futuro

La adopción del estándar por parte de todo el ecosistema Ethereum es el principal reto que tiene este nuevo estándar para que realmente pueda desplegar todo su valor a los usuarios finales.

Hay que construir los wallets que lo implemeten y trabajar en las aplicaciones descentralizadas y los protocolos, actuales y futuros, para que lo soporten.

La adopción por parte los desarrolladores de Ethereum no es un tema baladí:

  • tenemos el clásico problema del huevo y la gallina: los desarrolladores pueden dudar si abrazar el nuevo estándar hasta que tenga tracción y sin proyectos dándole soporte es muy difícil conseguir esa tracción,
  • la propuesta no es especialmente compatible con otras soluciones orgánicas que han ido surgiendo, lo que significa que los equipos tendrán que incurrir en cambios significativos y costosos para implementarla y, para finalizar,
  • el estándar, aunque mucho más flexible, también introduce nuevas complejidades que requiere una cierta curva de aprendizaje por parte de los desarrolladores.

Veremos si el sello de “estándar”, es suficiente para sea adoptado por la comunidad y todos los beneficios que promete lleguen al ecosistema y sirva para dar un empujón definitivo a la adopción masiva.

Conclusiones

  • Antes de la abstracción de cuentas, Ethereum sólo soportaba dos tipos de cuentas:
    • las EOAs que son las únicas que permiten iniciar transacciones en y que sólo puden usarse con una clave criptográfica privada,
    • las que contienen smart contracts que no pueden iniciar transacciones pero implementan la lógica de las aplicaciones distribuidas.
  • Esta situación fuerza a los usuarios a tener que usar EOAs y por tanto a tener que custodiar claves privadas criptográficas mediante wallets.
  • Los requerimientos técnicos de las EOAs las hacen incompatibles con la adpación masiva de la tecnología blockchain.
  • La abstracción de cuentas introduce un tercer tipo de cuentas que podríamos denominar smart accounts que son una especie de fusión entre EOAs y smart contracts.
  • Las smart accounts permiten iniciar transacciones e incluir lógica (cualquier cosa que puedas progarmar en un smart contract tradicional).
  • Esta capacidad de las smart accounts habilita una gran cantidad de funcionalidades que los wallets podrían ofrecer, entre las que destacan:
    • una gestión de autenticación y autorización más sencilla con mecanismos conocidos de las Web 2.0,
    • pagos automáticos y recurrentes,
    • pagos patrocinados,
    • pagos al protocolo mediante tókenes ERC-20,
    • agregación de transacciones y
    • muchos más.
  • El éxito del estándar dependerá en gran parte de la acogida que tenga entre la comunidad de desarrollo del ecosistema Ethereum.

Referencias