La esencia de la abstracción de cuentas es una Cuenta de Contrato. En Ethereum, hay dos tipos de cuentas:
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.
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:
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.
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 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:
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.
La esencia de AA es una cuenta de CA estandarizada y modularizada. ERC-4337 se manifiesta principalmente en las siguientes innovaciones:
El diagrama anterior describe aproximadamente el proceso de transacción estándar en ERC-4337:
Podemos resumir las principales diferencias entre AA y CA tradicional de la siguiente manera:
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:
A continuación, vamos a presentar MPC y sus características únicas.
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:
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.
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:
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:
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.
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.
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.
Si bien hemos discutido las ventajas de AA, el estándar ERC-4337 todavía está iterando rápidamente para abordar sus desventajas actuales:
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.
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.
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:
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:
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 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.
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.
Excepto por Ethereum, la mayoría de las nuevas blockchains públicas ya han implementado cuentas AA nativas.
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.
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.
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.
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.
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.
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 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.
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.
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:
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.
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.
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 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 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.
Bundler está actualmente en una fase de desarrollo e iteración rápida.
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.
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.
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.
Las cuentas EOA tradicionales a menudo luchan por lograr simultáneamente descentralización, usabilidad y seguridad.
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.
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.
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.
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 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.
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.
Actualmente, otro obstáculo para la adopción masiva de Web3 es la fragmentación de los ecosistemas blockchain en diferentes cadenas.
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.
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.
La mayor ventaja de introducir el paymaster es que establece programáticamente condiciones para subsidiar a los usuarios de Dapp.
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.
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.
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.
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.
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:
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.
Las transacciones basadas en intención proporcionan las siguientes ventajas:
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.
La esencia de la abstracción de cuentas es una Cuenta de Contrato. En Ethereum, hay dos tipos de cuentas:
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.
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:
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.
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 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:
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.
La esencia de AA es una cuenta de CA estandarizada y modularizada. ERC-4337 se manifiesta principalmente en las siguientes innovaciones:
El diagrama anterior describe aproximadamente el proceso de transacción estándar en ERC-4337:
Podemos resumir las principales diferencias entre AA y CA tradicional de la siguiente manera:
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:
A continuación, vamos a presentar MPC y sus características únicas.
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:
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.
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:
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:
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.
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.
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.
Si bien hemos discutido las ventajas de AA, el estándar ERC-4337 todavía está iterando rápidamente para abordar sus desventajas actuales:
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.
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.
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:
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:
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 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.
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.
Excepto por Ethereum, la mayoría de las nuevas blockchains públicas ya han implementado cuentas AA nativas.
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.
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.
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.
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.
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.
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 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.
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.
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:
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.
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.
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 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 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.
Bundler está actualmente en una fase de desarrollo e iteración rápida.
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.
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.
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.
Las cuentas EOA tradicionales a menudo luchan por lograr simultáneamente descentralización, usabilidad y seguridad.
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.
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.
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.
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 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.
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.
Actualmente, otro obstáculo para la adopción masiva de Web3 es la fragmentación de los ecosistemas blockchain en diferentes cadenas.
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.
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.
La mayor ventaja de introducir el paymaster es que establece programáticamente condiciones para subsidiar a los usuarios de Dapp.
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.
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.
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.
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.
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:
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.
Las transacciones basadas en intención proporcionan las siguientes ventajas:
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.