Modular Smart Accounts: ERC-7579 & ERC-6900

Para comenzar

Las smart accounts están evolucionando más allá de sus limitaciones iniciales, y estándares modulares como ERC-7579 están liderando esa transformación. A medida que la innovación en este espacio se acelera, las smart accounts modulares se consolidan como una pieza clave de la próxima generación de herramientas.

Hablemos del ERC-7579, una propuesta que describe las interfaces y comportamientos mínimos requeridos para las "cuentas inteligentes modulares" y sus módulos asociados. No dicta el funcionamiento interno de estas cuentas, sino que estandariza sus interfaces externas, lo que permite a los desarrolladores de módulos crear componentes reutilizables y compatibles con cualquier cuenta que cumpla con ERC-7579.

Especificaciones principales

• Configuraciones de cuentas inteligentes: Para garantizar la interoperabilidad, las cuentas inteligentes deben tener una interfaz que pueda proporcionar identificadores de cuenta, un facilitador de checks de modos de ejecución, así también checks de compatibilidad para tipos de módulos. Todo para una identificación única.

• Configuraciones de módulos: Las cuentas inteligentes deben incorporar una interfaz de configuración de módulos. Esto garantiza que los tipos de módulos se distingan para fines de autorización y especifica los procedimientos para instalar y desinstalar módulos. Además, incluye mecanismos para indicar cualquier cambio en la vida útil de un módulo.

• Hooks: Una extensión opcional. Los hooks (o ganchos) permiten que las cuentas inteligentes realicen comprobaciones lógicas personalizadas antes y después de las ejecuciones, lo que resalta la flexibilidad del estándar para acomodar funcionalidades personalizadas.

• ERC-1271 Forwarding: Al implementar ERC-1271, las cuentas inteligentes pueden reenviar llamadas de validación de firma a los validadores. Esto demuestra una integración de la funcionalidad modular con los estándares Ethereum existentes.

Modular Smart Accounts: ERC-7579 vs. ERC-6900

Además de ERC-7579, existe otra propuesta relevante: ERC-6900, un estándar que también aborda la modularidad de las cuentas inteligentes, pero desde un enfoque distinto en seguridad, escalabilidad y gobernanza de módulos.

De todas formas, se destacan las siguientes similitudes:

• Modularidad: ambos buscan partir la lógica en partes (módulos) capaces de conectarse entre sí dentro de las cuentas inteligentes.

• Account Abstraction: están construidos para trabajar en conjunto con bundlers de acuerdo al ERC-4337.

• Pluggable Architecture: ambos utilizan delegatecall o llamadas externas para ampliar la lógica.

• Customización: es posible adaptar las cuentas inteligentes a las necesidades de los usuarios.

Qué limitantes tiene el ERC-6900 que el ERC-7579 logra resolver?

Limitante ERC-6900	Elaboración	De qué manera ERC-7579 lo resuelve
Falta de un sistema de permisos estándar	ERC-6900 permite conectar módulos como validadores y ejecutores, pero carece de un sistema nativo para el control de acceso (por ejemplo, quién puede instalar, actualizar o eliminar módulos).	Presenta a los Módulos de Permiso:componentes desacoplados que definen quién puede acceder a qué módulos y bajo qué condiciones. Incluso aplica para configuraciones multifirma.
Los módulos están condicionados por el almacenamiento de las cuenta	ERC-6900 almacena metadatos del módulo directamente en el contrato de la cuenta (por ejemplo, almacenamiento slot-based), lo que genera mayores costos de gas, complejidad en las actualizaciones y riesgos de estado.	Los módulos ERC-7579 son contratos stateless: la lógica reside externamente y se referencia de forma dinámica a través de un Module Manager, lo que reduce el uso de gas y mejora las rutas de upgrades.
No composability between accounts // No hay componibilidad entre cuentas	Cada cuenta inteligente ERC-6900 gestiona su propia lógica de módulos. No existe un registro compartido ni interoperabilidad entre módulos, lo que dificulta el desarrollo de SDK de wallets o ecosistemas que reutilicen módulos en diferentes dApps.	ERC-7579 admite registros de módulos reutilizables y permissionless, lo que permite que las cuentas utilicen módulos compartidos, o que mejora la seguridad, la estandarización del ecosistema y la experiencia del desarrollador.
Rutas de ejecución menos componibles	ERC-6900 maneja la ejecución y la validación, pero no soporta flujos complejos como pre/post-hooks o enrutamiento lógico entre módulos (necesarios para plugins, simulaciones, batch ops etc.).	ERC-7579 introduces Hooks (new module type), allowing logic to run before and afterkey actions — great for security checks, analytics, batched interactions, or reactive behaviors.
Visión de compatibilidad limitada	Diseñado muy anteriormente en el ecosistema de Account Abstraction con una visión limitada de estándares futuros como ERC-4337 o capas de complementos modulares.	ERC-7579 es compatible de forma nativa con ERC-4337, ERC-6900 (a través de wrappers) y está diseñado para integraciones entre estándares a largo plazo (por ejemplo, plugins, intents, simulaciones).

ERC-7579 en el ecosistema de cuentas inteligentes

Uno de los principales desafíos que aborda el ERC-7579 es la fragmentación dentro de este ecosistema. Ocurre cuando varias implementaciones de cuentas inteligentes son incompatibles entre sí. Esta diversidad puede dificultar la interoperabilidad, ya que cada plataforma puede tener su propio conjunto de reglas y protocolos para cuentas inteligentes. La consecuencia es que genera ineficiencias y una mayor complejidad tanto para devs como para usuarios.

Otro desafío es la falta de estandarización. Los devs enfrentan dificultades para construir aplicaciones que funcionen con diversos tipos de cuentas inteligentes, lo que genera trabajo duplicado y división entre sectores de la industria. Uno de los objetivos de ERC-7579 es crear un método uniforme para las cuentas inteligentes, permitiéndoles funcionar sin problemas en toda la red Ethereum.

Esta estandarización reduce el tiempo y los gastos de desarrollo, además de mejorar la satisfacción del usuario al ofrecer interacciones más confiables y consistentes con los contratos inteligentes.

Seguridad en las cuentas modulares inteligentes

Uno de los mayores desafíos en este aspecto es si los módulos son realmente seguros en el momento de la instalación y la ejecución. Cuantos más permisos tenga un módulo por sobre la cuenta, más relevante será el asegurarlo. Por ejemplo, si un módulo tiene acceso de escritura a la cuenta, podemos pensar que un módulo malicioso puede modificar fácilmente el owner de la cuenta y tomar el control total de la misma. Así mismo, si un módulo puede proponer transacciones a ser ejecutadas en la cuenta sin validación adicional, podría vaciarla.

Garantizar la seguridad de los módulos durante la instalación y ejecución no es trivial, especialmente onchain. Una solución sería implementar un sistema de permisos para que la cuenta haga la verificación onchain. Dicho sistema podría permitir que los módulos declaren por sí mismos los permisos, los cuales serían reforzados por la cuenta siempre que se haga el llamado al módulo. Algunos ejemplos de estos permisos podrían ser: acceso de escritura o habilidad para ejecutar una transacción en nombre de la cuenta.

Sin embargo, implementar sistemas de permisos de este tipo no es viable, sobre todo si hablamos de hacer checks de todos los permisos existentes y casos excepcionales onchain. Algo más viable para garantizar la seguridad de los módulos es implementar las atestaciones. Éstas se definen como una declaración a nombre de un módulo de una cuenta inteligente, especialmente respecto a su seguridad. Siendo así, se puede crear un registry de atestaciones onchain que puede ser accesible por una cuenta inteligente. Sirve para consultarla siempre que el usuario quiera asegurarse respecto a la seguridad del módulo. Por supuesto, lo que contenga dicha atestación está a cargo de quien lo haya creado.

Registro de Módulos (Module Registry)

Rhinestone se ha enfocado en garantizar la seguridad de las cuentas modulares inteligentes. Fue así que presentaron al registry de atestaciones onchain. No sin antes haber considerado múltiples limitantes como lograr construir un sistema verdaderamente permissionless, que sea seguro, con incentivos alineados para todas partes, que exista la menor fragmentación posible y algunos más.

El Module Registry es una solución open-source que despliega un registro de atestaciones onchain de carácter permissionless que las cuentas inteligentes pueden consultar para chequear si un módulo es seguro o no. Una de las características principales es que está diseñada para que no exista fragmentación entre módulos, ya que está pensada para ser usada como un único registro de atestaciones. Ésto facilita bastante el trabajo de implementación para los devs, así como la experiencia del usuario al momento de consultar estas atestaciones.

Un posible problema tiene que ver con la centralización. Ya que se crea un punto único de dependencia para consultar estas atestaciones. De todas formas, una vez implementado el registro ya Rhinestone no tiene cómo controlarlo. Lo que significa que cualquier entidad puede crear atestaciones y usuarios pueden delegar la confianza no sólo a una sino varias entidades emisoras de atestaciones, sin obligar a que confíe únicamente en una entidad.

Otra de las características de esta solución es que es muy flexible para considerar y cumplir con las necesidades de cualquiera que quiera usarla: creador de atestaciones, usuarios, devs de cuentas inteligentes o quien sea. Esto es gracias a sus componentes principales: Schemas y Resolvers. Los mismos permiten aplicar lógicas customizadas al registry y esto lo puede hacer cualquiera.

Finalmente, una característica clave es que es económica de usar. El costo base de hacer querys con base a la consulta de si un módulo es seguro es algo menos que 8000 de gas (menos de 0,01 centavos de dólar en cualquier L2).