Introducción

El cambio de Cuentas de Propiedad Externa (EOA) a Cuentas de Contrato Inteligente (SCA) está ganando impulso y ha sido adoptado por muchos entusiastas, incluido el propio Vitalik. A pesar del entusiasmo, la adopción de SCA no está tan extendida como la de los EOA. La clave entre ellos son los desafíos que plantean los mercados bajistas, la preocupación por la migración, los problemas de firma, los gastos generales del gas y, lo más crítico, las dificultades de ingeniería.

La ventaja más importante de las abstracciones de cuentas (AA) es la capacidad de utilizar código para personalizar la funcionalidad. Sin embargo, un desafío de ingeniería importante es la no interoperabilidad de las funcionalidades de AA, y la fragmentación dificulta la integración y abre la puerta a la dependencia de un proveedor. Además, garantizar la seguridad y al mismo tiempo actualizar y componer funciones puede resultar complicado.

Ingrese a la abstracción de cuentas modulares, como un subconjunto del movimiento AA más amplio, este enfoque innovador puede separar las cuentas inteligentes de sus funciones personalizadas. El objetivo es crear una estructura modular para desarrollar carteras seguras y perfectamente integradas con diversas funcionalidades. En el futuro, puede crear una “tienda de aplicaciones” gratuita para cuentas de contratos inteligentes que libere las billeteras y las dApps de la creación de funciones, pero se centre en la experiencia del usuario.

Después de leer este artículo, los lectores obtendrán información sobre:

1. ¿Qué es la abstracción de cuentas modulares?
2. ¿Cómo interactúa la cuenta con los módulos?
3. ¿Cuál es la secuencia de llamada de módulos?
4. Cómo encontrar y verificar módulos de forma abierta

Una breve reseña de AA

Paisaje SCA

La EOA tradicional presenta muchos desafíos, como frase inicial, gas, cadena cruzada y transacciones múltiples. Nunca tuvimos la intención de introducir complejidad, pero de hecho, blockchain no es un juego fácil para las masas.

Account Abstraction aprovecha la cuenta de contrato inteligente que permite la validación y ejecución programables, donde el usuario puede aprobar una serie de transacciones de una sola vez, en lugar de firmar y transmitir cada una, e implementar muchas más funciones. Introduce beneficios en la experiencia del usuario (p. ej. extracción de gas y claves de sesión), costo (p. ej. transacción por lotes) y seguridad (p. ej. recuperación social, multi-sig). Actualmente, existen dos formas de lograr la abstracción de cuentas:

1. Capa de protocolo: algunos protocolos proporcionan soporte nativo de abstracción de cuentas, las transacciones ZKsync siguen el mismo flujo ya sea que se originen en EOA o SCA, que utiliza un único mempool y flujo de transacciones para admitir AA, y Starknet eliminó EOA y todas las cuentas son SCA, y tienen Carteras nativas de contratos inteligentes como Argent.
2. Capa de contrato: para Ethereum y sus L2 equivalentes, ERC4337 introduce un punto de entrada separado para que las transacciones admitan AA sin cambiar la capa de consenso. Proyectos como Stackup, Alchemy, Etherspot, Biconomy, Candide y Plimico están creando infraestructura de paquetes, y muchos más como Safe, Zerodev, Etherspot y Biconomy están creando pilas y SDK.

👉 Si no está familiarizado con AA o ERC4337, consulte la investigación anterior de SevenX aquí.

El dilema de la adopción de SCA

El tema de la abstracción de cuentas (AA) ha estado en discusión desde 2015 y ERC4337 lo impulsó aún más a la atención pública este año. Sin embargo, la cantidad de cuentas de contratos inteligentes implementadas aún palidece en comparación con las EOA.

Profundicemos en este dilema:

1. Impacto en el mercado bajista:
   Aunque AA introduce beneficios como el inicio de sesión fluido y la abstracción de gas, el mercado bajista predominante está formado principalmente por usuarios educados de EOA en lugar de nuevos, por lo que no hay ningún incentivo para las dApps y las billeteras. Aun así, las aplicaciones líderes todavía están en camino de adoptar AA, como Cyberconnect generó alrededor de 360.000 UserOps (transacciones de AA) solo al mes al presentar su sistema AA y su solución sin gas.
2. Obstáculos para la migración:
   Para billeteras y aplicaciones que han acumulado usuarios y activos almacenados en EOA, migrar activos de forma segura y conveniente sigue siendo un desafío. Sin embargo, iniciativas como EIP-7377 permiten a las EOA iniciar una transacción de migración única.
3. Problema de firma:
   Naturalmente, el contrato inteligente en sí no puede firmar mensajes, ya que no posee una clave privada como los EOA. Esfuerzos como ERC1271 lo hacen posible, pero la firma del mensaje no funcionará hasta la primera transacción, lo que plantea un desafío para las billeteras que utilizan la implementación contrafactual. Y el ERC-6492 propuesto por Ambire es un sucesor compatible con versiones anteriores del ERC-1271 que potencialmente resuelve el problema anterior.
4. Gastos generales de gas:
   La implementación, simulación y ejecución de SCA genera costos más altos en comparación con los EOA estándar. Esto se convierte en un elemento disuasorio para la adopción. Sin embargo, se han realizado varias pruebas, como desacoplar la creación de cuentas de las operaciones del usuario y eliminar la sal de la cuenta y se están considerando verificaciones de existencia para reducir estos costos.
5. Dificultades de ingeniería:
   El equipo ERC-4337 ha creado el repositorio eth-infinitism para proporcionar a los desarrolladores una implementación fundamental. Sin embargo, a medida que nos expandimos hacia funciones más matizadas o específicas para diferentes casos de uso, la integración y la decodificación se vuelven desafiantes.

En este artículo, profundizaremos en el problema número cinco: las dificultades de ingeniería.

🤔️

Cuenta de contrato inteligente modular para abordar las dificultades de ingeniería

Para profundizar en las dificultades de ingeniería:

1. Fragmentación:
   Las funciones ahora se habilitan de varias maneras, ya sea de forma nativa mediante SCA específicas o mediante sistemas de complementos independientes. Cada uno sigue su estándar, lo que obliga a los desarrolladores a decidir qué plataformas respaldar. Esto conduce a posibles bloqueos de plataforma o esfuerzos redundantes.
2. Seguridad:
   Si bien la flexibilidad entre cuentas y funciones ofrece ventajas, puede amplificar los problemas de seguridad. Las características pueden auditarse colectivamente, pero la ausencia de evaluaciones independientes podría aumentar el riesgo de vulnerabilidades en las cuentas.
3. Actualizabilidad:
   A medida que las funciones evolucionan, es importante conservar la capacidad de agregar, reemplazar o eliminar funcionalidades. Volver a implementar funciones existentes con cada actualización introduce complejidades.

Para navegar por estas aguas, necesitamos contratos actualizables que garanticen actualizaciones seguras y eficientes, núcleos reutilizables para mejorar la eficiencia general del desarrollo e interfaces estandarizadas para garantizar que las cuentas de contrato puedan realizar una transición fluida entre diferentes interfaces.

Estos términos convergen en un concepto singular: construcción de una arquitectura de abstracción de cuentas modular (AA modular).

Modular AA es un nicho dentro del movimiento AA más amplio que prevé la modularización de cuentas inteligentes para personalizarlas para los usuarios y permitir a los desarrolladores mejorar las funciones sin problemas con restricciones mínimas.

Sin embargo, en cualquier industria, establecer y promover un nuevo estándar es un gran desafío. Las fases iniciales pueden presenciar muchas soluciones diferentes antes de que todos se decidan por la principal. Sin embargo, es alentador ver a quienes trabajan en la abstracción de cuentas, ya sea el SDK 4337, los desarrolladores de billeteras, los equipos de infraestructura o los diseñadores de protocolos, todos juntos para acelerar el proceso.

Estructura Modular: Cuenta Principal y Módulos

¿Cómo llama la cuenta a los módulos para realizar funciones?

Llamada de delegado y contrato de representación

Llamada externa y llamada delegada:

Acerca de la llamada delegada

Mientras que la llamada delegada es similar a la llamada, pero en lugar de ejecutar el contrato de destino en su propio contexto, lo ejecuta en el contexto del estado actual del contrato que llama. Esto significa que cualquier cambio de estado realizado por el contrato de destino se realiza en el almacenamiento del contrato de llamada.

Contrato de proxy y llamada delegada

Para realizar la estructura componible y actualizable, se necesita un conocimiento fundamental llamado "contrato de proxy".

1. Contrato de proxy: un contrato normal almacena su lógica y sus estados, que no se pueden actualizar después de la implementación. Un contrato de proxy que utiliza la llamada delegada a otro contrato. Al hacer referencia a la función de implementación, la ejecuta en el estado actual del contrato de proxy.
2. Casos de uso: si bien el contrato de proxy permanece inmutable, puede implementar una nueva implementación detrás del proxy. Los contratos de proxy se utilizan para la capacidad de actualización y son más baratos de implementar y mantener en cadenas de bloques públicas.

Arquitectura segura

Arquitectura segura

Qué es seguro:

Safe es una infraestructura modular de cuentas inteligentes líder diseñada para brindar seguridad y flexibilidad probadas en batalla, y permite a los desarrolladores crear diversas aplicaciones y billeteras. En particular, muchos equipos se basan en Safe o se inspiran en él. Biconomy lanzó su cuenta ampliando Safe con 4337 nativo y multifirmas 1/1. Al ser testigo del despliegue de más de 164.000 contratos y bloquear un valor de más de 30.700 millones, Safe es sin duda el líder en el espacio.

¿Cuál es la estructura de Safe?

1. Contrato de cuenta segura: Contrato de proxy principal (con estado)
   La cuenta segura es un contrato proxy porque llama delegado a un contrato singleton. La cuenta segura contiene propietarios, umbrales y direcciones de implementación que están configuradas como variables del proxy, lo que define su estado.
2. Contrato singleton: Centro de integración (sin estado)
   Singleton presta servicios a la cuenta segura e integra y define diferentes integraciones, incluidos complementos, ganchos, controladores de funciones y validadores de firmas.
3. Contrato de módulo: Lógica y características personalizadas:
   Los módulos son poderosos. Los complementos como tipo modular pueden definir diferentes características como transmisiones de pago, mecanismos de recuperación y claves de sesión, y pueden servir como un puente entre web2 y web3 al obtener datos fuera de la cadena. Otros módulos como Hook como protector de seguridad y Function Handler responden a cualquier instrucción.

Qué sucede cuando adoptamos Safe:

1. Contratos actualizables:
   Es necesario implementar un nuevo singleton cada vez que se introducen nuevos complementos. Los usuarios conservan la autonomía para actualizar su Safe a la versión singleton deseada, alineándose con sus preferencias y requisitos.
2. Módulos componibles y reutilizables:
   La naturaleza modular de los complementos permite a los desarrolladores crear funcionalidades de forma independiente. Luego pueden seleccionar y combinar libremente estos complementos según sus casos de uso, fomentando un enfoque altamente personalizable.

Proxies de diamante ERC-2535

Arquitectura de diamante ERC2535

Acerca de ERC2535, servidores proxy de diamante:

El ERC2535 estandariza los diamantes, un sistema de contrato inteligente modular que se puede actualizar/ampliar después de la implementación y prácticamente no tiene límite de tamaño. Hasta ahora, muchos equipos se han inspirado en él, como el Kernel de Zerodev y el experimento de Soul Wallet.

¿Qué es la estructura del diamante?

1. Contrato diamante: contrato de proxy principal (con estado) Un diamante es un contrato de proxy que llama a funciones desde sus implementaciones mediante delegarcall.
2. Contrato de módulo/complemento/faceta: lógica y funciones personalizadas (sin estado) Un módulo o el llamado faceta es un contrato sin estado que podría implementar sus funciones en uno o más diamantes. Son contratos separados e independientes que pueden compartir funciones internas, bibliotecas y variables de estado.

¿Qué sucede cuando adoptamos Diamond?

1. Contratos actualizables: Diamond proporciona una forma sistemática de aislar diferentes complementos, conectarlos y compartir datos entre ellos, y también agrega, reemplaza o elimina directamente cualquier complemento mediante la función DiamondCut. No hay límite para la cantidad de complementos que se pueden agregar a los diamantes con el tiempo.
2. Complemento modular y reutilizable: cualquier número de diamantes puede utilizar un complemento implementado para reducir enormemente los costos de implementación.

Diferencia entre Safe Smart Account y Diamond Approach:

Abundan las similitudes entre las arquitecturas Safe y Diamond, ya que ambas se basan en contratos proxy en su núcleo y hacen referencia a contratos lógicos para lograr capacidad de actualización y modularidad.

No obstante, la principal distinción radica en el manejo de los contratos lógicos. Aquí hay una mirada más cercana:

1. Flexibilidad:
   En el contexto de habilitar nuevos complementos, Safe necesita volver a implementar su contrato Singleton para implementar el cambio en su Proxy. Por el contrario, Diamond logra esto directamente a través de la función DiamondCut en su Proxy. Esta variación en el enfoque se traduce en que Safe conserva un mayor grado de control, mientras que Diamond introduce flexibilidad y modularidad mejoradas.
2. Seguridad:
   la llamada delegada, utilizada en ambas estructuras por ahora, puede permitir que un código externo manipule el almacenamiento del contrato principal. En la arquitectura Safe, la llamada delegada apunta a un único contrato lógico, mientras que Diamond emplea la llamada delegada en múltiples contratos de módulo-complementos. En consecuencia, un complemento malicioso tiene el potencial de sobrescribir otro complemento, lo que introduce el riesgo de colisiones de almacenamiento que podrían comprometer la integridad del Proxy.
3. Costo:
   La flexibilidad inherente al enfoque Diamond viene de la mano de preocupaciones de seguridad amplificadas. Esto aumenta el factor de costo, lo que requiere auditorías integrales con cada adición de un nuevo complemento. La clave es asegurarse de que estos complementos no interfieran con las funciones de los demás, lo que presenta un desafío, particularmente para las pequeñas o medianas empresas que se esfuerzan por mantener estándares de seguridad sólidos.

El “enfoque de Cuenta Inteligente Segura” y el “enfoque Diamante” sirven como ejemplos de estructuras distintas que involucran servidores proxy y módulos. Cómo equilibrar la flexibilidad y la seguridad es crucial, y estos dos métodos podrían potencialmente complementarse en el futuro.

Secuencia de módulos: validador, ejecutor y gancho

¿Cuál es la secuencia de llamada de módulos?

Ampliemos nuestra discusión presentando ERC6900, un estándar propuesto por el equipo de Alchemy , inspirado en Diamond y diseñado específicamente para ERC-4337. Aborda el desafío de la modularidad en cuentas inteligentes al proporcionar interfaces comunes y coordina los esfuerzos entre los desarrolladores de complementos y billeteras.

Cuando se trata del proceso de transacción de AA, existen tres procesos principales: validación, ejecución y enlace. Todos estos pasos se pueden gestionar utilizando la cuenta proxy para llamar a los módulos, como comentamos anteriormente. Si bien diferentes proyectos pueden usar nombres diferentes, es importante comprender la lógica subyacente similar.

Nombres de funciones en diferentes diseños.

1. Validación: Garantiza la autenticidad y autoridad de la persona que llama a la cuenta.
2. Ejecución: Realiza cualquier lógica personalizada que permita la cuenta.
3. Hook: actúa como un módulo que se ejecuta antes o después de otra función. Puede modificar el estado o hacer que se deshaga toda la llamada.

ERC6900

Es crucial separar los módulos según una lógica diferente. Un enfoque estandarizado debería dictar cómo se deben escribir las funciones de validación, ejecución y enlace para cuentas de contratos inteligentes. Ya sea Safe o ERC6900, la estandarización ayuda a reducir la necesidad de esfuerzos de desarrollo únicos y específicos para ciertas implementaciones o ecosistemas y evita la dependencia de un proveedor.

Descubrimiento y seguridad de módulos

Cómo encontrar y verificar módulos de forma abierta

Una solución que está ganando impulso implica la creación de un lugar que permita a los usuarios descubrir módulos verificables, al que podemos llamar "registro". Este registro funciona de manera similar a una "App Store" y tiene como objetivo fomentar un mercado modular simplificado pero próspero.

Protocolo{Core} seguro

Protocolo{Core} seguro

Safe{Core} Protocol es un protocolo interoperable de código abierto para cuentas de contratos inteligentes, diseñado para mejorar la accesibilidad para varios proveedores y desarrolladores mientras mantiene una seguridad sólida a través de estándares y reglas bien definidos.

1. Cuenta: en el protocolo Safe{Core} , el concepto de cuenta es flexible y no está vinculado a una implementación específica. Esto permite que participen diversos proveedores de servicios de cuentas.
2. Gerente: El Gerente sirve como coordinador entre Cuentas, Registros y Módulos. También es responsable de la seguridad como capa de permisos.
3. Registros: los registros definen atributos de seguridad y aplican estándares como ERC6900 para módulos, con el objetivo de crear un entorno de "tienda de aplicaciones" abierto tanto para la capacidad de descubrimiento como para la seguridad.
4. Módulos: los módulos manejan funcionalidades y vienen en varios tipos iniciales, incluidos complementos, ganchos, validadores de firmas y controladores de funciones. Estos están abiertos a la participación de los desarrolladores, siempre que cumplan con los estándares establecidos.

Diseño de diamantes de imitación.

Diseño de diamantes de imitación.

El proceso se desarrolla de la siguiente manera:

1. Creación de una definición de esquema: un esquema sirve como una estructura de datos predefinida necesaria para la certificación. Las empresas pueden personalizarlo para adaptarlo a sus casos de uso específicos.
2. Creación de módulos basados en un esquema: los contratos inteligentes se registran como módulos, se obtiene un código de bytes y se elige un ID de esquema. Estos datos luego se almacenan en el registro.
3. Obtención de certificación para un módulo: los certificadores/auditores pueden proporcionar certificaciones para módulos según un esquema. Estas certificaciones pueden incluir un identificador único (UID) y referencias a otras certificaciones para el encadenamiento. Pueden propagarse a través de cadenas y verificar si se cumplen umbrales específicos en las cadenas de destino.
4. Implementación de lógica compleja con solucionadores: entran en juego los solucionadores, configurados opcionalmente en el esquema. Podrían invocarse durante la creación del módulo, el establecimiento de la certificación y la revocación. Estos solucionadores permiten a los desarrolladores incorporar una lógica compleja y diversa manteniendo al mismo tiempo las estructuras de certificación.
5. Acceso a consultas fácil de usar: las consultas ofrecen un medio para que los usuarios accedan a información de seguridad desde el front-end. Encuentre este EIP aquí.

Si bien este esquema se encuentra en sus primeras etapas, tiene el potencial de establecer un estándar de manera descentralizada y colaborativa. Su registro permite a los desarrolladores registrar sus módulos, a los auditores verificar su seguridad y a las billeteras integrarse y permite a los usuarios localizar módulos sin esfuerzo y verificar su información de certificación. Varios usos futuros podrían ser:

1. Atestados: entidades confiables, como Safe, podrían colaborar con Rhinestone como atestados de módulos internos. Al mismo tiempo, podrían sumarse testigos independientes.
2. Desarrolladores de módulos: a medida que toma forma un mercado abierto, los desarrolladores de módulos podrían potencialmente monetizar su trabajo a través del registro.
3. Usuarios: Al interactuar a través de interfaces fáciles de usar, como billeteras o dApps, los usuarios pueden examinar la información del módulo y delegar la confianza a diversos certificadores.

El concepto de "Registro de módulos" abre vías de monetización para los desarrolladores de complementos y módulos. Podría allanar aún más el camino para un “mercado de módulos”. Algunos aspectos podrían ser supervisados por el equipo de Safe, mientras que otros podrían manifestarse como mercados descentralizados, invitando a realizar contribuciones y registros de auditoría transparentes para todos. Al incorporar esto, podemos evitar la dependencia de proveedores y respaldar la expansión de EVM agregando una experiencia de usuario mejorada que atraiga a una audiencia más amplia.

Si bien estos enfoques garantizan la seguridad de un único módulo, la seguridad más amplia de las cuentas de contratos inteligentes no es infalible. Combinar módulos legítimos y pruebas de que no tienen colisiones de almacenamiento puede ser un desafío, lo que subraya la importancia de la billetera o la infraestructura AA para abordar tales preocupaciones.

Pensamientos finales

Al utilizar una pila modular de cuentas de contratos inteligentes, los proveedores de billeteras y las dApps pueden liberarse de las complejidades del mantenimiento tecnológico. Mientras tanto, los desarrolladores de módulos externos tienen la oportunidad de ofrecer servicios especializados adaptados a las necesidades individuales. Sin embargo, los desafíos a abordar incluyen lograr un equilibrio entre flexibilidad y seguridad, impulsar los estándares modulares e implementar interfaces estandarizadas que permitan a los usuarios actualizar y modificar fácilmente sus cuentas inteligentes.

Sin embargo, las cuentas de contrato inteligentes (SCA) modulares representan solo una pieza del rompecabezas de la adopción. Para aprovechar plenamente el potencial de SCA, se necesita soporte adicional de capa de protocolo de las soluciones de Capa 2, por lo que se necesita una infraestructura de paquetes robusta y un mempool peer-to-peer, un mecanismo de firma SCA más rentable y factible, sincronización y gestión de SCA entre cadenas. y desarrollar interfaces fáciles de usar.

De cara al futuro, imaginamos un futuro en el que la participación sea generalizada, lo que genera preguntas intrigantes: una vez que el flujo de pedidos de SCA se vuelva lo suficientemente rentable, ¿cómo entrarán en juego los mecanismos tradicionales de valor extraíble minero (MEV) para crear paquetes y capturar valor? Cuando la infraestructura madure, ¿cómo pueden las abstracciones de cuentas (AA) servir como capa fundamental para las transacciones “basadas en la intención”? Manténganse al tanto; el panorama evoluciona minuto a minuto.

Piezas importantes

1. Documento técnico seguro: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Documento de diamantes de imitación: https://docs.rhinestone.wtf/
3. Documento de biconomía: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Descargo de responsabilidad:

1. Este artículo está reimpreso de [SevenX Ventures ]. Todos los derechos de autor pertenecen al autor original [SevenX Ventures]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.