La infraestructura de la Billetera juega un papel crucial en desbloquear la experiencia web3 para la próxima generación de dapps.

Hasta ahora, los usuarios han tenido que instalar software adicional, buscar financiación con una moneda novedosa y enfrentarse a pantallas de confirmación desconocidas incluso antes de realizar la primera interacción en web3. A pesar de la mejora en la protección con cortafuegos y de alejarse de frases de semilla, estos obstáculos siguen siendo puntos de alta rotación para las aplicaciones descentralizadas.

El entorno ha sido propicio para innovaciones que abstraen las capas técnicas, permitiendo un proceso de incorporación intuitivo a nuevas experiencias financieras, sociales y de juego sin comprometer el ethos original de auto custodia y descentralización.

2023 ha sido un año crucial para el ecosistema de la billetera, con la abstracción de cuentas y desarrollos en todas las capas del stack que cambian las estructuras de mercado y la forma en que pensamos sobre la relación entre usuarios, dapps y billeteras.

Abstracción de cuenta: ¿Qué, por qué y cómo

Podemos pensar en la abstracción de la cuenta como la desvinculación de la gestión de la cuenta de la gestión de claves. Una cuenta es una entidad en la cadena de bloques que puede contener activos y tener un historial de transacciones. Los firmantes (claves) son entidades con la autoridad para realizar acciones en nombre de las cuentas.

Con las cuentas tradicionales (EOA), una clave privada conserva el control exclusivo y total sobre su cuenta asociada. La estricta relación 1 a 1 entre la clave privada y la cuenta significa lo siguiente:

Los usuarios están limitados a utilizar soluciones de gestión de claves dedicadas (por ejemplo, Metamask, Ledger) al interactuar con la cadena de bloques.

No hay camino de recurso para perder una clave privada, y la clave que controla una cuenta no se puede cambiar.

Todas las acciones originadas por esa clave privada se tratan como iguales, desde la acuñación de un NFT gratuito hasta mover millones de dólares.

La abstracción de la cuenta convierte la cuenta en un contrato inteligente con su lógica dinámica para qué clave(s) puede(n) realizar acciones en su nombre, alcance permisos y realizar controles adicionales según el caso de uso.

Podemos desglosar aún más sus beneficios examinando lo que se está abstrayendo.

Porque el protocolo Ethereum solo reconoce transacciones originadas en EOA, la abstracción de cuentas requiere una infraestructura fuera de la cadena para transmitir transacciones originadas en contratos inteligentes a la cadena.

ERC-4337 se introdujo en 2021 como una forma estandarizada de hacer esto sin cambios en el protocolo central. Sin embargo, algunos proyectos ya estaban ofreciendo los beneficios de AA mucho antes de que el estándar estuviera completamente desarrollado.

Billetera segura* multisig lanzada en 2017 y ha crecido para asegurar más de $50 mil millones en activos para DAOs, empresas e individuos por igual

La billetera móvil de Argent ha sido impulsada por cuentas de contratos inteligentes desde 2018

La billetera Sequence, lanzada en 2021, permitió a Skyweaver crear e iniciar sesión en sus cuentas inteligentes usando su correo electrónico y pagar tarifas usando tokens no nativos

Esto requería construir y mantener una infraestructura de retransmisión personalizada por parte del proyecto respectivo.

Introduce ERC-4337. El estándar ofrece una alternativa descentralizada y resistente a la censura para la capa de retransmisión, definiendo una interfaz para que las cuentas, los pagadores y los agregadores de firmas interactúen con retransmisores de terceros a través de un mempool compartido alternativo de transacciones abstractas de cuentas (Operaciones de Usuario).

Los relayers ("bundlers") agrupan múltiples UserOps en una transacción para enviar a un contrato de EntryPoint singleton, que posteriormente verifica que las tarifas serán pagadas (por la cuenta misma o a través de maestros de pagos) y ejecuta los UserOps respectivos a las cuentas inteligentes.

Podemos contrastar esto con la forma en que la validación y la ejecución ocurren en cadenas que ofrecen abstracción de cuenta de forma nativa y, por lo tanto, no requieren relés adicionales (por ejemplo, zkSync* y Starknet), así como la propuesta RIP-7560 recientemente publicada para AA nativa en Ethereum y sus rollups.

En marzo de 2023, se implementó el contrato 4337 EntryPoint en la red principal. Su comunidad ha tenido un gran éxito al lograr que los desarrolladores participen en el movimiento de abstracción de cuentas.

Esto trajo consigo una oleada de nuevos proveedores de infraestructura y servicios para el ecosistema de la billetera, y empujó a los proyectos existentes a asegurarse de que sus estrategias comerciales y conjuntos de productos continúen abordando las necesidades de los desarrolladores de aplicaciones que buscan aprovechar AA para ofrecer a sus usuarios una experiencia web3 sin problemas.

Infraestructura de Billetera y Pila AA

Firmantes y Gestión de Claves

La infraestructura de Gestión de Firmantes y Claves es responsable de generar y asegurar pares de claves públicas utilizadas para firmar mensajes, transacciones y operaciones de usuario. El ejemplo más sencillo aquí son las billeteras EOA tradicionales, pero han surgido proveedores de billeteras como servicio para permitir la incorporación sin semilla y la gestión de billeteras a través de métodos de autenticación alternativos como las redes sociales y el correo electrónico.

Bajo el capó, estos servicios almacenan el material clave en HSM como AWS KMS al que solo el usuario puede acceder mediante sus credenciales de autenticación (Magic, Turnkey), o funcionan bajo algún esquema SSS/MPC (Privy, Web3Auth, Portal, Capsule) para proteger los materiales.

Lit* mejora este diseño de almacén de claves en el lado del servidor al descentralizar las claves. Cada nodo en la red almacena una parte de una clave privada ECDSA generada a través de un algoritmo DKG, todas las operaciones tienen lugar en una virtualización encriptada. Se pueden asignar reglas de autenticación arbitrarias al par de claves, lo que le da al usuario o la aplicación un control completo sobre qué interacciones están permitidas, e imponer, por ejemplo, límites de gasto. La red también puede ser aprovechada por billeteras MPC 2-de-N como opción de respaldo y recuperación.

Este año, ha habido una experimentación rápida para aprovechar Hardware Signers y Passkeys como un firmante de una cuenta para brindar a los usuarios la gestión de claves listas para usar con dispositivos móviles o de escritorio modernos. Estos firmantes funcionan nativamente con autenticación biométrica (por ejemplo, FaceID, TouchID) para brindar seguridad adicional con una experiencia de usuario familiar.

Los firmantes de hardware utilizan subsistemas aislados como el iPhone Secure Enclave y Android Titan HSM para generar claves y firmar mensajes, garantizando seguridad a nivel de hardware. Debido a que las claves no pueden extraerse del dispositivo, esto es más poderoso en conjunto con métodos adicionales de recuperación o como parte de un sistema de autenticación de dos factores.

Las claves de paso son un estándar para la autenticación sin contraseña construido sobre WebAuthn. Aquí, se genera un par de claves en el sistema operativo del dispositivo, y se pueden sincronizar en otros dispositivos a través de servicios como iCloud, por lo que la recuperación es posible si el usuario ha optado por hacerlo.

Una limitación aquí es que las claves de paso y las firmas producidas por el Hardware Signer no son reconocidas de forma nativa por cadenas como Bitcoin y Ethereum. Utilizan la curva elíptica secp256r1 (R1), mientras que estas cadenas operan en la variación K1. Aunque hay un trabajo en curso para verificar de forma confiable y eficiente la R1, algunos productos habilitados para Passkey están pasando por servicios como Lit y Turnkey para producir una firma K1 una vez que el usuario se haya autenticado con su clave.

Un estándar a tener en cuenta aquí es EIP-7212, que propone agregar la curva R1 directamente al EVM como un contrato precompilado para que cada dispositivo moderno pueda firmar transacciones de forma nativa sin servicios de terceros o intermediarios.

A medida que el volumen de transacciones abstractas de cuentas crece, la agregación de firmas utilizando firmas BLS podría hacer que las tarifas de cuentas inteligentes sean más baratas que las EOAs en L2s. 4337 define una interfaz para contratos de ayuda de Aggregator que valida una sola firma agregada que aprueba múltiples UserOps en lugar de validar cada una por separado.

Relayers

Los relayers (por ejemplo, 4337 Bundlers) relayan transacciones u operaciones de usuario a un mempool. En cadenas con AA nativos, los operadores de red y los secuenciadores desempeñan este papel, eliminando la necesidad de relayers externos dedicados.

Al igual que hay múltiples implementaciones de cliente para Ethereum (por ejemplo, geth, erigon, reth), el ecosistema 4337 tiene múltiples implementaciones de paquetes en diferentes lenguajes, lo que hace que la red sea más sólida contra las vulnerabilidades de una sola implementación. Las especificaciones 4337 incluyen un conjunto de pruebas para garantizar la compatibilidad del paquete en toda la red. Los implementadores incluyen Stackup (Golang), Pimlico, Biconomy, Etherspot (Typescript), Candide (Python), OKX (Java) y Alchemy (Rust).

El modelo de incentivos para los agrupadores es similar al de los constructores de bloques, tomando tarifas de las operaciones de usuario que agrupa en lugar de transacciones. En la práctica, los agrupadores necesitan una API en el constructor de bloques para ver el bloque actual y crear un grupo que sea válido contra ese bloque y, por lo tanto, debe considerarse como parte del constructor de bloques.

A medida que crece la tracción de 4337, podemos esperar que los constructores también sean agrupadores, ya que este híbrido será más rentable que un simple constructor, ya que pueden seleccionar de las piscinas de transacciones y UserOps.

Pagadores

Los pagadores permiten la abstracción de tarifas al permitir que las dapps patrocinen el gas para los usuarios, permitiendo a los usuarios pagar tarifas con tokens no nativos, o liquidando fuera de la cadena a través de los rieles de pago tradicionales. Los servicios de pagadores tienen 2 componentes principales:

Un administrador de políticas de gas para que los desarrolladores definan las condiciones bajo las cuales patrocinarán el gas. Esto se puede aplicar a todo el proyecto, o basarse en un contrato específico o en una dirección de billetera específica. Los desarrolladores también pueden definir cómo quieren limitar la tasa de patrocinio de gas, por ejemplo, por precio del gas, número de solicitudes o monto patrocinado al mes. Los costos de patrocinio de gas generalmente se incluyen en la factura mensual de los desarrolladores por parte del proveedor de servicios con un recargo de alrededor del 5% sobre el monto patrocinado.

Un contrato inteligente de pagador valida si una transacción determinada es elegible para ser cubierta, ya sea en función del estado en cadena como los saldos de cuentas o las políticas de gestión de gas fuera de la cadena. El contrato de pagador mantiene un saldo de tokens nativos que se utiliza para pagar el gas, y puede contener lógica de oráculo de precios que verifica periódicamente la tasa de cambio entre el token de pago (por ejemplo, USDC) y el token nativo (por ejemplo, ETH).

Los pagadores pueden clasificarse en onchain u offchain:

Los maestros de pago en cadena (por ejemplo, ERC20Paymaster, StablecoinPaymaster) solo se basan en el estado en cadena para verificar si una transacción puede ser cubierta por el maestro de pagos o no. Esto significa que ciertos maestros de pagos, como aquellos que aceptan el pago de gas en tokens ERC-20, pueden hacerse sin permisos, con la salvedad de que el maestro de pagos debe ser aprobado por la cuenta para transferir los tokens de pago. Los administradores del contrato del maestro de pagos pueden retirar tokens y convertirlos de nuevo a su forma nativa para rellenar el contrato, establecer un margen sobre el precio ERC20, establecer un umbral para la diferencia de precios por la cual el maestro de pagos actualiza el precio ERC20 para la próxima operación del usuario, o actualizar manualmente el precio.

Los pagadores fuera de la cadena (por ejemplo, VerifyingPaymaster) implican interacciones con la API del pagador de un proveedor de servicios para patrocinar el UserOp. El servicio fuera de la cadena verifica la elegibilidad y firma la transacción utilizando las claves del pagador. Si bien esta solución está autorizada, los pagadores fuera de la cadena vienen con los beneficios de ahorro de gas al minimizar las verificaciones en cadena. Las políticas de gas pueden ser más detalladas y tener en cuenta actividades fuera de la cadena como la actividad en Discord.

Fábricas y marcos de cuentas

Las fábricas y marcos de cuentas proporcionan implementaciones inteligentes de cuentas "headless" y SDK que las dapps y los clientes de billeteras pueden construir, creando cuentas integradas auto-custodiadas en nombre de sus usuarios. Las propias cuentas son billeteras de contratos inteligentes que tienen su propia validación de firma, ejecución y lógica de protección de repetición (gestión de nonce). Los propietarios autorizan operaciones de usuario que se originan desde sus cuentas inteligentes utilizando su clave.

En un nivel alto, los proveedores de cuentas inteligentes provisionan 3 cosas principales:

Una implementación central para una billetera de contrato inteligente, con su propia lógica para validar, ejecutar transacciones y cualquier acción adicional para realizar antes y después de la ejecución. También contiene la lógica de cómo se pueden agregar características adicionales a la billetera a través de módulos nativos y de terceros.

Un contrato de fábrica que implementa nuevas instancias de la implementación de la billetera, iniciadas con el firmante inicial para esa cuenta. Según ERC-4337, las dapps pueden crear cuentas inteligentes para sus usuarios especificando la dirección del contrato de fábrica de su proveedor de elección.

Un SDK que brinda a los desarrolladores la capacidad de personalización plug-and-play para las cuentas inteligentes que están creando. Esto puede incluir diferentes opciones de firma, opciones de entrada/salida y tecnologías de retransmisión.

Bajo ERC-4337, elremetenteEl campo de un UserOp se refiere a la cuenta inteligente bajo la cual se está realizando la transacción. Si la cuenta aún no ha sido implementada, EntryPoint implementa la cuenta desde el contrato de fábrica especificado en el initCodeLas claves del usuario se pueden utilizar para reclamar la cuenta inteligente para realizar interacciones posteriores con dapp.

Proveedores de cuentas como Safe, Zerodev y Biconomy se integran con administradores de claves y la infraestructura de autenticación para brindar a las dapps la posibilidad de elegir cómo desean que los usuarios administren sus cuentas inteligentes. Por ejemplo, la integración de Web3Auth de Safe permite a los usuarios utilizar sus cuentas mediante redes sociales o correo electrónico, y la integración de Zerodev con Turnkey ofrece la opción de administrar cuentas con Passkeys.

Safe es más conocido por su producto de billetera inteligente probado en batalla ampliamente utilizado por individuos, equipos y DAOs. Hasta la fecha, se han implementado más de 5 millones de Safes en más de 12 cadenas, ejecutando más de 22 millones de transacciones. Antes de la v1.4.1 (lanzada en julio de 2023), los desarrolladores ya podían usar el relé de Gelato para habilitar transacciones con gas abstraído. Esta combinación actualmente impulsa productos de tarjetas de débito criptográficas como Gnosis Pay y BasedApp, donde los usuarios pueden comprar a cualquier proveedor que acepte Visa utilizando fondos en su Safe. La v1.4.1 aporta soporte ERC-4337 a través de módulos para ofrecer opciones adicionales en proveedores de relé.

ZeroDev es un proveedor de cuentas inteligentes lanzado a principios de este año construido para ERC-4337 desde el principio. Zerodev agrega múltiples proveedores de envasadoras para abstraer servicios de relé UserOp, y expone un panel de control de gestión de gas donde los desarrolladores pueden definir el alcance y la lógica de limitación de velocidad para patrocinar tarifas para los usuarios. Zerodev y Biconomy (que también ejecuta su propia red de envasadoras) dominan actualmente la cuota de mercado para cuentas habilitadas para 4337.

La función AccountKit de Alchemy cuenta con una implementación de cuenta inteligente compatible con 4337 denominada "LightAccount", que se basa en la implementación de EF y agrega soporte EIP-1271 (validación de firmas originadas por contratos inteligentes) junto con transferencias de propiedad, rotación de claves y almacenamiento de espacio de nombres.

Módulos de cuenta

Los módulos de cuenta son contratos inteligentes que actúan como componentes instalables en una cuenta inteligente. Aunque la infraestructura de los módulos todavía se encuentra en sus primeras etapas, visualizamos que los módulos serán descubribles e instalables por:

Desarrolladores: las cuentas inteligentes integradas pueden venir con módulos "preinstalados" según lo decida el desarrollador de la dapp, construyendo una billetera de inicio con funciones personalizadas para su caso de uso

Los usuarios finales: las interfaces de billetera pueden exponer una “tienda de módulos” donde los usuarios pueden descubrir nuevas funciones y agregarlas a su billetera

Con AA separando formalmente cómo se maneja la validación y ejecución de UserOp, los módulos pueden contener lógica solo de validación o solo de ejecución.

Validadores. Llamados durante la fase de validación de una UserOperation. Su función principal es verificar la firma de una UserOperation y determinar si es válida y debe ejecutarse. Los ejemplos incluyen multisig, ECDSA, passkeys, validación multicanal y claves de sesión. Las claves de sesión permiten a las dapps firmar en nombre del usuario para simplificar la experiencia de usuario, comportándose como claves privadas temporales con permisos personalizables y tiempo de caducidad.

Ejecutores. Llamado durante la fase de ejecución de una UserOperation. Amplían la lógica de ejecución de la cuenta y permiten un conjunto más diverso de acciones que puede realizar de forma nativa. Ejemplos incluyen acciones automatizadas que se activan fuera del flujo de ejecución regular de ERC-4337, como intercambios automáticos de tokens cuando el precio alcanza cierto umbral.

Hooks. Ejecute controles previos o posteriores y aplique controles contra la cuenta. Por ejemplo, un gancho podría ejecutarse después de la ejecución y revertir cualquier transacción que cumpla ciertos criterios para crear una mayor seguridad para el usuario.

Si bien algunas billeteras como Candide han desarrollado módulos que sus usuarios pueden instalar directamente, anticipamos un ecosistema rico de módulos de terceros descubribles en una interfaz tipo tienda de aplicaciones de sus billeteras, o compuestos en una billetera integrada "inicial" por desarrolladores de dapp.

Los marcos de cuentas inteligentes ya están diseñados teniendo en cuenta los módulos. El contrato principal de Safe maneja la lógica de gestión de módulos para agregar y eliminar módulos de la cuenta, pero deja la lógica y el almacenamiento relacionados con el módulo completamente delimitados a un contrato separado. Esta separación de preocupaciones mitiga el riesgo de que los módulos de terceros sobrescriban el mismo estado, comprometiendo la seguridad y el comportamiento esperado de la cuenta.

El Protocolo Safe{Core} introduce un marco abierto con módulos, ganchos, un administrador y registros con el objetivo de fomentar un ecosistema de cuentas inteligentes componible inspirado en los conocimientos del producto de billetera de Safe.

ZeroDev clasifica explícitamente sus módulos ("plugins") como validación o ejecución. Los módulos ejecutores están diseñados para ser emparejados con módulos validadores, lo que permite que funciones personalizadas sean "enrutadas" a través de diferentes validadores. Por ejemplo, una función de "transferencia de NFT" que solo permite que los NFT se transfieran a través de 2FA.

Algunas consideraciones en la construcción de un ecosistema robusto de cuentas inteligentes modulares:

Interoperabilidad. Con múltiples proveedores de cuentas inteligentes, cada uno con su propio enfoque sobre cómo terceros pueden añadir nuevas funciones a las cuentas, los desarrolladores de módulos están en una trayectoria hacia el bloqueo del proveedor o tener que gestionar la carga técnica de desarrollar las mismas funciones para cumplir con múltiples implementaciones de cuentas. Algunas soluciones para mitigar esto:

ERC-6900 para cuentas de contrato inteligente modular y complementos define interfaces para cuentas de contrato inteligente modulares (MSCAs), módulos ("complementos") que permiten que las implementaciones de cuentas compatibles con estándares y complementos sean interoperables entre sí.

El ModuleKit de Rhinestone para la construcción y prueba de módulos de cuenta inteligente proporciona plantillas y marcos para probar módulos contra diferentes implementaciones de cuentas, una biblioteca de integraciones (por ejemplo, protocolos DeFi), condiciones preconstruidas para la ejecución y automatización de seguridad para analizar el código del módulo y señalar vulnerabilidades de seguridad.

Seguridad. Permitir a los usuarios instalar software de terceros en sus billeteras plantea preguntas importantes sobre cómo las interfaces deben seleccionar y exponer información relevante sobre los módulos.

EIP-7484 proporciona un medio para verificar la legitimidad y seguridad de los módulos de cuentas inteligentes construidos de forma independiente. Aquí, un registro permite a los auditores hacer afirmaciones sobre la seguridad de esos módulos. Los frontends y las cuentas inteligentes pueden consultar el registro para obtener datos de afirmación, verificando que un módulo es seguro de usar. Consulte el registro de Rhinestone para una implementación de referencia de esto.

Más ampliamente, EIP-7512 tiene como objetivo crear un estándar para una representación en cadena de auditorías analizables por contratos inteligentes para extraer información relevante sobre quién realizó las auditorías y qué estándares han sido verificados.

Descubribilidad. Los registros pueden ser expuestos y consultados por plataformas de cuentas inteligentes e interfaces de billetera para ser instalados por desarrolladores o usuarios finales.

La capacidad de ampliar la funcionalidad de la billetera convierte las cuentas en plataformas para desarrolladores y nuevos canales de distribución para productos y servicios web3. Ya estamos viendo esto con Metamask Snaps, que permite a los usuarios personalizar su billetera de extensión del navegador con alertas de seguridad (a través de WalletGuard), funciones de privacidad (a través de Nocturne) e interoperabilidad con cadenas no EVM como Starknet y Bitcoin.

Cuando Chrome habilitó un ecosistema de desarrolladores para extender la funcionalidad del navegador a través de extensiones, esto los impulsó hacia la dominancia del mercado sobre los jardines amurallados existentes a pesar de ser una década más joven. Aunque para la mayoría de nosotros es difícil imaginar cómo podría ser la experiencia de la billetera cuando las cuentas modulares se vuelvan mainstream, ya se están sentando las bases para que la innovación sin permisos siga su curso.

Patrones de Desarrollo Emergentes y Sus Implicaciones

La pila de billetera evolucionada significa que:

Los desarrolladores pueden crear cuentas no custodiadas para sus usuarios en el contexto de sus aplicaciones, y buscarán herramientas como los SDK de conector para darles opciones sobre cómo construir el recorrido completo de incorporación.

Las billeteras integradas son una nueva categoría de billetera, cada proveedor con sus propias características y compensaciones en cuanto a portabilidad de cuenta, personalización y suposiciones de confianza.

Si jugaste con Ethereum dapps en 2018, es posible que recuerdes recibir un aviso de Metamask tan pronto como cargues el sitio. Esto se debió a la falta de buenas prácticas de UX en la conexión de billeteras y dapps, y a menudo los desarrolladores recurrían a comprobaciones codificadas para ver si un usuario tenía instalada una billetera de extensión mediante el navegador.window.ethereumEsto resultó en un comportamiento impredecible si los usuarios tenían múltiples billeteras de extensión instaladas, obligando a los usuarios a elegir una y creando un mercado menos competitivo para las billeteras.

El protocolo de comunicaciones WalletConnect* surgió para permitir a los usuarios conectar cualquier billetera a cualquier dapp, junto con Web3Modal, una biblioteca que envuelve botones y componentes modales para permitir a los usuarios elegir con qué billetera quieren usar la dapp.

Hoy en día, Web3Modal es una de las múltiples bibliotecas conectores de billeteras como RainbowKit, Web3Onboard y ConnectKit que simplifican la detección de billeteras y el proceso de autenticación basado en billeteras para los desarrolladores de dapps. Estas bibliotecas ofrecen opciones de personalización listas para usar, funciones de búsqueda de billeteras y pantallas que redirigen a los usuarios para instalar billeteras si aún no tienen una.

Más recientemente, EIP-6963 se finalizó como un mecanismo alternativo de descubrimiento de billetera para window.ethereum, permitiendo que dapps y scripts inyectados provistos por extensiones se comuniquen de manera predecible. Gracias al estándar, los usuarios ahora tienen más opciones al elegir una billetera de extensión de su elección para conectarse a dapps, y abre un mercado más competitivo para las billeteras.

Si bien las bibliotecas de conexión han mejorado significativamente DevEx y UX, la expectativa de que los usuarios ya tengan o instalen software adicional para interactuar con dapps sigue representando una barrera alta para la adopción.

Ya estamos viendo un atisbo de cómo será el futuro de la experiencia de incorporación de dapps, ya que la próxima generación de bibliotecas de billeteras, a las que llamaremos aquí "SDK de incorporación" completamente desarrollados, está cobrando impulso. Además de la autenticación basada en billetera, estos SDK ofrecen opciones alternativas de registro y inicio de sesión como correo electrónico, redes sociales, SMS, y crean billeteras integradas para usuarios sin requerirles instalar software adicional o navegar lejos de la dapp.

Los desarrolladores pueden integrar conectores ofrecidos por proveedores clave directamente (por ejemplo, Magic, Privy, Web3Auth) o utilizar aquellos que envuelven múltiples servicios (por ejemplo, Dynamic, Thirdweb, 0xPass) para ofrecer opciones de plug-and-play en las opciones de autenticación que desean exponer y el tipo de billetera que desean crear, personalizando completamente el flujo de incorporación. Los SDK de incorporación también pueden integrarse con proveedores de cuentas inteligentes para crear billeteras inteligentes integradas, ofreciendo más mejoras de UX como transacciones sin gas y entradas/salidas.

Con la creciente adopción de billeteras "headless" y un movimiento hacia billeteras integradas, lo que solía ser una clara línea de separación entre las billeteras y las dapps comienza a difuminarse.

Billeteras independientes vs. Billeteras integradas vs. Billeteras específicas de aplicación

Los usuarios de Web3 hoy están acostumbrados a interactuar con dapps a través de billeteras independientes como Metamask o las ofrecidas a través de WalletConnect, acumulando sus activos e historial en cadena en una o unas pocas cuentas.

A medida que más dapps buscan incorporar usuarios a través de billeteras integradas y múltiples proveedores disponibles, la gestión de cuentas se vuelve rápidamente complicada tanto para los desarrolladores de dapps como para los usuarios finales. Los desarrolladores de dapps tendrán que evaluar y gestionar múltiples proveedores mientras intentan evitar quedar atrapados. Para los usuarios finales, crear una nueva billetera por dapp llevará a una experiencia de gestión de activos e identidad fragmentada.

Si bien las billeteras específicas de la aplicación son deseables para ciertos casos de uso, hay muchas instancias en las que los usuarios podrían incorporarse a su primer dapp, crear una billetera incrustada con sus firmantes web2 o Passkey, y querer utilizar los activos que acumulan en esa cuenta en otro dapp al iniciar sesión con el mismo firmante.

Capsule es un proveedor de billetera integrada basada en MPC que ofrece portabilidad de billetera en las dapps que utilizan su servicio, brindando a los usuarios acceso a una billetera existente utilizando el mismo inicio de sesión por correo electrónico. Podemos anticipar que esto pronto será una oferta básica en los proveedores de WaaS.

Moonchute ayuda a los usuarios a gestionar múltiples cuentas inteligentes en el ínterin. Su gestor de cuentas unificado es una aplicación y API para descubrir billeteras inteligentes creadas por un firmante dado, lo que permite a los usuarios gestionar activos de múltiples cuentas en un solo lugar.

ERC-7555 propone una interfaz estandarizada inspirada en SSO y un patrón de solicitud/respuesta para que las aplicaciones descubran cuentas de usuario creadas utilizando esquemas de firma alternativos. Aquí, la aplicación redirigiría al usuario a la URI de un proveedor específico (que podría ser un dominio autohospedado) y analizaría la respuesta en busca de un firmante y la dirección de la cuenta inteligente asociada.

Migración de EOAs

Otro desafío destacado de AA es una forma fluida para los usuarios existentes, que ya tienen activos e historial en cadena acumulados en múltiples EOAs, migrar a cuentas inteligentes.

EIP-7377 propone un mecanismo en el protocolo para permitir a las EOAs enviar una transacción única que implementa código en su cuenta, efectivamente 'actualizando' una EOA a una billetera inteligente.

Aarc tiene como objetivo resolver la migración de activos para dapps y usuarios finales. Su interfaz de usuario y SDK indexa los activos y permisos de una dirección de origen específica, y permite a los usuarios seleccionar los activos que desean mover a cualquier dirección de destino, que podría ser una cuenta inteligente, otro EOA o una billetera MPC integrada creada con inicio de sesión social. Para dapps con usuarios existentes que están acostumbrados al flujo de billetera independiente, Aarc ofrece una solución para agilizar el proceso de migración a medida que buscan agregar billeteras integradas o funciones de AA a su producto.

Implicaciones de AA para la gestión de cuentas en múltiples cadenas

Dada la dinámica de la actividad de AA y L2, podemos anticipar un futuro en el que las cuentas inteligentes se conviertan en algo común sobre las EOAs, con los usuarios teniendo activos en múltiples cadenas.

Una ventaja de UX de EOAs es que los usuarios automáticamente tienen acceso a la misma dirección en diferentes cadenas de EVM usando la misma clave privada. La desventaja es que no es posible cambiar las claves que controlan una dirección dada y todos los fondos pueden perderse si el usuario pierde su clave privada.

Debido a que la abstracción de cuentas separa el almacén de claves del almacén de activos, es posible rotar claves para una cuenta determinada sin tener que migrar fondos y manteniendo la misma dirección. Las cuentas inteligentes pueden mantener la misma dirección a través de cadenas utilizando CREATE2, lo que brinda a los usuarios acceso a la cuenta incluso si el contrato aún no se ha implementado en una cadena determinada utilizando la misma clave de verificación inicial e implementación de cuenta.

Sin embargo, mantener la misma dirección en todas las cadenas puede ser un anti-patrón a largo plazo.

CREATE2 solo es posible en cadenas con equivalencia de bytecode de EVM. En un mundo multicanal con zk-Rollups (por ejemplo, zkSync) con ligeras desviaciones al EVM, este enfoque no será suficiente.

Podemos esperar que las claves necesarias para acceder a diversas cuentas cambiarán con el tiempo a medida que las billeteras expongan funciones adicionales de firma y rotación de claves. Bajo la configuración actual, esto puede causar rápidamente una deriva de estado de permisos de cuenta en las cadenas, ya que los cambios en los firmantes de una cuenta en una cadena no propagan automáticamente los nuevos permisos a las otras cadenas.

Soluciones a largo plazo que se han propuesto para multichain AA incluyen:

Un contrato de almacenamiento de clave dedicado al que una cuenta de usuario a través de cadenas lee al verificar permisos. Vea una implementación de esto desde Soul Wallet.

Utilizando los resolutores multichain de ENS como una capa de abstracción para diferentes direcciones.

La gestión de cuentas y firmantes entre cadenas todavía es un área en investigación activa. El objetivo final aquí es que un usuario pueda cambiar las claves que tienen acceso a múltiples cuentas en diferentes cadenas sin realizar un número extremadamente alto de transacciones.

Conclusion and Closing Thoughts

La abstracción de cuentas es un movimiento para desacoplar los firmantes de las cuentas mediante la creación de cuentas basadas en contratos (en lugar de EOAs) como entidades de primera clase en la cadena de bloques, lo que brinda a los usuarios flexibilidad en la gestión de claves y permisos de cuenta.

ERC-4337 como un estándar para relatar transacciones iniciadas por cuentas inteligentes ha catalizado la evolución de la infraestructura de la billetera para acomodar AA, dando lugar a nuevas estructuras de mercado, categorías de billetera, desarrollo de dapp y patrones de incorporación de usuarios.

La pila de billetera se ha desagregado en firmantes, retransmisores, proveedores de cuentas y módulos de cuentas, brindando a los desarrolladores la opción de personalizar la experiencia del usuario final. Esto conlleva la carga adicional de evaluar a cada proveedor en función de sus compensaciones en términos de gastos generales, resistencia a la censura, dependencia del proveedor y interoperabilidad.

Los caminos de migración desde las EOAs y la abstracción de cuentas en un contexto multichain siguen siendo áreas de investigación en curso. Esperamos ver las primeras implementaciones de las soluciones propuestas en el próximo año.

Creemos que estos desarrollos tienen implicaciones significativas en todo el ecosistema:

Para los nuevos usuarios, las billeteras ya no son el único punto de entrada en web3. Las aplicaciones tendrán una incorporación notablemente mejorada a través de billeteras integradas, transacciones sin gas y rampas de acceso en la billetera.

Para los usuarios actuales, las experiencias en cadena se volverán más fluidas a medida que las aplicaciones aprovechen características como las claves de sesión. Los usuarios avanzados tienen un control más detallado sobre los permisos de la cuenta y funciones adicionales de la billetera a través de módulos.

Para los desarrolladores, la infraestructura de cuenta modular convierte las billeteras en sistemas operativos. Los mercados de módulos son un nuevo canal de distribución sin permisos para productos y servicios web3.

La infraestructura de la billetera seguirá catalizando la adopción de web3. En 1kx estamos orgullosos de haber respaldado equipos que han sido pioneros en las ideas discutidas en este artículo, y seguiremos monitoreando el espacio para ver lo que está por venir.

Si estás trabajando en soluciones en este espacio o tienes pensamientos adicionales sobre el tema, por favor contáctanos@nichanank- me encantaría chatear contigo.

Muchas gracias a David Sneider, John Rising, Konrad Kopp, Kurt Larsen, Marc Sednaoui, Dogan Alparslan, Vivian Phung, Derek Rein, Tom Terado, Diana Biggs, Mel Quarto y pet3rpan por revisar borradores de esto.

*denota empresas de cartera 1kx

Declaración:

1. Este artículo es una reproducción de[1kx]，著作权归属原作者[1kx]，如对转载有异议，请联系Equipo Gate LearnEl equipo procesará rápidamente según el procedimiento correspondiente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente el punto de vista personal del autor y no constituyen consejos de inversión.
3. Las otras versiones del artículo son traducidas por el equipo de Gate Learn, si no se mencionaGate.ioNo se permite copiar, difundir o plagiar artículos traducidos en esta situación.