Análisis profundo del pasado y futuro de la abstractización de cuentas de Ethereum

Este artículo se divide en dos partes principales:

Primero, comenzando con la primera propuesta AA de 2015, el sistema organizará el contenido principal de las propuestas EIP hasta la fecha, revisará el proceso histórico de las propuestas AA y evaluará de manera integral las ventajas y desventajas de cada opción.

En segundo lugar, se comparan las críticas al mercado que enfrenta EIP4337, y se analiza en profundidad el EIP7702 que se incluirá en la próxima actualización de Ethereum; esta propuesta, una vez fusionada, cambiará por completo la forma de las aplicaciones en la cadena.

EIP-7702 tiene un significado revolucionario, analicemoslo en detalle.

1. Antecedentes de la abstracción de cuentas

1.1 El significado abstracto de la cuenta

El fundador de Ethereum, Vitalik, actualizó nuevamente el mapa de ruta del desarrollo de ETH a finales de 2023, pero no ha cambiado la posición sobre la abstracción de cuentas. El modelo principal actual está pasando de EIP-4337 a la siguiente fase de conversión voluntaria de cuentas EOA.

Desde el lanzamiento de EIP4337 hace más de un año, el 1 de marzo de 2023 se presentó oficialmente en WalletCon en Denver (, que ha sido ampliamente reconocido por los usuarios, pero no ha sido utilizado de manera extensiva. En este contradictorio entorno del mercado, el progreso de EIP-7702 se ha adelantado significativamente y se ha determinado que se fusionará en la próxima actualización.

) 1.2 Estado del mercado abstracto de cuentas

Después de un año y medio de desarrollo, EIP4337 tiene solo 12 millones de direcciones en las cadenas principales, de las cuales solo hay 6,764 direcciones activas en la red principal de Ethereum, lo que está muy por debajo de la cantidad de direcciones EOA y CA. El número de direcciones únicas en la red principal de Ethereum ha alcanzado los 270 millones, por lo que se puede decir que EIP4337 no ha tenido un desarrollo sustantivo en la red principal.

Sin embargo, esto no afecta el valor intrínseco de AA. Desde su diseño inicial, EIP4337 estaba destinado a no resolver bien el problema de la compatibilidad hacia adelante de la mainnet. Con la integración nativa de AA en varias L2, la cantidad de direcciones EIP4337 ha tenido un gran aumento en L2, con usuarios activos en las cadenas Base y Polygon alcanzando 1 millón y 3 millones en julio, lo cual sigue siendo bastante considerable.

Por lo tanto, no es que el diseño de EIP4337 tenga errores, tiene muchas ventajas. La situación actual proviene de las diferencias entre la mainnet y L2, que necesitan soluciones adecuadas para cada una.

![Análisis profundo del pasado y futuro de la abstracción de cuentas de Ethereum]###https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp(

2. ¿Qué es la cuenta abstracta?

La abstracción de cuentas es esencialmente una solución al problema de la separación de la propiedad.

En la máquina virtual de Ethereum ) EVM ( hay dos tipos de cuentas: cuenta externa ) EOA ( y cuenta de contrato ) CA (. La propiedad y el derecho de firma de EOA son, de hecho, poseídos por el mismo sujeto. La persona que posee la clave privada no solo tiene la "propiedad de la cuenta", sino que también tiene el derecho a "firmar la transferencia de todos los activos".

Esto es determinado por la estructura de transacciones de la cuenta de Ethereum. En la estructura de transacción estándar no hay un campo From, la transferencia de fondos se realiza a través de los parámetros VRS ) que el usuario firma ( para descomponer la dirección From. Esto ha causado la dificultad actual de la consolidación de la propiedad de la dirección EOA.

El efecto principal de EIP4337 es agregar la Dirección del Remitente en el campo de transacciones, separando así la clave privada de la dirección de operación.

La importancia de la separación de la propiedad radica en:

1. Dificultad para proteger la clave privada: perder la clave privada significa perder todos los activos.

2. Algoritmo de firma único: la verificación de transacciones en el protocolo nativo solo puede utilizar el algoritmo ECDSA.

3. Permisos de firma demasiado altos: sin multisig nativo, cualquier operación se puede ejecutar con una sola firma.

4. Las tarifas de transacción solo se pueden pagar con Ether, no se admite el comercio en masa.

5. Filtración de privacidad de las transacciones: el comercio uno a uno facilita el análisis de la información del titular de la cuenta.

Estas restricciones dificultan el uso de Ethereum por parte de los usuarios comunes:

• Para utilizar cualquier aplicación, es necesario poseer Ether y asumir el riesgo de fluctuación de precios.
• Necesita manejar la lógica de tarifas compleja, los conceptos de precio del Gas, límite de Gas, Nonce, etc. son demasiado complicados.
• Aunque la aplicación de billetera intenta optimizar la experiencia del usuario, los resultados son limitados.

Por lo tanto, la clave para romper el impasse radica en lograr la abstracción de cuentas, desacoplando la propiedad )Owner( y el derecho de firma )Signer(, lo que permitirá resolver gradualmente los problemas mencionados anteriormente.

A lo largo de la historia, ha habido varias propuestas, que finalmente convergen en dos rutas.

![Análisis profundo del pasado y futuro de la abstracción de cuentas de Ethereum])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(

3. Organización de la historia de propuestas de AA

La solución al problema parece tener muchas propuestas de EIP, pero en última instancia se reduce a dos enfoques centrales. Cada EIP no aprobado que se consideró finalmente se integró en las soluciones existentes.

) 3.1 Primera ruta: convertir la dirección EOA a la dirección CA

El 15 de noviembre de 2015, Vitalik propuso una nueva estructura de cuenta con contratos en el EIP-101. Cambiando la dirección para que solo tuviera código y espacio de almacenamiento, soportando el pago de tarifas con ERC20, a través de contratos precompilados convirtiendo el token nativo en un tipo de ERC20 para almacenar saldo, y simplificando los campos de transacción a solo to, startgas, data y code.

Esta es una transformación de tipo Gran Salto Adelante, que cambiará drásticamente el diseño subyacente, permitiendo que cada cuenta tenga su propia lógica de "código". ### es precisamente el efecto que EIP-7702 busca lograr. (.

También puede derivar otras funciones:

1. Las transacciones utilizan más algoritmos criptográficos, con el método de verificación de firma especificado por el Code interno de la dirección.
2. Posee características de resistencia a ataques cuánticos, ya que el código es actualizable.
3. Hacer que Ether tenga funciones consistentes con ERC20, como la autorización de retención.
4. Mejora del espacio de personalización de la cuenta, compatible con la recuperación social, soporte SBT, recuperación de claves, etc.

La razón por la que no se continuó con el avance es muy simple, claramente el paso fue demasiado grande, y no se consideraron adecuadamente los problemas de colisión de hash de transacciones actuales y las preocupaciones de seguridad, por lo que se ha dejado en suspenso. Pero cada concepto de ventaja se ha convertido en una de las funciones centrales de los posteriores EIP4337 y EIP7702.

Más tarde, hubo una serie de EIP que intentaron perfeccionar esta lógica:

EIP-859: abstracción de cuentas de la cadena principal )2018-01-30(

Intentando resolver el problema de despliegue de Code. Si el contrato de la parte transaccional no está desplegado, se utiliza el parámetro code adjunto a la transacción para ejecutar el despliegue del contrato de la billetera. También se propone un nuevo código de operación PAYGAS, que además de pagar el gas, también actúa como un separador entre la parte de verificación y la parte de ejecución en los parámetros de la transacción.

Aunque en ese momento no tuvo éxito, se convirtió en una de las lógicas centrales del actual EIP7702. Cada transacción de EIP7702 combina una estructura de transacción especial, lo que permite que la dirección EOA tenga capacidad de contrato en esta transacción.

EIP-7702: Establecer código de cuenta EOA )2024-05-07(

Este es el EIP central que se discutirá más adelante en este artículo, presentado por Vitalik como una alternativa al EIP-3074. El EIP-3074 ha sido descontinuado, y se ha determinado que el EIP-7702 se incluirá en la próxima bifurcación dura de ETH Prague/Electra.

) 3.2 Segunda ruta: dejar que la dirección EOA impulse la dirección CA

EIP-3074: agregar los códigos de operación AUTH y AUTHCALL ###2020-10-15(

Agregar dos nuevos OpCodes en EVM: AUTH y AUTHCALL, permitiendo que EOA autorice a los contratos a llamar a otros contratos en lugar de utilizar la identidad de EOA a través de estos dos opcode.

En resumen, EOA puede enviar mensajes firmados ) transacción ( a un contrato en el que confía llamado Invoker ). El contrato Invoker puede utilizar AUTH y AUTHCALL en lugar de EOA para emitir transacciones.

EIP-4337: Implementación de la abstracción de cuentas a través del grupo de memoria de transacciones (2021-09-29)

Diseñado inspirado en MEV, su valor central es evitar completamente los cambios en el protocolo de la capa de consenso.

EIP4337 propone un nuevo objeto de transacción llamado UserOperation, que los usuarios envían a la memoria caché, donde los bundlers empaquetan en lotes y entregan transacciones de ejecución de contratos desde la perspectiva de los mineros. Esencialmente, esto lleva las transacciones subyacentes y la operación de cuentas a un nivel de ejecución de contratos.

EIP-5189: A través de la operación de un endoso, cuenta abstracta (2022-06-29)

Se optimizó la lógica de EIP4337, estableciendo un mecanismo de respaldo de multas de fondos (endorser) para prevenir ataques DoS de Bundler maliciosos.

( 3.3 Otras propuestas que soportan AA

EIP-2718: sobre envoltura de nuevos tipos de transacciones )2020-06-13###

La propuesta ya finalizada define un nuevo tipo de transacción como un contenedor para futuros tipos de transacciones adicionales.

Al introducir un nuevo tipo de transacción, se distingue mediante una codificación específica, solo es necesario mantener la compatibilidad hacia atrás y no hacia adelante. El ejemplo más común es EIP1559, que distingue las tarifas de transacción, utilizando una nueva codificación de tipo de transacción, sin afectar el tipo de transacción legacy original.

EIP-3607: Prohibir la implementación de contratos por direcciones EOA (2021-06-10)

Solución complementaria en la ruta AA para evitar conflictos entre la dirección de despliegue del contrato y la dirección EOA. Controlar el método de generación del contrato, no se permite desplegar código en direcciones que ya son EOA. Este riesgo es muy bajo, la dirección de Ethereum tiene 160 bits de longitud, aunque existe un método para colisionar la clave privada y obtener la clave privada de una dirección de contrato específica, se estima que requeriría un año de tiempo incluso con toda la potencia de cálculo de Bitcoin.

( 3.4 ¿Cómo entender la evolución del desarrollo de la cuenta abstracta?

Primero es necesario entender el valor después de convertir a CA.

Básicamente, es el efecto práctico de EIP-4337, que puede lograr:

• Restauración social
• transacciones sin gas
• Transacciones por lotes
• Pago de gas
• Cuenta bloqueada
• Firma personalizada

Pero la principal desventaja de EIP-4337 es que va en contra del principio de motivación humana.

Se ve mejor, pero se ha caído en un ciclo vicioso del desarrollo del mercado: muchas Dapps aún no son compatibles, los usuarios no quieren usar direcciones CA, usar CA en realidad tiene un costo de transacción más alto ), el costo de transacción para escenarios de transferencias normales se duplica ###, y depende demasiado de la compatibilidad de la Dapp en sí.

Así que hasta ahora no se ha generalizado en la red principal de Ethereum.

El costo es el criterio de evaluación más importante para los usuarios, y debe reducirse.

Para reducir realmente el GAS, es necesario realizar una actualización de bifurcación suave en Ethereum, modificando el cálculo de GAS o los módulos de consumo de GAS de los códigos de operación. Dado que se va a hacer una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?

4. Análisis completo de EIP-7702

( 4.1 ¿Qué es EIP-7702?

A través de un nuevo tipo de transacción, se permite que una EOA tenga temporalmente funciones de contrato inteligente en una sola transacción, soportando transacciones por lotes, transacciones sin Gas y gestión de permisos personalizada, sin necesidad de introducir un nuevo opCode de EVM ) que afecte a la compatibilidad hacia adelante ###.

Permitir a los usuarios obtener la mayoría de las capacidades de AA sin necesidad de desplegar contratos inteligentes, incluso se puede proporcionar la capacidad a terceros para iniciar transacciones en nombre del usuario, sin necesidad de que el usuario proporcione su clave privada, solo se requiere firmar la información de autorización.

( 4.2 estructura de datos

Definir un nuevo tipo de transacción 0x04, TransactionPayload es el resultado de la serialización RLP del siguiente contenido:

rlp)[ chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destino, valor, datos, lista_de_acceso, lista_de_autorización, signature_y_parity, signature_r, signature_s ]###

Es importante que se ha añadido un objeto authorization_list, que almacena el código que el firmante desea ejecutar en su EOA. El usuario firma el código del contrato que se va a ejecutar al mismo tiempo que firma la transacción, existiendo como una lista bidimensional, lo que permite almacenar múltiples informaciones de operación y ejecutar operaciones en lote.

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

( 4.3 Ciclo de vida de la transacción

)# 4.3.1 Fase de verificación

Ejecutando la fase de inicio de la transacción, para cada tupla [chain_id, address, nonce, y_parity, r, s] de authorization_list:

1. Recuperar la dirección del firmante a partir de la firma r, s utilizando ecrecover.

2. Verificar la cadena ID### para evitar la reproducción de cadenas bifurcadas ###.

3. Verificar si el código del firmante de authority está vacío o ha delegado ( para validar si la transacción es una transacción válida 7702 ).

4. Verificar el nonce del firmante de authority ( para prevenir la repetición de la firma de authority ).

5. Establecer el código del firmante de authority en 0xef0100 || address( para eludir la estrategia de prevención de colisiones EIP3607).

6. Aumentar el nonce del firmante authority( para prevenir la repetición de firmas parciales).

7. Agregar la cuenta del firmante de authority a la lista de direcciones visitadas ( para la dirección caliente, reducir el costo de gas de almacenamiento de consulta ).

(# 4.3.2 Fase de ejecución de la operación

"Nueva" versión solo cambia el comportamiento de implementación del código.

No se establecerá el código de cuenta como contract_code, sino que se recuperará la dirección del código de authorization_list y se establecerá como código de cuenta.

Al ejecutar el código autorizado, cargue el código desde el campo address de authorization_list, y ejecútelo en el contexto de la cuenta del firmante.

El código del contrato del usuario se almacena realmente en una dirección específica en la cadena, no se incluye directamente en la transacción.

Las instrucciones de operación y los parámetros relacionados se almacenan en el campo data de la carga de la transacción.

) 4.4 El valor de EIP-7702

Hay cambios en toda la cadena del monedero Web3, la experiencia del usuario.