Al aprovechar una pila modular de cuentas de contratos inteligentes, los proveedores de billeteras y las dApps pueden escapar de la complejidad del mantenimiento técnico.

Escrito por: Rui

Compilado por: Shenchao TechFlow

Informe original en inglés publicado en septiembre de 2023

introducir

El cambio de cuentas de propiedad externa (EOA) a cuentas de contrato inteligentes (SCA) está en auge y cuenta con el apoyo de muchos entusiastas, incluido el propio Vitalik. A pesar del entusiasmo, la adopción de la SCA no ha sido tan generalizada como la de la EOA. Los problemas clave incluyen los desafíos del mercado bajista, las preocupaciones sobre la migración, los problemas de firmas, los gastos generales de gas y, lo más importante, los desafíos de ingeniería.

Una de las ventajas más importantes de la abstracción de cuentas (AA) es la capacidad de personalizar la funcionalidad mediante código. Sin embargo, un desafío de ingeniería importante es la no interoperabilidad de la funcionalidad AA, y esta fragmentación dificulta la integración y abre la puerta a la dependencia del proveedor. Además, garantizar la seguridad al actualizar y combinar funciones simultáneamente puede resultar complejo.

La abstracción de cuentas modulares surgió como un subconjunto del movimiento AA más amplio, un enfoque innovador para desacoplar las cuentas inteligentes de su funcionalidad personalizada. El objetivo es crear una estructura modular para desarrollar carteras seguras, perfectamente integradas y con diversas funcionalidades. En el futuro, puede implementar una “tienda de aplicaciones” de cuenta de contrato inteligente gratuita para que las billeteras y las dApps ya no se centren en la creación de funciones, sino en la experiencia del usuario.

AA Breve descripción

La EOA tradicional presenta muchos desafíos, como frases iniciales, gas, cadenas cruzadas y transacciones múltiples. Nunca tuvimos la intención de introducir complejidad, pero la realidad es que blockchain no es un juego fácil para las masas.

La abstracción de cuentas aprovecha las cuentas de contratos inteligentes, lo que permite la verificación y ejecución programables, lo que permite a los usuarios aprobar una serie de transacciones a la vez, en lugar de tener que firmar y transmitir cada transacción, y habilitar más funciones. Aporta beneficios a la experiencia del usuario (p. ej., abstracción de gas y claves de sesión), costo (p. ej., transacciones por lotes) y seguridad (p. ej., recuperación social, firma múltiple). Actualmente, existen dos formas de implementar la abstracción de cuentas:

• Capa de protocolo: algunos protocolos proporcionan soporte de abstracción de cuenta local. Las transacciones ZKsync, ya sea de EOA o SCA, siguen el mismo proceso, utilizando un único grupo de memoria y proceso de transacción para admitir AA, mientras que Starknet ha eliminado EOA y todas las cuentas Ambas son SCA Y tienen billeteras nativas de contratos inteligentes como Argent.
• Capa de contrato: para Ethereum y su equivalente L2, ERC4337 introduce una entrada de transacción separada para admitir AA sin cambiar la capa de consenso. Proyectos como Stackup, Alchemy, Etherspot, Biconomy, Candide y Plimico están creando infraestructura de paquetes, mientras que proyectos como Safe, Zerodev, Etherspot y Biconomy están creando pilas y SDK.

Dilemas de adopción de SCA

El tema de la abstracción de cuentas (AA) se ha debatido desde 2015 y ERC4337 lo destacó este año. Sin embargo, la cantidad de cuentas de contratos inteligentes implementadas sigue siendo mucho menor que la de EOA.

Profundicemos en este dilema:

Impacto del mercado bajista: Aunque AA introdujo beneficios como el inicio de sesión fluido y la abstracción de gas, las personas que actualmente experimentan el mercado bajista están compuestas principalmente por usuarios educados de EOA en lugar de usuarios nuevos, por lo que no es bueno para las dApps y las billeteras. No incentivos. Aun así, algunas aplicaciones líderes todavía están adoptando gradualmente AA, como Cyberconnect, que generó alrededor de 360.000 UserOps (transacciones AA) en solo un mes al presentar su sistema AA y su solución sin gas.

Barreras de migración: Para carteras y aplicaciones que han acumulado usuarios y activos, migrar activos de forma segura y conveniente sigue siendo un desafío. Sin embargo, iniciativas como EIP-7377 permiten a las EOA iniciar transacciones de migración únicas.

Problema de firma: El contrato inteligente en sí no puede firmar el mensaje de forma natural porque no tiene una clave privada como EOA. Esfuerzos como ERC1271 hacen posible dicha firma, pero la firma de mensajes no funciona hasta la primera transacción, lo que plantea un desafío para las billeteras que utilizan implementaciones contrafactuales. ERC-6492 propuesto por Ambire es un sucesor compatible con versiones anteriores de ERC-1271 y puede resolver los problemas anteriores.

Gastos generales: La implementación, simulación y ejecución de SCA genera costos más altos que el EOA estándar. Esto se convierte en una barrera para la adopción. Sin embargo, se han realizado algunas pruebas, como desvincular la creación de cuentas de las acciones del usuario y considerar eliminar las sales de cuentas y las comprobaciones de existencia, para reducir estos costos.

Dilema de ingeniería: El equipo de ERC-4337 ha establecido un repositorio de eth-infinitiism para proporcionar a los desarrolladores implementaciones básicas. Sin embargo, a medida que avanzamos hacia funcionalidades más granulares o específicas en diferentes casos de uso, la integración y decodificación se vuelve un desafío.

En este artículo, profundizaremos en el quinto tema: los desafíos de ingeniería.

Cuentas modulares de contratos inteligentes para resolver problemas de ingeniería

Una explicación más detallada de los desafíos de ingeniería es la siguiente:

• Fragmentación: varias funciones ahora se habilitan de diferentes maneras, ya sea a través de SCA específicos o sistemas de complementos independientes. Cada uno sigue sus propios estándares, lo que obliga a los desarrolladores a decidir qué plataformas admitir. Esto puede provocar el bloqueo de la plataforma o la duplicación de esfuerzos.
• Seguridad: si bien la flexibilidad entre cuentas y funciones aporta ventajas, también puede exacerbar los problemas de seguridad. Las funciones pueden auditarse colectivamente, pero la falta de una evaluación independiente puede aumentar el riesgo de violaciones de cuentas.
• Capacidad de actualización: a medida que la funcionalidad evoluciona, es importante conservar la capacidad de agregar, reemplazar o eliminar funcionalidad. Volver a implementar la funcionalidad existente con cada actualización introduce complejidad.

Para abordar estos problemas, necesitamos contratos actualizables para garantizar 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 sin problemas entre diferentes interfaces.

Estos términos convergen en un concepto común: construir una arquitectura modular de abstracción de cuentas (Modular AA).

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

Sin embargo, establecer y promover nuevos estándares es un gran desafío en cualquier industria. Pueden surgir muchas soluciones diferentes en las etapas iniciales antes de que todos acepten la solución principal. Sin embargo, es alentador que tanto el SDK 4337, los desarrolladores de billeteras, los equipos de infraestructura y los diseñadores de protocolos estén trabajando juntos para acelerar este proceso.

Estructura modular: cuenta principal y módulos

Llamada de delegado y contrato de representación

Llamadas externas y llamadas delegadas:

Aunque la llamada delegada es similar a la llamada, en lugar de ejecutar el contrato de destino en su propio contexto, ejecuta el contrato de destino en el estado actual del contrato de llamada. Esto significa que cualquier cambio de estado realizado por el contrato de destino se aplicará al almacenamiento del contrato de llamada.

Para implementar una estructura componible y actualizable se requiere un conocimiento básico llamado “contrato de agencia”.

• Contrato de agente: los contratos ordinarios almacenan su lógica y estado y no se pueden actualizar después de la implementación. Un contrato de proxy utiliza un delegado para llamar a otro contrato. Implementar una función por referencia, que se ejecuta en el estado actual del contrato del agente.
• Caso de uso: si bien el contrato de proxy sigue siendo el mismo, puede implementar nuevas implementaciones 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

Safe es una infraestructura modular líder de cuentas inteligentes diseñada para brindar seguridad y flexibilidad probadas en batalla, lo que permite a los desarrolladores crear diversas aplicaciones y billeteras. Vale la pena señalar que muchos equipos se basan en Safe o se inspiran en él. Biconomy lanza su cuenta ampliando la firma múltiple nativa 4337 y 1/1 en Safe. Con más de 164.000 contratos implementados y más de 30.700 millones de dólares en valor bloqueado, Safe es sin duda la mejor opción en este espacio.

Estructura de Caja Fuerte

• Contrato de cuenta segura: contrato de agente principal (con estado)

La cuenta segura es un contrato proxy porque llama delegada a un contrato singleton. La cuenta segura contiene el propietario, el umbral y la dirección de implementación, que se configuran como variables para el agente, definiendo así su estado.

• Contrato singleton: centro de integración (sin estado)

El singleton sirve a la cuenta Safe e integra y define diferentes integraciones, incluidos complementos, enlaces, controladores de funciones y validadores de firmas.

• Contrato de módulo: lógica y funciones personalizadas.

Los módulos son muy poderosos. Como tipo modular, los complementos pueden definir diferentes funciones, como flujos de pago, mecanismos de recuperación y claves de sesión, y servir como un puente entre cadenas entre Web2 y Web3 mediante la obtención de datos fuera de la cadena. Otros módulos, como los ganchos, actúan como protectores de seguridad y los controladores de funciones responden a cualquier instrucción.

¿Qué sucede cuando adoptamos Safe?

• Contratos actualizables:

Cada vez que se introduce un nuevo complemento, es necesario implementar un nuevo singleton. Los usuarios conservan la autonomía para actualizar Safe a la versión singleton deseada para satisfacer sus preferencias y requisitos.

• Módulos componibles y reutilizables:

La naturaleza modular de los complementos permite a los desarrolladores crear funciones de forma independiente. Luego, pueden seleccionar y combinar estos complementos según sus propios casos de uso, lo que facilita un enfoque altamente personalizable.

Agente de diamantes ERC-2535

Acerca de ERC2535 y Diamond Agent

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

**¿Qué es la estructura Diamante? **

• Contrato Diamond: Contrato de Agente Principal (Stateful) Diamond es un contrato proxy que llama funciones desde su implementación a través de llamadas de delegado.
• Módulos/complementos/contratos facetados: lógica y funcionalidad personalizadas (sin estado) Un módulo o la llamada faceta es un contrato sin estado que puede implementar su funcionalidad en uno o más Diamonds. Son contratos independientes que pueden compartir funciones internas, bibliotecas y variables de estado.

**¿Qué sucede cuando adoptamos Diamond? **

• Contratos actualizables: Diamond proporciona una forma sistemática de aislar diferentes complementos y conectarlos entre sí, y agregar, reemplazar o eliminar directamente cualquier complemento a través de la función DiamondCut. No hay límite para la cantidad de complementos que se pueden agregar a Diamond con el tiempo.
• Complementos modulares y reutilizables: cualquier número de Diamonds puede utilizar un complemento implementado, lo que reduce en gran medida los costos de implementación.

Diferencia entre Safe Smart Account y el método Diamond

Existen muchas similitudes entre las arquitecturas Safe y Diamond, ya que ambas dependen de contratos proxy como núcleo y hacen referencia a contratos lógicos para la capacidad de actualización y la modularidad.

Sin embargo, la principal diferencia radica en el manejo de contratos lógicos. Aquí hay instrucciones más detalladas:

• Flexibilidad: Con un nuevo complemento habilitado, Safe necesita volver a implementar su contrato singleton para implementar los cambios en su agente. Por el contrario, Diamond hace esto directamente a través de la función DiamondCut en su delegado. Esta diferencia de enfoque significa que Safe conserva un mayor grado de control, mientras que Diamond introduce una mayor flexibilidad y modularidad.
• Seguridad: Actualmente, la llamada delegada se utiliza en ambas estructuras, lo que permite que el 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 usa la llamada delegada entre múltiples contratos de módulo (complementos). Por lo tanto, es posible que un complemento malicioso sobrescriba otro complemento, introduciendo así el riesgo de conflictos de almacenamiento que pueden comprometer la integridad del agente.
• Costo: La flexibilidad inherente al enfoque de Diamond conlleva mayores preocupaciones de seguridad. Esto agrega un factor de costo y requiere una auditoría completa cada vez que se agrega un nuevo complemento. La clave es garantizar que estos complementos no interfieran con la funcionalidad de los demás, lo que puede ser un desafío para las pequeñas y medianas empresas que intentan mantener estándares de seguridad sólidos.

El “Método de Cuenta Inteligente Segura” y el “Método Diamante” son ejemplos de diferentes estructuras que involucran agentes y módulos. Cómo equilibrar la flexibilidad y la seguridad es fundamental, y es probable que ambos enfoques se complementen en el futuro.

Orden del módulo: validador, ejecutor y gancho

Ampliemos nuestra discusión presentando el estándar propuesto por el equipo de Alchemy, ERC6900, que se inspiró en Diamond y se adaptó específicamente para ERC-4337. Resuelve el desafío de la modularidad en las cuentas inteligentes al proporcionar una interfaz común y coordinar el trabajo entre los desarrolladores de complementos y billeteras.

Cuando se trata del proceso de transacción de AA, hay tres procesos principales: Verificación, Ejecución y Hook. Como comentamos anteriormente, estos pasos se pueden gestionar llamando al módulo mediante una cuenta proxy. Aunque diferentes proyectos pueden usar nombres diferentes, es importante capturar una lógica subyacente similar.

• Verificación: Garantiza la autenticidad y autoridad de la cuenta de la persona que llama.
• Ejecución: Ejecute cualquier lógica personalizada permitida por la cuenta. *Hook: como 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.

Separar módulos según una lógica diferente es crucial. Un enfoque estandarizado debería especificar cómo se deben escribir las funciones Hook, ejecución y verificación de cuentas de contratos inteligentes. Ya sea Safe o ERC6900, la estandarización ayuda a reducir la necesidad de esfuerzos de desarrollo únicos para una implementación o ecosistema específico y evita la dependencia de un proveedor.

Descubrimiento y seguridad del módulo

Una solución que está en auge consiste en crear un lugar que permita a los usuarios descubrir módulos verificables, lo que podríamos llamar un “registro”. Este registro es similar a una “tienda de aplicaciones” y está diseñado para promover un mercado modular simplificado pero próspero.

Protocolo{básico}seguro

Safe{Core} Protocol es un protocolo de cuenta de contrato inteligente interoperable y de código abierto diseñado para aumentar la accesibilidad para una variedad de proveedores y desarrolladores a través de estándares y reglas claramente definidos, manteniendo al mismo tiempo una seguridad sólida.

• Cuenta: En el protocolo Safe{Core}, el concepto de cuenta es flexible y no está restringido por una implementación específica. Esto permite que participen varios proveedores de servicios de cuentas.
• Gerente: El gerente actúa como coordinador entre cuentas, registros y módulos. También es responsable de la seguridad, actuando como capa de permisos.
• Registro: El registro define atributos de seguridad y aplica estándares de módulos como ERC6900, con el objetivo de crear un entorno de “tienda de aplicaciones” abierto para descubrimiento y seguridad.
• Módulos: los módulos manejan la funcionalidad y se proporcionan en varios tipos iniciales, incluidos complementos, ganchos, validadores de firmas y controladores de funciones. Los desarrolladores pueden contribuir siempre que cumplan con los estándares establecidos.

Diseño de diamantes de imitación

El proceso se desarrolla de la siguiente manera:

• Crear definición de esquema: el esquema sirve como una estructura de datos predefinida como prueba. Las empresas pueden personalizar el patrón según sus casos de uso específicos.
• Crear un módulo basado en un patrón: el contrato inteligente se registra como módulo, obtiene el código de bytes y selecciona el ID del patrón. Estos datos luego se almacenan en el registro.
• Obtener el certificado del módulo: El prover/auditor puede proporcionar certificados para el módulo según el esquema. Estos certificados pueden incluir identificadores únicos (UID) y referencias a otros certificados para vincularlos. Se pueden propagar en la cadena y verificar que se cumplan ciertos umbrales en la cadena de destino.
• Utilice analizadores para implementar lógica compleja: los analizadores se configuran opcionalmente en el patrón. Se pueden llamar durante la creación del módulo, el establecimiento de pruebas y el desmontaje. Estos analizadores permiten a los desarrolladores incorporar lógica compleja y diversa manteniendo la estructura de la prueba.
• Acceso a consultas fácil de usar: Query proporciona una forma para que los usuarios accedan a la información de seguridad desde el front-end. El EIP se puede encontrar aquí.

Aunque este modelo aún 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, integrar billeteras y a los usuarios encontrar módulos fácilmente y verificar su información de certificación. Puede haber los siguientes usos en el futuro:

• Certificador: Entidades de confianza, como Safe, pueden cooperar con Rhinestone como certificadores de módulos internos. Al mismo tiempo, también pueden participar probadores independientes.
• Desarrolladores de módulos: Con la formación de un mercado abierto, es posible que los desarrolladores de módulos comercialicen su trabajo a través del registro.
• Usuarios: a través de interfaces fáciles de usar, como billeteras o dApps, los usuarios pueden ver la información del módulo y delegar la confianza a diferentes probadores.

El concepto de “registro de módulos” proporciona oportunidades de ganancias para los desarrolladores de complementos y módulos. También podría allanar el camino para un “mercado de módulos”. Algunos de estos aspectos pueden ser supervisados por el equipo de Safe, mientras que otros pueden manifestarse como mercados descentralizados que invitan a todos a contribuir y proporcionar un seguimiento de auditoría transparente. Al adoptar este enfoque, podemos evitar la dependencia de proveedores y respaldar la expansión de EVM al brindar una mejor experiencia de usuario que atraiga a un público más amplio.

Aunque estos métodos garantizan la seguridad de los módulos individuales, la seguridad general de las cuentas de contratos inteligentes no es absolutamente confiable. Combinar módulos legítimos y demostrar que no tienen conflictos de almacenamiento puede ser un desafío, lo que subraya la importancia de las billeteras o la infraestructura AA para resolver tales problemas.

Resumir

Al aprovechar una pila modular de cuentas de contratos inteligentes, los proveedores de billeteras y las dApps pueden escapar de la complejidad del mantenimiento técnico. Al mismo tiempo, los desarrolladores de módulos externos tienen la oportunidad de ofrecer servicios profesionales adaptados a las necesidades individuales. Sin embargo, los desafíos que deben abordarse incluyen lograr un equilibrio entre flexibilidad y seguridad, impulsar el avance de estándares modulares e implementar interfaces estandarizadas que permitan a los usuarios actualizar y modificar fácilmente sus Cuentas Inteligentes.

Sin embargo, las cuentas modulares de contratos inteligentes (SCA) son solo una pieza del rompecabezas de la adopción. Para aprovechar plenamente el potencial de SCA, también se requiere soporte de capa de protocolo de soluciones de segunda capa, así como una poderosa infraestructura de paquetes y grupos de memoria de igual a igual, mecanismos de firma SCA más rentables y factibles, sincronización SCA entre cadenas. y gestión, además de desarrollar interfaces fáciles de usar.

Visualizamos un futuro con una participación amplia, lo que plantea algunas preguntas interesantes: una vez que el proceso de pedidos de SCA se vuelva lo suficientemente rentable, ¿cómo entrarán al espacio los mecanismos tradicionales de valor extraíble minero (MEV), construirán paquetes y capturarán valor? Cuando la infraestructura madure, ¿cómo puede la abstracción de cuentas (AA) convertirse en la capa básica para las transacciones “basadas en la intención”? Estén atentos ya que esta área está en constante evolución.