*Nota del editor: Las cuentas de contratos inteligentes (SCA, por sus siglas en inglés) están ganando impulso y cuentan con el apoyo de muchos empresarios principales, incluido Vitalik, pero todavía hay muchos desafíos para la adopción de SCA. La abstracción de cuentas (AA) tiene la ventaja de usar la personalización de código, pero su falta de interoperabilidad presenta problemas de integración y bloqueo de proveedores. La abstracción de cuentas modulares tiene como objetivo crear una estructura modular para desarrollar billeteras que sean versátiles, seguras y perfectamente integradas. *
Rui, inversor de SevenX Ventures >, identificó los cinco principales desafíos para la adopción de SCA (impacto en el mercado bajista, dificultad de migración, problemas de firma, altos costos de gas y desafíos de ingeniería) y los discutió más a fondo. Además, un análisis de la arquitectura de las cuentas modulares de contratos inteligentes señala que la SCA modular es solo una pequeña parte de los desafíos de adopción.
Para aprovechar todo el potencial de SCA, se necesitan soluciones de capa 2 para proporcionar soporte adicional a la capa de protocolo, una infraestructura robusta de empaquetadores y grupos de memoria punto a punto, un mecanismo de firma SCA más rentable y viable, sincronización y gestión de SCA entre cadenas, y el desarrollo de interfaces fáciles de usar.
¿Qué sucederá en el futuro, a medida que se resuelvan los desafíos actuales y más personas adopten SCA? Rui también hace algunas preguntas interesantes. BlockBeats compiló el texto original de la siguiente manera:
El cambio de las cuentas de propiedad externa (EOA) a las cuentas de contratos inteligentes (SCA) está ganando impulso y ya cuenta con el apoyo de muchos empresarios principales, incluido Vitalik. A pesar de ello, la adopción de la SCA no ha sido tan generalizada como la de la EOA. Entre las cuestiones clave se encuentran el impacto del mercado bajista, la dificultad de migrar la EOA a la SCA, los problemas de firma, los altos costes del gas y, lo que es más importante, los retos de desarrollo.
La ventaja más significativa de la abstracción de cuentas (AA) es la capacidad de personalizar la funcionalidad mediante código. Sin embargo, la falta de interoperabilidad de la funcionalidad AA presenta un desafío importante, ya que esta fragmentación dificulta la integración de AA y refuerza la dependencia del proveedor. Además, también es un desafío importante garantizar la seguridad y, al mismo tiempo, ser actualizable y componible.
La aparición de la abstracción de cuentas modulares es un nicho en la tendencia AA, un enfoque innovador que separa las cuentas inteligentes de sus funciones personalizadas. El objetivo era crear una estructura modular para desarrollar billeteras con múltiples funciones, seguridad e integración perfecta. En el futuro, la abstracción modular de cuentas permitirá una cuenta de contrato inteligente gratuita "tienda de aplicaciones", lo que permitirá a las billeteras y dApps centrarse en mejorar la experiencia del usuario en lugar de tener que dedicar demasiado esfuerzo a crear funciones.
Breve abstracción del relato (AA)
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
La EOA tradicional presenta muchos desafíos para la exposición de las personas a la cadena de bloques, como las frases semilla, las tarifas de gas, las operaciones entre cadenas y las transacciones múltiples.
La abstracción de cuentas aprovecha las cuentas de contratos inteligentes para permitir la validación y la configuración programables. Esto significa que los usuarios podrán aprobar una serie de transacciones a la vez, en lugar de tener que firmar y transmitir cada transacción. La abstracción de cuentas también puede permitir más funciones, como la mejora de la experiencia del usuario (por ejemplo, la abstracción de gas y las claves de sesión), la reducción de costos (por ejemplo, las transacciones masivas) y la mejora de la seguridad (por ejemplo, la recuperación social, la firma múltiple). Actualmente, hay dos formas de abstraer cuentas:
· Capa de protocolo: Algunos protocolos proporcionan de forma nativa soporte de abstracción de cuentas nativas, las transacciones de ZKSync utilizan un único mempool y flujo de transacciones para admitir AA, tanto de EOA como de SCA siguen el mismo proceso, mientras que Starknet ha eliminado EOA, todas las cuentas son SCA y tienen billeteras nativas de contratos inteligentes como Argent.
· Capa de contrato: Para Ethereum y L2 similares, ERC4337 introdujo un mempool separado para admitir AA sin cambiar la capa de consenso. Lugares como Stackup, Alchemy, Etherspot, Biconomy, Candide y Plimico están construyendo una infraestructura de empaquetados, mientras que cosas como Safe, Zerodev, Etherspot y Biconomy están construyendo paquetes y SDK.
El dilema de adoptar SCA
El tema de la abstracción de cuentas (AA) se ha discutido desde 2015 y este año ha sido objeto de atención por ERC 4337. Sin embargo, el número de cuentas de contratos inteligentes desplegadas todavía no es tan bajo como EOA.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Profundicemos en este dilema:
El impacto del mercado bajista
A pesar de las ventajas de AA, como el inicio de sesión sin problemas y la extracción de gas, en el actual mercado bajista, donde todos los usuarios son usuarios de EOA educados y no hay muchos usuarios nuevos, no hay ningún incentivo para que las dApps y las billeteras adopten SCA. Aun así, algunas de las principales dApps están adoptando gradualmente AA, como Cyberconnect, que generó alrededor de 360.000 UserOps (transacciones AA) en solo un mes al introducir su sistema AA y su solución sin gas.
Obstáculos migratorios
Para las billeteras y aplicaciones que ya han acumulado usuarios y activos, sigue siendo un desafío migrar activos de manera segura y conveniente. Sin embargo, un esquema como EIP-7377 permite a EOA iniciar una transacción de migración única.
Problemas de firma
El contrato inteligente en sí no puede firmar mensajes porque no tiene una clave privada como EOA. Intentos como ERC1271 hacen que esto sea posible, pero la firma de mensajes no funciona hasta la primera transacción, lo que a su vez plantea un desafío para las billeteras implementadas con contrafactuales. ERC-6492, propuesto por Ambire, es el sucesor compatible con versiones anteriores de ERC-1271 y puede ser capaz de resolver el problema anterior.
Costo del gas
El mayor costo de implementar, simular y ejecutar SCA en comparación con EOA estándar también es una barrera para la adopción. Sin embargo, se han realizado algunas pruebas, como separar la creación de cuentas de las acciones del usuario, eliminar la "sal" asociada a una cuenta, etc.
Problemas de ingeniería
El equipo de ERC-4337 ha creado un repositorio de eth-infinitism que proporciona una implementación base para los desarrolladores. Sin embargo, a medida que los desarrolladores escalan a funciones más granulares y específicas para diferentes casos de uso, la integración y la decodificación se enfrentan a más desafíos. En este artículo, profundizaremos en los desafíos de ingeniería.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Resuelva los desafíos de ingeniería con cuentas modulares de contratos inteligentes
Los desafíos de ingeniería se pueden desarrollar en tres aspectos: fragmentación, seguridad y capacidad de actualización.
· Fragmentación: Las funciones ahora se pueden habilitar de varias maneras, ya sea a través de una SCA específica o a través de un sistema de complemento independiente. Cada plataforma y proveedor de servicios sigue sus propios estándares, lo que lleva a los desarrolladores a decidir qué plataformas y proveedores de servicios admitir. Esto puede dar lugar a una posible dependencia de la plataforma (proveedor) o a un trabajo redundante.
· Seguridad: Si bien desacoplar las cuentas y las funciones brinda el beneficio de la flexibilidad, también puede hacer que los problemas de seguridad sean más graves. Debido a que todas las características pueden revisarse juntas, la falta de una evaluación independiente puede aumentar el riesgo de vulnerabilidades de la cuenta.
· Capacidad de actualización: a medida que su cuenta crece, es importante mantener la capacidad de agregar, reemplazar o eliminar funciones, y cada actualización que vuelve a implementar las funciones existentes presenta 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 una transición fluida entre diferentes frontends.
Estos términos convergen en un concepto común: la construcción de una arquitectura de abstracción de cuentas modulares (AA modular).
La abstracción de cuentas modulares es una subdivisión del desarrollo más amplio de AA que prevé la modularización de las cuentas inteligentes para proporcionar servicios personalizados 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 en cualquier industria es un gran desafío. Hasta que todos acepten el mismo estándar, pueden surgir muchas soluciones diferentes en la fase inicial. Es alentador ver que aquellos que trabajan para refinar y promover la abstracción de cuentas, ya sea el SDK 4337, billeteras, equipos de infraestructura o diseñadores de capas de protocolo, están trabajando juntos para acelerar este proceso.
Estructura modular: cuentas maestras y módulos
Cómo la cuenta invoca el módulo para implementar la función
Delegar contrato de llamada y proxy
Llamadas externas y delegadas:
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
Acerca de las llamadas de delegados
Si bien una "llamada delegada" es similar a una "llamada", no se ejecuta en el contexto del contrato de destino, sino en el contexto del estado actual del contrato de llamada. Esto significa que cualquier cambio de estado realizado por el contrato de destino cambiará el almacenamiento del contrato de llamada.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Contratos de proxy y llamadas de delegado
**Para lograr una estructura componible y actualizable, es necesario introducir un concepto básico de "contrato de agencia". **
Contrato de proxy: un contrato normal almacena su lógica y estado, y no se puede actualizar después de la implementación. El contrato de proxy se implementa en otro contrato mediante una llamada delegada. Implemente la función por referencia para ejecutarla en el estado actual del contrato de proxy.
Caso de uso: Si bien el contrato de proxy sigue siendo el mismo, puede implementar una nueva implementación detrás del agente. Los contratos de proxy son actualizables y menos costosos de implementar y mantener en blockchains públicas.
Arquitectura segura! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Arquitectura segura
Qué es Safe: Safe es la infraestructura modular líder de cuentas inteligentes diseñada para proporcionar seguridad y flexibilidad probadas en batalla, y permite a los desarrolladores crear diversas aplicaciones y billeteras. Muchos equipos están creando aplicaciones sobre (o inspiradas en) Safe. Por ejemplo, Biconomy amplió Safe con 4337 nativo y multifirma 1/1 cuando lanzó su cuenta de contrato inteligente. Habiendo sido testigo del despliegue de más de 164.000 contratos y asegurado más de 30.700 millones de dólares en valor, Safe es sin duda un líder en su espacio.
La estructura de Safe incluye un contrato de cuenta segura, un contrato singleton y un contrato de módulo.
Contrato de apoderado: con estado
La cuenta segura es un contrato proxy porque la llamada delegada es un contrato singleton. Una cuenta de seguridad contiene variables en las que el propietario, el umbral y la dirección de implementación se establecen como agentes, y su estado se define en función de ellos.
单例合约(singleton contract):Integration Hub(无状态)
El contrato singleton sirve a las cuentas seguras y define diferentes integraciones de contratos de módulos, incluidos Plugin, Hook, Function Handler y Signature Validator.
Módulos: Lógica y funcionalidad personalizadas
Los contratos de módulos son poderosos. Los plugins, como tipos modulares, pueden definir diferentes funciones, como los flujos de pago, los mecanismos de recuperación y las claves de sesión, y pueden actuar como puente entre la Web2 y la Web3 mediante la obtención de datos fuera de la cadena. Otros módulos, como los ganchos y los controladores de funciones como guardias de seguridad, pueden responder a cualquier comando.
Los cambios que han cambiado desde la adopción de Safe:
Contratos actualizables: Cada vez que se introduce un nuevo complemento, se debe implementar un nuevo singleton. El usuario conserva la autonomía para actualizar Safe a la versión singleton deseada.
Módulos componibles y reutilizables: La naturaleza modular de los plugins permite a los desarrolladores desarrollar funciones de forma independiente. Son libres de elegir y combinar estos complementos de acuerdo con su caso de uso, lo que resulta en un enfoque altamente personalizable.
ERC-2535 Diamante 代理
**! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
Acerca de ERC2535, Agente de Diamantes:
ERC2535 modelo estandarizado Diamond, un sistema modular de contratos inteligentes que se puede actualizar/escalar después de la implementación prácticamente sin limitaciones de tamaño. Actualmente, muchos equipos, como los experimentos de Kernel y Soul Wallet de Zerodev, se han inspirado en la estructura Diamond.
¿Qué es la estructura del diamante?**
Contrato Diamante: Contrato de proxy principal (con estado) Diamond es un contrato de proxy que utiliza un método de invocación delegado para llamar a una función desde su implementación.
Módulo/Plugin/Faceta Contract: Lógica y Funcionalidad Personalizada (sin Estado) Un módulo o llamada Faceta es un contrato sin estado que puede desplegar su funcionalidad en uno o más Diamantes. Son contratos separados e independientes que pueden compartir funciones intrínsecas, bibliotecas y variables de estado.
Cambios con Diamante:
Contratos actualizables: Diamond proporciona una forma sistemática de aislar diferentes complementos y conectarlos entre sí, compartir datos entre ellos y también agregar/reemplazar/eliminar cualquier complemento directamente usando la función diamondCut. Con el tiempo, no habrá límite en el número de plugins que se pueden añadir a Diamond.
Plugins modulares y reutilizables: Los plugins desplegados pueden ser utilizados por cualquier número de Diamonds, lo que reduce drásticamente los costes de implementación.
Diferencia entre la Cuenta Inteligente Segura y el método Diamante:
Hay muchas similitudes entre las arquitecturas Safe y Diamond, las cuales se basan en sus contratos proxy principales y contratos lógicos de referencia para la capacidad de actualización y la modularidad.
La principal diferencia entre ambos es el manejo de los contratos lógicos. Específicamente:
· Flexibilidad: Con un nuevo complemento habilitado, Safe necesita volver a implementar su contrato singleton para implementar cambios en su proxy. Por el contrario, Diamond logra esto directamente a través de la función diamondCut en su contrato de representación. La diferencia de enfoque significa que Safe conserva un mayor grado de control, mientras que Diamond introduce una mayor flexibilidad y modularidad.
· Seguro: Actualmente utilizado en ambas estructuras, permite que el código externo manipule el almacenamiento del contrato principal. En la arquitectura segura, las llamadas delegadas apuntan a un único contrato lógico, mientras que Diamond usa llamadas delegadas en varios contratos-complementos de módulos. Como resultado, es posible que un complemento malicioso sobrescriba otro complemento, lo que introduce el riesgo de conflictos de almacenamiento y compromete la integridad del proxy.
· Costo: En el enfoque Diamante, la flexibilidad y la seguridad se unen. Esto aumenta el costo, y cada vez que se agrega un nuevo complemento, debe auditarse por completo. La clave es asegurarse de que estos complementos no interfieran con la funcionalidad de los demás, un propósito que es un desafío, especialmente para las pequeñas y medianas empresas que luchan por mantener altos estándares de seguridad.
El "Método de la Cuenta Inteligente Segura" y el "Método Diamante" son ejemplos de diferentes estructuras que involucran agentes y módulos. Equilibrar la flexibilidad y la seguridad es fundamental, y estos dos enfoques seguirán evolucionando y complementándose en el futuro.
Orden del módulo: validador, ejecutor y gancho
Analicemos esto más a fondo presentando ERC6900, un estándar inspirado en Diamond del equipo de Alchemy que está diseñado específicamente para ERC-4337. Resuelve los desafíos de la modularidad de las cuentas inteligentes al proporcionar una interfaz común y coordina el trabajo entre los desarrolladores de complementos y billeteras.
Cuando se trata del proceso de transacción de AA, hay tres procesos principales: validación, ejecución y vinculación. Como hemos comentado anteriormente, todos estos pasos se pueden administrar mediante el módulo de llamada a la cuenta de proxy. Si bien los diferentes proyectos pueden usar diferentes nombres, es importante comprender la lógica subyacente de la similitud.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
El nombre de la función en diferentes diseños
Validador: Garantiza la autenticidad y los permisos de la persona que llama a la cuenta.
Ejecución (UTOR): ejecute cualquier lógica personalizada que permita la cuenta.
Gancho: Actúa como un módulo que se ejecuta antes o después de otra función. Puede modificar el estado o deshacer toda la llamada.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Es importante separar los módulos de acuerdo con diferentes lógicas. El enfoque estandarizado debe especificar cómo escribir funciones de validación, ejecución y vinculación para cuentas de contratos inteligentes. Ya sea segura o ERC6900, la estandarización ayuda a reducir la necesidad de esfuerzos de desarrollo únicos específicos para ciertas implementaciones o ecosistemas y evita la dependencia de un proveedor.
Descubrimiento y seguridad de módulos
Cómo encontrar y validar módulos de forma abierta: Una solución que se está desarrollando consiste en crear un área que permita a los usuarios descubrir módulos verificables, lo que se puede denominar "registro". El registro funciona como una "tienda de aplicaciones" y tiene como objetivo fomentar un mercado modular simplificado pero próspero.
Safe{Core} 协议
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
El protocolo Safe{Core} es un protocolo interoperable de código abierto para cuentas de contratos inteligentes diseñado para mejorar la accesibilidad para una amplia gama de proveedores y desarrolladores, al tiempo que mantiene una seguridad sólida a través de estándares y reglas bien definidos.
· Cuentas: En el protocolo Safe{Core}, el concepto de cuentas es flexible y no está vinculado a una implementación específica. Esto permite que se involucren diferentes proveedores de servicios de cuentas.
· Gerente: El gerente actúa como coordinador entre cuentas, registros y módulos. También se encarga de la seguridad como capa de licencias.
· Registro: El registro define los atributos de seguridad y hace cumplir los estándares de los módulos, como ERC6900 para crear un entorno abierto de "tienda de aplicaciones" para la visibilidad y la seguridad.
· Módulos: Los módulos manejan la funcionalidad y tienen una variedad de tipos iniciales, incluidos complementos, ganchos, validadores de firmas y controladores de funciones. Los desarrolladores pueden participar siempre que cumplan con los criterios establecidos.
Diamantes de imitación 设计
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
El proceso se desarrolla de la siguiente manera:
· Crear un esquema: Un esquema proporciona una estructura de datos predefinida. Las personas pueden adaptarlo para que se adapte a su caso de uso específico.
· Crear módulos basados en el esquema: el contrato inteligente registrado como módulo obtiene el código de bytes y selecciona el ID del esquema, y los datos se almacenan en el registro.
· Obtener la certificación del módulo: El probador/auditor puede proporcionar una prueba del módulo basada en la arquitectura. Estas certificaciones pueden incluir un identificador único (UID) y referencias a otras certificaciones utilizadas para el vínculo. Pueden propagarse a través de cadenas y verificar que la cadena de destino cumpla con ciertos umbrales.
· Implementar lógica compleja con un solucionador: El analizador (opcional) entra en juego. Se les puede llamar durante la creación del módulo, el establecimiento de la atestación y la revocación. Estos analizadores permiten a los desarrolladores integrar lógicas complejas y diversas mientras mantienen estructuras de prueba.
Acceso a consultas fácil de usar: la consulta proporciona una manera para que los usuarios accedan a la información de seguridad desde el front-end.
Si bien el modelo aún se encuentra en sus primeras etapas, tiene el potencial de establecer estándares de manera descentralizada y colaborativa. El registro permite a los desarrolladores registrar sus módulos, a los auditores verificar su seguridad, a las billeteras integrarlas y permite a los usuarios encontrar fácilmente los módulos y verificar su información de certificación. Varios usos futuros podrían ser:
· Certificador: Una entidad de confianza como Safe puede trabajar con Rhinestone como probador de módulos internos. Al mismo tiempo, también pueden adherirse certificadores independientes.
· Desarrollador de módulos: Con la formación de un mercado abierto, es posible que los desarrolladores de módulos moneticen su trabajo a través de un registro.
· Usuarios: Participar a través de una interfaz fácil de usar, como una billetera o dApp, permite a los usuarios verificar la información del módulo y delegar la confianza a diferentes probadores.
El concepto de "registro de módulos" abre vías para que los desarrolladores de plugins y módulos puedan monetizar. Podría allanar aún más el camino para un "mercado de módulos". Algunos aspectos pueden ser supervisados por el equipo de Safe, mientras que otros pueden manifestarse como un mercado descentralizado que invita a todos a contribuir y proporciona una pista de auditoría transparente. La incorporación de esto evita la dependencia de un proveedor y respalda la expansión de la EVM al agregar una experiencia de usuario mejorada que atrae a un público más amplio.
Si bien estos métodos garantizan la seguridad de los módulos individuales, las cuentas de contratos inteligentes no son infalibles cuando se trata de una seguridad más amplia. Puede ser un desafío combinarlo con módulos de cumplimiento y demostrar que no tienen conflictos de almacenamiento, lo que destaca la importancia de las billeteras o la infraestructura AA para abordar estos problemas.
Resumen
Al aprovechar una pila modular de cuentas de contratos inteligentes, los proveedores de billeteras y dApps pueden liberarse de las complejidades del mantenimiento técnico. Al mismo tiempo, los desarrolladores de módulos externos tienen la oportunidad de brindar servicios profesionales personalizados. Sin embargo, los desafíos que deben abordarse incluyen lograr un equilibrio entre flexibilidad y seguridad, impulsar estándares modulares e implementar interfaces estandarizadas que permitan a los usuarios actualizar y modificar fácilmente sus cuentas inteligentes.
Además, las cuentas modulares de contratos inteligentes (SCA) son solo una pequeña parte del rompecabezas de la adopción. Para aprovechar todo el potencial de SCA, se necesitan soluciones de capa 2 para proporcionar soporte adicional a la capa de protocolo, como una sólida infraestructura de paquetes y grupos de memoria punto a punto, un mecanismo de firma SCA más rentable y viable, mecanismos de sincronización y gestión de SCA entre cadenas, y el desarrollo de interfaces fáciles de usar.
En el futuro, habrá una mayor adopción de SCA, pero también planteará algunas preguntas interesantes: ¿cómo entrarán en el espacio los mecanismos tradicionales de valor extraíble (MEV) de los mineros para construir empaquetadores y capturar valor una vez que el flujo de órdenes de SCA sea lo suficientemente rentable, y cómo servirá la abstracción de cuentas (AA) como capa base para las transacciones "basadas en la intención" cuando la infraestructura madure?
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Una mirada en profundidad a las arquitecturas y desafíos de las cuentas modulares de contratos inteligentes
作者:Rui,Inversor de SevenX Ventures
编译:Luccy,Joyce,BlockBeats
Rui, inversor de SevenX Ventures >, identificó los cinco principales desafíos para la adopción de SCA (impacto en el mercado bajista, dificultad de migración, problemas de firma, altos costos de gas y desafíos de ingeniería) y los discutió más a fondo. Además, un análisis de la arquitectura de las cuentas modulares de contratos inteligentes señala que la SCA modular es solo una pequeña parte de los desafíos de adopción.
El cambio de las cuentas de propiedad externa (EOA) a las cuentas de contratos inteligentes (SCA) está ganando impulso y ya cuenta con el apoyo de muchos empresarios principales, incluido Vitalik. A pesar de ello, la adopción de la SCA no ha sido tan generalizada como la de la EOA. Entre las cuestiones clave se encuentran el impacto del mercado bajista, la dificultad de migrar la EOA a la SCA, los problemas de firma, los altos costes del gas y, lo que es más importante, los retos de desarrollo.
La ventaja más significativa de la abstracción de cuentas (AA) es la capacidad de personalizar la funcionalidad mediante código. Sin embargo, la falta de interoperabilidad de la funcionalidad AA presenta un desafío importante, ya que esta fragmentación dificulta la integración de AA y refuerza la dependencia del proveedor. Además, también es un desafío importante garantizar la seguridad y, al mismo tiempo, ser actualizable y componible.
La aparición de la abstracción de cuentas modulares es un nicho en la tendencia AA, un enfoque innovador que separa las cuentas inteligentes de sus funciones personalizadas. El objetivo era crear una estructura modular para desarrollar billeteras con múltiples funciones, seguridad e integración perfecta. En el futuro, la abstracción modular de cuentas permitirá una cuenta de contrato inteligente gratuita "tienda de aplicaciones", lo que permitirá a las billeteras y dApps centrarse en mejorar la experiencia del usuario en lugar de tener que dedicar demasiado esfuerzo a crear funciones.
Breve abstracción del relato (AA)
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
La EOA tradicional presenta muchos desafíos para la exposición de las personas a la cadena de bloques, como las frases semilla, las tarifas de gas, las operaciones entre cadenas y las transacciones múltiples.
La abstracción de cuentas aprovecha las cuentas de contratos inteligentes para permitir la validación y la configuración programables. Esto significa que los usuarios podrán aprobar una serie de transacciones a la vez, en lugar de tener que firmar y transmitir cada transacción. La abstracción de cuentas también puede permitir más funciones, como la mejora de la experiencia del usuario (por ejemplo, la abstracción de gas y las claves de sesión), la reducción de costos (por ejemplo, las transacciones masivas) y la mejora de la seguridad (por ejemplo, la recuperación social, la firma múltiple). Actualmente, hay dos formas de abstraer cuentas:
· Capa de protocolo: Algunos protocolos proporcionan de forma nativa soporte de abstracción de cuentas nativas, las transacciones de ZKSync utilizan un único mempool y flujo de transacciones para admitir AA, tanto de EOA como de SCA siguen el mismo proceso, mientras que Starknet ha eliminado EOA, todas las cuentas son SCA y tienen billeteras nativas de contratos inteligentes como Argent.
· Capa de contrato: Para Ethereum y L2 similares, ERC4337 introdujo un mempool separado para admitir AA sin cambiar la capa de consenso. Lugares como Stackup, Alchemy, Etherspot, Biconomy, Candide y Plimico están construyendo una infraestructura de empaquetados, mientras que cosas como Safe, Zerodev, Etherspot y Biconomy están construyendo paquetes y SDK.
El dilema de adoptar SCA
El tema de la abstracción de cuentas (AA) se ha discutido desde 2015 y este año ha sido objeto de atención por ERC 4337. Sin embargo, el número de cuentas de contratos inteligentes desplegadas todavía no es tan bajo como EOA.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Profundicemos en este dilema:
A pesar de las ventajas de AA, como el inicio de sesión sin problemas y la extracción de gas, en el actual mercado bajista, donde todos los usuarios son usuarios de EOA educados y no hay muchos usuarios nuevos, no hay ningún incentivo para que las dApps y las billeteras adopten SCA. Aun así, algunas de las principales dApps están adoptando gradualmente AA, como Cyberconnect, que generó alrededor de 360.000 UserOps (transacciones AA) en solo un mes al introducir su sistema AA y su solución sin gas.
Para las billeteras y aplicaciones que ya han acumulado usuarios y activos, sigue siendo un desafío migrar activos de manera segura y conveniente. Sin embargo, un esquema como EIP-7377 permite a EOA iniciar una transacción de migración única.
El contrato inteligente en sí no puede firmar mensajes porque no tiene una clave privada como EOA. Intentos como ERC1271 hacen que esto sea posible, pero la firma de mensajes no funciona hasta la primera transacción, lo que a su vez plantea un desafío para las billeteras implementadas con contrafactuales. ERC-6492, propuesto por Ambire, es el sucesor compatible con versiones anteriores de ERC-1271 y puede ser capaz de resolver el problema anterior.
El mayor costo de implementar, simular y ejecutar SCA en comparación con EOA estándar también es una barrera para la adopción. Sin embargo, se han realizado algunas pruebas, como separar la creación de cuentas de las acciones del usuario, eliminar la "sal" asociada a una cuenta, etc.
El equipo de ERC-4337 ha creado un repositorio de eth-infinitism que proporciona una implementación base para los desarrolladores. Sin embargo, a medida que los desarrolladores escalan a funciones más granulares y específicas para diferentes casos de uso, la integración y la decodificación se enfrentan a más desafíos. En este artículo, profundizaremos en los desafíos de ingeniería.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Resuelva los desafíos de ingeniería con cuentas modulares de contratos inteligentes
Los desafíos de ingeniería se pueden desarrollar en tres aspectos: fragmentación, seguridad y capacidad de actualización.
· Fragmentación: Las funciones ahora se pueden habilitar de varias maneras, ya sea a través de una SCA específica o a través de un sistema de complemento independiente. Cada plataforma y proveedor de servicios sigue sus propios estándares, lo que lleva a los desarrolladores a decidir qué plataformas y proveedores de servicios admitir. Esto puede dar lugar a una posible dependencia de la plataforma (proveedor) o a un trabajo redundante.
· Seguridad: Si bien desacoplar las cuentas y las funciones brinda el beneficio de la flexibilidad, también puede hacer que los problemas de seguridad sean más graves. Debido a que todas las características pueden revisarse juntas, la falta de una evaluación independiente puede aumentar el riesgo de vulnerabilidades de la cuenta.
· Capacidad de actualización: a medida que su cuenta crece, es importante mantener la capacidad de agregar, reemplazar o eliminar funciones, y cada actualización que vuelve a implementar las funciones existentes presenta 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 una transición fluida entre diferentes frontends.
Estos términos convergen en un concepto común: la construcción de una arquitectura de abstracción de cuentas modulares (AA modular).
La abstracción de cuentas modulares es una subdivisión del desarrollo más amplio de AA que prevé la modularización de las cuentas inteligentes para proporcionar servicios personalizados 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 en cualquier industria es un gran desafío. Hasta que todos acepten el mismo estándar, pueden surgir muchas soluciones diferentes en la fase inicial. Es alentador ver que aquellos que trabajan para refinar y promover la abstracción de cuentas, ya sea el SDK 4337, billeteras, equipos de infraestructura o diseñadores de capas de protocolo, están trabajando juntos para acelerar este proceso.
Estructura modular: cuentas maestras y módulos
Cómo la cuenta invoca el módulo para implementar la función
Delegar contrato de llamada y proxy
Llamadas externas y delegadas:
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
Acerca de las llamadas de delegados
Si bien una "llamada delegada" es similar a una "llamada", no se ejecuta en el contexto del contrato de destino, sino en el contexto del estado actual del contrato de llamada. Esto significa que cualquier cambio de estado realizado por el contrato de destino cambiará el almacenamiento del contrato de llamada.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Contratos de proxy y llamadas de delegado
**Para lograr una estructura componible y actualizable, es necesario introducir un concepto básico de "contrato de agencia". **
Contrato de proxy: un contrato normal almacena su lógica y estado, y no se puede actualizar después de la implementación. El contrato de proxy se implementa en otro contrato mediante una llamada delegada. Implemente la función por referencia para ejecutarla en el estado actual del contrato de proxy.
Caso de uso: Si bien el contrato de proxy sigue siendo el mismo, puede implementar una nueva implementación detrás del agente. Los contratos de proxy son actualizables y menos costosos de implementar y mantener en blockchains públicas.
Arquitectura segura! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Arquitectura segura
Qué es Safe: Safe es la infraestructura modular líder de cuentas inteligentes diseñada para proporcionar seguridad y flexibilidad probadas en batalla, y permite a los desarrolladores crear diversas aplicaciones y billeteras. Muchos equipos están creando aplicaciones sobre (o inspiradas en) Safe. Por ejemplo, Biconomy amplió Safe con 4337 nativo y multifirma 1/1 cuando lanzó su cuenta de contrato inteligente. Habiendo sido testigo del despliegue de más de 164.000 contratos y asegurado más de 30.700 millones de dólares en valor, Safe es sin duda un líder en su espacio.
La estructura de Safe incluye un contrato de cuenta segura, un contrato singleton y un contrato de módulo.
Contrato de apoderado: con estado
La cuenta segura es un contrato proxy porque la llamada delegada es un contrato singleton. Una cuenta de seguridad contiene variables en las que el propietario, el umbral y la dirección de implementación se establecen como agentes, y su estado se define en función de ellos.
单例合约(singleton contract):Integration Hub(无状态)
El contrato singleton sirve a las cuentas seguras y define diferentes integraciones de contratos de módulos, incluidos Plugin, Hook, Function Handler y Signature Validator.
Módulos: Lógica y funcionalidad personalizadas
Los contratos de módulos son poderosos. Los plugins, como tipos modulares, pueden definir diferentes funciones, como los flujos de pago, los mecanismos de recuperación y las claves de sesión, y pueden actuar como puente entre la Web2 y la Web3 mediante la obtención de datos fuera de la cadena. Otros módulos, como los ganchos y los controladores de funciones como guardias de seguridad, pueden responder a cualquier comando.
Los cambios que han cambiado desde la adopción de Safe:
Contratos actualizables: Cada vez que se introduce un nuevo complemento, se debe implementar un nuevo singleton. El usuario conserva la autonomía para actualizar Safe a la versión singleton deseada.
Módulos componibles y reutilizables: La naturaleza modular de los plugins permite a los desarrolladores desarrollar funciones de forma independiente. Son libres de elegir y combinar estos complementos de acuerdo con su caso de uso, lo que resulta en un enfoque altamente personalizable.
ERC-2535 Diamante 代理
**! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
Acerca de ERC2535, Agente de Diamantes:
ERC2535 modelo estandarizado Diamond, un sistema modular de contratos inteligentes que se puede actualizar/escalar después de la implementación prácticamente sin limitaciones de tamaño. Actualmente, muchos equipos, como los experimentos de Kernel y Soul Wallet de Zerodev, se han inspirado en la estructura Diamond.
¿Qué es la estructura del diamante?**
Contrato Diamante: Contrato de proxy principal (con estado) Diamond es un contrato de proxy que utiliza un método de invocación delegado para llamar a una función desde su implementación.
Módulo/Plugin/Faceta Contract: Lógica y Funcionalidad Personalizada (sin Estado) Un módulo o llamada Faceta es un contrato sin estado que puede desplegar su funcionalidad en uno o más Diamantes. Son contratos separados e independientes que pueden compartir funciones intrínsecas, bibliotecas y variables de estado.
Cambios con Diamante:
Contratos actualizables: Diamond proporciona una forma sistemática de aislar diferentes complementos y conectarlos entre sí, compartir datos entre ellos y también agregar/reemplazar/eliminar cualquier complemento directamente usando la función diamondCut. Con el tiempo, no habrá límite en el número de plugins que se pueden añadir a Diamond.
Plugins modulares y reutilizables: Los plugins desplegados pueden ser utilizados por cualquier número de Diamonds, lo que reduce drásticamente los costes de implementación.
Diferencia entre la Cuenta Inteligente Segura y el método Diamante:
Hay muchas similitudes entre las arquitecturas Safe y Diamond, las cuales se basan en sus contratos proxy principales y contratos lógicos de referencia para la capacidad de actualización y la modularidad.
La principal diferencia entre ambos es el manejo de los contratos lógicos. Específicamente:
· Flexibilidad: Con un nuevo complemento habilitado, Safe necesita volver a implementar su contrato singleton para implementar cambios en su proxy. Por el contrario, Diamond logra esto directamente a través de la función diamondCut en su contrato de representación. La diferencia de enfoque significa que Safe conserva un mayor grado de control, mientras que Diamond introduce una mayor flexibilidad y modularidad.
· Seguro: Actualmente utilizado en ambas estructuras, permite que el código externo manipule el almacenamiento del contrato principal. En la arquitectura segura, las llamadas delegadas apuntan a un único contrato lógico, mientras que Diamond usa llamadas delegadas en varios contratos-complementos de módulos. Como resultado, es posible que un complemento malicioso sobrescriba otro complemento, lo que introduce el riesgo de conflictos de almacenamiento y compromete la integridad del proxy.
· Costo: En el enfoque Diamante, la flexibilidad y la seguridad se unen. Esto aumenta el costo, y cada vez que se agrega un nuevo complemento, debe auditarse por completo. La clave es asegurarse de que estos complementos no interfieran con la funcionalidad de los demás, un propósito que es un desafío, especialmente para las pequeñas y medianas empresas que luchan por mantener altos estándares de seguridad.
El "Método de la Cuenta Inteligente Segura" y el "Método Diamante" son ejemplos de diferentes estructuras que involucran agentes y módulos. Equilibrar la flexibilidad y la seguridad es fundamental, y estos dos enfoques seguirán evolucionando y complementándose en el futuro.
Orden del módulo: validador, ejecutor y gancho
Analicemos esto más a fondo presentando ERC6900, un estándar inspirado en Diamond del equipo de Alchemy que está diseñado específicamente para ERC-4337. Resuelve los desafíos de la modularidad de las cuentas inteligentes al proporcionar una interfaz común y coordina el trabajo entre los desarrolladores de complementos y billeteras.
Cuando se trata del proceso de transacción de AA, hay tres procesos principales: validación, ejecución y vinculación. Como hemos comentado anteriormente, todos estos pasos se pueden administrar mediante el módulo de llamada a la cuenta de proxy. Si bien los diferentes proyectos pueden usar diferentes nombres, es importante comprender la lógica subyacente de la similitud.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
El nombre de la función en diferentes diseños
Validador: Garantiza la autenticidad y los permisos de la persona que llama a la cuenta.
Ejecución (UTOR): ejecute cualquier lógica personalizada que permita la cuenta.
Gancho: Actúa como un módulo que se ejecuta antes o después de otra función. Puede modificar el estado o deshacer toda la llamada.
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Es importante separar los módulos de acuerdo con diferentes lógicas. El enfoque estandarizado debe especificar cómo escribir funciones de validación, ejecución y vinculación para cuentas de contratos inteligentes. Ya sea segura o ERC6900, la estandarización ayuda a reducir la necesidad de esfuerzos de desarrollo únicos específicos para ciertas implementaciones o ecosistemas y evita la dependencia de un proveedor.
Descubrimiento y seguridad de módulos
Cómo encontrar y validar módulos de forma abierta: Una solución que se está desarrollando consiste en crear un área que permita a los usuarios descubrir módulos verificables, lo que se puede denominar "registro". El registro funciona como una "tienda de aplicaciones" y tiene como objetivo fomentar un mercado modular simplificado pero próspero.
Safe{Core} 协议
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
El protocolo Safe{Core} es un protocolo interoperable de código abierto para cuentas de contratos inteligentes diseñado para mejorar la accesibilidad para una amplia gama de proveedores y desarrolladores, al tiempo que mantiene una seguridad sólida a través de estándares y reglas bien definidos.
· Cuentas: En el protocolo Safe{Core}, el concepto de cuentas es flexible y no está vinculado a una implementación específica. Esto permite que se involucren diferentes proveedores de servicios de cuentas.
· Gerente: El gerente actúa como coordinador entre cuentas, registros y módulos. También se encarga de la seguridad como capa de licencias.
· Registro: El registro define los atributos de seguridad y hace cumplir los estándares de los módulos, como ERC6900 para crear un entorno abierto de "tienda de aplicaciones" para la visibilidad y la seguridad.
· Módulos: Los módulos manejan la funcionalidad y tienen una variedad de tipos iniciales, incluidos complementos, ganchos, validadores de firmas y controladores de funciones. Los desarrolladores pueden participar siempre que cumplan con los criterios establecidos.
Diamantes de imitación 设计
! [Una mirada en profundidad a la arquitectura y los desafíos de las cuentas modulares de contratos inteligentes] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
El proceso se desarrolla de la siguiente manera:
· Crear un esquema: Un esquema proporciona una estructura de datos predefinida. Las personas pueden adaptarlo para que se adapte a su caso de uso específico.
· Crear módulos basados en el esquema: el contrato inteligente registrado como módulo obtiene el código de bytes y selecciona el ID del esquema, y los datos se almacenan en el registro.
· Obtener la certificación del módulo: El probador/auditor puede proporcionar una prueba del módulo basada en la arquitectura. Estas certificaciones pueden incluir un identificador único (UID) y referencias a otras certificaciones utilizadas para el vínculo. Pueden propagarse a través de cadenas y verificar que la cadena de destino cumpla con ciertos umbrales.
· Implementar lógica compleja con un solucionador: El analizador (opcional) entra en juego. Se les puede llamar durante la creación del módulo, el establecimiento de la atestación y la revocación. Estos analizadores permiten a los desarrolladores integrar lógicas complejas y diversas mientras mantienen estructuras de prueba.
Acceso a consultas fácil de usar: la consulta proporciona una manera para que los usuarios accedan a la información de seguridad desde el front-end.
Si bien el modelo aún se encuentra en sus primeras etapas, tiene el potencial de establecer estándares de manera descentralizada y colaborativa. El registro permite a los desarrolladores registrar sus módulos, a los auditores verificar su seguridad, a las billeteras integrarlas y permite a los usuarios encontrar fácilmente los módulos y verificar su información de certificación. Varios usos futuros podrían ser:
· Certificador: Una entidad de confianza como Safe puede trabajar con Rhinestone como probador de módulos internos. Al mismo tiempo, también pueden adherirse certificadores independientes.
· Desarrollador de módulos: Con la formación de un mercado abierto, es posible que los desarrolladores de módulos moneticen su trabajo a través de un registro.
· Usuarios: Participar a través de una interfaz fácil de usar, como una billetera o dApp, permite a los usuarios verificar la información del módulo y delegar la confianza a diferentes probadores.
El concepto de "registro de módulos" abre vías para que los desarrolladores de plugins y módulos puedan monetizar. Podría allanar aún más el camino para un "mercado de módulos". Algunos aspectos pueden ser supervisados por el equipo de Safe, mientras que otros pueden manifestarse como un mercado descentralizado que invita a todos a contribuir y proporciona una pista de auditoría transparente. La incorporación de esto evita la dependencia de un proveedor y respalda la expansión de la EVM al agregar una experiencia de usuario mejorada que atrae a un público más amplio.
Si bien estos métodos garantizan la seguridad de los módulos individuales, las cuentas de contratos inteligentes no son infalibles cuando se trata de una seguridad más amplia. Puede ser un desafío combinarlo con módulos de cumplimiento y demostrar que no tienen conflictos de almacenamiento, lo que destaca la importancia de las billeteras o la infraestructura AA para abordar estos problemas.
Resumen
Al aprovechar una pila modular de cuentas de contratos inteligentes, los proveedores de billeteras y dApps pueden liberarse de las complejidades del mantenimiento técnico. Al mismo tiempo, los desarrolladores de módulos externos tienen la oportunidad de brindar servicios profesionales personalizados. Sin embargo, los desafíos que deben abordarse incluyen lograr un equilibrio entre flexibilidad y seguridad, impulsar estándares modulares e implementar interfaces estandarizadas que permitan a los usuarios actualizar y modificar fácilmente sus cuentas inteligentes.
Además, las cuentas modulares de contratos inteligentes (SCA) son solo una pequeña parte del rompecabezas de la adopción. Para aprovechar todo el potencial de SCA, se necesitan soluciones de capa 2 para proporcionar soporte adicional a la capa de protocolo, como una sólida infraestructura de paquetes y grupos de memoria punto a punto, un mecanismo de firma SCA más rentable y viable, mecanismos de sincronización y gestión de SCA entre cadenas, y el desarrollo de interfaces fáciles de usar.
En el futuro, habrá una mayor adopción de SCA, pero también planteará algunas preguntas interesantes: ¿cómo entrarán en el espacio los mecanismos tradicionales de valor extraíble (MEV) de los mineros para construir empaquetadores y capturar valor una vez que el flujo de órdenes de SCA sea lo suficientemente rentable, y cómo servirá la abstracción de cuentas (AA) como capa base para las transacciones "basadas en la intención" cuando la infraestructura madure?