Informe de abstracción de cuenta de Cypher Capital: Pros, Contras, Infraestructura Existente y Perspectivas Futuras

Intermedio12/17/2023, 1:57:20 PM
Este artículo analiza los desarrollos técnicos y perspectivas de la abstracción de cuentas en Web3. Profundiza en los principios de implementación de las cuentas AA, contrastándolas con la Computación Multi-Parte (MPC) y las Cuentas de Contrato (CA) para resaltar la singularidad de las cuentas AA. Además, el artículo discute el potencial de combinar cuentas AA con las intenciones del usuario y chips seguros en dispositivos finales para mejorar tanto la seguridad como la conveniencia.

¿Qué es la Abstracción de Cuenta (AA)

Diferencias entre AA, EOA y CA

La esencia de la abstracción de cuentas es una Cuenta de Contrato. En Ethereum, hay dos tipos de cuentas:

  • Dirección del Contrato
  • Cuentas de Propiedad Externa

Un ejemplo simple es que la Dirección del Contrato es la dirección donde se implementa el contrato. Cualquier contrato en Ethereum que pueda ser llamado tiene una dirección de contrato, como la dirección del contrato de USDT. Una cuenta EOA es la conocida cuenta ETH, como la cuenta mostrada en la billetera Metamask.

0xdac17f958d2ee523a2206206994597c13d831ec7es la dirección del contrato para tokens USDT. Las direcciones de contrato no pueden crearse directamente desde el exterior; son creadas y gestionadas por EOAs. El EOA que creó la dirección del contrato USDT es 0x36928500Bc1dCd7af6a2B4008875CC336b927D57.

Por lo tanto, entendemos que una cuenta AA es un tipo especial de Cuenta de Contrato (CA) en Ethereum. Las cuentas AA aún deben ser creadas por EOAs y son controladas por EOAs externos porque la única forma de interactuar con la cadena de Ethereum es a través de EOAs. En consecuencia, AA sirve como una implementación estandarizada y modular de billeteras de CA, que continúa evolucionando con el tiempo.

Historia de Desarrollo de Cuentas AA

Acabamos de explicar la relación entre AA y CA. Antes de la propuesta del estándar ERC-4337, ya existía un número significativo de carteras CA disponibles. A continuación, proporcionamos información sobre tres carteras CA populares y cómo operan:

Cartera de Parity

Durante las primeras etapas del desarrollo de Ethereum, surgieron varias carteras de contratos. La más conocida es la cartera Parity, desarrollada por el equipo de Gavin Wood, los fundadores de PolkaDot. Parity está implementada en Rust y sirve como alternativa al nodo Geth, que está desarrollado en Golang. Parity Wallet es una cartera de contrato multi-firma que permite a múltiples cuentas externamente propiedad (EOAs) controlar y gestionar una cuenta de contrato (CA). Sin embargo, en 2017, un hacker explotó un error en la cartera Parity y robó más de 150,000 ETH. Este incidente causó una pérdida de confianza en las carteras de contratos.

Como resultado, las billeteras AA requieren una práctica extensa y estandarización para evitar que ocurran incidentes similares.

Cartera de Gnosis

La billetera multi-firma de Gnosis es actualmente la billetera multi-firma principal y es utilizada por la mayoría de las instituciones y desarrolladores. Un número significativo de equipos almacenan sus fondos de desarrollo en la billetera multi-firma de Gnosis para evitar que los miembros del equipo actúen maliciosamente. Equipos destacados que utilizan Gnosis Safe incluyenYearn,Aave, yBalancer. La seguridad de la Puerta de Gnosis es extremadamente alta, pero su uso es relativamente caro, lo cual es un problema común con las carteras de CA.

UniPass

Unipass Wallet combina la tecnología MPC y los monederos de contrato de CA, lo que permite a los usuarios utilizar el inicio de sesión social sin la custodia propia de un monedero EOA. Cabe destacar que tanto el monedero Parity como el Gnosis Safe aún requieren que los usuarios custodien sus claves privadas. El flujo general de Unipass es:

  • Inicio de sesión social al crear una billetera CA en cadena
  • Interacción con la cadena
    Los usuarios inician transacciones
    MPC verifica la validez de las transacciones de usuario
    Una billetera EOA controlada por MPC inicia transacciones en la cuenta del usuario de CA
    La cuenta de CA ejecuta la transacción y paga gas al pagador de UniPass

Es importante tener en cuenta que la solución AA original de Unipass no se adhiere completamente al estándar ERC-4337. El control de la billetera todavía se delega a un EOA que está controlado por el MPC de Unipass.

Implementación de AA (ERC-4337)

La esencia de AA es una cuenta de CA estandarizada y modularizada. ERC-4337 se manifiesta principalmente en las siguientes innovaciones:

  • bundler : Las cuentas tradicionales de CA todavía requieren que los usuarios inicien transacciones a través de una cuenta EOA externa, lo que obliga a los usuarios a almacenar ETH en sus cuentas EOA para las tarifas de gas. En ERC-4337, los usuarios empaquetan sus transacciones como UserOperations y las envían al bundler, quien inicia la transacción, eliminando así la necesidad de que los usuarios reserven gas por adelantado.
  • Firmas agregadas BLS: El agrupador empaqueta múltiples UserOperations en una sola transacción y genera una firma agregada BLS, la cual luego se valida en cadena a través de una única verificación de firma BLS.
  • pagador : Los usuarios pueden designar un pagador para pagar el gas.

El diagrama anterior describe aproximadamente el proceso de transacción estándar en ERC-4337:

  • El usuario empaqueta UserOp y lo envía al agrupador
  • Bundler verifica la validez de UserOp y lo empaqueta en una transacción
  • Bundler envía la transacción a la red principal de ETH
    Punto de entrada: Punto de entrada del contrato para la transacción enviada por el agrupador
    handleOps: Contrato específicamente utilizado para ejecutar transacciones de usuario
    pagador : Contrato utilizado para pagar el gas del usuario

Podemos resumir las principales diferencias entre AA y CA tradicional de la siguiente manera:

  • Los usuarios no envían transacciones directamente, sino que dejan el empaquetado al agrupador
  • La verificación de la firma se traslada de la capa de consenso a la capa de contrato, donde el contrato valida la firma
  • Introducción de un pagador modularizado, que permite a los usuarios elegir libremente quién paga por el gas

Cómo AA Difiere De MPC

Antes de comprender completamente AA, muchas personas suelen confundir los conceptos de AA y MPC porque ambos admiten características como la recuperación social y los complementos sin navegador. Las diferencias esenciales entre AA y MPC son las siguientes:

  • AA sigue siendo descentralizado y existe en la cadena, mientras que MPC es centralizado y a menudo alojado por una o más instituciones.
  • Las transacciones AA son ejecutadas por la dirección del contrato AA, mientras que MPC es realizada por la EOA alojada por la institución, lo que hace que MPC siga siendo una cuenta EOA gestionada.
  • La ejecución de una transacción AA implica interacciones con múltiples contratos relacionados con AA en cadena, mientras que MPC interactúa directamente con el EOA. MPC no incurre en tarifas de gas adicionales.

A continuación, vamos a presentar MPC y sus características únicas.

  • La tecnología MPC es más madura, y las billeteras calientes de los intercambios centralizados han implementado MPC para evitar fallos de un solo punto, mejorando significativamente la seguridad de los intercambios centralizados.
  • MPC consta de múltiples nodos, con cada nodo poseyendo solo un fragmento de la clave privada. Las transacciones solo pueden ser firmadas cuando múltiples nodos de MPC alcanzan consenso. Como resultado, el robo de la clave privada de un solo nodo no conduce a la pérdida de fondos.
  • Actualmente, hay muchas soluciones de MPC de código abierto. Para principios específicos, puedes consultarhttps://tor.us/, una solución de nodo MPC de código abierto desarrollada por Web3Auth.

Las soluciones de MPC son ampliamente utilizadas en los logins sociales actuales, y muchos proyectos han lanzado billeteras MPC para proporcionar una experiencia de billetera sin cadena, eliminando la necesidad de que los usuarios instalen billeteras de complementos o gestionen claves privadas. En la industria, estos tipos de billeteras administradas se denominan colectivamente Wallet-as-a-Service (WaaS). Los proyectos maduros incluyen:

  • Autenticación Web3
  • Red de Partículas
  • Enlace mágico
  • Coinbase Base

Ante un número creciente de servicios de WaaS, es previsible que en el futuro haya más productos que ofrezcan WaaS. Sin embargo, los intercambios centralizados tienen un volumen de usuarios absoluto y una amplia experiencia empresarial en este campo, por lo que es posible que todos los intercambios centralizados proporcionen servicios relacionados en el futuro.

Ventajas de AA

Recuperación Social

La principal desventaja de las Cuentas Externamente Propiedad (EOA) tradicionales es que los usuarios son responsables de almacenar sus propias claves privadas. Esta auto-custodia presenta los siguientes problemas:

  • Alto costo cognitivo. La mayoría de los usuarios no pueden entender las claves pública y privada.
  • Si los usuarios pierden su clave privada, no hay forma de recuperar la cuenta.

AA (Account Abstraction) está diseñado para permitir a los usuarios establecer cuentas de recuperación social. Pueden usar una o más EOA externas para recuperar el control sobre su AA. El flujo común para la recuperación social es el siguiente:

  • El usuario pierde el acceso al EOA actual que controla el AA, o este se ve comprometido.
  • Dos EOA adicionales están vinculados a la AA del usuario: \
    EOA de amigo \
    EOA custodiado institucionalmente
  • Estos dos EOAs inician una apelación y, después de completar una prueba de multisig 2/3, cambian el EOA vinculado del AA al nuevo EOA del usuario.

A través de este proceso de apelación, incluso si el usuario pierde el control del EOA que rige el AA, aún puede cambiar a un nuevo EOA. A diferencia del inicio de sesión social de MPC (Cómputo de Partes Múltiples), esta recuperación social es completamente descentralizada y no tiene un único punto de falla.

Delegación de Gas

La delegación de gas es fundamental para la adopción masiva de la cadena de bloques. Para los nuevos usuarios que ingresan a Web3, el mayor punto de dolor es pre-financiar las tarifas de gas. Al utilizar el Paymaster de AA para delegar gas, los nuevos usuarios pueden recibir subsidios, lo que reduce la barrera de entrada a las aplicaciones Web3.

Interoperabilidad sin fricción entre cadenas

Otro problema central que afecta la adopción masiva de Web3 es la compatibilidad entre cadenas. Paymaster, a través de la integración de protocolos entre cadenas como Layer0/Warmhole, permite a los usuarios depositar en Cadena A (por ejemplo, Ethereum) y utilizar aplicaciones en Cadena B (por ejemplo, Matic o BSC) de forma transparente, haciendo que las fronteras entre cadenas desaparezcan y ayudando a que las nuevas Dapps ganen usuarios de otras cadenas.

Desventajas del AA actual

Si bien hemos discutido las ventajas de AA, el estándar ERC-4337 todavía está iterando rápidamente para abordar sus desventajas actuales:

Creación separada para cada cadena/capa2

A diferencia de EOA, una vez que se crea un EOA, se puede utilizar en cualquier cadena compatible con EVM, ya que el mismo par de claves público-privadas puede usarse para interactuar en diferentes cadenas. Sin embargo, debido a la naturaleza de AA como Cuenta de Contrato (CA), un nuevo contrato de AA debe ser desplegado por separado en cada cadena o Capa2. El alto costo de despliegue de contratos de AA podría desalentar a los usuarios de adoptar AAs.

Además, si los usuarios implementan de manera incorrecta, como usar diferentes Fábricas para implementar cuentas de contrato AA, pueden terminar con direcciones AA diferentes en diferentes cadenas, lo que puede causar confusión significativa y dificultades en el uso y la comprensión. Si bien las Fábricas de Billetera AA actuales han logrado generar la misma dirección AA en diferentes cadenas, los usuarios aún deben tener cuidado al verificar los protocolos que están utilizando para garantizar que sus direcciones AA sigan siendo consistentes en varias cadenas, evitando así cualquier problema o confusión futuros.

Altos costos de implementación

Como se mencionó, las cuentas AA requieren que los usuarios implementen los contratos AA generados por Wallet Factory en diferentes cadenas y Layer2 por separado. Incluso con las actuales sidechains, cadenas compatibles con EVM y tarifas de gas más bajas en Layer2, sigue siendo un gasto significativo. Con las tarifas de gas actuales y el precio del ETH en $1800, implementar una cuenta AA en la red principal de ETH costaría aproximadamente $20-$40, mientras que en cadenas compatibles con EVM o Layer2, oscilaría entre $0.5 y $5. Para la mayoría de los usuarios, es difícil aceptar el costo de implementación antes de siquiera usar la Dapp. Suponiendo que este costo esté subvencionado por un Bundler o Paymaster, el costo de la subvención sigue siendo demasiado alto y requiere un fuerte incentivo.

Costo de gas significativamente más alto que EOAs

Dependiendo de la implementación de AA y el número de transacciones agrupadas en una sola transacción de Bundler (cuantas más transacciones, menor será el costo de gas por UserOP), el consumo de gas de las transacciones estándar actuales de ERC-4337 puede ser varias veces mayor que el de las cuentas regulares de EOA. Esto se debe a que una transacción iniciada por una cuenta AA a menudo requiere llamar a 3 o más contratos e implica cálculos complejos como la verificación de firma BLS en cadena. El estándar actual de ERC-4337 también se está optimizando para esto, con el siguiente plan de trabajo:

  • Simplificando el número de contratos llamados en transacciones de cuenta AA
  • Presentación de contratos precompilados de curva elíptica en ETH para reducir el consumo de gas para la verificación de firmas en cadena

Estimación de la tarifa de gas bajo el estándar ERC-4337

Acabamos de mencionar el costo relativamente alto de usar el estándar ERC-4337. ¿Cuáles son los costos específicos? Primero, introduzcamos un concepto, que es la fórmula de cálculo para las tarifas de gas:

tarifa = gas × precio

Entonces, ¿cuáles son los costos de implementación y uso de ERC-4337? El equipo de StackUp ha proporcionado estimaciones precisas en su blog.

https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337

Tabla 1. Gas para transacciones ERC-4337

La tabla anterior muestra:

  • El costo de crear una cuenta AA es aproximadamente 20 veces el costo de una transacción EOA.
  • Las transferencias de tokens nativos en cuentas AA cuestan alrededor de 4 veces más que en EOA.
  • Para transferencias ERC20, los AAs cuestan solo 1.5 veces más que los EOAs.

Tabla 2. Estimaciones de tarifas de gas para transacciones ERC-4337

Esta tabla proporciona estimaciones de costos para varias operaciones en la cuenta AA ERC-4337 utilizando los precios actuales del gas. Podemos observar lo siguiente:

  • En la red principal de ETH, el costo de crear una cuenta AA es muy alto, aproximadamente $20-30.
  • Bajo Rollup, debido a la tecnología de compresión de datos, el costo de crear una cuenta de AA es menor, similar al costo de las transferencias.
  • En otras cadenas compatibles con EVM, el costo de crear una cuenta AA es relativamente más bajo debido a la tarifa base de gas más baja.

En resumen, debido al alto costo de crear cuentas AA ERC-4337 en la red principal, es probable que la adopción general ocurra primero en Layer2 y cadenas compatibles con EVM.

Compatibilidad Dapp y Compatibilidad del Navegador Blockchain

Otro obstáculo para el desarrollo de AA es la compatibilidad de la infraestructura con los contratos de AA. La mayoría de las Dapps fuera de la cadena AA nativa solo admiten cuentas EOA. El soporte para AA requiere que las Dapps utilicen el SDK de AA para transacciones y modifiquen los parámetros de consulta para la información del usuario.

Además, los navegadores de blockchain como Etherscan están diseñados principalmente para EOAs. Para mejorar la comodidad de consultar las cuentas de AA, estos navegadores pueden requerir una serie de optimizaciones de UI y UX.

Abstracción de Cuenta Nativa (AA Nativa)

Pros y contras de AA nativo

Excepto por Ethereum, la mayoría de las nuevas blockchains públicas ya han implementado cuentas AA nativas.

  • Ventajas
    Soporte de capa de consenso

Los AAs nativos se implementan en la capa de consenso de la cadena, lo que significa que no requieren desarrolladores de la comunidad para su implementación. Estos suelen ser contratos internos o del sistema desarrollados y mantenidos por los desarrolladores de la cadena de bloques.

Costos de implementación más bajos y tarifas de gas adicionales

Los contratos internos a menudo tienen permisos y prioridades más altos, y sus cálculos de gas son diferentes de los contratos externos. Por lo tanto, los AA nativos tienen costos de implementación más bajos y generalmente no agregan un gasto significativo de gas.

  • Cons
    Menor flexibilidad

La actualización de los AAs nativos requiere que los desarrolladores de la cadena pública sean responsables, a menudo necesitando bifurcaciones suaves o duras. Esto los hace menos flexibles que el ERC-4337 modular, lo que limita el ritmo de iteración y lanzamiento de nuevas funciones.

  • Aprenda de la experiencia de ERC-4337 y aumente la escalabilidad

Las cadenas con AAs nativos están estudiando activamente la extensibilidad y modularidad de ERC-4337, lo que permite construir más funciones sobre los AAs nativos.

Cerca

Near implementa AAs nativos en la capa de consenso con cuentas almacenadas directamente en la cadena de bloques. Admite múltiples claves de acceso y recuperación social (correo electrónico, número de teléfono). La siguiente imagen ilustra las diferencias entre una cuenta de ETH y una de Near.

Aptos / Sui

Debido al modelo de propiedad de recursos en Aptos y Sui, tanto Aptos como Sui han implementado AA nativo en la capa de consenso. Tomando Aptos como ejemplo, una cuenta de Aptos es un conjunto de recursos en la cadena de bloques, por lo que al crear una cuenta de Aptos, es necesario prepagar Aptos para completar la inicialización de la cuenta. Las cuentas de Aptos/Sui también admiten el cambio de la clave de autenticación, pero la dirección de la cuenta sigue siendo la misma, entre otras características de AA.

ZKsync

A diferencia de Near/Aptos/Sui/Starknet, ZKsync admite tanto EOA como AA en la capa de consenso. Por lo tanto, ZKsync puede iniciar transacciones utilizando tanto EOA como AA, lo que le permite ser utilizado con billeteras populares como Metamask y Argent. El diseño de AA de ZKSync se basa en ERC-4337, lo que lo hace compatible con billeteras y Dapps que admiten EIP-4337. Actualmente, el costo de gas adicional para transacciones AA en ZKsync es aproximadamente execution_gas + 20000, lo que equivale a alrededor de 0.01USD en el momento de la escritura. Este es un costo pequeño en comparación con AA ERC-4337 no nativas.

Starknet

Starknet admite nativamente AA y no admite transacciones iniciadas por EOA. Las cuentas AA en Starknet están diseñadas en base a ERC-4337. Actualmente, los contratos AA en Starknet son proporcionados por OpenZeppelin y desarrollados usando Cairo.

ICP

Las cuentas AA nativas en ICP se llaman Identidad en Internet (II para abreviar). La implementación de II es diferente de ERC-4337. II utiliza WebAuthn, comúnmente utilizado en marcos de Web2, lo que permite a los usuarios controlar sus cuentas utilizando los chips de seguridad incorporados en sus teléfonos inteligentes. Los usuarios pueden agregar y eliminar dispositivos libremente. En esencia, II convierte los dispositivos smartphone del usuario en monederos de hardware.

Infraestructura AA existente

Bundler

Bundler reemplaza el Mempool de nodo anterior en el ecosistema AA. UserOps ya no se envían a los Validadores, sino que se envían a los Bundlers para empaquetarlos y procesarlos en cadena. Los bundlers principales son los siguientes:

  • Agrupador de Stackup:

El agrupador de Stackup está implementado en Go lang y tiene como objetivo integrarse perfectamente con Go Ethereum (geth). Es el primer agrupador de estándares de producción en esta lista que cumple completamente con ERC-4337. Stackup se mantiene activamente y cuenta con una documentación completa, lo que lo convierte en el agrupador más popular actualmente. Stackup ofrece servicios de agrupación, eliminando la necesidad de que los equipos configuren su propio servicio de agrupación.

  • Infinitism Bundler

El agrupador de Infinitism está desarrollado en TypeScript y fue desarrollado por el autor original de ERC-4337. Infinitism también desarrolla contratos ERC-4337, lo que hace que su agrupador sea altamente compatible con ERC-4337. Sin embargo, se necesita una verificación adicional para el rendimiento y la estabilidad ya que está desarrollado en TypeScript.

  • Silius(AA-bundler) está siendo desarrollado por Vid Kersic, un miembro clave del protocolo Ethereum, utilizando Rust. Esto contribuirá a la integración de herramientas AA en el ecosistema Rust.
  • Skandha

Skandha es un empaquetador basado en TypeScript desarrollado por Etherspot. Etherspot está activo en la implementación de la memoria compartida del empaquetador. Skandha pasó todas las pruebas en abril de 2023.

  • Voltaire

Voltaire es un protocolo de agrupación desarrollado por el equipo de Candide para admitir su propia billetera de Candide. Voltaire es una implementación basada en Python de ERC-4337. Actualmente, Voltaire proporciona un buen soporte para la propia billetera de código abierto de Candide.

  • Rundler

Rundler es un protocolo de Bundler desarrollado por Alchemy, el proveedor de servicios de nodo más grande para Ethereum. Actualmente, Rundler no es de código abierto, pero debido a la gran base de usuarios de Alchemy, puede recibir un importante soporte de tráfico.

Puntos de dolor del agrupador

Bundler está actualmente en una fase de desarrollo e iteración rápida.

  • Comunicación entre bundlers

El punto doloroso actual que el bundler necesita abordar es la consistencia y los problemas de comunicación del mempool del bundler. Suponiendo que hay múltiples protocolos de bundler en el mercado y hay una falta de comunicación entre ellos, puede llevar a un problema grave de ataques DDoS al bundler. Si un usuario envía simultáneamente transacciones a múltiples bundlers sin comunicación entre ellos, estos bundlers empaquetarán y enviarán simultáneamente UserOps al validador. Sin embargo, solo se ejecutará el UserOp del primer bundler, y las transacciones de los bundlers restantes serán rechazadas debido al mismo nonce. En este caso, si el paymaster del usuario tiene un saldo insuficiente, los bundlers pagarán gas inválido por estos UserOps. Por lo tanto, actualmente, la comunicación entre los bundlers es un problema que debe abordarse para evitar ataques de spam de UserOp a los bundlers.

  • Descentralización del agrupador

Los agrupadores actuales son altamente centralizados. Si los agrupadores ponen en lista negra a ciertos usuarios, esto resultaría en que sus transacciones no pudieran ejecutarse. Esto va en contra de la descentralización y la naturaleza sin permisos de la cadena de bloques.

Pagador

Paymaster es una parte importante de AA, ya que puede subsidiar las tarifas de gas de los usuarios y reducir significativamente la barrera de entrada para Web3. Aquí hay algunas implementaciones populares de paymaster:

  • pago de acumulaciones
    El pagador de Stackups es parte del ecosistema de Stackups AA. Stackups ha implementado un panel de control de pagador donde las DApps u otros proveedores de servicios pueden configurar sus propias cuentas de subsidio enhttps://app.stackup.sh/sign-inpatrocinar las transacciones de los usuarios.

  • Tablero de Biconomy

El panel de Biconomy permite a organizaciones y desarrolladores utilizar componentes AA en sus proyectos. Los propietarios de proyectos pueden configurar sus proyectos para pagar las tarifas de gas para los usuarios a través de maestros de pago y agregar condiciones de patrocinio de gas. Al registrar su maestro de pagos para cualquier cadena compatible, las DApps pueden simplificar en gran medida la experiencia Web3 para los usuarios.

Billeteras
  • Ambire
    Ambire es una billetera web basada en AA que es autogestionada y es compatible con billeteras de plugins, billeteras de hardware y accesos sociales. Ambire también emite tokens de billetera para la gobernanza de la billetera Ambire. Actualmente, Ambire es compatible con las cadenas compatibles con EVM y Layer2 más populares.
  • Argent
    Argent es actualmente la billetera más popular en el ecosistema Layer2 y ya soporta proyectos Layer2 principales como Starknet y ZKsync.
  • Aguacate
    Avocado es una billetera web que permite a los usuarios pagar todas las tarifas de gas utilizando USDC y proporciona una experiencia de usuario fluida en diferentes cadenas.
  • Seguro
    Safe es la cartera de CA multisignatura mencionada anteriormente desarrollada por Gnosis. Debido a su alta seguridad y costos de uso, es utilizada principalmente por instituciones y equipos para la gestión de fondos.
  • Secuencia
    Sequence soporta inicio de sesión social y proporciona una experiencia de billetera sin complementos.

La importancia de AA para la adopción masiva de Web3

AA logra centralización, usabilidad y seguridad simultáneamente.

Las cuentas EOA tradicionales a menudo luchan por lograr simultáneamente descentralización, usabilidad y seguridad.

  • Las carteras EOA auto custodiadas como Metamask satisfacen la descentralización pero requieren que los usuarios gestionen sus claves privadas, lo que supone una barrera de entrada muy alta para los nuevos usuarios. Además, si el dispositivo es comprometido, existe un riesgo de robo de claves privadas.
  • Las cuentas de custodia de EOA de MPC eliminan la necesidad de que los usuarios custodien sus claves privadas, pero el MPC en sí todavía está controlado por una institución. Si la institución actúa maliciosamente o es pirateada, introduce un único punto de falla, lo que va en contra de la lógica de descentralización de la cadena de bloques.
  • Por otro lado, las carteras AA pueden abordar estos problemas. Durante la incorporación del usuario, los agrupadores pueden crear cuentas para los usuarios y gestionar las claves privadas de EOA de AA. A medida que los usuarios se familiarizan con Web3 o cuando sus activos en cadena alcanzan un cierto umbral, el control de la cuenta EOA de AA puede descentralizarse a través de contratos inteligentes, como el uso de carteras de hardware.

La delegación de gas de Paymaster transfiere la carga de costos para los usuarios

En el marco EOA tradicional, los usuarios a menudo necesitan adquirir tokens de blockchain como ETH a través de monedas fiduciarias para usar aplicaciones Web3. Esto suele implicar el uso de exchanges centralizados (CEX) para depositar moneda fiduciaria, intercambiarla por el token requerido y finalmente transferirla a una cuenta EOA recién creada. Este proceso requiere una comprensión significativa de Web3 y es engorroso en muchas regiones. Al introducir pagadores en AA, los costos iniciales de incorporación para los usuarios pueden ser delegados a los propietarios de proyectos de DApps. La transferencia de tarifas de gas tiene implicaciones significativas para la adopción masiva de Web3.

Seguridad mejorada

  • Auditorías de seguridad para el pagador

Actualmente, ERC-4337 está en sus primeras etapas, y se están desarrollando numerosas herramientas basadas en ella. En el lado del pagador, la UserOp del usuario puede ser auditada para evitar que ocurra un rug, como aprobaciones excesivas o transferencias de fondos no autorizadas. La auditoría de seguridad del pagador puede llevarse a cabo utilizando métodos bien establecidos en el sector financiero web2 para revisar transacciones problemáticas y garantizar la seguridad de los fondos del usuario.

  • Aislamiento de cuenta

Otra innovación que se está desarrollando es el aislamiento de seguridad de las cuentas, como separar la cuenta de fondos de la cuenta de juegos, etc. Cuando los usuarios utilizan funciones DeFi familiares y de transferencia, se utiliza la cuenta de fondos con una auditoría de seguridad más estricta. Cuando los usuarios prueban GameFi o DeFi no familiar, se utiliza la cuenta de juegos. De esta manera, sin aumentar las claves privadas que los usuarios necesitan gestionar, el diseño de aislamiento de seguridad de las cuentas garantiza la seguridad de los fondos de los usuarios a nivel subyacente.

Perspectivas y oportunidades para AA

Experiencia de seguridad mejorada con chips seguros nativos para móviles/ordenadores y monederos hardware

Actualmente, muchos dispositivos como teléfonos inteligentes y computadoras portátiles tienen chips seguros incorporados, como el Chip de Seguridad Apple T2 utilizado en Mac y iPhone. Por lo tanto, fundamentalmente, cada dispositivo con un chip Tee es una billetera de hardware confiable. Sin embargo, estos chips seguros actualmente no admiten algoritmos de firma de blockchain comunes como ECDSA.

  • La seguridad actual de las claves privadas de EOA
    Plugins/billeteras móviles

La seguridad actual de las claves privadas de EOA en complementos/monederos móviles se almacena directamente en texto plano en el dispositivo. Si el dispositivo se ve comprometido, los activos del usuario pueden perderse rápidamente. Por lo tanto, los monederos de extensión del navegador como Metamask tienen una alta usabilidad pero una baja seguridad.

Monederos de hardware

Los monederos de hardware garantizan que las claves privadas nunca salgan del dispositivo y no puedan ser accedidas directamente por partes externas. Sin embargo, la mayoría de los usuarios no pueden llevar sus monederos de hardware consigo en todo momento, lo que resulta en una alta seguridad pero una baja usabilidad.

  • Presentando AA, utilizando un chip seguro para la seguridad del dispositivo

Al utilizar la billetera AA y el innovador método de verificación en cadena, las transacciones pueden ser firmadas directamente por el chip seguro del dispositivo, asegurando que la clave privada del usuario nunca abandone el dispositivo. Esto proporciona una mayor seguridad en comparación con las cuentas tradicionales EOA. Actualmente, la Identidad en Internet del Computer y un proyecto llamado Porton Wallet en el ETHBogota Hackathon han implementado una solución que utiliza la firma del chip seguro del dispositivo y la clave de sesión, permitiendo a los usuarios aprovechar plenamente la seguridad de sus dispositivos, como teléfonos inteligentes o computadoras, equivalente a una billetera de hardware.

Gracias al diseño altamente modular de ERC-4337, a través de su expansión e iteración, las cuentas AA lograrán una seguridad significativamente mejorada.

Experiencia sin cadenas para usuarios de intercambio cruzado + AA

Actualmente, otro obstáculo para la adopción masiva de Web3 es la fragmentación de los ecosistemas blockchain en diferentes cadenas.

  • Experiencia de uso de DApp a través de cadenas actualmente

Como ejemplo simple, consideremos a un usuario en Ethereum (ETH) que desea experimentar una aplicación en la Binance Smart Chain (BSC). ¿Qué debería hacer este usuario? Primero, el usuario necesita intercambiar sus ETH por los correspondientes USDT/USDC y luego utilizar un puente de cadena cruzada para transferir estos tokens de ETH a BSC. Después de eso, el usuario debe comprar algo de BNB en un exchange centralizado (CEX) y transferirlo a BSC. Solo entonces el usuario podrá comenzar a experimentar varias aplicaciones DeFi en BSC. Todo este proceso es lento, tiene mala seguridad y conlleva una empinada curva de aprendizaje, especialmente para nuevos usuarios que podrían no estar familiarizados con los puentes de cadena cruzada.

  • Experiencia después de introducir AA + paymaster intercadenas

A través de los protocolos de intercambio cruzado comúnmente utilizados en la actualidad, como Layer0 + AA, el proceso de uso de DApp en diferentes cadenas puede simplificarse en gran medida. El pagador puede integrar completamente los protocolos de intercambio cruzado para lograr el "cargue una vez, pague en todas partes". Por ejemplo, si un usuario recarga USDC en el pagador de ETH, siempre y cuando la cuenta AA del usuario en diferentes cadenas sea la misma y esté vinculada al mismo pagador, el pagador puede encargarse de la contabilidad en nombre del usuario. El usuario no necesita transferir manualmente activos a ninguna cadena compatible con EVM/Layer2 con la misma dirección de cuenta.

Ubicación de anuncios, Subvenciona Gas para la Promoción de Dapp

La mayor ventaja de introducir el paymaster es que establece programáticamente condiciones para subsidiar a los usuarios de Dapp.

  • Subsidios sin AA y pagador

En el pasado, ha habido casos en los que los proyectos del ecosistema Web3 subvencionaron el gas para atraer a los clientes. Sin embargo, subsidiar las cuentas EOA sin establecer condiciones programáticamente a menudo condujo al mal uso de los fondos de subvención por parte de bots y estafadores, como transferir directamente los fondos de subvención, sin atraer a clientes genuinos.

  • Subsidios con pagador

Actualmente, los paneles de control de paymaster generalmente incluyen la funcionalidad de subsidiar las tarifas de gas para las Dapps. Los desarrolladores de proyectos pueden establecer fácilmente las condiciones de las subvenciones en el panel de control, de modo que solo las transacciones que cumplan con condiciones específicas sean elegibles para la subvención. Al controlar las condiciones de transacción en los subsidios a través de paymaster, las Dapps pueden atraer a más usuarios genuinos mientras mantienen los costos bajo control.

  • Debido al diseño modular de ERC-4337, los futuros pagadores pueden integrar más servicios, como proveedores de servicios de publicidad, abriendo posibilidades más amplias para la adopción masiva de aplicaciones Web3.

Crecimiento explosivo en Mobile DApps

Bajo EOA, debido a la dominancia de Metamask, las Dapps actuales se acceden principalmente a través de interfaces web, lo que resulta en una mayor cuota de mercado para las billeteras de complementos web. Sin embargo, la adopción masiva de web3 depende de la participación de los usuarios móviles, lo que hace que el desarrollo y la adaptación de AA sean más nativos para dispositivos móviles.

Juegos totalmente en cadena

Con la creciente popularidad de Dark Forest, la tendencia de los juegos completamente en cadena está surgiendo silenciosamente. Sin embargo, la experiencia del usuario al utilizar EOA (Cuentas Poseídas Externamente) en juegos es muy pobre. Imagina tener que usar una billetera para autorizar o firmar transacciones cada vez que realizas alguna acción en un juego. Esta interrupción constante impide que los jugadores se centren completamente en el juego en sí. Para abordar este problema, se han desarrollado Cuentas Arcade, que son versiones especializadas de AA regulares, específicamente para juegos completamente en cadena. Estas cuentas autorizan operaciones de juego específicas, lo que permite a los jugadores participar en juegos completamente en cadena sin la necesidad de autorizaciones repetitivas y firma de transacciones. Como resultado, la experiencia de juego se mejora enormemente. Es probable que el aumento de los juegos completamente en cadena en el futuro impulse la adopción generalizada de las cuentas AA.

Transacciones basadas en la intención

Recientemente, el concepto de transacciones basadas en la intención ha ganado popularidad con el surgimiento de Unibot, y Uniswap también ha lanzado el proyecto Uniswap X para promover la implementación de transacciones basadas en la intención. El siguiente ejemplo puede explicar qué son las transacciones basadas en la intención:

  • Alice quiere intercambiar 1 ETH por 1000 USDT. Alice envía esta intención a un grupo de transacciones específico. La intención define que Alice transferirá 1 ETH y recibirá 1000 USDT. La intención también define el período de validez de la transacción, digamos 1 hora.
  • Otros traders en la piscina de transacciones buscan continuamente intenciones ejecutables.

Si alguien está dispuesto a ejecutar la intención, la contraparte inicia otra intención de transferir 1000 USDT a Alice y recibir 1 ETH.

La transacción se ha emparejado correctamente.

  • Finalmente, un empaquetador agrupa múltiples intenciones y las envía al blockchain.

Las transacciones basadas en intención proporcionan las siguientes ventajas:

  • Precio de ejecución determinista, que proporciona una ventaja significativa en comparación con la incertidumbre del precio de los swaps.
  • Tarifas de gas más bajas, ya que múltiples transacciones de intención pueden ser agregadas y enviadas a la cadena de bloques, reduciendo el consumo de gas para las transacciones individuales.
  • Experiencias comerciales más diversas, ya que las transacciones basadas en intenciones abren la posibilidad de coincidencias comerciales fuera de la cadena, lo que lleva a la aparición de modelos comerciales más diversos, como Unibot, que implementa funcionalidades de Libro de Órdenes y front-running.

Actualmente, CowSwap ha implementado Transacciones Basadas en Intención basadas en EOA. Sin embargo, las Transacciones Basadas en Intención basadas en EOA aún requieren que los usuarios autoricen (ERC-20, Aprobar) antes de iniciar la transacción. Sin embargo, bajo la nueva arquitectura de cuenta de AA, los usuarios pueden enviar Aprobar e Intención juntos al agrupador. El agrupador de AA puede acceder simultáneamente a la Lista de Intenciones, emparejar intenciones y proporcionar una experiencia comercial más conveniente.

Descargo de responsabilidad:

  1. Este artículo es una reimpresión de [chaincatcher]. Todos los derechos de autor pertenecen al autor original [Presidente: Bill Qian, Investigador: Bonan Yuan]. Si hay objeciones a esta reimpresión, por favor contacte al equipo de Gate Learn, y ellos lo resolverán rápidamente.
  2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejos de inversión.
  3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.

Informe de abstracción de cuenta de Cypher Capital: Pros, Contras, Infraestructura Existente y Perspectivas Futuras

Intermedio12/17/2023, 1:57:20 PM
Este artículo analiza los desarrollos técnicos y perspectivas de la abstracción de cuentas en Web3. Profundiza en los principios de implementación de las cuentas AA, contrastándolas con la Computación Multi-Parte (MPC) y las Cuentas de Contrato (CA) para resaltar la singularidad de las cuentas AA. Además, el artículo discute el potencial de combinar cuentas AA con las intenciones del usuario y chips seguros en dispositivos finales para mejorar tanto la seguridad como la conveniencia.

¿Qué es la Abstracción de Cuenta (AA)

Diferencias entre AA, EOA y CA

La esencia de la abstracción de cuentas es una Cuenta de Contrato. En Ethereum, hay dos tipos de cuentas:

  • Dirección del Contrato
  • Cuentas de Propiedad Externa

Un ejemplo simple es que la Dirección del Contrato es la dirección donde se implementa el contrato. Cualquier contrato en Ethereum que pueda ser llamado tiene una dirección de contrato, como la dirección del contrato de USDT. Una cuenta EOA es la conocida cuenta ETH, como la cuenta mostrada en la billetera Metamask.

0xdac17f958d2ee523a2206206994597c13d831ec7es la dirección del contrato para tokens USDT. Las direcciones de contrato no pueden crearse directamente desde el exterior; son creadas y gestionadas por EOAs. El EOA que creó la dirección del contrato USDT es 0x36928500Bc1dCd7af6a2B4008875CC336b927D57.

Por lo tanto, entendemos que una cuenta AA es un tipo especial de Cuenta de Contrato (CA) en Ethereum. Las cuentas AA aún deben ser creadas por EOAs y son controladas por EOAs externos porque la única forma de interactuar con la cadena de Ethereum es a través de EOAs. En consecuencia, AA sirve como una implementación estandarizada y modular de billeteras de CA, que continúa evolucionando con el tiempo.

Historia de Desarrollo de Cuentas AA

Acabamos de explicar la relación entre AA y CA. Antes de la propuesta del estándar ERC-4337, ya existía un número significativo de carteras CA disponibles. A continuación, proporcionamos información sobre tres carteras CA populares y cómo operan:

Cartera de Parity

Durante las primeras etapas del desarrollo de Ethereum, surgieron varias carteras de contratos. La más conocida es la cartera Parity, desarrollada por el equipo de Gavin Wood, los fundadores de PolkaDot. Parity está implementada en Rust y sirve como alternativa al nodo Geth, que está desarrollado en Golang. Parity Wallet es una cartera de contrato multi-firma que permite a múltiples cuentas externamente propiedad (EOAs) controlar y gestionar una cuenta de contrato (CA). Sin embargo, en 2017, un hacker explotó un error en la cartera Parity y robó más de 150,000 ETH. Este incidente causó una pérdida de confianza en las carteras de contratos.

Como resultado, las billeteras AA requieren una práctica extensa y estandarización para evitar que ocurran incidentes similares.

Cartera de Gnosis

La billetera multi-firma de Gnosis es actualmente la billetera multi-firma principal y es utilizada por la mayoría de las instituciones y desarrolladores. Un número significativo de equipos almacenan sus fondos de desarrollo en la billetera multi-firma de Gnosis para evitar que los miembros del equipo actúen maliciosamente. Equipos destacados que utilizan Gnosis Safe incluyenYearn,Aave, yBalancer. La seguridad de la Puerta de Gnosis es extremadamente alta, pero su uso es relativamente caro, lo cual es un problema común con las carteras de CA.

UniPass

Unipass Wallet combina la tecnología MPC y los monederos de contrato de CA, lo que permite a los usuarios utilizar el inicio de sesión social sin la custodia propia de un monedero EOA. Cabe destacar que tanto el monedero Parity como el Gnosis Safe aún requieren que los usuarios custodien sus claves privadas. El flujo general de Unipass es:

  • Inicio de sesión social al crear una billetera CA en cadena
  • Interacción con la cadena
    Los usuarios inician transacciones
    MPC verifica la validez de las transacciones de usuario
    Una billetera EOA controlada por MPC inicia transacciones en la cuenta del usuario de CA
    La cuenta de CA ejecuta la transacción y paga gas al pagador de UniPass

Es importante tener en cuenta que la solución AA original de Unipass no se adhiere completamente al estándar ERC-4337. El control de la billetera todavía se delega a un EOA que está controlado por el MPC de Unipass.

Implementación de AA (ERC-4337)

La esencia de AA es una cuenta de CA estandarizada y modularizada. ERC-4337 se manifiesta principalmente en las siguientes innovaciones:

  • bundler : Las cuentas tradicionales de CA todavía requieren que los usuarios inicien transacciones a través de una cuenta EOA externa, lo que obliga a los usuarios a almacenar ETH en sus cuentas EOA para las tarifas de gas. En ERC-4337, los usuarios empaquetan sus transacciones como UserOperations y las envían al bundler, quien inicia la transacción, eliminando así la necesidad de que los usuarios reserven gas por adelantado.
  • Firmas agregadas BLS: El agrupador empaqueta múltiples UserOperations en una sola transacción y genera una firma agregada BLS, la cual luego se valida en cadena a través de una única verificación de firma BLS.
  • pagador : Los usuarios pueden designar un pagador para pagar el gas.

El diagrama anterior describe aproximadamente el proceso de transacción estándar en ERC-4337:

  • El usuario empaqueta UserOp y lo envía al agrupador
  • Bundler verifica la validez de UserOp y lo empaqueta en una transacción
  • Bundler envía la transacción a la red principal de ETH
    Punto de entrada: Punto de entrada del contrato para la transacción enviada por el agrupador
    handleOps: Contrato específicamente utilizado para ejecutar transacciones de usuario
    pagador : Contrato utilizado para pagar el gas del usuario

Podemos resumir las principales diferencias entre AA y CA tradicional de la siguiente manera:

  • Los usuarios no envían transacciones directamente, sino que dejan el empaquetado al agrupador
  • La verificación de la firma se traslada de la capa de consenso a la capa de contrato, donde el contrato valida la firma
  • Introducción de un pagador modularizado, que permite a los usuarios elegir libremente quién paga por el gas

Cómo AA Difiere De MPC

Antes de comprender completamente AA, muchas personas suelen confundir los conceptos de AA y MPC porque ambos admiten características como la recuperación social y los complementos sin navegador. Las diferencias esenciales entre AA y MPC son las siguientes:

  • AA sigue siendo descentralizado y existe en la cadena, mientras que MPC es centralizado y a menudo alojado por una o más instituciones.
  • Las transacciones AA son ejecutadas por la dirección del contrato AA, mientras que MPC es realizada por la EOA alojada por la institución, lo que hace que MPC siga siendo una cuenta EOA gestionada.
  • La ejecución de una transacción AA implica interacciones con múltiples contratos relacionados con AA en cadena, mientras que MPC interactúa directamente con el EOA. MPC no incurre en tarifas de gas adicionales.

A continuación, vamos a presentar MPC y sus características únicas.

  • La tecnología MPC es más madura, y las billeteras calientes de los intercambios centralizados han implementado MPC para evitar fallos de un solo punto, mejorando significativamente la seguridad de los intercambios centralizados.
  • MPC consta de múltiples nodos, con cada nodo poseyendo solo un fragmento de la clave privada. Las transacciones solo pueden ser firmadas cuando múltiples nodos de MPC alcanzan consenso. Como resultado, el robo de la clave privada de un solo nodo no conduce a la pérdida de fondos.
  • Actualmente, hay muchas soluciones de MPC de código abierto. Para principios específicos, puedes consultarhttps://tor.us/, una solución de nodo MPC de código abierto desarrollada por Web3Auth.

Las soluciones de MPC son ampliamente utilizadas en los logins sociales actuales, y muchos proyectos han lanzado billeteras MPC para proporcionar una experiencia de billetera sin cadena, eliminando la necesidad de que los usuarios instalen billeteras de complementos o gestionen claves privadas. En la industria, estos tipos de billeteras administradas se denominan colectivamente Wallet-as-a-Service (WaaS). Los proyectos maduros incluyen:

  • Autenticación Web3
  • Red de Partículas
  • Enlace mágico
  • Coinbase Base

Ante un número creciente de servicios de WaaS, es previsible que en el futuro haya más productos que ofrezcan WaaS. Sin embargo, los intercambios centralizados tienen un volumen de usuarios absoluto y una amplia experiencia empresarial en este campo, por lo que es posible que todos los intercambios centralizados proporcionen servicios relacionados en el futuro.

Ventajas de AA

Recuperación Social

La principal desventaja de las Cuentas Externamente Propiedad (EOA) tradicionales es que los usuarios son responsables de almacenar sus propias claves privadas. Esta auto-custodia presenta los siguientes problemas:

  • Alto costo cognitivo. La mayoría de los usuarios no pueden entender las claves pública y privada.
  • Si los usuarios pierden su clave privada, no hay forma de recuperar la cuenta.

AA (Account Abstraction) está diseñado para permitir a los usuarios establecer cuentas de recuperación social. Pueden usar una o más EOA externas para recuperar el control sobre su AA. El flujo común para la recuperación social es el siguiente:

  • El usuario pierde el acceso al EOA actual que controla el AA, o este se ve comprometido.
  • Dos EOA adicionales están vinculados a la AA del usuario: \
    EOA de amigo \
    EOA custodiado institucionalmente
  • Estos dos EOAs inician una apelación y, después de completar una prueba de multisig 2/3, cambian el EOA vinculado del AA al nuevo EOA del usuario.

A través de este proceso de apelación, incluso si el usuario pierde el control del EOA que rige el AA, aún puede cambiar a un nuevo EOA. A diferencia del inicio de sesión social de MPC (Cómputo de Partes Múltiples), esta recuperación social es completamente descentralizada y no tiene un único punto de falla.

Delegación de Gas

La delegación de gas es fundamental para la adopción masiva de la cadena de bloques. Para los nuevos usuarios que ingresan a Web3, el mayor punto de dolor es pre-financiar las tarifas de gas. Al utilizar el Paymaster de AA para delegar gas, los nuevos usuarios pueden recibir subsidios, lo que reduce la barrera de entrada a las aplicaciones Web3.

Interoperabilidad sin fricción entre cadenas

Otro problema central que afecta la adopción masiva de Web3 es la compatibilidad entre cadenas. Paymaster, a través de la integración de protocolos entre cadenas como Layer0/Warmhole, permite a los usuarios depositar en Cadena A (por ejemplo, Ethereum) y utilizar aplicaciones en Cadena B (por ejemplo, Matic o BSC) de forma transparente, haciendo que las fronteras entre cadenas desaparezcan y ayudando a que las nuevas Dapps ganen usuarios de otras cadenas.

Desventajas del AA actual

Si bien hemos discutido las ventajas de AA, el estándar ERC-4337 todavía está iterando rápidamente para abordar sus desventajas actuales:

Creación separada para cada cadena/capa2

A diferencia de EOA, una vez que se crea un EOA, se puede utilizar en cualquier cadena compatible con EVM, ya que el mismo par de claves público-privadas puede usarse para interactuar en diferentes cadenas. Sin embargo, debido a la naturaleza de AA como Cuenta de Contrato (CA), un nuevo contrato de AA debe ser desplegado por separado en cada cadena o Capa2. El alto costo de despliegue de contratos de AA podría desalentar a los usuarios de adoptar AAs.

Además, si los usuarios implementan de manera incorrecta, como usar diferentes Fábricas para implementar cuentas de contrato AA, pueden terminar con direcciones AA diferentes en diferentes cadenas, lo que puede causar confusión significativa y dificultades en el uso y la comprensión. Si bien las Fábricas de Billetera AA actuales han logrado generar la misma dirección AA en diferentes cadenas, los usuarios aún deben tener cuidado al verificar los protocolos que están utilizando para garantizar que sus direcciones AA sigan siendo consistentes en varias cadenas, evitando así cualquier problema o confusión futuros.

Altos costos de implementación

Como se mencionó, las cuentas AA requieren que los usuarios implementen los contratos AA generados por Wallet Factory en diferentes cadenas y Layer2 por separado. Incluso con las actuales sidechains, cadenas compatibles con EVM y tarifas de gas más bajas en Layer2, sigue siendo un gasto significativo. Con las tarifas de gas actuales y el precio del ETH en $1800, implementar una cuenta AA en la red principal de ETH costaría aproximadamente $20-$40, mientras que en cadenas compatibles con EVM o Layer2, oscilaría entre $0.5 y $5. Para la mayoría de los usuarios, es difícil aceptar el costo de implementación antes de siquiera usar la Dapp. Suponiendo que este costo esté subvencionado por un Bundler o Paymaster, el costo de la subvención sigue siendo demasiado alto y requiere un fuerte incentivo.

Costo de gas significativamente más alto que EOAs

Dependiendo de la implementación de AA y el número de transacciones agrupadas en una sola transacción de Bundler (cuantas más transacciones, menor será el costo de gas por UserOP), el consumo de gas de las transacciones estándar actuales de ERC-4337 puede ser varias veces mayor que el de las cuentas regulares de EOA. Esto se debe a que una transacción iniciada por una cuenta AA a menudo requiere llamar a 3 o más contratos e implica cálculos complejos como la verificación de firma BLS en cadena. El estándar actual de ERC-4337 también se está optimizando para esto, con el siguiente plan de trabajo:

  • Simplificando el número de contratos llamados en transacciones de cuenta AA
  • Presentación de contratos precompilados de curva elíptica en ETH para reducir el consumo de gas para la verificación de firmas en cadena

Estimación de la tarifa de gas bajo el estándar ERC-4337

Acabamos de mencionar el costo relativamente alto de usar el estándar ERC-4337. ¿Cuáles son los costos específicos? Primero, introduzcamos un concepto, que es la fórmula de cálculo para las tarifas de gas:

tarifa = gas × precio

Entonces, ¿cuáles son los costos de implementación y uso de ERC-4337? El equipo de StackUp ha proporcionado estimaciones precisas en su blog.

https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337

Tabla 1. Gas para transacciones ERC-4337

La tabla anterior muestra:

  • El costo de crear una cuenta AA es aproximadamente 20 veces el costo de una transacción EOA.
  • Las transferencias de tokens nativos en cuentas AA cuestan alrededor de 4 veces más que en EOA.
  • Para transferencias ERC20, los AAs cuestan solo 1.5 veces más que los EOAs.

Tabla 2. Estimaciones de tarifas de gas para transacciones ERC-4337

Esta tabla proporciona estimaciones de costos para varias operaciones en la cuenta AA ERC-4337 utilizando los precios actuales del gas. Podemos observar lo siguiente:

  • En la red principal de ETH, el costo de crear una cuenta AA es muy alto, aproximadamente $20-30.
  • Bajo Rollup, debido a la tecnología de compresión de datos, el costo de crear una cuenta de AA es menor, similar al costo de las transferencias.
  • En otras cadenas compatibles con EVM, el costo de crear una cuenta AA es relativamente más bajo debido a la tarifa base de gas más baja.

En resumen, debido al alto costo de crear cuentas AA ERC-4337 en la red principal, es probable que la adopción general ocurra primero en Layer2 y cadenas compatibles con EVM.

Compatibilidad Dapp y Compatibilidad del Navegador Blockchain

Otro obstáculo para el desarrollo de AA es la compatibilidad de la infraestructura con los contratos de AA. La mayoría de las Dapps fuera de la cadena AA nativa solo admiten cuentas EOA. El soporte para AA requiere que las Dapps utilicen el SDK de AA para transacciones y modifiquen los parámetros de consulta para la información del usuario.

Además, los navegadores de blockchain como Etherscan están diseñados principalmente para EOAs. Para mejorar la comodidad de consultar las cuentas de AA, estos navegadores pueden requerir una serie de optimizaciones de UI y UX.

Abstracción de Cuenta Nativa (AA Nativa)

Pros y contras de AA nativo

Excepto por Ethereum, la mayoría de las nuevas blockchains públicas ya han implementado cuentas AA nativas.

  • Ventajas
    Soporte de capa de consenso

Los AAs nativos se implementan en la capa de consenso de la cadena, lo que significa que no requieren desarrolladores de la comunidad para su implementación. Estos suelen ser contratos internos o del sistema desarrollados y mantenidos por los desarrolladores de la cadena de bloques.

Costos de implementación más bajos y tarifas de gas adicionales

Los contratos internos a menudo tienen permisos y prioridades más altos, y sus cálculos de gas son diferentes de los contratos externos. Por lo tanto, los AA nativos tienen costos de implementación más bajos y generalmente no agregan un gasto significativo de gas.

  • Cons
    Menor flexibilidad

La actualización de los AAs nativos requiere que los desarrolladores de la cadena pública sean responsables, a menudo necesitando bifurcaciones suaves o duras. Esto los hace menos flexibles que el ERC-4337 modular, lo que limita el ritmo de iteración y lanzamiento de nuevas funciones.

  • Aprenda de la experiencia de ERC-4337 y aumente la escalabilidad

Las cadenas con AAs nativos están estudiando activamente la extensibilidad y modularidad de ERC-4337, lo que permite construir más funciones sobre los AAs nativos.

Cerca

Near implementa AAs nativos en la capa de consenso con cuentas almacenadas directamente en la cadena de bloques. Admite múltiples claves de acceso y recuperación social (correo electrónico, número de teléfono). La siguiente imagen ilustra las diferencias entre una cuenta de ETH y una de Near.

Aptos / Sui

Debido al modelo de propiedad de recursos en Aptos y Sui, tanto Aptos como Sui han implementado AA nativo en la capa de consenso. Tomando Aptos como ejemplo, una cuenta de Aptos es un conjunto de recursos en la cadena de bloques, por lo que al crear una cuenta de Aptos, es necesario prepagar Aptos para completar la inicialización de la cuenta. Las cuentas de Aptos/Sui también admiten el cambio de la clave de autenticación, pero la dirección de la cuenta sigue siendo la misma, entre otras características de AA.

ZKsync

A diferencia de Near/Aptos/Sui/Starknet, ZKsync admite tanto EOA como AA en la capa de consenso. Por lo tanto, ZKsync puede iniciar transacciones utilizando tanto EOA como AA, lo que le permite ser utilizado con billeteras populares como Metamask y Argent. El diseño de AA de ZKSync se basa en ERC-4337, lo que lo hace compatible con billeteras y Dapps que admiten EIP-4337. Actualmente, el costo de gas adicional para transacciones AA en ZKsync es aproximadamente execution_gas + 20000, lo que equivale a alrededor de 0.01USD en el momento de la escritura. Este es un costo pequeño en comparación con AA ERC-4337 no nativas.

Starknet

Starknet admite nativamente AA y no admite transacciones iniciadas por EOA. Las cuentas AA en Starknet están diseñadas en base a ERC-4337. Actualmente, los contratos AA en Starknet son proporcionados por OpenZeppelin y desarrollados usando Cairo.

ICP

Las cuentas AA nativas en ICP se llaman Identidad en Internet (II para abreviar). La implementación de II es diferente de ERC-4337. II utiliza WebAuthn, comúnmente utilizado en marcos de Web2, lo que permite a los usuarios controlar sus cuentas utilizando los chips de seguridad incorporados en sus teléfonos inteligentes. Los usuarios pueden agregar y eliminar dispositivos libremente. En esencia, II convierte los dispositivos smartphone del usuario en monederos de hardware.

Infraestructura AA existente

Bundler

Bundler reemplaza el Mempool de nodo anterior en el ecosistema AA. UserOps ya no se envían a los Validadores, sino que se envían a los Bundlers para empaquetarlos y procesarlos en cadena. Los bundlers principales son los siguientes:

  • Agrupador de Stackup:

El agrupador de Stackup está implementado en Go lang y tiene como objetivo integrarse perfectamente con Go Ethereum (geth). Es el primer agrupador de estándares de producción en esta lista que cumple completamente con ERC-4337. Stackup se mantiene activamente y cuenta con una documentación completa, lo que lo convierte en el agrupador más popular actualmente. Stackup ofrece servicios de agrupación, eliminando la necesidad de que los equipos configuren su propio servicio de agrupación.

  • Infinitism Bundler

El agrupador de Infinitism está desarrollado en TypeScript y fue desarrollado por el autor original de ERC-4337. Infinitism también desarrolla contratos ERC-4337, lo que hace que su agrupador sea altamente compatible con ERC-4337. Sin embargo, se necesita una verificación adicional para el rendimiento y la estabilidad ya que está desarrollado en TypeScript.

  • Silius(AA-bundler) está siendo desarrollado por Vid Kersic, un miembro clave del protocolo Ethereum, utilizando Rust. Esto contribuirá a la integración de herramientas AA en el ecosistema Rust.
  • Skandha

Skandha es un empaquetador basado en TypeScript desarrollado por Etherspot. Etherspot está activo en la implementación de la memoria compartida del empaquetador. Skandha pasó todas las pruebas en abril de 2023.

  • Voltaire

Voltaire es un protocolo de agrupación desarrollado por el equipo de Candide para admitir su propia billetera de Candide. Voltaire es una implementación basada en Python de ERC-4337. Actualmente, Voltaire proporciona un buen soporte para la propia billetera de código abierto de Candide.

  • Rundler

Rundler es un protocolo de Bundler desarrollado por Alchemy, el proveedor de servicios de nodo más grande para Ethereum. Actualmente, Rundler no es de código abierto, pero debido a la gran base de usuarios de Alchemy, puede recibir un importante soporte de tráfico.

Puntos de dolor del agrupador

Bundler está actualmente en una fase de desarrollo e iteración rápida.

  • Comunicación entre bundlers

El punto doloroso actual que el bundler necesita abordar es la consistencia y los problemas de comunicación del mempool del bundler. Suponiendo que hay múltiples protocolos de bundler en el mercado y hay una falta de comunicación entre ellos, puede llevar a un problema grave de ataques DDoS al bundler. Si un usuario envía simultáneamente transacciones a múltiples bundlers sin comunicación entre ellos, estos bundlers empaquetarán y enviarán simultáneamente UserOps al validador. Sin embargo, solo se ejecutará el UserOp del primer bundler, y las transacciones de los bundlers restantes serán rechazadas debido al mismo nonce. En este caso, si el paymaster del usuario tiene un saldo insuficiente, los bundlers pagarán gas inválido por estos UserOps. Por lo tanto, actualmente, la comunicación entre los bundlers es un problema que debe abordarse para evitar ataques de spam de UserOp a los bundlers.

  • Descentralización del agrupador

Los agrupadores actuales son altamente centralizados. Si los agrupadores ponen en lista negra a ciertos usuarios, esto resultaría en que sus transacciones no pudieran ejecutarse. Esto va en contra de la descentralización y la naturaleza sin permisos de la cadena de bloques.

Pagador

Paymaster es una parte importante de AA, ya que puede subsidiar las tarifas de gas de los usuarios y reducir significativamente la barrera de entrada para Web3. Aquí hay algunas implementaciones populares de paymaster:

  • pago de acumulaciones
    El pagador de Stackups es parte del ecosistema de Stackups AA. Stackups ha implementado un panel de control de pagador donde las DApps u otros proveedores de servicios pueden configurar sus propias cuentas de subsidio enhttps://app.stackup.sh/sign-inpatrocinar las transacciones de los usuarios.

  • Tablero de Biconomy

El panel de Biconomy permite a organizaciones y desarrolladores utilizar componentes AA en sus proyectos. Los propietarios de proyectos pueden configurar sus proyectos para pagar las tarifas de gas para los usuarios a través de maestros de pago y agregar condiciones de patrocinio de gas. Al registrar su maestro de pagos para cualquier cadena compatible, las DApps pueden simplificar en gran medida la experiencia Web3 para los usuarios.

Billeteras
  • Ambire
    Ambire es una billetera web basada en AA que es autogestionada y es compatible con billeteras de plugins, billeteras de hardware y accesos sociales. Ambire también emite tokens de billetera para la gobernanza de la billetera Ambire. Actualmente, Ambire es compatible con las cadenas compatibles con EVM y Layer2 más populares.
  • Argent
    Argent es actualmente la billetera más popular en el ecosistema Layer2 y ya soporta proyectos Layer2 principales como Starknet y ZKsync.
  • Aguacate
    Avocado es una billetera web que permite a los usuarios pagar todas las tarifas de gas utilizando USDC y proporciona una experiencia de usuario fluida en diferentes cadenas.
  • Seguro
    Safe es la cartera de CA multisignatura mencionada anteriormente desarrollada por Gnosis. Debido a su alta seguridad y costos de uso, es utilizada principalmente por instituciones y equipos para la gestión de fondos.
  • Secuencia
    Sequence soporta inicio de sesión social y proporciona una experiencia de billetera sin complementos.

La importancia de AA para la adopción masiva de Web3

AA logra centralización, usabilidad y seguridad simultáneamente.

Las cuentas EOA tradicionales a menudo luchan por lograr simultáneamente descentralización, usabilidad y seguridad.

  • Las carteras EOA auto custodiadas como Metamask satisfacen la descentralización pero requieren que los usuarios gestionen sus claves privadas, lo que supone una barrera de entrada muy alta para los nuevos usuarios. Además, si el dispositivo es comprometido, existe un riesgo de robo de claves privadas.
  • Las cuentas de custodia de EOA de MPC eliminan la necesidad de que los usuarios custodien sus claves privadas, pero el MPC en sí todavía está controlado por una institución. Si la institución actúa maliciosamente o es pirateada, introduce un único punto de falla, lo que va en contra de la lógica de descentralización de la cadena de bloques.
  • Por otro lado, las carteras AA pueden abordar estos problemas. Durante la incorporación del usuario, los agrupadores pueden crear cuentas para los usuarios y gestionar las claves privadas de EOA de AA. A medida que los usuarios se familiarizan con Web3 o cuando sus activos en cadena alcanzan un cierto umbral, el control de la cuenta EOA de AA puede descentralizarse a través de contratos inteligentes, como el uso de carteras de hardware.

La delegación de gas de Paymaster transfiere la carga de costos para los usuarios

En el marco EOA tradicional, los usuarios a menudo necesitan adquirir tokens de blockchain como ETH a través de monedas fiduciarias para usar aplicaciones Web3. Esto suele implicar el uso de exchanges centralizados (CEX) para depositar moneda fiduciaria, intercambiarla por el token requerido y finalmente transferirla a una cuenta EOA recién creada. Este proceso requiere una comprensión significativa de Web3 y es engorroso en muchas regiones. Al introducir pagadores en AA, los costos iniciales de incorporación para los usuarios pueden ser delegados a los propietarios de proyectos de DApps. La transferencia de tarifas de gas tiene implicaciones significativas para la adopción masiva de Web3.

Seguridad mejorada

  • Auditorías de seguridad para el pagador

Actualmente, ERC-4337 está en sus primeras etapas, y se están desarrollando numerosas herramientas basadas en ella. En el lado del pagador, la UserOp del usuario puede ser auditada para evitar que ocurra un rug, como aprobaciones excesivas o transferencias de fondos no autorizadas. La auditoría de seguridad del pagador puede llevarse a cabo utilizando métodos bien establecidos en el sector financiero web2 para revisar transacciones problemáticas y garantizar la seguridad de los fondos del usuario.

  • Aislamiento de cuenta

Otra innovación que se está desarrollando es el aislamiento de seguridad de las cuentas, como separar la cuenta de fondos de la cuenta de juegos, etc. Cuando los usuarios utilizan funciones DeFi familiares y de transferencia, se utiliza la cuenta de fondos con una auditoría de seguridad más estricta. Cuando los usuarios prueban GameFi o DeFi no familiar, se utiliza la cuenta de juegos. De esta manera, sin aumentar las claves privadas que los usuarios necesitan gestionar, el diseño de aislamiento de seguridad de las cuentas garantiza la seguridad de los fondos de los usuarios a nivel subyacente.

Perspectivas y oportunidades para AA

Experiencia de seguridad mejorada con chips seguros nativos para móviles/ordenadores y monederos hardware

Actualmente, muchos dispositivos como teléfonos inteligentes y computadoras portátiles tienen chips seguros incorporados, como el Chip de Seguridad Apple T2 utilizado en Mac y iPhone. Por lo tanto, fundamentalmente, cada dispositivo con un chip Tee es una billetera de hardware confiable. Sin embargo, estos chips seguros actualmente no admiten algoritmos de firma de blockchain comunes como ECDSA.

  • La seguridad actual de las claves privadas de EOA
    Plugins/billeteras móviles

La seguridad actual de las claves privadas de EOA en complementos/monederos móviles se almacena directamente en texto plano en el dispositivo. Si el dispositivo se ve comprometido, los activos del usuario pueden perderse rápidamente. Por lo tanto, los monederos de extensión del navegador como Metamask tienen una alta usabilidad pero una baja seguridad.

Monederos de hardware

Los monederos de hardware garantizan que las claves privadas nunca salgan del dispositivo y no puedan ser accedidas directamente por partes externas. Sin embargo, la mayoría de los usuarios no pueden llevar sus monederos de hardware consigo en todo momento, lo que resulta en una alta seguridad pero una baja usabilidad.

  • Presentando AA, utilizando un chip seguro para la seguridad del dispositivo

Al utilizar la billetera AA y el innovador método de verificación en cadena, las transacciones pueden ser firmadas directamente por el chip seguro del dispositivo, asegurando que la clave privada del usuario nunca abandone el dispositivo. Esto proporciona una mayor seguridad en comparación con las cuentas tradicionales EOA. Actualmente, la Identidad en Internet del Computer y un proyecto llamado Porton Wallet en el ETHBogota Hackathon han implementado una solución que utiliza la firma del chip seguro del dispositivo y la clave de sesión, permitiendo a los usuarios aprovechar plenamente la seguridad de sus dispositivos, como teléfonos inteligentes o computadoras, equivalente a una billetera de hardware.

Gracias al diseño altamente modular de ERC-4337, a través de su expansión e iteración, las cuentas AA lograrán una seguridad significativamente mejorada.

Experiencia sin cadenas para usuarios de intercambio cruzado + AA

Actualmente, otro obstáculo para la adopción masiva de Web3 es la fragmentación de los ecosistemas blockchain en diferentes cadenas.

  • Experiencia de uso de DApp a través de cadenas actualmente

Como ejemplo simple, consideremos a un usuario en Ethereum (ETH) que desea experimentar una aplicación en la Binance Smart Chain (BSC). ¿Qué debería hacer este usuario? Primero, el usuario necesita intercambiar sus ETH por los correspondientes USDT/USDC y luego utilizar un puente de cadena cruzada para transferir estos tokens de ETH a BSC. Después de eso, el usuario debe comprar algo de BNB en un exchange centralizado (CEX) y transferirlo a BSC. Solo entonces el usuario podrá comenzar a experimentar varias aplicaciones DeFi en BSC. Todo este proceso es lento, tiene mala seguridad y conlleva una empinada curva de aprendizaje, especialmente para nuevos usuarios que podrían no estar familiarizados con los puentes de cadena cruzada.

  • Experiencia después de introducir AA + paymaster intercadenas

A través de los protocolos de intercambio cruzado comúnmente utilizados en la actualidad, como Layer0 + AA, el proceso de uso de DApp en diferentes cadenas puede simplificarse en gran medida. El pagador puede integrar completamente los protocolos de intercambio cruzado para lograr el "cargue una vez, pague en todas partes". Por ejemplo, si un usuario recarga USDC en el pagador de ETH, siempre y cuando la cuenta AA del usuario en diferentes cadenas sea la misma y esté vinculada al mismo pagador, el pagador puede encargarse de la contabilidad en nombre del usuario. El usuario no necesita transferir manualmente activos a ninguna cadena compatible con EVM/Layer2 con la misma dirección de cuenta.

Ubicación de anuncios, Subvenciona Gas para la Promoción de Dapp

La mayor ventaja de introducir el paymaster es que establece programáticamente condiciones para subsidiar a los usuarios de Dapp.

  • Subsidios sin AA y pagador

En el pasado, ha habido casos en los que los proyectos del ecosistema Web3 subvencionaron el gas para atraer a los clientes. Sin embargo, subsidiar las cuentas EOA sin establecer condiciones programáticamente a menudo condujo al mal uso de los fondos de subvención por parte de bots y estafadores, como transferir directamente los fondos de subvención, sin atraer a clientes genuinos.

  • Subsidios con pagador

Actualmente, los paneles de control de paymaster generalmente incluyen la funcionalidad de subsidiar las tarifas de gas para las Dapps. Los desarrolladores de proyectos pueden establecer fácilmente las condiciones de las subvenciones en el panel de control, de modo que solo las transacciones que cumplan con condiciones específicas sean elegibles para la subvención. Al controlar las condiciones de transacción en los subsidios a través de paymaster, las Dapps pueden atraer a más usuarios genuinos mientras mantienen los costos bajo control.

  • Debido al diseño modular de ERC-4337, los futuros pagadores pueden integrar más servicios, como proveedores de servicios de publicidad, abriendo posibilidades más amplias para la adopción masiva de aplicaciones Web3.

Crecimiento explosivo en Mobile DApps

Bajo EOA, debido a la dominancia de Metamask, las Dapps actuales se acceden principalmente a través de interfaces web, lo que resulta en una mayor cuota de mercado para las billeteras de complementos web. Sin embargo, la adopción masiva de web3 depende de la participación de los usuarios móviles, lo que hace que el desarrollo y la adaptación de AA sean más nativos para dispositivos móviles.

Juegos totalmente en cadena

Con la creciente popularidad de Dark Forest, la tendencia de los juegos completamente en cadena está surgiendo silenciosamente. Sin embargo, la experiencia del usuario al utilizar EOA (Cuentas Poseídas Externamente) en juegos es muy pobre. Imagina tener que usar una billetera para autorizar o firmar transacciones cada vez que realizas alguna acción en un juego. Esta interrupción constante impide que los jugadores se centren completamente en el juego en sí. Para abordar este problema, se han desarrollado Cuentas Arcade, que son versiones especializadas de AA regulares, específicamente para juegos completamente en cadena. Estas cuentas autorizan operaciones de juego específicas, lo que permite a los jugadores participar en juegos completamente en cadena sin la necesidad de autorizaciones repetitivas y firma de transacciones. Como resultado, la experiencia de juego se mejora enormemente. Es probable que el aumento de los juegos completamente en cadena en el futuro impulse la adopción generalizada de las cuentas AA.

Transacciones basadas en la intención

Recientemente, el concepto de transacciones basadas en la intención ha ganado popularidad con el surgimiento de Unibot, y Uniswap también ha lanzado el proyecto Uniswap X para promover la implementación de transacciones basadas en la intención. El siguiente ejemplo puede explicar qué son las transacciones basadas en la intención:

  • Alice quiere intercambiar 1 ETH por 1000 USDT. Alice envía esta intención a un grupo de transacciones específico. La intención define que Alice transferirá 1 ETH y recibirá 1000 USDT. La intención también define el período de validez de la transacción, digamos 1 hora.
  • Otros traders en la piscina de transacciones buscan continuamente intenciones ejecutables.

Si alguien está dispuesto a ejecutar la intención, la contraparte inicia otra intención de transferir 1000 USDT a Alice y recibir 1 ETH.

La transacción se ha emparejado correctamente.

  • Finalmente, un empaquetador agrupa múltiples intenciones y las envía al blockchain.

Las transacciones basadas en intención proporcionan las siguientes ventajas:

  • Precio de ejecución determinista, que proporciona una ventaja significativa en comparación con la incertidumbre del precio de los swaps.
  • Tarifas de gas más bajas, ya que múltiples transacciones de intención pueden ser agregadas y enviadas a la cadena de bloques, reduciendo el consumo de gas para las transacciones individuales.
  • Experiencias comerciales más diversas, ya que las transacciones basadas en intenciones abren la posibilidad de coincidencias comerciales fuera de la cadena, lo que lleva a la aparición de modelos comerciales más diversos, como Unibot, que implementa funcionalidades de Libro de Órdenes y front-running.

Actualmente, CowSwap ha implementado Transacciones Basadas en Intención basadas en EOA. Sin embargo, las Transacciones Basadas en Intención basadas en EOA aún requieren que los usuarios autoricen (ERC-20, Aprobar) antes de iniciar la transacción. Sin embargo, bajo la nueva arquitectura de cuenta de AA, los usuarios pueden enviar Aprobar e Intención juntos al agrupador. El agrupador de AA puede acceder simultáneamente a la Lista de Intenciones, emparejar intenciones y proporcionar una experiencia comercial más conveniente.

Descargo de responsabilidad:

  1. Este artículo es una reimpresión de [chaincatcher]. Todos los derechos de autor pertenecen al autor original [Presidente: Bill Qian, Investigador: Bonan Yuan]. Si hay objeciones a esta reimpresión, por favor contacte al equipo de Gate Learn, y ellos lo resolverán rápidamente.
  2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejos de inversión.
  3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!