Análisis profundo de la evolución y el futuro de la abstracción de cuentas de Ethereum
Introducción
Este artículo se divide en dos partes principales:
La primera parte parte de la primera propuesta de abstracción de cuentas de 2015, el sistema revisa el contenido de las principales propuestas de EIP hasta la fecha, revisa la evolución histórica de las soluciones de abstracción de cuentas y evalúa las ventajas y desventajas de cada solución.
La segunda parte se centra en comparar la fría reacción del mercado tras el lanzamiento de EIP4337 y analiza en profundidad EIP7702, que se incorporará a la próxima actualización de Ethereum. Una vez que esta propuesta se fusione, cambiará fundamentalmente la forma de las aplicaciones en la cadena.
EIP-7702 como una revolución histórica, analicemos su contenido en detalle.
1. Abstracción de cuentas el fondo
1.1 la ubicación de la abstracción de cuentas
El fundador de Ethereum, Vitalik, actualizó nuevamente el mapa de desarrollo de ETH a finales de 2023, pero no se modificó la configuración de la abstracción de cuentas. Actualmente, la ruta de desarrollo principal es la conversión voluntaria de EOA que entra en la siguiente etapa desde EIP-4337(Conversión Voluntaria de EOA).
1.2 El estado 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 cadenas principales es de solo 12 millones, de las cuales solo hay 6,764 direcciones activas en la red principal de Ethereum, lo que está muy lejos del número de direcciones EOA y CA. El número de direcciones independientes en la red principal de Ethereum ha alcanzado los 270 millones, por lo que se puede decir que EIP4337 prácticamente no ha tenido un desarrollo sustantivo en la red principal.
Sin embargo, esto no afecta el valor esencial de la abstracción de cuentas (AA). El propósito original del EIP4337 es resolver el problema de compatibilidad hacia adelante de la red principal, por lo que ha experimentado un crecimiento explosivo en varias cadenas L2 que apoyan de forma nativa la abstracción de cuentas. Por ejemplo, en julio, la cantidad de usuarios activos mensuales en las cadenas Base y Polygon alcanzó 1 millón y 3 millones, respectivamente, lo que es un buen desempeño.
Por lo tanto, el diseño de EIP4337 no está equivocado, tiene muchas ventajas. La situación actual se debe principalmente a las diferencias entre la red principal y L2, que necesitan adoptar soluciones adecuadas para cada una.
2. ¿Qué es la abstracción de cuentas?
La abstracción de cuentas es esencialmente una solución al 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 cuenta externa, la propiedad y el derecho de firma son en realidad 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".
Esto está determinado por la estructura de transacciones de cuentas de Ethereum. A partir de la estructura de transacciones, se puede ver que la transacción estándar de Ethereum en realidad no tiene el campo From. Entonces, ¿cómo se determina la dirección de gasto en una transferencia de fondos? En realidad, se deduce la dirección From a través del parámetro VRS (, es decir, la firma del usuario ).
Esto involucra conceptos como ECDSA y funciones de umbral unidireccionales, que no se expandirán aquí. En resumen, este mecanismo garantiza la seguridad a través de la criptografía, pero también ha llevado a la actual dificultad en la consolidación de la propiedad de direcciones EOA.
El papel fundamental de EIP4337 es añadir la dirección del remitente en el campo de transacciones, logrando así la separación entre la clave privada y la dirección de la operación.
La razón por la cual la separación de la propiedad es tan importante es que el diseño de la cuenta externa (EOA) generará más problemas:
Dificultad para proteger la clave privada: si el usuario pierde la clave privada (, es atacado por hackers o sufre un descifrado criptográfico ), eso significa que perderá todos sus activos.
Algoritmo de firma único: el protocolo nativo solo puede utilizar el algoritmo de firma y verificación ECDSA al verificar transacciones.
Permisos de firma demasiado altos: no se admite la firma múltiple nativa ( la firma múltiple solo se puede implementar a través de un contrato inteligente ), una sola firma puede ejecutar cualquier operación.
Las tarifas de transacción solo se pueden pagar con Ether, no se admiten transacciones por lotes.
Filtración de privacidad en las transacciones: las transacciones uno a uno pueden revelar la información privada del titular de la cuenta.
Estas limitaciones dificultan el uso de Ethereum por parte de los usuarios comunes:
Primero, para usar cualquier aplicación en Ethereum, los usuarios deben poseer Ether ( y asumir el riesgo de la volatilidad de su precio ).
En segundo lugar, los usuarios necesitan manejar una lógica de tarifas compleja, el precio del Gas, el límite de Gas, el bloqueo de transacciones (, el orden del Nonce ) y otros conceptos que son demasiado complejos para los usuarios.
Por último, a pesar de que muchas billeteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización de productos, los resultados son limitados.
Por lo tanto, la solución radica en implementar la abstracción de cuentas, desacoplando la propiedad (Owner) y el derecho de firma (Signer), para abordar gradualmente los problemas mencionados anteriormente.
A lo largo de la historia se han propuesto diversas soluciones, que finalmente se resumen en dos rutas principales.
3. Contexto de la Propuesta Histórica de la Abstracción de Cuentas
La solución al problema parece tener múltiples propuestas de EIP, pero en última instancia, solo hay dos enfoques centrales. Cada uno de los problemas considerados por los EIP no aprobados se ha convergido en los puntos de ruptura de la solución actual.
( 3.1 Primera ruta: transformar la dirección EOA en una dirección CA
Desde el 15 de noviembre de 2015, en torno a EIP-101, Vitalik propuso una nueva estructura de cuentas basada en contratos. Los principales cambios incluyen:
Cambiar la dirección a solo código y espacio de almacenamiento
Cambiar el soporte de tarifas, permitir el pago con tokens ERC20
A través de contratos precompilados, los tokens nativos se transforman en tokens tipo ERC20, con funciones como la autorización de retención.
Simplificar los campos de la transacción a to, startgas, data y code
Esta propuesta puede considerarse un cambio revolucionario, que modificará en gran medida 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 EIP-7702 busca lograr ###.
También puede derivar otras funciones, por ejemplo:
Permitir que las transacciones utilicen más algoritmos de cifrado, que pueden ser especificados por el método de verificación y autenticación interna del código de cada dirección.
Posee características de resistencia a ataques cuánticos, ya que el código puede actualizarse.
Hacer que el Ether tenga características funcionales consistentes con los contratos ERC20, el efecto principal es implementar la autorización de deducción, sin necesidad de consumir monedas nativas.
Mejorar el espacio de personalización de la cuenta, compatible con la recuperación social, soporte SBT, recuperación de claves y otras funciones.
La razón por la que este plan no se ha seguido adelante es muy simple: se dio un paso demasiado grande. No se consideraron adecuadamente los problemas de colisión de hash de transacciones y los riesgos de seguridad en ese momento, por lo que se ha dejado en suspenso. Sin embargo, cada una de las ideas de sus ventajas se ha convertido en una de las funciones centrales de EIP4337 y EIP7702.
Después, hubo una serie de EIP que intentaron perfeccionar esta lógica:
EIP-859: abstracción de cuentas de la cadena principal (2018-01-30)
Intentar resolver problemas de implementación de Code. La función principal es: si el contrato de la parte transaccional no está implementado, se utiliza el parámetro code adjunto a la transacción para ejecutar la implementación de la billetera del contrato. Además, se propuso un nuevo código de operación PAYGAS, que además de pagar gas, también se convierte en un delimitador 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, esto se ha convertido en una de las lógicas centrales de 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 capacidades de contrato en esta transacción.
EIP-7702: establecer código de cuenta EOA (2024-05-07)
Este también es el EIP central que se discutirá más adelante en este artículo, presentado por Vitalik, como una alternativa a EIP-3074. Por lo tanto, EIP-3074 ha sido desechado, y EIP-7702 ha sido confirmado para ser incluido en la próxima bifurcación dura ETH Prague/Electra(Pectra), cuyos detalles se desarrollarán a continuación.
( 3.2 Segunda ruta: permitir que la dirección EOA impulse la dirección CA
EIP-3074: añadir los códigos de operación AUTH y AUTHCALL )2020-10-15###
Agregar dos nuevos códigos de operación AUTH y AUTHCALL en EVM, permitiendo que EOA autorice a contratos a llamar a otros contratos en lugar de usar la identidad de EOA a través de estos códigos de operación.
En pocas palabras, una EOA puede enviar un mensaje firmado ( a un contrato en el que confía, llamado Invoker ). Este contrato Invoker puede utilizar los códigos de operación AUTH y AUTHCALL para enviar transacciones en lugar de esta EOA.
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 inspirándose en MEV, y su valor central radica en evitar por completo los cambios en el protocolo de la capa de consenso.
EIP4337 propuso un nuevo objeto de transacción UserOperation, que los usuarios envían al pool de memoria, y los bundlers lo empaquetan en lotes desde la perspectiva de los mineros para entregar la ejecución del contrato de transacciones. Esencialmente, esto lleva las transacciones subyacentes y la operación de cuentas a un nivel de ejecución de contrato.
EIP-5189: Operar cuentas abstractas a través de endosantes (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 multas de fondos (endorser) para prevenir ataques de bloqueo DoS maliciosos de Bundler.
( 3.3 Otras propuestas para apoyar la abstracción de cuentas
EIP-2718: sobre envoltura de nuevos tipos 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 transacciones.
El efecto final es que, al introducir un nuevo tipo de transacción, se diferencian las distintas transacciones mediante una codificación específica, lo que permite que solo necesiten ser compatibles hacia atrás, sin necesidad de ser compatibles 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 y no afecta al tipo de transacción legacy original.
EIP-3607: prohibir la implementación de contratos por direcciones EOA )2021-06-10###
Esta es una solución complementaria en la ruta AA, utilizada para evitar el problema de conflicto entre la dirección de despliegue del contrato y la dirección EOA. Controlará el método de generación del contrato, no permitiendo que el sistema despliegue código en una dirección que ya sea una dirección EOA. Este riesgo es en realidad muy bajo, ya que 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 la dirección del contrato específico, según la estimación de la potencia de cálculo de toda la red de Bitcoin, también tomaría 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.
Básicamente, es el efecto práctico de EIP-4337, que puede lograr:
recuperación social
transacciones sin gas
Transacciones por lotes
Reglas basadas en el tiempo
Multisig
Pago basado en reglas
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 de desarrollo del mercado: muchas Dapps aún no son compatibles, lo que lleva a los usuarios a no querer usar direcciones CA. Incluso el uso de CA puede generar costos de transacción más altos ) en escenarios de transferencia normal, las tarifas de transacción pueden duplicarse (, y también depende demasiado de la compatibilidad de la Dapp en sí.
Por lo tanto, aún 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.
Pero para reducir realmente el GAS, es necesario realizar una actualización de bifurcación suave en Ethereum mismo, modificando el cálculo de GAS o los módulos de consumo de GAS de los códigos de operación, entre otros. Dado que se va a hacer una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?
![Análisis profundo de la abstracción de cuentas de Ethereum: pasado y futuro])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp###
4. Análisis completo de EIP-7702
( 4.1 ¿Qué es EIP-7702?
Distingue a través de un nuevo tipo de transacción, permitiendo que una EOA tenga temporalmente la funcionalidad de un contrato inteligente en una sola transacción, lo que a su vez apoya operaciones comerciales como transacciones por lotes, transacciones sin Gas y gestión de permisos personalizados, todo ello sin necesidad de introducir nuevos códigos de operación EVM ) que afecten la compatibilidad hacia adelante (.
Puede permitir a los usuarios obtener la mayoría de las capacidades de AA sin desplegar contratos inteligentes, e incluso puede ofrecer la capacidad a terceros para iniciar transacciones en nombre del usuario, sin necesidad de que el usuario proporcione su clave privada, solo necesita firmar la información de autorización.
) 4.2 estructura de datos
Define un nuevo tipo de transacción 0x04, cuyo TransactionPayload es el resultado de la serialización RLP del siguiente contenido:
rlp###[
chain_id, // ID de cadena, utilizado para prevenir ataques de repetición
nonce, // contador de transacciones, asegura la unicidad de la transacción
max_priority_fee_per_gas, // tarifa de transacción 1559
max_fee_per_gas, // tarifa de transacción 1559
gas_limit,
destino, // dirección 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,
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 contrato al mismo tiempo que firma la transacción, y este se presenta como una lista bidimensional, indicando lo que se puede
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.
17 me gusta
Recompensa
17
4
Compartir
Comentar
0/400
FancyResearchLab
· 08-04 18:02
Otra nueva moda que surge de un teórico PI. ¿Y el paper de agua?
Ver originalesResponder0
BrokenDAO
· 08-04 18:01
Otro experimento repetido que se presenta bajo la bandera de la innovación, no seamos demasiado optimistas... Es probable que el EIP-7702 repita el mismo error que el 4337.
Ver originalesResponder0
LiquidityHunter
· 08-04 17:58
¿4337? Los datos muestran que la tasa de adopción es solo del 0.02%... 7702 es el verdadero negocio.
Ver originalesResponder0
rugged_again
· 08-04 17:32
Vitalik Buterin esta vez sigue siendo muy estable, realmente bien.
Evolución de la abstracción de cuentas de Ethereum: de EIP-4337 a la transformación revolucionaria de EIP-7702
Análisis profundo de la evolución y el futuro de la abstracción de cuentas de Ethereum
Introducción
Este artículo se divide en dos partes principales:
La primera parte parte de la primera propuesta de abstracción de cuentas de 2015, el sistema revisa el contenido de las principales propuestas de EIP hasta la fecha, revisa la evolución histórica de las soluciones de abstracción de cuentas y evalúa las ventajas y desventajas de cada solución.
La segunda parte se centra en comparar la fría reacción del mercado tras el lanzamiento de EIP4337 y analiza en profundidad EIP7702, que se incorporará a la próxima actualización de Ethereum. Una vez que esta propuesta se fusione, cambiará fundamentalmente la forma de las aplicaciones en la cadena.
EIP-7702 como una revolución histórica, analicemos su contenido en detalle.
1. Abstracción de cuentas el fondo
1.1 la ubicación de la abstracción de cuentas
El fundador de Ethereum, Vitalik, actualizó nuevamente el mapa de desarrollo de ETH a finales de 2023, pero no se modificó la configuración de la abstracción de cuentas. Actualmente, la ruta de desarrollo principal es la conversión voluntaria de EOA que entra en la siguiente etapa desde EIP-4337(Conversión Voluntaria de EOA).
1.2 El estado 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 cadenas principales es de solo 12 millones, de las cuales solo hay 6,764 direcciones activas en la red principal de Ethereum, lo que está muy lejos del número de direcciones EOA y CA. El número de direcciones independientes en la red principal de Ethereum ha alcanzado los 270 millones, por lo que se puede decir que EIP4337 prácticamente no ha tenido un desarrollo sustantivo en la red principal.
Sin embargo, esto no afecta el valor esencial de la abstracción de cuentas (AA). El propósito original del EIP4337 es resolver el problema de compatibilidad hacia adelante de la red principal, por lo que ha experimentado un crecimiento explosivo en varias cadenas L2 que apoyan de forma nativa la abstracción de cuentas. Por ejemplo, en julio, la cantidad de usuarios activos mensuales en las cadenas Base y Polygon alcanzó 1 millón y 3 millones, respectivamente, lo que es un buen desempeño.
Por lo tanto, el diseño de EIP4337 no está equivocado, tiene muchas ventajas. La situación actual se debe principalmente a las diferencias entre la red principal y L2, que necesitan adoptar soluciones adecuadas para cada una.
2. ¿Qué es la abstracción de cuentas?
La abstracción de cuentas es esencialmente una solución al 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 cuenta externa, la propiedad y el derecho de firma son en realidad 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".
Esto está determinado por la estructura de transacciones de cuentas de Ethereum. A partir de la estructura de transacciones, se puede ver que la transacción estándar de Ethereum en realidad no tiene el campo From. Entonces, ¿cómo se determina la dirección de gasto en una transferencia de fondos? En realidad, se deduce la dirección From a través del parámetro VRS (, es decir, la firma del usuario ).
Esto involucra conceptos como ECDSA y funciones de umbral unidireccionales, que no se expandirán aquí. En resumen, este mecanismo garantiza la seguridad a través de la criptografía, pero también ha llevado a la actual dificultad en la consolidación de la propiedad de direcciones EOA.
El papel fundamental de EIP4337 es añadir la dirección del remitente en el campo de transacciones, logrando así la separación entre la clave privada y la dirección de la operación.
La razón por la cual la separación de la propiedad es tan importante es que el diseño de la cuenta externa (EOA) generará más problemas:
Dificultad para proteger la clave privada: si el usuario pierde la clave privada (, es atacado por hackers o sufre un descifrado criptográfico ), eso significa que perderá todos sus activos.
Algoritmo de firma único: el protocolo nativo solo puede utilizar el algoritmo de firma y verificación ECDSA al verificar transacciones.
Permisos de firma demasiado altos: no se admite la firma múltiple nativa ( la firma múltiple solo se puede implementar a través de un contrato inteligente ), una sola firma puede ejecutar cualquier operación.
Las tarifas de transacción solo se pueden pagar con Ether, no se admiten transacciones por lotes.
Filtración de privacidad en las transacciones: las transacciones uno a uno pueden revelar la información privada del titular de la cuenta.
Estas limitaciones dificultan el uso de Ethereum por parte de los usuarios comunes:
Primero, para usar cualquier aplicación en Ethereum, los usuarios deben poseer Ether ( y asumir el riesgo de la volatilidad de su precio ).
En segundo lugar, los usuarios necesitan manejar una lógica de tarifas compleja, el precio del Gas, el límite de Gas, el bloqueo de transacciones (, el orden del Nonce ) y otros conceptos que son demasiado complejos para los usuarios.
Por último, a pesar de que muchas billeteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización de productos, los resultados son limitados.
Por lo tanto, la solución radica en implementar la abstracción de cuentas, desacoplando la propiedad (Owner) y el derecho de firma (Signer), para abordar gradualmente los problemas mencionados anteriormente.
A lo largo de la historia se han propuesto diversas soluciones, que finalmente se resumen en dos rutas principales.
3. Contexto de la Propuesta Histórica de la Abstracción de Cuentas
La solución al problema parece tener múltiples propuestas de EIP, pero en última instancia, solo hay dos enfoques centrales. Cada uno de los problemas considerados por los EIP no aprobados se ha convergido en los puntos de ruptura de la solución actual.
( 3.1 Primera ruta: transformar la dirección EOA en una dirección CA
Desde el 15 de noviembre de 2015, en torno a EIP-101, Vitalik propuso una nueva estructura de cuentas basada en contratos. Los principales cambios incluyen:
Esta propuesta puede considerarse un cambio revolucionario, que modificará en gran medida 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 EIP-7702 busca lograr ###.
También puede derivar otras funciones, por ejemplo:
Permitir que las transacciones utilicen más algoritmos de cifrado, que pueden ser especificados por el método de verificación y autenticación interna del código de cada dirección.
Posee características de resistencia a ataques cuánticos, ya que el código puede actualizarse.
Hacer que el Ether tenga características funcionales consistentes con los contratos ERC20, el efecto principal es implementar la autorización de deducción, sin necesidad de consumir monedas nativas.
Mejorar el espacio de personalización de la cuenta, compatible con la recuperación social, soporte SBT, recuperación de claves y otras funciones.
La razón por la que este plan no se ha seguido adelante es muy simple: se dio un paso demasiado grande. No se consideraron adecuadamente los problemas de colisión de hash de transacciones y los riesgos de seguridad en ese momento, por lo que se ha dejado en suspenso. Sin embargo, cada una de las ideas de sus ventajas se ha convertido en una de las funciones centrales de EIP4337 y EIP7702.
Después, hubo una serie de EIP que intentaron perfeccionar esta lógica:
EIP-859: abstracción de cuentas de la cadena principal (2018-01-30)
Intentar resolver problemas de implementación de Code. La función principal es: si el contrato de la parte transaccional no está implementado, se utiliza el parámetro code adjunto a la transacción para ejecutar la implementación de la billetera del contrato. Además, se propuso un nuevo código de operación PAYGAS, que además de pagar gas, también se convierte en un delimitador 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, esto se ha convertido en una de las lógicas centrales de 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 capacidades de contrato en esta transacción.
EIP-7702: establecer código de cuenta EOA (2024-05-07)
Este también es el EIP central que se discutirá más adelante en este artículo, presentado por Vitalik, como una alternativa a EIP-3074. Por lo tanto, EIP-3074 ha sido desechado, y EIP-7702 ha sido confirmado para ser incluido en la próxima bifurcación dura ETH Prague/Electra(Pectra), cuyos detalles se desarrollarán a continuación.
( 3.2 Segunda ruta: permitir que la dirección EOA impulse la dirección CA
EIP-3074: añadir los códigos de operación AUTH y AUTHCALL )2020-10-15###
Agregar dos nuevos códigos de operación AUTH y AUTHCALL en EVM, permitiendo que EOA autorice a contratos a llamar a otros contratos en lugar de usar la identidad de EOA a través de estos códigos de operación.
En pocas palabras, una EOA puede enviar un mensaje firmado ( a un contrato en el que confía, llamado Invoker ). Este contrato Invoker puede utilizar los códigos de operación AUTH y AUTHCALL para enviar transacciones en lugar de esta EOA.
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 inspirándose en MEV, y su valor central radica en evitar por completo los cambios en el protocolo de la capa de consenso.
EIP4337 propuso un nuevo objeto de transacción UserOperation, que los usuarios envían al pool de memoria, y los bundlers lo empaquetan en lotes desde la perspectiva de los mineros para entregar la ejecución del contrato de transacciones. Esencialmente, esto lleva las transacciones subyacentes y la operación de cuentas a un nivel de ejecución de contrato.
EIP-5189: Operar cuentas abstractas a través de endosantes (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 multas de fondos (endorser) para prevenir ataques de bloqueo DoS maliciosos de Bundler.
( 3.3 Otras propuestas para apoyar la abstracción de cuentas
EIP-2718: sobre envoltura de nuevos tipos 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 transacciones.
El efecto final es que, al introducir un nuevo tipo de transacción, se diferencian las distintas transacciones mediante una codificación específica, lo que permite que solo necesiten ser compatibles hacia atrás, sin necesidad de ser compatibles 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 y no afecta al tipo de transacción legacy original.
EIP-3607: prohibir la implementación de contratos por direcciones EOA )2021-06-10###
Esta es una solución complementaria en la ruta AA, utilizada para evitar el problema de conflicto entre la dirección de despliegue del contrato y la dirección EOA. Controlará el método de generación del contrato, no permitiendo que el sistema despliegue código en una dirección que ya sea una dirección EOA. Este riesgo es en realidad muy bajo, ya que 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 la dirección del contrato específico, según la estimación de la potencia de cálculo de toda la red de Bitcoin, también tomaría 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.
Básicamente, es 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 de desarrollo del mercado: muchas Dapps aún no son compatibles, lo que lleva a los usuarios a no querer usar direcciones CA. Incluso el uso de CA puede generar costos de transacción más altos ) en escenarios de transferencia normal, las tarifas de transacción pueden duplicarse (, y también depende demasiado de la compatibilidad de la Dapp en sí.
Por lo tanto, aún 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.
Pero para reducir realmente el GAS, es necesario realizar una actualización de bifurcación suave en Ethereum mismo, modificando el cálculo de GAS o los módulos de consumo de GAS de los códigos de operación, entre otros. Dado que se va a hacer una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?
![Análisis profundo de la abstracción de cuentas de Ethereum: pasado y futuro])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp###
4. Análisis completo de EIP-7702
( 4.1 ¿Qué es EIP-7702?
Distingue a través de un nuevo tipo de transacción, permitiendo que una EOA tenga temporalmente la funcionalidad de un contrato inteligente en una sola transacción, lo que a su vez apoya operaciones comerciales como transacciones por lotes, transacciones sin Gas y gestión de permisos personalizados, todo ello sin necesidad de introducir nuevos códigos de operación EVM ) que afecten la compatibilidad hacia adelante (.
Puede permitir a los usuarios obtener la mayoría de las capacidades de AA sin desplegar contratos inteligentes, e incluso puede ofrecer la capacidad a terceros para iniciar transacciones en nombre del usuario, sin necesidad de que el usuario proporcione su clave privada, solo necesita firmar la información de autorización.
) 4.2 estructura de datos
Define un nuevo tipo de transacción 0x04, cuyo TransactionPayload es el resultado de la serialización RLP del siguiente contenido:
rlp###[ chain_id, // ID de cadena, utilizado para prevenir ataques de repetición nonce, // contador de transacciones, asegura la unicidad de la transacción max_priority_fee_per_gas, // tarifa de transacción 1559 max_fee_per_gas, // tarifa de transacción 1559 gas_limit, destino, // dirección 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, 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 contrato al mismo tiempo que firma la transacción, y este se presenta como una lista bidimensional, indicando lo que se puede