¿Qué es la abstracción de cuentas modular?

Modular AA es un movimiento cuyo objetivo es evangelizar sobre las cuentas inteligentes modularizadas. La meta es hacer que las cuentas sean personalizables para los usuarios y permitir a los desarrolladores construir funcionalidades de cuenta autocontenidas y con contexto enriquecido.

Las cuentas de contrato inteligente (SCAs) modulares permiten a los desarrolladores crear nuevas extensiones útiles para las cuentas. Algunos ejemplos incluyen:

1. Recuperación social: permite que un dispositivo de confianza o amigos te ayuden a recuperar tu cuenta en caso de que pierdas el acceso
2. Límites de gasto: permite que las apps gasten tokens en tu nombre hasta un límite especificado
3. Soporte de passkeys: inicia sesión con tu biometría, como FaceID

Al estandarizar la modularidad, el riesgo de contraparte puede reducirse considerablemente, lo que da lugar a experiencias de usuario web3 simples y seguras.

El estándar ERC-4337 define los componentes de infraestructura y los estándares de código que, al implementarse, permiten a los usuarios tener un contrato inteligente como tipo de cuenta principal en lugar de una clave privada. Históricamente, el tipo de cuenta principal era una EOA (End User Account), que, a diferencia de las SCAs, no cuenta con lógica de validación y ejecución personalizada.

Este artículo busca ofrecerte una visión general de Modular Account Abstraction, lo que permite hacer, y los estándares e implementaciones existentes.

¿Cuáles son los diferentes tipos de cuentas de contrato inteligente modulares?

Las cuentas de contrato inteligente son, en esencia, contratos inteligentes; son actualizables, extensibles y también heredables. Dependiendo de la implementación de la SCA, puede permitir o no la adición de plugins/módulos. Este artículo explorará dos conceptos diferentes de modular AA: ERC-6900 y SAFE Modules.

1. ERC-6900: cuentas de contrato inteligente modulares y plugins

El objetivo de ERC-6900 es definir un conjunto de interfaces entre una implementación estándar de Account y de Module. La propuesta busca mejorar la experiencia del desarrollador, la interoperabilidad de Modules y la portabilidad de datos al cambiar entre implementaciones de cuentas.

El estándar está inspirado en ERC-2535; sin embargo, no exige a los desarrolladores seguir el patrón Diamond.

¿Qué son los plugins de ERC-6900 para cuentas de contrato inteligente modulares?

¿Qué tipos de plugins define ERC-6900?

Según el estándar, los plugins pueden ser de tres tipos:

1. Validation Schemes: definen las circunstancias bajo las cuales la modular smart contract account (MSCA) aprobará las transacciones en su nombre
2. Execution Logic: cualquier lógica arbitraria que se ejecute durante la ejecución
3. Hooks: los hooks pueden disparar cualquier lógica que se ejecute antes y después de la ejecución de la user operation

El estándar también define:

1. Cómo implementar plugins de Validation, Execution y Hook para una MSCA.
2. Cómo las implementaciones de cuentas compatibles deben agregar, quitar, actualizar e inspeccionar plugins.
3. Tipos auxiliares como FunctionReference.

¿Qué tipos de interfaces define ERC-6900?

La especificación ERC-6900 define tres interfaces principales: IPluginUpdate, IPluginLoupe e IStandardExecutor.

1. IPluginUpdate

La interfaz IPluginUpdate define:

• Las acciones de plugin ADD, REMOVE y REPLACE
• Los tipos de Validator y los tipos de Hook
• Structs definidos por el usuario para actualizar los distintos tipos de plugins
• Una función estandarizada updatePlugins que se llama al actualizar plugins, y el evento ExecutionPluginUpdate que se emite después de la actualización

2. IPluginLoupe

IPluginLoupe está inspirado en ERC-2535, y ERC-6900 define cómo una dapp u otros contratos pueden leer los plugins compatibles con la MSCA.

3. IStandardExecutor

La interfaz IStandardExecutor que las cuentas de contrato inteligente modulares deben implementar para permitir una ejecución abierta.

2. SAFE modules

Todas las cuentas basadas en SAFE tienen soporte para SAFE Modules. Para mantener altos estándares de seguridad, el equipo de SAFE siguió el patrón de separación de responsabilidades e implementó distintos tipos de módulos.

• Modules: direcciones incluidas en una lista blanca que pueden ejecutar transacciones en nombre de la Safe Smart Account.
• Guard: un contrato que puede configurarse para realizar verificaciones adicionales sobre las transacciones que se van a ejecutar.
• Fallback Handler: un contrato que puede configurarse para manejar llamadas entrantes (de lectura) arbitrarias.

Puedes encontrar más información en el artículo sobre la arquitectura de SCA modular de Safe.

¿Qué son los SAFE SCA modules?

Los Modules de SAFE son contratos inteligentes individuales que tienen permiso para ejecutar transacciones en la cuenta de contrato inteligente SAFE del usuario. Los Modules pueden ejecutar transacciones arbitrarias en la cuenta SAFE mediante la función execTransactionFromModule. Dado que el equipo de SAFE decide cómo se implementan las cuentas SAFE, los desarrolladores de plugins deben cumplir con sus reglas y lineamientos. Los SAFE modules solo son compatibles con cuentas SAFE.

Existen importantes supuestos de confianza entre el desarrollador del módulo y el usuario, por lo que es más probable que los módulos ya probados en producción sigan siendo adoptados.

¿Qué son los SAFE SCA guards?

Los Guards son contratos inteligentes que se pueden configurar para una cuenta SAFE con el fin de realizar verificaciones de seguridad adicionales sobre las transacciones entrantes. Antes de ejecutar una transacción, se llama a un

Guard con todos los parámetros de la transacción, y si el Guard no revierte, la transacción continúa hacia su ejecución.

El Guard se vuelve a llamar después de la ejecución para realizar verificaciones de cambio de estado o ejecutar lógica arbitraria.

Los Guards también pueden pensarse como hooks, ya que son adecuados para verificaciones de estado antes y después de la transacción.

¿Qué es el SAFE SCA fallback handler?

El Fallback Handler ejecuta todas las llamadas hechas a la cuenta SAFE que puedan ser manejadas por él. Esto puede ser útil para cumplir con estándares de la industria como las firmas de contrato (EIP-1271). Según SAFE, "los plugins son completamente independientes de los contratos centrales de SAFE y mantienen su propio almacenamiento".

Conclusión

Modular Account Abstraction, tal como lo describe ERC-6900 y lo diseñan Safe Modules, busca extender las capacidades de las Smart Contract Accounts mediante plugins, que pueden ser construidos por desarrolladores e instalados de forma segura por los usuarios de wallets de contrato inteligente.

Para más información, explora nuestro centro educativo sobre ERC-4337, o revisa nuestras Embedded Accounts listas para usar y comienza a construir hoy mismo.