¿Qué es la abstracción de cuentas?

Cada cuenta de Ethereum implementa cinco funcionalidades:

• Autenticación
• Autorización
• Protección de repetición
• Pago de gasolina
• Ejecución

Una EOA los implementa de forma codificada:

• La autenticación y la autorización están agrupadas: una clave ECDSA inmutable demuestra la identidad y otorga plena autoridad.
• La protección de repetición es un simple nonce: un contador que aumenta monótonamente.
• El pago del gas se realiza directamente desde el saldo ETH de la EOA.
• Ejecución: una única llamada a un único destino.

La abstracción de cuentas significa agregar lógica programática a estas cinco funcionalidades:

• Autenticación: cualquier forma de demostrar la propia identidad.
• Autorización: cualquier política de acceso.
• Protección de reproducción: orden de transacciones desacoplada de la protección de reproducción.
• Pago de gas: pago de gas desacoplado de la propia cuenta.
• Ejecución: cualquier lógica de ejecución.

Ejemplos de casos de uso de abstracción de cuentas

• Diferentes esquemas de firma
  • secp256r1 (enclave seguro, claves de acceso)
  • Schnorr
  • BLS
  • Tant-cuántico
  • Pruebas ZK (p. ej. zkemail)
• Rotación de claves
  • Reemplazar claves comprometidas
  • Cambio de Deadman para herencia (la clave se activa si la cuenta está inactiva durante un año)
• Diferentes políticas de acceso
  • multifirma
  • Acceso basado en roles
  • claves de sesión específicas de dapp
  • Recuperación social
• Diferentes esquemas de protección de repetición
  • Transacciones paralelas de diferentes entidades
  • Transacciones futuras prefirmadas que serán enviadas por terceros
  • Canal administrativo
• Abstracción de gas
  • Patrocinio de gas por parte de terceros.
  • Pago con activos distintos de ETH
  • Privacidad: reclamos anónimos de lanzamiento aéreo o retiros de paquetes acumulativos o mezcladores de ZK
• Abstracción de ejecución
  • Agrupar varias llamadas a múltiples destinos (p. ej. aprobar+transferirDe)
  • Atomicidad
  • Mejoras de UX específicas de dapp.

ERC-4337 vs EIP-3074: falsa dicotomía

EIP-3074 tiene como objetivo abstraer la ejecución sobrecargando el EOA con lógica de ejecución arbitraria a través de invocadores. Tiene una propiedad única: ampliar las capacidades de un EOA sin tener que migrar activos a una nueva cuenta. No es necesario abordar cuestiones como el acceso descentralizado porque la ejecución no lo afecta. Las otras cuatro funcionalidades sí lo hacen, pero están fuera del alcance de EIP-3074.

ERC-4337 tiene como objetivo abstraer la cuenta completa: las cinco funcionalidades. Es un problema más difícil de resolver si se quiere preservar la descentralización y la resistencia a la censura. El objetivo de ERC-4337 es mitigar el DoS y los vectores de ataque dolorosos habilitados al abstraer las primeras cuatro funcionalidades sin recurrir a una infraestructura centralizada. Como ERC, no puede ampliar las capacidades de una EOA y requiere migrar a una cuenta inteligente.

La superposición entre los dos métodos es mínima: solo abstracción de ejecución.

Además, cada método tiene como objetivo resolver problemas que el otro no resuelve: EIP-3074 tiene como objetivo servir a los EOA existentes y mantener las cosas lo más simples posible. ERC-4337 tiene como objetivo proporcionar una abstracción de cuenta completa sin sacrificar las propiedades centrales de Ethereum, como la descentralización.

Si uno insiste en comparar ERC-4337 con una propuesta anterior, la más cercana es EIP-2938, no EIP-3074. EIP-2938 fue un gran avance en la abstracción de cuentas, la primera propuesta en darse cuenta de la dificultad de mitigar DoS en un mempool AA. ERC-4337 resuelve ciertos problemas que EIP-2938 no resolvió, pero una comparación completa está fuera del alcance de este documento.

¿Qué pueden resolver tanto ERC-4337 como EIP-3074?

Ambos resuelven la abstracción de ejecución y, por lo tanto, habilitan la última categoría de los casos de uso anteriores:

• Agrupar múltiples llamadas a múltiples destinos
• Atomicidad
• Mejoras de UX específicas de dapp.

¿Qué puede hacer EIP-3074 que ERC-4337 no puede hacer?

• Agregue una funcionalidad de ejecución compleja a los EOA existentes.
  • ERC-4337 no puede agregar funcionalidad a los EOA porque es un ERC.
• Simplicidad y mejor eficiencia del gas cuando solo se necesita ejecución-abstracción.
  • La abstracción completa de la cuenta agrega complejidad que no es necesaria para la abstracción de la ejecución.

¿Qué puede hacer ERC-4337 que no pueda hacer EIP-3074?

• Admite cualquier cadena EVM desde el día 1. No hay cambios de consenso.
  • EIP-3074 tendría que ser adoptado por cada cadena mediante un cambio de consenso.
• Innovación sin permiso
  • Las billeteras solo permitirán invocadores EIP-3074 incluidos en la lista blanca. Cualquiera puede crear y utilizar cuentas ERC-4337.
• Abstracción completa de la cuenta: todos los casos de uso anteriores, sin sacrificar la descentralización:
  • Diferentes esquemas de firma.
    • EIP-3074 utiliza ECDSA. El EIP menciona un camino futuro para pasar a un esquema diferente, pero siempre que la EOA respete la clave ECDSA, un invocador no puede evitar que se use directamente.
  • Rotación de claves.
    • Con EIP-3074, la EOA todavía tiene una clave irrevocable.
  • Diferentes políticas de acceso
    • La clave ECDSA puede omitir al invocador y realizar cualquier operación en la cuenta. Sin control de acceso granular.
  • Diferentes esquemas de protección de repetición
    • La cuenta sigue siendo una EOA y utiliza un nonce unidimensional.
  • Abstracción de gas
    • La cuenta paga su propio gas, con ETH.
    • Se podría construir un sistema de extracción de gas sobre EIP-3074, utilizando un relé para enviar metatransacciones en nombre de la cuenta. Sin embargo, proteger dichos relés contra DoS y duelo es un desafío, por lo que probablemente obtendrán permiso. La mayor parte de la complejidad del ERC-4337 se debe a que esos retransmisores (paquetes) no tienen permiso.

¿Pueden EIP-3074 + EIP-5003 hacer lo que hace ERC-4337?

EIP-5003 complementa EIP-3074 al permitir que la EOA revoque su clave ECDSA y se convierta en un contrato inteligente. Como contrato, puede abstraer el resto de las funcionalidades de la cuenta, por ejemplo sustituir ECDSA por una firma diferente, rotar claves, aplicar políticas de acceso, etc. En ese sentido, es algo equivalente a propuestas como EIP-6913 y EIP-7377, pero es superior a EIP-7377 porque como código de operación puede utilizar un sistema de extracción de gas para la migración misma.

Una vez que el EOA se convierte en un contrato inteligente, ya no se pueden realizar transacciones directamente y es necesario acceder a él a través de otro EOA. Esto presenta el desafío que ERC-4337 está diseñado para resolver. El usuario tiene dos formas de realizar transacciones con la cuenta después de la migración:

1. Mantenga otra EOA financiada para realizar transacciones con la cuenta y firme cada transacción dos veces. Esto anula el valor de la abstracción de cuentas y da como resultado una mala experiencia de usuario.
2. Utilice un relé que mantenga un EOA financiado, ponga las transacciones en cadena y la cuenta lo reembolse. Proteger un relé de este tipo contra DoS y duelo es más difícil de lo que parece, por lo que algunos proyectos ejecutan un relé autorizado. Esto resulta en una pérdida de descentralización y resistencia a la censura.

La forma de descentralizar el acceso a la cuenta posterior a la migración es aplicar ciertas restricciones hasta que la cuenta pague el combustible. Este enfoque fue adoptado tanto por EIP-2938 como por ERC-4337. El<a href="https://notes.ethereum.org/ @yoav /unified-erc-4337-mempool">ERC-4337 mempool ofrece una forma descentralizada de realizar transacciones con la cuenta.

TL;DR: No, simplemente resalta la necesidad de ERC-4337.

Advertencia: la migración EOA se considera perjudicial

Es tentador para los usuarios existentes de EOA migrar a una cuenta inteligente local en lugar de transferir activos. Sin embargo, conlleva ciertas vulnerabilidades, algunas de las cuales no pueden mitigarse.

¿Qué podría salir mal si la clave EOA se ve comprometida después de haber sido revocada?

1. La clave sigue siendo válida en otras cadenas (incluidas cadenas futuras que ni siquiera existen en el momento de la migración). Se puede utilizar para reclamar la misma cuenta en otras cadenas y transferir cualquier activo enviado a la cuenta en estas cadenas.
2. Los sistemas fuera de la cadena, como el proceso de inicio de sesión de las interfaces dapp, verifican las firmas. Muchos de ellos admiten EIP-1271 para firmas de contratos inteligentes, pero solo lo prueban si falla ecrecover. La clave podría usarse para comprometer la cuenta en estos sistemas.
3. Se puede utilizar en cadena (en la misma cadena donde ha sido revocado) para firmar autorizaciones de permisos. Si la cuenta contiene tokens ERC-20 que admiten permisos, estos tokens pueden ser robados usando la clave revocada.
4. Los puentes entre cadenas a menudo verifican una firma durante el retiro. Si la cuenta envía fondos a otra cadena a través de dicho puente, la clave revocada puede usarse para retirar los fondos del otro lado.

El usuario podría quemar la clave privada después de la migración y esperar que no queden copias, pero entonces el usuario tampoco podrá reclamar la misma dirección en otras cadenas.

Por lo tanto, la migración se debe utilizar como último recurso cuando existe una razón importante para conservar la dirección anterior. De forma predeterminada, es mejor implementar cuentas nuevas con CREATE2 en lugar de migrarlas desde un EOA, para que no estén vinculadas a una clave EOA en otras cadenas.

La comunidad tiende a enfatizar demasiado la importancia de la migración de EOA porque la mayoría de los usuarios actuales tienen EOA. Los próximos mil millones de usuarios podrían comenzar con una cuenta inteligente y no tener que migrar desde una EOA. Nosotros, los usuarios actuales de EOA, somos una pequeña fracción de eso. La migración puede ser importante por un tiempo para que los usuarios actuales migren. Se convertirá en un flujo poco utilizado cuando la abstracción de cuentas sea la norma.

¿Existe sinergia entre ERC-4337 y EIP-3074?

Sí, podrían <a href="https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy"> combinarse de maneras interesantes. Si una cadena adopta EIP-3074, los proyectos que utilizan ERC-4337 podrían utilizarlo para su beneficio.

RIP-7560: Un camino prometedor para el futuro de la abstracción de cuentas

Tanto EIP-3074 como ERC-4337 son pasos para obtener algunos de los beneficios de la abstracción completa de cuentas nativas. El primero se centra en obtener todos los beneficios de la abstracción de ejecución y el segundo se centra en obtener todos los beneficios de la abstracción de cuentas en todas las cadenas EVM, pero de una forma no nativa que es menos eficiente.

Una cadena que desee que sus usuarios se beneficien de la abstracción completa de cuentas nativas podría adoptar RIP-7560. Utiliza la misma arquitectura de cuenta y mempool que ERC-4337 pero funciona de forma nativa a nivel de protocolo.

No es necesario adoptar RIP-7560 desde el día 1, y las cuentas existentes podrán migrar a él en las cadenas que decidan adoptarlo en cualquier momento en el futuro:

• Las cuentas ERC-4337 podrán migrar a RIP-7560 sin cambiar su arquitectura, cambiando su implementación para confiar en la dirección de punto de entrada especial definida en RIP-7560. Una cuenta puede ser compatible con ERC-4337 y RIP-7560 con poco esfuerzo, por lo que ni siquiera es necesaria una migración.
• Es posible que EOA pueda migrar directamente a RIP-7560 sin pasar por ERC-4337 o EIP-3074. RIP-7560 ya admite la extracción de gas para EOA. Un RIP futuro podría permitir que la EOA establezca su código, ya sea usando un código de operación como SETCODE (EIP-6913) o AUTHUSURP (EIP-5003), o agregando un subtipo TransactionType4 similar a EIP-7377. Este código de operación/subtipo podría ser utilizado por un contrato de migración que se llama en la transacción Tipo-4 (RIP-7560). Sin embargo, se desaconseja la migración de EOA .

RIP-7560 necesita sus comentarios

Estamos recopilando comentarios sobre RIP-7560 antes de proponer su consagración. Si está interesado en la abstracción de cuentas nativas, revise las relaciones públicas o únase a la discusión.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [https://notes.ethereum.org/@ yoav/erc-4337-vs-eip-3074-false-dichotomy@yoav]. Todos los derechos de autor pertenecen al autor original [@yoav]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Sanv Nurlae y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Sanv Nurlae. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.