Más sobre Account Account Abstraction
Artículo de Charles Guillemet CTO en Ledger SAS
Si no sabes lo que es Account Abstraction te recomiendo que vayas a este primer artículo que escribí hace unos meses.
Ledger SAS es uno de los principales fabricantes de soluciones de almacenamiento de criptomonedas para el sector retail, aquí somos fans de Ledger y tenemos varios. Eso si, todavía no hemos conseguido que nos cedan un Ledger Nano X, y mucho menos esperamos un Ledger Stax. Por ahora nos contentamos con el Ledger Nano S Plus.
Ledger SAS es también el principal proveedor de soluciones empresariales en lo que se refiere a servicios con su solución Ledger Enterprise, algo menos conocido para la mayoría de nosotros.
Charles Guillemet es el CTO de Ledger y ha escrito un artículo muy interesante sobre Account Abstraction, en adelante AA. Lo que Charles piense sobre AA es algo que todos debemos escuchar, muy probablemente sea un viaje al futuro sobre lo que nos espera.
¿Cómo podría afectar la “Account Abstraction” al paisaje criptográfico?
Charles Guillemet, CTO de Ledger, explora cómo el concepto de "Account Abstraction" mejorará radicalmente la experiencia del usuario en el ámbito criptográfico y por qué las hardware wallet servirán como raíces fundamentales de confianza en este nuevo paradigma.
La revolución global de internet ha traído consigo una innegable ola de digitalización que ahora se extiende al propio concepto de propiedad con el surgimiento de las tecnologías blockchain. A medida que navegamos por esta transición de una era de Internet a la siguiente, de Web2 a Web3, la fricción/dificultad para los usuarios parece intensificarse. Las interacciones en blockchain siguen siendo complejas y primitivas; carecen de seguridad y facilidad de uso, especialmente en lo que respecta a la gestión de cuentas y accesos, lo que disuade a demasiadas personas de entrar en el campo de las criptomonedas.
La "Account Abstraction", una tecnología habilitada por blockchain que permite a las personas utilizar contratos inteligentes como sus cuentas y establecer sus propias reglas flexibles para la gestión de billeteras, es una promesa significativa para aliviar esta fricción e inculcar reglas mejoradas de usuario y medidas de seguridad en el espacio criptográfico.
En este artículo, profundizaré en el concepto de “Account Abstraction” y exploraré cómo podría sustentar el futuro de las tecnologías blockchain.
Externally Owned Account (EOA):
Para comprender completamente las tecnologías de “Account Abstraction”, es necesario captar el paradigma inicial de implementación de las blockchains, arraigado en lo que comúnmente llamamos "Externally Owned Account" (EOA, por sus siglas en inglés).
Una EOA funciona con usuarios generando pares criptográficos de claves: una clave pública para crear direcciones y una clave privada que permite a sus propietarios controlar una cuenta. Dentro del marco de la EOA, el firmante y la cuenta son la misma entidad. Una vez que se genera el par de claves, los usuarios demuestran la propiedad de la dirección calculando una firma digital para ejecutar transacciones. El consenso descentralizado valida estas transacciones verificando que la firma sea correcta y que efectivamente se haya calculado utilizando la clave privada que corresponde a la dirección dada.
La EOA está en el núcleo del diseño original de Bitcoin y Ethereum. A pesar de ser bastante elemental, este mecanismo es increíblemente eficiente para que una red de usuarios seudónimos transfiera valor en un entorno sin permisos. Sin embargo, su diseño es limitante cuando se trata de implementar características mejoradas como gobernanza, mecanismos de recuperación o ejecución de código de manera más general.
Algunos protocolos de blockchain importantes ya incluyen casos de uso de este tipo.
El caso de Bitcoin:
Bitcoin tiene un lenguaje de programación limitado (a propósito) que permite que su protocolo aplique reglas en cadena cuando interactúa con cuentas. Por ejemplo, el lenguaje de script de Bitcoin permite a los usuarios crear billeteras multisig que aplican reglas de gasto sobre el UTXO (salida de transacción no gastada) del usuario.
Además, los bloqueos temporales pueden implementarse también. Por ejemplo, en Bitcoin, es posible crear una billetera multisig que implementa las siguientes reglas, como se muestra en la ilustración a continuación:
Hay 3 firmantes registrados en una billetera determinada.
Se requieren 2 firmas de un total de 3 para mover fondos.
Ningún fondo puede moverse antes de un bloque específico.
Este tipo de funcionalidad es parte de lo que hace que Bitcoin sea versátil y permita a los usuarios establecer reglas personalizadas para sus fondos, mejorando así la seguridad y la gestión de sus activos.
El caso de Ethereum:
En Ethereum, el principio de diseño es diferente, ya que la visión original era crear una máquina de cómputo descentralizada y sin confianza. A diferencia de Bitcoin, la semántica del lenguaje es Turing completo, lo que permite realizar fácilmente cualquier tipo de cálculo, incluida la ejecución de programas arbitrarios (contratos inteligentes) que se ejecutan en cadena y proporcionan cómputo confiable. Estos contratos inteligentes también permiten diseños mejorados e innovaciones increíbles, como los Automated Market Makers (AMM). Sin embargo, el lenguaje de Ethereum conduce a problemas de indecidibilidad, pero eso es otra historia.
Uno de los principales límites del diseño de Ethereum es el hecho de que todas las ejecuciones de contratos inteligentes deben originarse desde una "Externally Owned Account" (EOA). Por ejemplo, es imposible crear un contrato inteligente independiente que se ejecute por sí mismo en cada bloque. Hacerlo requeriría una EOA que inicie transacciones y pague por la ejecución de gas en cada bloque.
La implementación de contratos inteligentes en cadena: algunas ideas interesantes
El aprovechamiento de un diseño sofisticado de contratos inteligentes para la gobernanza en cadena ya se ha implementado de diversas formas.
Gnosis Safe:
Plataformas criptográficas como Gnosis Safe han hecho un gran trabajo al proporcionar un multisig en cadena que permite a los usuarios establecer un nivel mínimo de reglas de gobernanza sobre una cuenta.
Con Gnosis Safe, varias partes controlan conjuntamente una billetera de Ethereum y establecen reglas y condiciones personalizadas para las transacciones, como requerir un número mínimo de firmas o aprobaciones antes de la ejecución de una transacción. Los diferentes firmantes pueden personalizar la configuración de seguridad según sus preferencias. Por ejemplo, pueden establecer límites de gastos diarios, habilitar la integración de billeteras de hardware para una seguridad adicional o requerir múltiples niveles de autenticación para transacciones específicas. Estas cuentas inteligentes son controladas por varias "Externally Owned Account" (EOA) que emiten firmas válidas en cadena y luego desencadenan la transacción de tokens que se encuentra en el contrato inteligente.
Threshold Signature Schemes (TSS): gobernanza fuera de cadena con tarifas mínimas:
Investigaciones recientes en criptografía se centraron en la creación de esquemas de firmas de umbral (también conocidos como esquemas de firmas de umbral o computación multiparte (MPC)) para implementar la parte de autorización múltiple de la gobernanza, fuera de cadena.
Esta idea tiene ventajas interesantes. En particular, es compatible directamente con el modelo de EOA y minimiza las tarifas.
Algoritmo de Firma Digital de Curva Elíptica (ECDSA): seguro, pero con fuertes desventajas:
Las blockchains de Ethereum y Bitcoin utilizan un esquema de firma digital de curva elíptica (ECDSA) para las transacciones.
Sin embargo, a diferencia de la firma de Schnorr, ECDSA no es probablemente seguro bajo la dificultad del DLP (Logaritmo Discreto) y el Modelo del Oráculo Aleatorio. Además, ECDSA no se creó para admitir nativamente Esquemas de Firmas de Umbral, lo que lleva a diseños complicados. Más específicamente, la agregación de firmas de otros esquemas de firmas es probablemente segura, mientras que la de ECDSA no lo es. Las ecuaciones de Esquemas de Firmas de Umbral sobre ECDSA son complicadas, lo que lleva a problemas de implementación regulares. Por último, pero no menos importante, actualmente no hay un esquema de TSS que se ejecute en enclaves seguros, lo que lleva a peligrosas compensaciones de seguridad.
"Account Abstraction”: ¿el cambio real que necesita la criptografía?
La gran novedad introducida por el concepto de “Account Abstraction” es el uso de contratos inteligentes en cadena para implementar la billetera y las reglas de gobernanza en torno a ella. Estas ideas ya se han implementado en múltiples cuentas de contratos inteligentes, como Argent, o con gobernanza mínima mediante multisig en cadena, como Gnosis Safe.
Se ha avanzado mucho en esta área en los últimos meses y años, y se han realizado algunos intentos de estandarización. El estándar reciente que ha tenido mucho impulso se conoce como ERC-4337. Este estándar proporciona un marco integral para implementar diferentes tipos de operaciones con una gobernanza flexible y específica.
Más específicamente, ERC-4337 resuelve las especificidades técnicas de la implementación de la Abstracción de Cuentas en un contexto de blockchain EOA, incluyendo:
Intención de la operación.
Validación de la operación.
Ejecución y pago de tarifas (recuerde que en Ethereum, todas las operaciones son desencadenadas por una EOA que paga las tarifas. Por lo tanto, ERC4337 proporciona un marco de incentivos para que los agrupadores descentralizados desencadenen la ejecución de las operaciones que los usuarios pretenden ejecutar).
El nonce, un mecanismo antirrepetición que era simplemente incremental para las EOAs y que puede ser más sofisticado aquí.
En cuanto a la gobernanza, es posible crear diferentes firmantes y quórum para completar operaciones específicas. Esquemáticamente, el usuario interactuará con su contrato inteligente, el contrato inteligente luego verifica si se cumplen las reglas de gobernanza y finalmente ejecuta las operaciones.
La verificación de la gobernanza puede ser igualmente compleja. Uno de los beneficios de tener esta lógica en funcionamiento en cadena con un lenguaje Turing completo es que es posible crear reglas de gobernanza arbitrarias y implementar la verificación de firmas para cualquier algoritmo. Como se mencionó anteriormente, el esquema ECDSA tiene muchas limitaciones, en primer lugar, no es adecuado para la agregación de firmas (MPC / TSS) y, en segundo lugar, no es compatible con las implementaciones actuales en los enclaves seguros de dispositivos móviles."
Una Experiencia de Usuario Mejorada y Seguridad Flexible:
Gracias a la “Account Abstraction”, es posible realizar varias atomic calls a diferentes contratos en la misma transacción con una cuenta inteligente, lo que conlleva grandes mejoras al navegar por las DApps típicas (por ejemplo, ya no es necesario enviar 2 transacciones distintas para una aprobación de tokens ERC-20 y luego un depósito), así como para la seguridad del usuario (por ejemplo, la resolución de ENS puede realizarse directamente mediante la cuenta de contrato inteligente).
El camino hacia métodos innovadores de Recuperación Social:
Al permitir operaciones complejas a nivel de cuenta, la “Account Abstraction” puede realizar diversos casos de uso avanzados, como el “Social Recovery”. En este escenario, los usuarios pueden designar un grupo de guardianes de confianza que pueden otorgarles acceso a su cuenta en caso de que lo pierdan. EIP 5883 y el más reciente EIP 7093 describen métodos interesantes para implementar estos mecanismos sociales.
Una vez más, los usuarios pueden especificar tanto un umbral como un conjunto de reglas que iniciarán el proceso de recuperación de la cuenta en caso de pérdida de acceso, lo que podría mejorar radicalmente la experiencia del usuario en el ámbito criptográfico.
Firma de agregación BLS/Schnorr:
Como se mencionó anteriormente, otra debilidad de ECDSA es el diseño complicado de la firma de umbral. A diferencia de ECDSA, BLS y Schnorr han sido diseñados para admitir el esquema de firma de umbral, y estos estándares son esencialmente aditivos. En resumen, es posible calcular una firma válida agregando varias firmas parciales con sólidas garantías de seguridad.
La implementación de firmas BLS o Schnorr podría permitir cierta gobernanza de tokens mientras se minimizan las tarifas en la verificación por parte del contrato inteligente (una verificación en lugar de una verificación por cada firma). Este mecanismo de agregación se describe e implementa opcionalmente como parte del estándar EIP 4337.
¿Qué lo siguiente en “Account Abstraction”?
El caso de las Passkeys:
La “Account Abstraction” compite directamente con las billeteras de software en el contexto de las EOA. El modelo de seguridad de las Software Wallet es muy débil, ya que cualquier software malicioso puede drenar los fondos de los usuarios debido a su conectividad a Internet inherente y, en general, su amplia superficie de ataque. Las Software Wallet no pueden realmente mejorar esta situación, ya que los diseños basados en SoC (System On Chip) (teléfonos inteligentes) son muy heterogéneos y no todos contienen un “elemento seguro - secure element”.
Cuando sí contienen un “elemento seguro - secure element”, los desarrolladores no pueden cargar su propio código para implementar firmas de Ethereum/Bitcoin. En este contexto, simplemente NO es posible aprovechar las únicas características de seguridad contenidas en los teléfonos de alta gama.
Al incorporar la lógica de la “Account Abstraction”, los desarrolladores pueden acceder a una implementación de firmas digitales en un “elemento seguro - secure element”. Esto incluye WebAuthn, que está disponible de manera inmediata a nivel del sistema operativo a través del estándar de “Passkeys”.
También es posible establecer una regla en cadena en la que las firmas provengan de las Passkeys de los usuarios. Estas claves de pase utilizan una curva elíptica diferente a la que se usa en la cadena de Ethereum, pero como la verificación de la firma se puede implementar en el propio contrato inteligente, este mecanismo se vuelve factible.
En cuanto a la experiencia del usuario (UX), los usuarios pueden beneficiarse de una amplia integración dentro de los ecosistemas de Apple, Google y Microsoft. También proporciona un mejor nivel de seguridad que una Software Wallet completa. Además, el contrato inteligente puede aplicar varios mecanismos de gobernanza y seguridad en cadena. Por ejemplo, cada transacción puede estar protegida por un firewall Web3 que se implementa fuera de la cadena y autoriza al contrato inteligente a ejecutar una transacción específica. Este tipo de mecanismo permite una seguridad flexible de acuerdo con el perfil de riesgo del usuario.
Con la premisa de “La seguridad lo primero”, una configuración como esta (“Account Abstraction” como autentificador de “Passkeys”) ofrece garantías mejores que las Wallets móviles actuales. Los teléfonos inteligentes modernos pueden utilizar Trustzone para implementar “Passkeys”. Sin embargo, el panorama actual de la implementación de claves de pase no es satisfactorio por las siguientes razones:
Es probable que las “Passkeys” se implementen en modo completamente de software para Android e iOS. No aprovechan el “elemento seguro - secure element” incorporado (¿aún?).
Los teléfonos inteligentes no implementan una Interfaz de Usuario de Confianza y el marco de “Passkeys” no proporciona la información necesaria a los usuarios cuando firman, lo que significa que podrían dar su consentimiento para transacciones que no entienden.
Esta situación destaca la necesidad de una mayor seguridad y transparencia en las implementaciones de “Passkeys” y resalta cómo la “Account Abstraction” podría mejorar significativamente la seguridad y la experiencia del usuario en el ámbito de las criptomonedas.
La “Account Abstraction” y la importancia de las Hardware Wallets como fuentes de confianza
El concepto de “Account Abstraction” potencia la gobernanza detallada de diversos activos dentro de un contrato inteligente. Cuando se utiliza una billetera para microtransacciones, estas reglas de gobernanza permiten la ejecución fácil de transacciones de bajo valor. Por otro lado, para transacciones de mayor valor, sigue siendo fundamental un nivel más alto de seguridad, lo que convierte a las Hardware Wallet en la elección indiscutible.
Por ejemplo, la “Account Abstraction” habilitará:
Dinero de bolsillo/Transacciones del día a día, que se puede gastar utilizando Passkeys en cualquier teléfono inteligente.
Transacciones de mayor valor, todas requerirán una firma segura de Hardware Wallet y un firewall Web3.
Gestión de ahorros y de identidad, que requerirá una firma de Hardware Wallet + Passkey + bloqueo temporal + firewall Web3.
A medida que continúen desarrollándose, estas reglas de gobernanza deberán implementarse con las Hardware Wallet como la raíz fundamental de confianza, ya que estos dispositivos ofrecen seguridad y propiedad inquebrantables. De hecho, si bien la “Account Abstraction” cambia el modelo de seguridad, la wallet en su conjunto todavía necesita garantías de seguridad sólidas. El diseño de las reglas de gobernanza tiene una importancia fundamental desde una perspectiva de seguridad, especialmente en la protección de las claves responsables de su modificación. Además, los diferentes firmantes que pueden interactuar con la capa de “Account Abstraction” todavía necesitarán ciertas formas de secretos (claves privadas) para autenticarse. Proteger estos secretos y proporcionar al usuario toda la información necesaria para dar su consentimiento a cualquier interacción en blockchain sigue siendo crucial, incluso en un marco de “Account Abstraction”.
Reflexiones Finales:
Como se exploró anteriormente, el paradigma de EOA (Externally Owned Account) sigue siendo algo rudimentario. En contraste, la capacidad de la “Account Abstraction” para hacer cumplir reglas complejas en cadena es probable que se convierta en un cambio radical para los usuarios de criptomonedas. Interesantemente, el reciente progreso en torno al EIP 4337 nos acerca a este cambio significativo.
Por supuesto, se presentan varios desafíos.
Uno de estos desafíos es que la propia cadena de bloques ejecuta el modelo de gobernanza flexible de la “Account Abstraction”, lo que significa que la ejecución conlleva costos elevados en comparación con las transacciones regulares de EOA. En la capa 1 de Ethereum, la cadena no es muy escalable y, en consecuencia, la ejecución es bastante costosa. Sin embargo, en las capas 2 escalables, la “Account Abstraction” podría convertirse en la opción predeterminada en la que los usuarios definan reglas de gobernanza complejas que se hacen cumplir mediante el consenso de la capa 2 y se anclan en la capa 1 de Ethereum.
Otro desafío es la necesidad fundamental de crear una forma estándar de interactuar con los marcos de “Account Abstraction”, hasta ahora centrados en cadenas de EVM. Estas billeteras genéricas ofrecen una amplia gama de posibilidades, incluida una alta flexibilidad. Sin embargo, sin estandarización, también podrían permanecer como propietarias, lo que a su vez podría desafiar la adopción masiva.
De hecho, es probable que seamos testigos de un futuro en el que el paradigma de la “Account Abstraction” podría convertirse en una característica fundamental de las cadenas de EVM, mientras que la interacción de EOA podría desempeñar un papel fundamental en otras redes de blockchain, incluido Bitcoin, aunque un panorama de protocolos fragmentados no sea deseable para los usuarios. También podemos anticipar que estos cambios, impulsados por la “Account Abstraction”, finalmente se integrarán a nivel de la cadena de bloques. Una cosa es segura: la “Account Abstraction” pertenece al futuro de la cadena de bloques.
Artículo original publicado en el Blog de Ledger y enlace al hilo de X publicado por Charles Guillemet.
Gracias por la traducción!!!