EIP-3074 se convirtió en el tema más candente de la noche a la mañana, ya que se autorizó su inclusión en el próximo hard fork de Ethereum (Pectra/Petra). Sin embargo, ¿a qué se debe tanto revuelo y cómo afectará a Ethereum y al ecosistema EVM? En este artículo exploraremos esta propuesta, responderemos preguntas frecuentes y disiparemos algunos mitos y malentendidos. Vamos a sumergirnos, ¿de acuerdo?
Resumen de EIP/ERC de abstracción de cuentas
Para fortalecer su comprensión de la abstracción de cuenta, necesita saber que el 99% de las veces, cuando alguien dice "Abstracción de cuenta", se refiere a "cuentas (de contrato) inteligentes", que es cuando la cuenta se basa en un código de contrato en lugar de un única clave privada. Aún puede autenticarse mediante una única clave privada, como es el caso la mayor parte del tiempo (esto es importante más adelante), pero también puede ser una billetera con múltiples firmas, como es el caso de Safe.
El significado original de "abstracción de cuenta" era "permitir que los contratos inteligentes inicien transacciones", pero desde entonces ha cambiado a "todas las características que habilitan las cuentas de contratos inteligentes".
Las cuentas de contrato inteligente habilitan estas funciones y más
Abstracción de gas: dApps que patrocinan el gas, el usuario paga el gas en diferentes tokens ERC20, o incluso paga por adelantado el gas, lo cual es excelente para la incorporación entre cadenas.
Esto es excelente para la privacidad y OpSec porque elimina el doxxing al pedirle a sus amigos que agreguen fondos a su cuenta con ETH MATIC, cualquiera que sea la moneda nativa de la cadena/rollup, o peor aún, retirarse de los intercambios.
Lotes de transacciones: o agrupar múltiples acciones en una sola transacción. Esto es fantástico tanto para la seguridad como para la eficiencia del gas.
Seguridad: Resolución de aprobaciones ERC-20. Como efecto secundario del procesamiento por lotes, podemos realizar una aprobación de cantidad exacta junto con cada acción que la requiera, haciendo desaparecer el problema de aprobación. ¿Por qué? Porque no necesitamos aprobaciones infinitas/sobrantes, y no necesitamos una segunda firma para la aprobación.
Criptografía personalizada: habilitación de nuevas curvas criptográficas, WebAuthn, enclave seguro de iOS, seguridad cuántica y más.
Rotación de claves y recuperación de cuentas: cambiar las claves privadas de una cuenta existente o recuperar una cuenta mediante esquemas como la recuperación social de Argent.
¿Notas algo? Todos ellos ayudan a la seguridad de alguna manera.
Volvamos a los ERC.
Generalmente, todos los ERC relacionados con la abstracción de Cuentas afirman que esas características son su motivación, pero no necesariamente las proporcionan; simplemente ayudan a allanar el camino para que esas características se generalicen.
Analicémoslo. Los grandes ERC resuelven distintos problemas:
Iniciación de transacciones: la capacidad de los contratos para iniciar transacciones.
Nativo: tipo de transacción especial dentro del protocolo que puede originarse a partir de un contrato inteligente. Incluye ERC-2938, posteriormente reemplazado por RIP-7560
Emulado: ERC-4337 está "emulado" en el sentido de que las transacciones todavía son iniciadas por una EOA. Esto no significa que el usuario deba conocer esta EOA. Este EOA es controlado y operado por el agrupador.
Conversión de usuarios existentes: aquí es donde entra en juego EIP-3074 (y su compañero más pequeño, ERC-5003)
EIP-3074 permite delegar el control de un EOA EXISTENTE a un contrato inteligente. El contrato inteligente puede controlar este EOA y realizar llamadas desde su dirección, pero no puede iniciar transacciones. Esto es importante porque todavía tenemos que resolver el problema de inicio de transacciones.
ERC-5003 permite que una EOA se convierta "completamente" en una cuenta de contrato inteligente, gracias a la revocación de la clave privada original que actúa como una clave maestra para esta EOA.
Firmas: Los contratos normalmente no pueden firmar firmas. Pero en cierto modo pueden... pueden definir una lógica que defina cuál es una firma válida para ese contrato. Por ejemplo, una billetera de contrato inteligente que sea multifirma entre Bob y Alice definirá una firma válida como isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature). Esto debe definirse en el código del contrato.
ERC-1271 define una interfaz para que esto suceda.
ERC-6492 lo amplía para admitir cuentas de contratos inteligentes aún no implementadas: esto permite la misma dirección en todas las cadenas sin problemas, al tiempo que permite al usuario firmar mensajes.
Ambos deben ser implementados por dApps para funcionar.
Para crear verdaderamente una experiencia AA, debes resolver todo lo anterior simultáneamente. Es por eso que EIP-3074 no compite con ERC-4337, RIP-7560 ni con ningún otro ERC de abstracción de cuentas.
Si quieres ver todo esto visualmente, te sugerimos esta diapositiva de una charla sobre desmitificación de los ERC de AA.
FUD común EIP-3074 que rompe mitos
Comencemos con el elefante en la habitación. Ha habido tres piezas de FUD relacionadas con EIP-3074:
Permite que las dApps maliciosas drene las billeteras existentes en una sola transacción: es cierto que se puede producir dicha firma, pero no hay ninguna razón o caso de uso para que un proveedor de billeteras permita que las dApps le obliguen a firmar dichas solicitudes. Asegurar esto desde el lado de la billetera es mucho más fácil que asegurar su clave privada, y filtrar una clave privada tiene el mismo efecto.
La cuenta conserva una única clave maestra (la clave EOA original). Hay un ERC adicional que resuelve esto, EIP-5003, también conocido como AUTHUSURP, que permite revocar la clave privada original.
EIP-3074 es una curita que no ofrece los beneficios de AA nativo: EIP-3074 nunca tuvo la intención de competir con propuestas de AA reales como RIP-7560. No es una curita para AA; es un camino migratorio. Todavía necesitamos AA nativo porque, como recordamos antes, no resuelve el problema de inicio de transacciones.
Pros y contras de EIP-3074
Ventaja: crea una ruta de migración muy sencilla para que los usuarios existentes de MetaMask, Trezor, Ledger, etc., experimenten las funciones de abstracción de cuentas en sus cuentas existentes.
Desventaja: sacrifica la rotación de claves. Si bien todas las funciones AA mencionadas anteriormente se pueden habilitar, la rotación de claves se vuelve un poco difícil de alcanzar porque la clave privada original conserva el control sobre la cuenta en todas las redes que nunca se han utilizado, incluso con EIP-5003.
ejercicio mental
Aquí tienes un ejercicio mental que te ayudará a comprender las piezas en movimiento:
Existe una EOA, аlice.eth (0x696969..69), en la red principal de Ethereum. Este EOA es de cadena cruzada por definición, por lo que también existe en todos los paquetes acumulativos y cadenas EVM.
Esta EOA está controlada únicamente por una clave privada A, propiedad de Alice.
EIP-3074 se activa.
Una dApp maliciosa intenta engañar a Alice y le pide que firme una firma AUTH EIP-3074, autorizando un contrato malicioso. La billetera ignora esta solicitud y desconecta la dApp porque está bien implementada y no existe ningún caso de uso para permitir esto desde una dApp.
Alice hace clic en un botón "habilitar la abstracción de cuenta" en su proveedor de billetera (por ejemplo, MetaMask, a través de Snap o Ambire, de forma nativa). La billetera firma una firma AUTH EIP-3074, que autoriza un contrato creado por el proveedor de la billetera que ayuda a realizar procesamiento por lotes, patrocinio de gas, etc.
Este contrato se controla únicamente mediante la clave privada A.
alice.eth ahora está controlado por separado por dos entidades: la clave privada A (en modo EOA) y el nuevo contrato, que en sí mismo también está controlado únicamente por la clave privada A.
Alice ahora puede realizar procesamiento por lotes, pero para patrocinar gas, el proveedor de billetera de Alice debe implementar ERC-4337 o RIP-7560 (si la red lo admite), o un repetidor propietario para que Alice no tenga que usar su ETH ( lo cual es un requisito estricto de la red si desea iniciar una transacción).
Alice decide convertir alice.eth en multifirma, y el proveedor de la billetera indica al contrato que revoque la clave privada A y autorice una multifirma 2/2 de las claves privadas BMobilePhone y BLaptop.
Sin embargo, esto no funciona porque la clave privada A todavía controla Alice.eth: según EIP-3074, la clave privada original conserva el control a pesar de estar delegada en un contrato.
EIP-5003 se activa en Ethereum y permite a alice.eth enviar una instrucción especial a la red a través de su proveedor de billetera para revocar el control de la clave privada A.
alice.eth ahora se convirtió con éxito a multi-sig, pero solo en Ethereum. La clave privada A (propiedad de Alice) aún conserva el control sobre alice.eth en todas las demás redes.
Al final, hemos aprendido algunas cosas:
Hemos hecho algo sorprendente porque, sin EIP-3074, Alice probablemente nunca habría adoptado la abstracción de cuentas.
EIP-3074 no resuelve todo; Todavía necesitamos ERC-4337 y RIP-7560 tanto como ayer.
EIP-3074 no funciona bien con la rotación de claves, incluso si tenemos EIP-5003. Es por eso que todavía necesitamos cuentas inteligentes reales para facilitar casos de uso como firmas múltiples y rotación de claves.
Como nota al margen, creemos que la rotación de claves es demasiado nueva para la mayoría y un poco complicada en un mundo de cadenas cruzadas donde no se tiene el mismo estado entre todos los resúmenes y cadenas. La mayoría de los usuarios parecen apegarse al paradigma de una clave = una cuenta, especialmente con las carteras de hardware, que son lo suficientemente seguras para la mayoría de los casos de uso.
Preguntas más frecuentes
El resto de este artículo tendrá un formato similar a preguntas frecuentes para que podamos abordar mejor algunas de las preguntas más comunes que tiene la gente.
¿Ayuda a MetaMask a salir adelante?
Creemos que las empresas de abstracción de cuentas obtendrán un valor mucho mayor con una experiencia de usuario de incorporación más sencilla que los titulares al poder ofrecer funciones AA a su audiencia actual.
En otras palabras, "desata" el poder de las carteras AA en todo el mercado al que se dirige, no sólo en los primeros usuarios que desean trasladar sus fondos a una nueva dirección.
Gracias a MetaMask Snaps, muchas empresas de AA se centrarán en construir AA en MetaMask, que es el posicionamiento del cerebro galáctico que nadie, excepto los observadores más astutos, vio venir.
¿Es inseguro el procesamiento por lotes?
Absolutamente no. Aún ves lo que estás firmando. Esto, combinado con la simulación de transacciones, significa que firmar múltiples acciones es tan seguro y, en la mayoría de los casos prácticos, más seguro que firmar una sola acción.
El procesamiento por lotes de transacciones es una de las características más elogiadas de Account Abstraction
¿Esto ayuda a las dApps a adoptar AA? ¿Resuelve problemas de compatibilidad?
Las dApps funcionan con cualquier forma de abstracción de Cuenta con algunas excepciones:
Algunas dApps discriminan las cuentas inteligentes (de contrato)
Algunas dApps no son compatibles con ERC-1271
EIP-3074 resuelve mágicamente ambos problemas: las cuentas aparecen como EOA (no tienen código), por lo que no pueden ser discriminadas. En cuanto a las firmas, los EOA habilitados para AA (a través de 3074) seguirán firmando como EOA, por lo que no hay ningún problema. Funcionará mágicamente con todas las dApps a costa de perder la rotación de claves.
Sin embargo, si la mayoría de las personas eligen EOA habilitadas para AA en lugar de cuentas puramente inteligentes, esto desincentiva a las dApps a no admitir ERC-1271 y ERC-6492, pero ERC-4337 ya ayudó a generar mucha conciencia sobre las propuestas de firma.
¿Qué pasa con la revocación de la clave original?
Puede revocar la clave a través de EIP-5003 (que aún no está previsto en el hard fork).
Un matiz de esto es que esta no es una solución perfecta en un mundo de cadenas cruzadas. La EOA siempre comenzará como una EOA en cada nueva cadena que comience a utilizar, lo que significa que la clave original nunca podrá revocarse realmente. Pero esto se aplica a todas las formas de AA porque los permisos/privilegios originales con los que creó la cuenta son siempre con los que comienza la cuenta en cualquier red nueva.
EIP-3074 funciona mejor al incorporar todas las funciones de AA, excepto la rotación de claves, a los EOA existentes. En otras palabras, si elige habilitar AA para un EOA, siempre quedará atrapado con la clave privada original detrás de este EOA.
¿Mata al AA nativo (RIP-7560)?
No, porque aún necesitas una solución para iniciar la transacción, al menos si quieres pagar el gas en un token diferente al nativo (o necesitas patrocinio de gas).
ERC-4337 es una de esas soluciones que no requiere actualizaciones de protocolo (no es nativa), pero el AA nativo consagrado en el protocolo es inmensamente valioso, ya que resuelve la sobrecarga de gas y la complejidad de ERC-4337.
Pero ser, ¿qué pasa con EIP-7377?
EIP-7377 permite convertir una EOA en una cuenta inteligente. En lugar de permitir que un contrato inteligente controle el EOA junto con el PK original, este EIP permite que un contrato se haga cargo del EOA en una sola transacción.
Puede considerarse una alternativa al EIP-3074 + EIP-5003, pero no ganó tanto impulso.
Pensamientos finales
EIP-3074 no es una curita. Es extremadamente optimista para el futuro de Ethereum y el ecosistema EVM porque pedir a los usuarios que abandonen repentinamente sus cuentas existentes y transfieran todos sus fondos, posiciones de participación, etc., a una nueva cuenta (cuenta de contrato inteligente) eleva significativamente la barrera de entrada.
EIP-3074 proporcionará un nuevo término medio y una incorporación gradual, que es exactamente lo que necesitamos para mejorar drásticamente la UX.
¿Interesado en Ambire? Síganos:
Discordia | X (Twitter) | Reddit | GitHub | Telegrama | Facebook
