Profundidad del análisis de la evolución histórica y las perspectivas futuras de la abstracción de cuentas de Ethereum
Introducción
Este artículo explorará la historia del desarrollo de la abstracción de cuentas de Ethereum (AA) desde dos aspectos principales:
Primero, rastrearemos el contexto histórico desde la primera propuesta AA en 2015, organizaremos sistemáticamente el contenido principal de las propuestas EIP hasta la fecha, profundizaremos en el proceso de evolución de la propuesta AA y realizaremos una evaluación integral de las ventajas y desventajas de cada opción.
En segundo lugar, nos centraremos en analizar las razones de la débil reacción del mercado tras el lanzamiento del EIP4337 y exploraremos en profundidad el EIP7702, que se incluirá en las futuras actualizaciones de Ethereum. Una vez que esta propuesta se fusione, cambiará fundamentalmente la forma de las aplicaciones en cadena.
EIP-7702 se considera una revolución histórica, profundicemos juntos en sus secretos.
1. Abstracción de cuentas del contexto
1.1 La ubicación del significado de la abstracción de cuentas
El fundador de Ethereum actualizó recientemente la hoja de ruta de desarrollo de ETH, pero la configuración sobre la abstracción de cuentas no ha cambiado. El modelo principal actual está pasando de EIP-4337 a la próxima fase de "conversión voluntaria de cuentas EOA".
A pesar de que el lanzamiento de EIP4337 ha pasado más de un año, la reacción del mercado es bastante contradictoria: los usuarios reconocen su valor en general, pero la tasa de uso real no es alta. En este contexto, el progreso de EIP-7702 se ha adelantado significativamente y se ha confirmado que se integrará en la próxima actualización.
1.2 La situación actual del mercado de la abstracción de cuentas
Después de un año y medio de desarrollo, el número total de direcciones de EIP4337 en las principales cadenas de bloques es de solo 12 millones, de las cuales en la red principal de Ethereum solo hay 6,764 direcciones activas, lo que está muy lejos del número de direcciones de EOA y CA. El número de direcciones independientes en la red principal de Ethereum ha alcanzado los 270 millones, lo que demuestra que EIP4337 prácticamente no ha tenido avances sustanciales en la red principal.
Sin embargo, esto no significa que el valor intrínseco de AA se vea afectado. El diseño del EIP4337 lo condena a tener dificultades para resolver adecuadamente el problema de la compatibilidad hacia adelante de la red principal. A medida que varios L2 se integran comúnmente con AA nativo, el número de direcciones del EIP4337 ha experimentado un crecimiento explosivo en L2, donde los usuarios activos mensuales de las cadenas Base y Polygon alcanzaron los 1 millón y 3 millones respectivamente en julio, lo cual es bastante considerable.
Por lo tanto, el problema no radica en el diseño de EIP4337, sino en las diferencias entre la red principal y L2, que requieren soluciones adecuadas para cada una.
2. ¿Qué es la abstracción de cuentas?
La abstracción de cuentas resuelve esencialmente el problema de la separación de la propiedad.
En la arquitectura de la máquina virtual de Ethereum ( EVM ) hay dos tipos de cuentas: cuenta externa ( EOA ) y cuenta de contrato ( Contract Account ). En la EOA, la propiedad de la cuenta y el derecho de firma son poseídos por la misma entidad. La persona que posee la clave privada no solo tiene la "propiedad" de la cuenta, sino que también tiene el derecho de "firmar la transferencia de todos los activos".
Esta característica está determinada por la estructura de transacciones de cuentas de Ethereum. En la estructura de transacciones estándar de Ethereum, en realidad no hay un campo From. La dirección del iniciador de la transacción se obtiene mediante el parámetro VRS (, es decir, se obtiene a través de la firma del usuario ).
Este diseño, aunque garantiza la seguridad a través de la criptografía, también ha llevado a la actual dificultad de la fusión de la propiedad de las direcciones EOA.
El efecto principal de EIP4337 es la adición de la dirección del remitente en el campo de transacción, lo que permite la separación de la clave privada y la dirección operada.
La razón por la que la separación de la propiedad es tan importante es que el diseño de EOA genera muchos problemas:
Dificultad para proteger la clave privada: perder la clave privada significa perder todos los activos.
Algoritmo de firma único: el protocolo nativo solo admite algoritmos de firma y verificación ECDSA.
Permisos de firma excesivos: sin soporte nativo para múltiples firmas, una sola firma puede ejecutar cualquier operación.
Las tarifas de transacción solo se pueden pagar con ETH, no se admiten transacciones por lotes.
La privacidad de las transacciones es fácil de filtrar: las transacciones uno a uno facilitan el análisis de la información de los titulares de cuentas.
Estas limitaciones hacen que sea difícil para los usuarios comunes utilizar Ethereum:
Primero, los usuarios deben poseer Ether ( y asumir el riesgo de fluctuación de precios ) para poder usar las aplicaciones en Ethereum.
En segundo lugar, los usuarios necesitan manejar una lógica de tarifas compleja, como el precio del Gas, el límite del Gas, el bloqueo de transacciones ( y el orden del Nonce ), conceptos que son demasiado complejos para los usuarios.
Por último, aunque muchas billeteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización del producto, el efecto es limitado.
Por lo tanto, la clave para superar las dificultades radica en implementar la abstracción de cuentas, desacoplando la propiedad (Owner) y el derecho de firma (Signer), para así abordar gradualmente los problemas mencionados anteriormente.
A lo largo de la historia se han propuesto diversas soluciones, que finalmente se han consolidado en dos rutas principales.
3. Revisión de la historia de propuestas de AA
La solución al problema parece tener múltiples propuestas de EIP, pero en última instancia, solo hay dos enfoques centrales. Cada problema considerado por un EIP no aprobado, finalmente se ha convertido en un punto de ruptura de la solución existente.
3.1 Primera ruta: convertir la dirección EOA en una dirección CA
Desde noviembre de 2015, Vitalik propuso en EIP-101 una nueva estructura de cuentas utilizando contratos. Esta propuesta sugiere que las direcciones se cambien para que solo contengan código y espacio de almacenamiento, apoyando el pago de tarifas con tokens ERC20, transformando el token nativo en un token tipo ERC20 ( que tiene funciones de autorización de deducción, ) y simplificando los campos de transacción para que solo contengan to, startgas, data y code.
Esta propuesta puede considerarse una revolución, ya que cambiará drásticamente el diseño subyacente, haciendo que cada dirección de cuenta tenga su propia lógica de "código" (, que es precisamente el efecto que busca lograr el actual EIP-7702 ).
También puede derivar otras funciones, como:
Soporte para transacciones que utilizan más algoritmos criptográficos, con métodos de verificación y autenticación especificados por el Code interno de cada dirección.
Posee características de resistencia a ataques cuánticos, porque el código es actualizable.
Dotar a Ether de características funcionales consistentes con el contrato ERC20, logrando la autorización de deducción de manera que no sea necesario consumir moneda nativa.
Mejora del espacio de personalización de la cuenta, soporte para recuperación social, SBT, recuperación de claves y otras funciones.
La razón por la que este plan no pudo avanzar es simple: se dieron pasos demasiado grandes, se consideraron de manera insuficiente los problemas de colisión de hash de las transacciones y las preocupaciones de seguridad en ese momento, por lo que se dejó en suspenso. Sin embargo, cada uno de los conceptos ventajosos se convirtió en una de las funciones centrales de los posteriores EIP4337 y EIP7702.
A partir de entonces, hubo una serie de EIP que intentaron perfeccionar esta lógica:
EIP-859: abstracción de cuentas de la cadena principal (2018-01-30)
Esta propuesta intenta resolver el problema del despliegue del código. Su función principal es que, cuando el contrato de la parte transaccional no está desplegado, se utiliza el parámetro code que acompaña a la transacción para ejecutar el despliegue de la billetera del contrato. Además, 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 no se logró en ese momento, esta idea se convirtió en una de las lógicas centrales del actual EIP7702. Cada transacción de EIP7702, combinada con una estructura de transacción especial, puede incluir cierto código, permitiendo así que la dirección EOA tenga capacidad de contrato en esta transacción.
EIP-7702: establecer el código de cuenta EOA (2024-05-07)
Este es el núcleo de la discusión posterior del artículo EIP, propuesto por Vitalik, como alternativa a EIP-3074. Por lo tanto, EIP-3074 ha sido desechado, y EIP-7702 se ha determinado que se incluirá en la próxima bifurcación dura ETH Prague/Electra(Pectra), cuyos detalles discutiremos en profundidad más adelante.
3.2 Segunda ruta: permitir que la dirección EOA impulse la dirección CA
EIP-3074: aumentar los códigos de operación AUTH y AUTHCALL (2020-10-15)
Esta propuesta sugiere agregar dos nuevos códigos de operación AUTH y AUTHCALL en el EVM, permitiendo que el EOA autorice a contratos a invocar otros contratos en lugar de la identidad del EOA a través de estos dos códigos de operación.
En resumen, un EOA puede enviar un mensaje firmado ( a un contrato en el que confía, llamado Invoker ), y ese contrato Invoker puede utilizar los códigos de operación AUTH y AUTHCALL en lugar de que este EOA envíe la transacción.
EIP-4337: implementación de la abstracción de cuentas en el pool de memoria de transacciones (2021-09-29)
Esta propuesta está diseñada inspirada en MEV, y su valor central radica en evitar completamente cambios en el protocolo de la capa de consenso.
EIP-4337 propuso un nuevo objeto de transacción llamado UserOperation. Los usuarios envían este objeto a la memoria, y los bundlers lo empaquetan en lotes desde la perspectiva de los mineros y lo entregan para ejecutar transacciones de contrato. Esencialmente, eleva las operaciones de transacción y cuenta a un nivel de ejecución de contrato.
EIP-5189: a través de la operación del endoso de abstracción de cuentas (2022-06-29)
Esto puede verse como una optimización de la lógica de EIP4337, mediante el establecimiento de un mecanismo de respaldo de penalización de fondos (endorser) para prevenir ataques de DoS por parte de Bundlers maliciosos.
( 3.3 Otras propuestas que apoyan la abstracción de cuentas
EIP-2718: sobre envoltura de un nuevo tipo de transacción )2020-06-13###
Esta es una propuesta que ya ha sido finalizada, que define un nuevo tipo de transacción, como un sobre para futuros tipos de transacción que se añadirán.
Su efecto final es que, al introducir nuevos tipos de transacciones, se pueden distinguir diferentes tipos de transacciones mediante una codificación específica, lo que solo requiere considerar la compatibilidad hacia atrás, sin necesidad de compatibilidad hacia adelante. El ejemplo más común es EIP1559, que distingue las tarifas de transacción, utiliza una nueva codificación de tipo de transacción, sin afectar al tipo de transacción legacy original.
EIP-3607: prohíbe la implementación de contratos por direcciones EOA (2021-06-10)
Esta es una solución complementaria en la ruta AA, utilizada para prevenir el problema de conflicto entre la dirección de implementación del contrato y la dirección de la EOA. Controlará el método de generación del contrato, prohibiendo al sistema implementar código en direcciones que ya son direcciones de EOA. Este riesgo es en realidad muy pequeño, considerando que la dirección de Ethereum tiene hasta 160 bits. Aunque existe un método para colisionar la clave privada para obtener la clave privada de una dirección de contrato específica, se estima que incluso utilizando toda la potencia de cálculo de la red de Bitcoin, tomaría aproximadamente un año.
( 3.4 ¿Cómo entender el desarrollo de la abstracción de cuentas?
Primero es necesario entender el valor después de convertirse en CA.
Este es básicamente el efecto práctico de EIP-4337, que puede lograr:
Soporte para múltiples firmas y recuperación social
Soporte para transacciones por lotes
Soporte para el pago de tarifas de gas con tokens ERC20
Soporte para límites de transacción
Soporte para transacciones sin gas ) pago de gas ###
Soporte para el bloqueo de cuentas y el cambio entre la billetera fría y caliente (.
Sin embargo, la principal desventaja de EIP-4337 es que va en contra del principio de motivación humana.
Parece mejor, pero ha caído en un ciclo vicioso del desarrollo del mercado: muchas Dapp aún no son compatibles, los usuarios no quieren usar direcciones de CA, e incluso usar CA puede generar costos de transacción más altos. En escenarios de transferencia comunes, las tarifas de transacción pueden duplicarse, dependiendo en exceso de la compatibilidad de la Dapp misma.
Esta es la razón por la cual no se ha popularizado hasta ahora en la red principal de Ethereum.
El costo es el criterio de medición más importante para los usuarios, y debe reducirse.
Pero para reducir realmente el GAS, es necesario realizar una actualización de bifurcación suave de Ethereum, modificando el cálculo del GAS o el consumo de GAS de los códigos de operación, entre otros módulos. Dado que se va a realizar una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?
![Profundidad de la interpretación de la abstracción de cuentas de Ethereum: pasado y futuro])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp(
4. Análisis completo de EIP-7702
) 4.1 Introducción a EIP-7702
La propuesta permite, mediante la introducción de un nuevo tipo de transacción, que las EOA tengan temporalmente la funcionalidad de contrato inteligente en una sola transacción, lo que apoya operaciones comerciales como transacciones en lote, transacciones sin Gas y gestión de permisos personalizados, sin necesidad de introducir un nuevo opCode de EVM que afecte la compatibilidad hacia adelante (.
Permite a los usuarios obtener la mayor parte de las capacidades de AA sin necesidad de desplegar contratos inteligentes, e incluso admite a terceros para que inicien transacciones en nombre del usuario, sin necesidad de que el usuario proporcione su clave privada, solo es necesario firmar la información de autorización.
) 4.2 estructura de datos
EIP-7702 define un nuevo tipo de transacción 0x04, el TransactionPayload de este tipo de transacción es el resultado de la serialización RLP del siguiente contenido:
El nuevo objeto authorization_list almacena el código que los firmantes desean ejecutar en su EOA. El usuario firma la transacción al mismo tiempo que firma lo que se va a ejecutar.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
5
Compartir
Comentar
0/400
CryptoPunster
· hace16h
7702 ya ha llegado, 4337 aún no ha llegado a la orilla.
Ver originalesResponder0
RektRecovery
· 08-01 17:29
meh... otra propuesta de AA que probablemente será destruida como lo fue la 4337. lo predigo ahora
Ver originalesResponder0
BearMarketNoodler
· 08-01 17:26
La nueva propuesta finalmente ha llegado, 4337 aún no se ha calentado.
Ver originalesResponder0
Degentleman
· 08-01 17:25
¿Has hecho algo nuevo otra vez? Déjame ver.
Ver originalesResponder0
DancingCandles
· 08-01 17:11
Realmente, hablé durante media hora y no dije nada.
EIP-7702: Un nuevo avance en la abstracción de cuentas de Ethereum y el desarrollo futuro
Profundidad del análisis de la evolución histórica y las perspectivas futuras de la abstracción de cuentas de Ethereum
Introducción
Este artículo explorará la historia del desarrollo de la abstracción de cuentas de Ethereum (AA) desde dos aspectos principales:
Primero, rastrearemos el contexto histórico desde la primera propuesta AA en 2015, organizaremos sistemáticamente el contenido principal de las propuestas EIP hasta la fecha, profundizaremos en el proceso de evolución de la propuesta AA y realizaremos una evaluación integral de las ventajas y desventajas de cada opción.
En segundo lugar, nos centraremos en analizar las razones de la débil reacción del mercado tras el lanzamiento del EIP4337 y exploraremos en profundidad el EIP7702, que se incluirá en las futuras actualizaciones de Ethereum. Una vez que esta propuesta se fusione, cambiará fundamentalmente la forma de las aplicaciones en cadena.
EIP-7702 se considera una revolución histórica, profundicemos juntos en sus secretos.
1. Abstracción de cuentas del contexto
1.1 La ubicación del significado de la abstracción de cuentas
El fundador de Ethereum actualizó recientemente la hoja de ruta de desarrollo de ETH, pero la configuración sobre la abstracción de cuentas no ha cambiado. El modelo principal actual está pasando de EIP-4337 a la próxima fase de "conversión voluntaria de cuentas EOA".
A pesar de que el lanzamiento de EIP4337 ha pasado más de un año, la reacción del mercado es bastante contradictoria: los usuarios reconocen su valor en general, pero la tasa de uso real no es alta. En este contexto, el progreso de EIP-7702 se ha adelantado significativamente y se ha confirmado que se integrará en la próxima actualización.
1.2 La situación actual del mercado de la abstracción de cuentas
Después de un año y medio de desarrollo, el número total de direcciones de EIP4337 en las principales cadenas de bloques es de solo 12 millones, de las cuales en la red principal de Ethereum solo hay 6,764 direcciones activas, lo que está muy lejos del número de direcciones de EOA y CA. El número de direcciones independientes en la red principal de Ethereum ha alcanzado los 270 millones, lo que demuestra que EIP4337 prácticamente no ha tenido avances sustanciales en la red principal.
Sin embargo, esto no significa que el valor intrínseco de AA se vea afectado. El diseño del EIP4337 lo condena a tener dificultades para resolver adecuadamente el problema de la compatibilidad hacia adelante de la red principal. A medida que varios L2 se integran comúnmente con AA nativo, el número de direcciones del EIP4337 ha experimentado un crecimiento explosivo en L2, donde los usuarios activos mensuales de las cadenas Base y Polygon alcanzaron los 1 millón y 3 millones respectivamente en julio, lo cual es bastante considerable.
Por lo tanto, el problema no radica en el diseño de EIP4337, sino en las diferencias entre la red principal y L2, que requieren soluciones adecuadas para cada una.
2. ¿Qué es la abstracción de cuentas?
La abstracción de cuentas resuelve esencialmente el problema de la separación de la propiedad.
En la arquitectura de la máquina virtual de Ethereum ( EVM ) hay dos tipos de cuentas: cuenta externa ( EOA ) y cuenta de contrato ( Contract Account ). En la EOA, la propiedad de la cuenta y el derecho de firma son poseídos por la misma entidad. La persona que posee la clave privada no solo tiene la "propiedad" de la cuenta, sino que también tiene el derecho de "firmar la transferencia de todos los activos".
Esta característica está determinada por la estructura de transacciones de cuentas de Ethereum. En la estructura de transacciones estándar de Ethereum, en realidad no hay un campo From. La dirección del iniciador de la transacción se obtiene mediante el parámetro VRS (, es decir, se obtiene a través de la firma del usuario ).
Este diseño, aunque garantiza la seguridad a través de la criptografía, también ha llevado a la actual dificultad de la fusión de la propiedad de las direcciones EOA.
El efecto principal de EIP4337 es la adición de la dirección del remitente en el campo de transacción, lo que permite la separación de la clave privada y la dirección operada.
La razón por la que la separación de la propiedad es tan importante es que el diseño de EOA genera muchos problemas:
Dificultad para proteger la clave privada: perder la clave privada significa perder todos los activos.
Algoritmo de firma único: el protocolo nativo solo admite algoritmos de firma y verificación ECDSA.
Permisos de firma excesivos: sin soporte nativo para múltiples firmas, una sola firma puede ejecutar cualquier operación.
Las tarifas de transacción solo se pueden pagar con ETH, no se admiten transacciones por lotes.
La privacidad de las transacciones es fácil de filtrar: las transacciones uno a uno facilitan el análisis de la información de los titulares de cuentas.
Estas limitaciones hacen que sea difícil para los usuarios comunes utilizar Ethereum:
Primero, los usuarios deben poseer Ether ( y asumir el riesgo de fluctuación de precios ) para poder usar las aplicaciones en Ethereum.
En segundo lugar, los usuarios necesitan manejar una lógica de tarifas compleja, como el precio del Gas, el límite del Gas, el bloqueo de transacciones ( y el orden del Nonce ), conceptos que son demasiado complejos para los usuarios.
Por último, aunque muchas billeteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización del producto, el efecto es limitado.
Por lo tanto, la clave para superar las dificultades radica en implementar la abstracción de cuentas, desacoplando la propiedad (Owner) y el derecho de firma (Signer), para así abordar gradualmente los problemas mencionados anteriormente.
A lo largo de la historia se han propuesto diversas soluciones, que finalmente se han consolidado en dos rutas principales.
3. Revisión de la historia de propuestas de AA
La solución al problema parece tener múltiples propuestas de EIP, pero en última instancia, solo hay dos enfoques centrales. Cada problema considerado por un EIP no aprobado, finalmente se ha convertido en un punto de ruptura de la solución existente.
3.1 Primera ruta: convertir la dirección EOA en una dirección CA
Desde noviembre de 2015, Vitalik propuso en EIP-101 una nueva estructura de cuentas utilizando contratos. Esta propuesta sugiere que las direcciones se cambien para que solo contengan código y espacio de almacenamiento, apoyando el pago de tarifas con tokens ERC20, transformando el token nativo en un token tipo ERC20 ( que tiene funciones de autorización de deducción, ) y simplificando los campos de transacción para que solo contengan to, startgas, data y code.
Esta propuesta puede considerarse una revolución, ya que cambiará drásticamente el diseño subyacente, haciendo que cada dirección de cuenta tenga su propia lógica de "código" (, que es precisamente el efecto que busca lograr el actual EIP-7702 ).
También puede derivar otras funciones, como:
Soporte para transacciones que utilizan más algoritmos criptográficos, con métodos de verificación y autenticación especificados por el Code interno de cada dirección.
Posee características de resistencia a ataques cuánticos, porque el código es actualizable.
Dotar a Ether de características funcionales consistentes con el contrato ERC20, logrando la autorización de deducción de manera que no sea necesario consumir moneda nativa.
Mejora del espacio de personalización de la cuenta, soporte para recuperación social, SBT, recuperación de claves y otras funciones.
La razón por la que este plan no pudo avanzar es simple: se dieron pasos demasiado grandes, se consideraron de manera insuficiente los problemas de colisión de hash de las transacciones y las preocupaciones de seguridad en ese momento, por lo que se dejó en suspenso. Sin embargo, cada uno de los conceptos ventajosos se convirtió en una de las funciones centrales de los posteriores EIP4337 y EIP7702.
A partir de entonces, hubo una serie de EIP que intentaron perfeccionar esta lógica:
EIP-859: abstracción de cuentas de la cadena principal (2018-01-30)
Esta propuesta intenta resolver el problema del despliegue del código. Su función principal es que, cuando el contrato de la parte transaccional no está desplegado, se utiliza el parámetro code que acompaña a la transacción para ejecutar el despliegue de la billetera del contrato. Además, 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 no se logró en ese momento, esta idea se convirtió en una de las lógicas centrales del actual EIP7702. Cada transacción de EIP7702, combinada con una estructura de transacción especial, puede incluir cierto código, permitiendo así que la dirección EOA tenga capacidad de contrato en esta transacción.
EIP-7702: establecer el código de cuenta EOA (2024-05-07)
Este es el núcleo de la discusión posterior del artículo EIP, propuesto por Vitalik, como alternativa a EIP-3074. Por lo tanto, EIP-3074 ha sido desechado, y EIP-7702 se ha determinado que se incluirá en la próxima bifurcación dura ETH Prague/Electra(Pectra), cuyos detalles discutiremos en profundidad más adelante.
3.2 Segunda ruta: permitir que la dirección EOA impulse la dirección CA
EIP-3074: aumentar los códigos de operación AUTH y AUTHCALL (2020-10-15)
Esta propuesta sugiere agregar dos nuevos códigos de operación AUTH y AUTHCALL en el EVM, permitiendo que el EOA autorice a contratos a invocar otros contratos en lugar de la identidad del EOA a través de estos dos códigos de operación.
En resumen, un EOA puede enviar un mensaje firmado ( a un contrato en el que confía, llamado Invoker ), y ese contrato Invoker puede utilizar los códigos de operación AUTH y AUTHCALL en lugar de que este EOA envíe la transacción.
EIP-4337: implementación de la abstracción de cuentas en el pool de memoria de transacciones (2021-09-29)
Esta propuesta está diseñada inspirada en MEV, y su valor central radica en evitar completamente cambios en el protocolo de la capa de consenso.
EIP-4337 propuso un nuevo objeto de transacción llamado UserOperation. Los usuarios envían este objeto a la memoria, y los bundlers lo empaquetan en lotes desde la perspectiva de los mineros y lo entregan para ejecutar transacciones de contrato. Esencialmente, eleva las operaciones de transacción y cuenta a un nivel de ejecución de contrato.
EIP-5189: a través de la operación del endoso de abstracción de cuentas (2022-06-29)
Esto puede verse como una optimización de la lógica de EIP4337, mediante el establecimiento de un mecanismo de respaldo de penalización de fondos (endorser) para prevenir ataques de DoS por parte de Bundlers maliciosos.
( 3.3 Otras propuestas que apoyan la abstracción de cuentas
EIP-2718: sobre envoltura de un nuevo tipo de transacción )2020-06-13###
Esta es una propuesta que ya ha sido finalizada, que define un nuevo tipo de transacción, como un sobre para futuros tipos de transacción que se añadirán.
Su efecto final es que, al introducir nuevos tipos de transacciones, se pueden distinguir diferentes tipos de transacciones mediante una codificación específica, lo que solo requiere considerar la compatibilidad hacia atrás, sin necesidad de compatibilidad hacia adelante. El ejemplo más común es EIP1559, que distingue las tarifas de transacción, utiliza una nueva codificación de tipo de transacción, sin afectar al tipo de transacción legacy original.
EIP-3607: prohíbe la implementación de contratos por direcciones EOA (2021-06-10)
Esta es una solución complementaria en la ruta AA, utilizada para prevenir el problema de conflicto entre la dirección de implementación del contrato y la dirección de la EOA. Controlará el método de generación del contrato, prohibiendo al sistema implementar código en direcciones que ya son direcciones de EOA. Este riesgo es en realidad muy pequeño, considerando que la dirección de Ethereum tiene hasta 160 bits. Aunque existe un método para colisionar la clave privada para obtener la clave privada de una dirección de contrato específica, se estima que incluso utilizando toda la potencia de cálculo de la red de Bitcoin, tomaría aproximadamente un año.
( 3.4 ¿Cómo entender el desarrollo de la abstracción de cuentas?
Primero es necesario entender el valor después de convertirse en CA.
Este es básicamente el efecto práctico de EIP-4337, que puede lograr:
Sin embargo, la principal desventaja de EIP-4337 es que va en contra del principio de motivación humana.
Parece mejor, pero ha caído en un ciclo vicioso del desarrollo del mercado: muchas Dapp aún no son compatibles, los usuarios no quieren usar direcciones de CA, e incluso usar CA puede generar costos de transacción más altos. En escenarios de transferencia comunes, las tarifas de transacción pueden duplicarse, dependiendo en exceso de la compatibilidad de la Dapp misma.
Esta es la razón por la cual no se ha popularizado hasta ahora en la red principal de Ethereum.
El costo es el criterio de medición más importante para los usuarios, y debe reducirse.
Pero para reducir realmente el GAS, es necesario realizar una actualización de bifurcación suave de Ethereum, modificando el cálculo del GAS o el consumo de GAS de los códigos de operación, entre otros módulos. Dado que se va a realizar una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?
![Profundidad de la interpretación de la abstracción de cuentas de Ethereum: pasado y futuro])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp(
4. Análisis completo de EIP-7702
) 4.1 Introducción a EIP-7702
La propuesta permite, mediante la introducción de un nuevo tipo de transacción, que las EOA tengan temporalmente la funcionalidad de contrato inteligente en una sola transacción, lo que apoya operaciones comerciales como transacciones en lote, transacciones sin Gas y gestión de permisos personalizados, sin necesidad de introducir un nuevo opCode de EVM que afecte la compatibilidad hacia adelante (.
Permite a los usuarios obtener la mayor parte de las capacidades de AA sin necesidad de desplegar contratos inteligentes, e incluso admite a terceros para que inicien transacciones en nombre del usuario, sin necesidad de que el usuario proporcione su clave privada, solo es necesario firmar la información de autorización.
) 4.2 estructura de datos
EIP-7702 define un nuevo tipo de transacción 0x04, el TransactionPayload de este tipo de transacción 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_paridad, signature_r, signature_s ])
El nuevo objeto authorization_list almacena el código que los firmantes desean ejecutar en su EOA. El usuario firma la transacción al mismo tiempo que firma lo que se va a ejecutar.