Prefacio

El artículo está dividido en dos secciones principales:

En la primera parte, comenzará con la primera propuesta AA de 2015, organizando sistemáticamente el contenido principal de las propuestas de EIP hasta la fecha. Su objetivo es explorar el desarrollo histórico de las propuestas AA y evaluar exhaustivamente las fortalezas y debilidades de cada propuesta.

En la segunda parte, se centrará en comparar la retroalimentación del mercado tras la introducción de EIP-4337 y luego profundizará en el análisis de EIP-7702, que está previsto que se incluya en la próxima actualización de Ethereum. Se espera que esta propuesta, una vez fusionada, transforme significativamente la naturaleza de las aplicaciones en cadena.

EIP-7702 promete cambios revolucionarios, y lo discutiremos en detalle.

1. Antecedentes de la Abstracción de Cuenta

1.1 El significado de la abstracción de cuenta

A finales de 2023, el fundador de Ethereum Vitalik Buterin actualizó una vez más el plan de desarrollo de ETH. Sin embargo, las disposiciones relacionadas con la Abstracción de Cuentas permanecieron sin cambios. El modelo principal actual continúa evolucionando desde EIP-4337 hacia la siguiente fase: Conversión voluntaria de EOA (conversión autoiniciada de cuentas EOA).

https://x.com/VitalikButerin/status/1741190491578810445

Desde el lanzamiento de EIP-4337 hace más de un año (el 1 de marzo de 2023, en WalletCon en Denver, los desarrolladores de la Fundación Ethereum anunciaron que los contratos principales de ERC-4337 habían pasado la auditoría de OpenZeppelin, marcando un hito histórico para su lanzamiento oficial), ha recibido un amplio reconocimiento por parte de los usuarios pero no ha visto una adopción generalizada. Este entorno de mercado paradójico ha acelerado el progreso de EIP-7702, que ahora se ha confirmado que será incluido en la próxima actualización.

1.2 Estado actual del mercado de la abstracción de cuentas

Sin más preámbulos, veamos los datos.

Después de un año y medio de desarrollo, EIP-4337 solo ha acumulado 12 millones de direcciones en cuentas principales de cadena. Lo que es particularmente sorprendente es que en la red principal de Ethereum, solo hay 6,764 direcciones activas. Si bien puede haber problemas con las dimensiones estadísticas, este número sigue siendo muy diferente de los recuentos de direcciones para EOAs y CAs. Para contextualizar, el número de direcciones únicas en la red principal de Ethereum ha alcanzado los 270 millones (fuente: https://etherscan.io/chart/addressError: Texto de origen no válido.

Se puede decir que EIP-4337 no ha tenido un progreso sustancial en la red principal.

(Chart source: https://dune.com/niftytable/account-abstraction)

Sin embargo, esto no disminuye el valor inherente de la Abstracción de Cuenta (AA). Desde el principio, el diseño del EIP-4337 estaba destinado a enfrentar problemas significativos de compatibilidad con versiones anteriores en la red principal. En consecuencia, con varias cadenas de Capa 2 integrando AA nativa, el EIP-4337 ha experimentado un crecimiento sustancial en direcciones en la Capa 2. Por ejemplo, en julio, el número de usuarios activos en las cadenas Base y Polygon alcanzó 1 millón y 3 millones, respectivamente, lo cual es bastante impresionante.

Por lo tanto, no es que el diseño de EIP-4337 esté defectuoso; tiene muchas ventajas que resumiremos sistemáticamente. La situación actual surge de las diferencias entre la red principal y la Capa 2, cada una requiriendo soluciones a medida.

2. ¿Qué es la Abstracción de Cuenta?

La Abstracción de Cuenta puede sonar compleja, pero en esencia aborda el problema de separar la propiedad.

En la arquitectura de la Máquina Virtual Ethereum (EVM), hay dos tipos de cuentas: Cuentas de Propiedad Externa (EOAs) y Cuentas de Contrato. En las EOAs, la propiedad y la autoridad de firma son mantenidas por la misma entidad. La persona con la clave privada no solo es dueña de la cuenta, sino que también tiene el derecho de firmar y transferir todos sus activos.

Esta configuración está determinada por la estructura de transacción de la cuenta de Ethereum. En una transacción estándar de Ethereum, no hay una dirección directa de "Desde" visible. Cuando ocurre una transferencia de fondos, la dirección real desde la que se gastan los fondos se infiere a través de los parámetros VRS (es decir, la firma del usuario).

Esto implica conceptos como la criptografía asimétrica ECDSA y funciones de umbral unidireccionales, pero no entraremos en detalles aquí. Básicamente, la criptografía garantiza la seguridad, lo que lleva a la situación actual en la que la propiedad y la autoridad de firma están combinadas en las EOAs.

El efecto principal de EIP-4337 es agregar un campo de Dirección del remitente a la transacción, lo que permite separar la clave privada y la dirección operada.

Entonces, ¿por qué es tan importante separar la propiedad?

Debido a que el diseño de las Cuentas de Propiedad Externa (EOAs) conlleva varios problemas:

Protección de la clave privada: perder la clave privada (debido a pérdida, piratería o compromiso criptográfico) significa perder todos los activos.

Algoritmos de Firma Limitados**: El protocolo nativo solo admite ECDSA para firmar y verificar.

Alta Autoridad de Firma: Sin soporte nativo para multi-firma (que solo se puede lograr a través de contratos inteligentes), una sola firma puede ejecutar cualquier operación.

Tarifas de transacción: Las tarifas solo se pueden pagar en Ether, que no es compatible con un alto volumen de transacciones.

Privacidad de la transacción: las transacciones uno a uno facilitan el análisis de la información privada del titular de la cuenta.

Estas restricciones hacen que sea difícil para los usuarios promedio usar Ethereum:

Para usar cualquier aplicación en Ethereum, los usuarios deben poseer ETH (y asumir el riesgo de las fluctuaciones del precio de ETH).

Los usuarios necesitan lidiar con una lógica de tarifas compleja, como el precio del gas, el límite de gas y el bloqueo de transacciones (orden de nonce), lo cual puede ser demasiado complicado.

Aunque muchas carteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización del producto, su efectividad ha sido limitada.

La solución radica en implementar la Abstracción de Cuenta, que desacopla la propiedad (Propietario) y la autoridad de firma (Firmante) para abordar estos problemas. Históricamente, han surgido muchas soluciones, convergiendo finalmente en dos enfoques principales.

3. Visión general histórica de las propuestas de abstracción de cuentas

Si bien puede parecer que hay muchas propuestas de EIP que abordan el problema, fundamentalmente, solo hay dos enfoques principales. Los problemas considerados en propuestas anteriores que no fueron aprobadas finalmente han convergido en las soluciones actuales.

3.1 La primera opción es convertir la dirección EOA en una dirección CA

El 15 de noviembre de 2015, Vitalik Buterin propuso una nueva estructura de cuenta en torno a EIP-101, que implicaba el uso de contratos como cuentas. Esto transformaría las direcciones en entidades con solo código y espacio de almacenamiento, cambiaría el soporte de tarifas para que se pagara a través de tokens ERC20 y usaría contratos precompilados para convertir tokens nativos en tokens similares a ERC20 para el almacenamiento de saldos (con características como la autorización delegada). Los campos de transacción se simplificaron para incluir solo to, startgas, data y code)

En retrospectiva, este fue un cambio revolucionario que alteraría drásticamente el diseño subyacente, dando a cada dirección de cuenta su propia lógica de "código", que es esencialmente lo que EIP-7702 busca lograr hoy. Este enfoque también podría habilitar funciones adicionales, como:

Permitir que las transacciones utilicen más algoritmos criptográficos especificados por el código interno de cada dirección para verificación y autenticación.

Proporcionando resistencia cuántica debido a la naturaleza actualizable del código.

Dotar a Ether de las mismas características funcionales que los contratos ERC20, con funciones como la autorización delegada, eliminando la necesidad de gastos de moneda nativa.

Mejora de la personalización de la cuenta, soporte para la recuperación social, SBT (tokens vinculados al alma) y recuperación de claves.

La razón por no avanzar esta propuesta era simple: los pasos eran demasiado ambiciosos. Problemas como colisiones de hash de transacciones y preocupaciones de seguridad no fueron abordados completamente, lo que llevó a su aplazamiento. Sin embargo, muchos de sus beneficios se han convertido en características fundamentales en EIP subsiguientes, incluyendo EIP-4337 y EIP-7702.

Varios EIP intentaron refinar esta lógica más tarde:

EIP-859: Account Abstraction on Mainnet (30 de enero de 2018) tuvo como objetivo abordar problemas de implementación de código. Su función principal era utilizar el códigoparámetro adjunto a transacciones para desplegar billeteras de contrato si el contrato no fue desplegado. También introdujo un nuevo opcode PAYGAS para separar las partes de verificación y ejecución de una transacción.

Aunque no progresó en su momento, esta lógica se ha convertido en un componente clave de EIP-7702, que permite a las direcciones EOA tener capacidades de contrato a través de estructuras de transacción especiales que pueden incluir código.

EIP-7702: Establecer el Código de Cuenta EOA (7 de mayo de 2024) es la clave EIP discutida aquí. Vitalik propuso EIP-7702 como una alternativa a EIP-3074. En consecuencia, EIP-3074 fue abandonada y EIP-7702 está listo para ser incluido en la próxima bifurcación dura ETH Prague/Electra (Pectra). Se discutirán más detalles a continuación.

3.2 El segundo enfoque es permitir que las direcciones EOA impulsen las direcciones CA.

EIP-3074: Agregar los opcodes AUTH y AUTHCALL (15 de octubre de 2020)

Esta EIP introduce dos nuevas opcodes, AUTH y AUTHCALL, en el EVM, permitiendo a los EOAs autorizar contratos para reemplazar su identidad y llamar a otros contratos. En esencia, un EOA puede enviar un mensaje firmado (transacción) a un contrato de confianza (llamado un Invoker). El contrato Invoker puede luego usar los opcodes AUTH y AUTHCALL para enviar la transacción en nombre del EOA.

EIP-4337: Implementación de la Abstracción de Cuentas a través de Pools de Transacciones (29 de septiembre de 2021)

Inspirado por MEV, el valor central de este EIP es que evita cambios en el protocolo de la capa de consenso. El EIP-4337 introduce un nuevo objeto de transacción, UserOperation, que los usuarios envían a un grupo de memoria. Los agrupadores luego agrupan y entregan estas transacciones para la ejecución del contrato, trasladando efectivamente las operaciones de transacción y cuenta de nivel inferior a la capa del contrato.

EIP-5189: Operaciones de cuenta abstractas a través de avalistas (29 de junio de 2022)

Este EIP optimiza EIP-4337 abordando posibles problemas con los agrupadores maliciosos. Introduce un mecanismo para que los fondos respaldados por endosantes eviten ataques de denegación de servicio penalizando a los actores malintencionados.

3.3 Otras propuestas que respaldan la abstracción de cuentas

EIP-2718: Nuevo sobre de tipo de transacción (13 de junio de 2020)

Esta propuesta finalizada define un nuevo tipo de transacción como un sobre para futuros tipos de transacción. Asegura que cuando se introducen nuevos tipos de transacciones, estos puedan distinguirse por un codificación específica, manteniendo la compatibilidad hacia atrás sin afectar a los tipos heredados. Un ejemplo común es EIP-1559, que diferenció las tarifas de transacción con una nueva codificación de tipo de transacción mientras preservaba los tipos heredados.

EIP-3607: Prevenir que las direcciones EOA desplieguen contratos (10 de junio de 2021)

Esta propuesta complementaria aborda el problema de las direcciones de implementación de contratos que entran en conflicto con las direcciones de EOA. Controla los métodos de creación de contratos, evitando que el código se implemente en direcciones ya utilizadas por EOAs. El riesgo es mínimo dada la longitud de 160 bits de las direcciones de Ethereum, aunque teóricamente posible a través de colisiones de claves, requeriría un esfuerzo computacional significativo.

3.4 Comprendiendo el Desarrollo de la Abstracción de Cuentas

Para comprender el valor de la transición a las direcciones de CA, es esencial entender los efectos prácticos de EIP-4337, que puede lograr...

Sin embargo, la desventaja principal de EIP-4337 es que viola el principio de incentivos humanos. Aunque parece ofrecer mejoras, cae en un callejón sin salida en el desarrollo del mercado. Muchas Dapps aún no son compatibles con él, lo que hace que los usuarios rechacen usar direcciones CA. Además, el uso de CAs puede resultar en costos de transacción más altos (por ejemplo, las tarifas de transacción pueden duplicarse en escenarios de transferencia ordinarios), lo que lo hace muy dependiente de la compatibilidad de las Dapps.

Como resultado, hasta la fecha no se ha generalizado en la red principal de Ethereum. El costo es el factor más crucial para los usuarios y debe reducirse. Para reducir verdaderamente los costos de GAS, Ethereum necesitaría una actualización de soft fork para modificar los cálculos de GAS o cambiar el consumo de GAS de los opcodes. Dada la necesidad de un soft fork, ¿por qué no considerar directamente EIP-7702?

4. Análisis exhaustivo de EIP-7702

4.1 ¿Qué es EIP-7702

Se distingue por nuevos tipos de transacciones, que permiten que EOA tenga temporalmente la función de un contrato inteligente en una sola transacción, lo que admite transacciones por lotes, transacciones sin gas y gestión de permisos personalizados en los negocios, sin necesidad de introducir un nuevo opCode de EVM (afectando la compatibilidad hacia adelante).

Permite a los usuarios obtener la mayoría de las capacidades de AA sin implementar contratos inteligentes, e incluso puede proporcionar a un tercero la capacidad de iniciar transacciones en nombre de los usuarios. No requiere que los usuarios proporcionen claves privadas, sino que solo necesita firmar información autorizada.

4.2 Estructura de datos

Definió un nuevo tipo de transacción 0x04. El TransactionPayload de este tipo de transacción es el resultado de la serialización de codificación RLP del siguiente contenido

rlp([

chain_id, //ID de cadena, utilizado para prevenir ataques de repetición.

nonce, // Contador de transacciones para garantizar la unicidad de la transacción.

max_priority_fee_per_gas, //tarifa de transacción 1559

max_fee_per_gas, //1559 transaction fee

gas_limit,

destino, //Dirección de destino de la transacción

valor,

datos,

access_list, //Lista de acceso, utilizada para la optimización de gas en EIP-2929.

lista de autorización,

signature_y_parity, // 3 parámetros de firma, utilizados para verificar la firma de la transacción.

signature_r,

firma_s

]

Lo importante es que el objeto authorization_list se agregue para almacenar el código que el firmante desea ejecutar en su EOA. Cuando el usuario firma la transacción, también firma el código del contrato a ejecutar. Existe como una lista bidimensional, lo que indica que se pueden almacenar múltiples información de operaciones en lotes, realizar operaciones en lotes.

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

4.3 Ciclo de Vida de la Transacción

Fase de verificación 4.3.1

Al comienzo de la fase de ejecución de la transacción, por cada[chain_id, address, nonce, y_parity, r, s]tupla en lalista de autorización:

Use the ecrecoverfunción para recuperar la dirección del firmante a partir de la firma(r, s). Tenga en cuenta que esto utiliza el mecanismo existente de Ethereum, por lo que el algoritmo de firma permanece sin cambios por este EIP. La dirección se recupera usando: autoridad = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s). Esto es similar a cómo el desdela dirección se deriva de las firmas, pero se aplica a la firma de lista específica.

Verifique la ID de la cadena para evitar ataques de repetición en diferentes cadenas.

Compruebe si el autoridadEl código del firmante está vacío o delegado (para confirmar si la transacción es una transacción válida de EIP-7702, con mecanismos de delegación que manejan la ejecución).

Verificar el autoridadnúmero de nonce del firmante para evitar ataques de repetición en las firmas.

Establecer el autoridadcódigo del firmante para0xef0100 || dirección (para evadir las estrategias de prevención de colisiones de EIP-3607).

Incrementar el autoridadnonce del firmante (para evitar la repetición local de la firma).

Agregar el autoridadcuenta del firmante a la lista de acceso (para la transición al almacenamiento en caliente, reduciendo los costos de gas para el acceso).

Fase de ejecución 4.3.2

¿Dónde se ejecutan el código del contrato e las instrucciones operativas?

La nueva versión cambia la forma en que se implementa el código del contrato. En lugar de establecer el código de la cuenta directamente, obtiene el código de lista de autorizacióndirección y la establece como el código de cuenta.

Al ejecutar el código autorizado, cargar el código desde la dirección especificada en el lista de autorizacióny ejecútelo en el contexto de la cuenta del firmante. Esto significa que el código del contrato del usuario se almacena en una dirección específica en la cadena de bloques, en lugar de incluirse directamente en la transacción.

Las instrucciones operativas y los parámetros relacionados se almacenan en el datoscampo de la carga útil de la transacción.

¿Cuál es el valor de EIP-7702?

EIP-7702 introduce un valor significativo ya que cambia fundamentalmente todo el proceso de transacción para las carteras Web3, lo que conduce a una transformación drástica en la experiencia del usuario. Las transacciones ordinarias iniciadas por un EOA (Cuenta de Propiedad Externa) ahora pueden ejecutar múltiples lógicas similares a las ejecuciones de contratos inteligentes, como transferencias por lotes. Esto también afecta los escenarios de CeFi, afectando la identificación de transacciones y las tarifas para retiros y consolidación.

EIP-7702 rompe muchas suposiciones de larga data: rompe la invariante de que el saldo de una cuenta solo puede disminuir debido a transacciones originadas desde esa cuenta. Rompe la invariante de que el nonce de EOA aumenta en 1 después de que la ejecución de una transacción comienza (ahora puede aumentar simultáneamente por múltiples valores). Rompe la lógica protectora que se basa en comparar tx.originymsg.sender, introduciendo riesgos potenciales para muchos contratos existentes. También rompe el hecho de que un EOA en sí mismo no puede emitir eventos, lo que podría afectar la identificación y el monitoreo de ciertos eventos en la cadena. Finalmente, rompe la suposición de que una dirección de EOA siempre recibirá con éxito activos ERC20, 721, 1155 y otros (ya que puede fallar debido al mecanismo de devolución de llamada).

4.5 Comparación entre EIP-7702 y EIP-4337

1. Ventajas de EIP-7702

EIP-7702 tiene varias ventajas. Una de ellas son los costos de gas más bajos, ya que no requiere pasar por el módulo de entrada, reduciendo las operaciones en cadena. Otra es la reducción de los costos de migración de usuario, ya que no es necesario desplegar un contrato en cadena como entidad principal de antemano.

En comparación con EIP-4337, EIP-7702 también admite la ejecución de código delegada y ofrece dos tipos de delegación:

Delegación completa: Esto significa delegar el control total de una operación específica a una dirección concreta. Por ejemplo, un usuario puede delegar la gestión de todos los tokens ERC-20 a una dirección de contrato inteligente, lo que permite que el contrato realice todas las operaciones relacionadas en nombre del usuario.

Delegación protegida: Esto implica agregar restricciones y salvaguardias durante la delegación para garantizar la seguridad y controlabilidad de las operaciones delegadas. Por ejemplo, un usuario puede delegar solo derechos de gestión parciales de tokens ERC-20 a un contrato inteligente o establecer condiciones (por ejemplo, gastar un máximo del 1% del saldo total por día).

2. Desventajas de EIP-7702

La principal desventaja de EIP-7702 es que implica una actualización de bifurcación suave, que requiere consenso de la comunidad para avanzar. Sus cambios son sustanciales y podrían tener un amplio impacto en el ecosistema en cadena. Según una evaluación inicial de Shisi Jun, se han identificado varios desafíos, pero estos desafíos también podrían representar oportunidades de mercado:

El alto grado de libertad dificulta la auditoría, lo que lleva a los usuarios a demandar billeteras más confiables para garantizar la protección de seguridad.

Los cambios en la arquitectura original son significativos. Aunque se pueden distinguir diferentes tipos de transacciones, muchas infraestructuras fundamentales, especialmente los contratos inmutables en cadena, es posible que no sean directamente compatibles.

Si bien EIP-7702 proporciona capacidades de contrato a las direcciones de EOA, el espacio de almacenamiento correspondiente no se puede retener.

El costo de las transacciones individuales es ligeramente mayor debido a un aumento significativo en la sección Calldata. El costo total estimado de una llamada será de 16 (gas)15 (bytes) = 240 (gas) para los costos de calldata, más el costo de 2 de EIP-386015 = 30, and approximately 150 for runtime costs. Therefore, even preparing an account with no operations would increase gas costs by around 500.

“Si el receptor firma un código que carece de una función de recepción, el remitente puede enfrentarse a un DoS al intentar enviar activos.” Ver el caso. Este problema surge cuando EOA A firma algo que no debería tener, un archivo reproducible con una implementación incorrecta (que carece receive()).

La lógica de consolidación y retiro en cadena puede ser inconsistente. Por ejemplo, al transferir tokens ERC-20, si la cuenta receptora tiene código, el contrato de token llamaráonERC20Receiveden la cuenta del destinatario. Si onERC20Receivedsi devuelve o devuelve un valor incorrecto, la transferencia de tokens se revertirá.

Además, si una EOA puede emitir eventos, ¿podría haber algún problema? Algunas infraestructuras pueden necesitar prestar atención a esto.

Estos son solo algunos de los inconvenientes resumidos por Shisi Jun basados en la propuesta actual EIP-7702 y las discusiones en el foro oficial. Un análisis completo requerirá examinar el código de implementación final.

5. Resumen

El artículo puede parecer extenso, pero contiene solo alrededor de 6,000 palabras. Muchas referencias a interpretaciones pasadas de EIP están vinculadas dentro del texto para una exploración más profunda, por lo que no profundizaré en ellas aquí.

Actualmente, parece que la abstracción de cuentas solo se puede colocar en el sexto módulo, que es la etapa final de arreglar todo antes de impulsarlo hacia adelante. El progreso acelerado de EIP-7702 principalmente trae desafíos a la seguridad del sistema. Es previsible que finalmente se implementará. Después de todo, la fusión de Ethereum, que implicó una revisión importante del algoritmo de consenso, ya ha ocurrido. Un nuevo tipo de transacción es relativamente menor en comparación.

Sin embargo, esta vez los cambios son bastante disruptivos, rompiendo múltiples reglas en cadena previamente “imposibles” y alterando la lógica de la mayoría de las DApps. Sin embargo, EIP-7702 agarra firmemente el punto más crucial: reduce significativamente los costos para el usuario. En contraste, EIP-4337 casi duplica los costos de transacción.

Los usuarios siguen siendo direcciones de EOA (Cuenta Poseída Externamente), pero solo invocan y usan la lógica de la CA (Cuenta de Contrato) cuando es necesario, reduciendo así los costos de retención. No es necesario convertirse primero en una identidad de CA en la cadena antes de realizar acciones, lo que significa que los usuarios no necesitan registrarse.

Los usuarios pueden realizar fácilmente múltiples transacciones en paralelo utilizando su EOA, como combinar la autorización para la deducción y ejecutar las deducciones. Esto reduce inherentemente los costos de transacción para los usuarios. Para las DApps, especialmente proyectos que requieren gestión a nivel de empresa en la cadena, como los intercambios, esta optimización es revolucionaria. Si la consolidación por lotes se implementa de forma nativa, los costos operativos básicos de los intercambios podrían reducirse en más de la mitad, beneficiando en última instancia a los usuarios.

Por lo tanto, aunque EIP-7702 introduce muchos cambios, su impacto en el costo por sí solo lo hace digno de estudio y adaptación para todas las DApps. Esta vez, los usuarios están sin duda del lado de EIP-7702.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [PANews]. Todos los derechos de autor pertenecen al autor original [Catorceavo Señor]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen asesoramiento de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.