Análisis en profundidad del pasado y 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 AA de 2015, sistematiza el contenido de las principales propuestas de EIP hasta la fecha, explora el desarrollo histórico de las propuestas de AA y realiza una evaluación integral de cada plan.
La segunda parte se centra en comparar la reacción del mercado tras el lanzamiento de EIP4337, así como en analizar en profundidad el EIP7702 que se incluirá en la próxima versión de actualización de Ethereum. Una vez que esta propuesta se combine, cambiará por completo la forma de las aplicaciones en la cadena.
EIP-7702 tiene un significado revolucionario, vamos a profundizar en ello.
1. El contexto de la abstracción de cuentas
1.1 la ubicación del significado de la abstracción de cuentas
El fundador de Ethereum, Vitalik, actualizó nuevamente la hoja de ruta de desarrollo de ETH a finales de 2023, pero la posición sobre la abstracción de cuentas no ha cambiado. El modelo principal actual está pasando de EIP-4337 a la próxima etapa de "conversión voluntaria de cuentas EOA".
1.2 estado 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 cadenas más populares es de solo 12 millones, de las cuales solo 6,764 son direcciones activas en la red principal de Ethereum, lo que representa una gran diferencia en comparación con el 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 el desarrollo de EIP4337 en la red principal ha sido lento.
Sin embargo, esto no afecta el valor esencial de AA. El diseño de EIP4337 predestina que sea difícil de ser compatible hacia adelante en la mainnet. Con la integración generalizada de AA nativa en varias cadenas L2, el número de direcciones de EIP4337 ha explotado en L2, con la actividad mensual de julio de las cadenas Base y Polygon alcanzando 1 millón y 3 millones respectivamente, mostrando un buen desempeño.
Por lo tanto, el diseño de EIP4337 no es erróneo, tiene muchas ventajas. La situación actual se debe a las diferencias entre la mainnet y L2, que requieren 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 EVM hay dos tipos de cuentas: cuenta externa ( EOA ) y cuenta de contrato ( CA ). En la cuenta externa, la propiedad 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 también el derecho a "firmar la transferencia de todos los activos".
Esto está determinado por la estructura de transacción de la cuenta de Ethereum. A partir de la estructura de la transacción, se puede ver que una transacción estándar en realidad no tiene el campo From. Al transferir fondos, la dirección específica de consumo se obtiene mediante el parámetro VRS (, es decir, la firma del usuario se resuelve a la inversa ).
El efecto central de EIP4337 es que se ha añadido la dirección del remitente en el campo de transacción, logrando así la separación entre 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 cuentas externas (EOA) dará lugar a muchos problemas:
Dificultad para proteger la clave privada: perder la clave privada significa perder todos los activos.
Algoritmo de firma único: la verificación de transacciones del protocolo nativo solo puede utilizar el algoritmo ECDSA.
Permisos de firma demasiado altos: sin función nativa de múltiples firmas, se puede ejecutar cualquier operación con una sola firma.
La tarifa de transacción solo se puede pagar con Ether, no se admite la negociación en lote.
La privacidad de las transacciones es fácil de filtrar: 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:
Primero, el usuario debe poseer Ether y asumir el riesgo de fluctuaciones de precios.
En segundo lugar, los usuarios necesitan manejar la lógica compleja de tarifas, como el precio del Gas, el límite de Gas y conceptos como el bloqueo de transacciones.
Por último, las billeteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización del producto, pero los efectos 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), lo que permitirá resolver gradualmente los problemas mencionados anteriormente.
A lo largo de la historia, ha habido varias propuestas, que finalmente se reducen a dos rutas.
3. Organización de la historia de las 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 problema considerado en las EIP no aprobadas se ha convertido en un punto de avance para las soluciones existentes.
3.1 Primera ruta: convertir la dirección EOA en una dirección CA
Desde noviembre de 2015, Vitalik propuso una nueva estructura de cuenta basada en contratos en el EIP-101. Cambiando la dirección para que solo contenga código y espacio de almacenamiento, soporta el pago de tarifas en ERC20, y a través de contratos precompilados convierte los tokens nativos en un saldo similar al de ERC20, simplificando los campos de transacción a to, startgas, data y code.
Este plan puede considerarse una revolución de gran salto, modificará significativamente el diseño subyacente, permitiendo que cada dirección de cuenta tenga su propia lógica de "código". ( es precisamente el efecto que EIP-7702 busca lograr ).
También puede derivar otras funciones, como:
Permitir que las transacciones utilicen más algoritmos criptográficos, especificando el método de verificación y autenticación a través del Código interno de cada dirección.
Tiene características de resistencia a ataques cuánticos, porque el código puede ser actualizado.
Hacer que Ether tenga las mismas funciones que un contrato ERC20, como la autorización de retención.
Mejorar el 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ó avanzando es principalmente porque se dieron pasos demasiado grandes, y no se consideraron adecuadamente los problemas actuales de colisión de hash en las transacciones y los riesgos de seguridad. Sin embargo, cada concepto positivo se ha convertido en una de las funciones clave de los posteriores EIP4337 y EIP7702.
Posteriormente, hay una serie de EIP que intentan perfeccionar esta lógica:
EIP-859: abstracción de cuentas de la cadena principal (2018-01-30)
Intentar resolver el problema de despliegue del código. La función principal es que, 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 monedero del contrato. También se propone un nuevo código de operación PAYGAS, que además de pagar el gas, también sirve como separador entre la parte de verificación y la parte de ejecución en los parámetros de la transacción.
Aunque no tuvo éxito en ese momento, esto se convirtió en una de las lógicas centrales de EIP7702. Cada transacción de EIP7702, combinada con una estructura de transacción especial, puede adjuntar un cierto código, permitiendo que la cuenta EOA tenga capacidades 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, propuesto por Vitalik como una alternativa a EIP-3074. EIP-3074 ha sido desechado, y EIP-7702 se incluirá en la próxima bifurcación dura ETH Prague/Electra(Pectra).
3.2 Segunda ruta: permitir que la dirección EOA impulse la dirección CA
EIP-3074: aumento de los códigos de operación AUTH y AUTHCALL (2020-10-15)
Agregar dos nuevos OpCode en EVM: AUTH y AUTHCALL, para que EOA pueda autorizar a contratos a llamar a otros contratos en lugar de utilizar la identidad de EOA mediante estos dos opcode.
En resumen, un EOA puede enviar un mensaje firmado ( y una transacción ) 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 emitir transacciones en lugar del EOA.
EIP-4337: implementar la abstracción de cuentas mediante el grupo de memoria de transacciones )2021-09-29(
Diseñado con inspiración 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 UserOperation, que los usuarios envían a la memoria, y los bundlers lo empaquetan en lotes desde la perspectiva de los mineros para entregar la ejecución de transacciones del contrato, esencialmente elevando las transacciones subyacentes y la operación de cuentas al nivel del contrato.
EIP-5189: a través de la operación de patrocinadores de abstracción de cuentas )2022-06-29(
Esta es una optimización de la lógica de EIP4337, que establece un mecanismo de respaldo de penalización de fondos para prevenir ataques de bloqueo DoS por parte de Bundlers maliciosos.
) 3.3 Otras propuestas que apoyan la abstracción de cuentas
EIP-2718: envoltura de nuevo tipo de transacción ###2020-06-13(
Esta es una propuesta que ya está Final, definiendo un nuevo tipo de transacción como el sobre para futuros tipos de transacciones que se añadirán.
El efecto final es que al introducir un nuevo tipo de transacción, se diferencia el tipo de transacción mediante una codificación específica, solo necesita ser compatible hacia atrás, sin necesidad de ser compatible 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: hacer que la dirección EOA no pueda desplegar contratos )2021-06-10(
Esta es una solución complementaria en la ruta AA, utilizada para prevenir conflictos 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 se despliegue código en direcciones que ya son direcciones EOA. Este riesgo es en realidad muy pequeño, 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, se estima que con toda la potencia de cálculo de Bitcoin también tomaría un año.
) 3.4 ¿Cómo entender la evolución de la abstracción de cuentas?
Primero hay que entender el valor que se convierte a CA, básicamente es el efecto real de EIP-4337:
Soporte para transacciones por lotes
Soporte para recuperación social
Soporte para la verificación de firma personalizada
No se requieren tokens nativos para pagar tarifas.
Gestión de permisos más granular
Escalabilidad
Sin embargo, la principal desventaja de EIP-4337 es que va en contra del principio de motivación humana.
Parece mejor, pero cae en un ciclo vicioso del desarrollo del mercado: muchas Dapp aún no son compatibles, los usuarios no quieren usar direcciones de cuenta, usar cuentas en realidad tiene un costo de transacción más alto en comparación con ### escenarios de transferencias normales, las tarifas de transacción se duplican en (, y hay una dependencia excesiva de la compatibilidad de la Dapp en sí.
Por lo tanto, aún no se ha difundido en la red principal de Ethereum.
El costo es el criterio más importante para los usuarios, y debe reducirse.
Pero para reducir realmente el GAS, es necesario que Ethereum en sí realice una actualización de bifurcación suave, modificando el cálculo de GAS o el consumo de GAS de los códigos de operación, entre otros módulos. Dado que se necesita una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?
![Análisis profundo del pasado y futuro de la abstracción de cuentas de Ethereum])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. Análisis completo de EIP-7702
) 4.1 ¿Qué es EIP-7702?
Permite que las EOA tengan temporalmente funciones de contratos inteligentes en una sola transacción a través de un nuevo tipo de transacción, soportando transacciones en lote, transacciones sin Gas y gestión de permisos personalizada, sin necesidad de introducir un nuevo opCode de EVM que afecte la compatibilidad hacia adelante ###.
Los usuarios pueden obtener la mayoría de las capacidades de AA sin necesidad de desplegar contratos inteligentes, e incluso pueden proporcionar a terceros la capacidad de 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:
Es importante que se haya añadido el 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 el código del contrato que se va a ejecutar, existiendo como una lista bidimensional, lo que permite almacenar múltiples informaciones de operación y realizar operaciones por lotes.
Al comenzar la ejecución de la transacción, para cada tupla [chain_id, address, nonce, y_parity, r, s] de authorization_list:
Recuperar la dirección del firmante a partir de la firma r, s con ecrecover.
Verifique la cadena ID### para evitar la reproducción de cadenas bifurcadas ###.
Verificar si el código del firmante de authority está vacío o ha sido delegado.
Verificar el nonce del firmante authority ( para prevenir la repetición de la firma authority ).
Establecer el código del firmante de authority en 0xef0100 || address( para eludir la estrategia de prevención de colisiones EIP3607).
Aumentar el nonce de los firmantes de authority ( para prevenir la reproducción de firmas parciales ).
Agregar la cuenta del firmante de authority a la lista de direcciones visitadas ( y reducir los gastos de gas de almacenamiento de consulta ).
(# 4.3.2 Fase de ejecución de operaciones
La "nueva" versión solo ha cambiado el comportamiento de implementación del código.
No se debe establecer account_code como contract_code, sino que se debe recuperar el código especificado por address de authorization_list y establecerlo como account_code.
Al ejecutar el código autorizado, carga el código desde el campo de dirección de authorization_list y ejecútalo en el contexto de la cuenta del firmante.
Esto significa que el código del contrato del usuario se almacena realmente en una dirección específica en la cadena, en lugar de estar contenido directamente en la transacción.
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.
11 me gusta
Recompensa
11
7
Compartir
Comentar
0/400
LiquidationWizard
· 07-25 01:53
¿Qué demonios está haciendo el 7702?
Ver originalesResponder0
GasWaster
· 07-24 18:03
omg otro eip... gasté 2eth en transacciones fallidas el año pasado y ¿ahora me dicen esto?
Ver originalesResponder0
EntryPositionAnalyst
· 07-24 15:19
AA ha vuelto a tener popularidad en pocos días.
Ver originalesResponder0
MetaMuskRat
· 07-22 06:03
Otra vez empezando a hablar de AA, ¿es la misma botella vieja con vino nuevo de la cadena de bloques?
Ver originalesResponder0
WenAirdrop
· 07-22 05:57
Cadena de bloques熬夜Subida repentina狗
Ver originalesResponder0
CryptoAdventurer
· 07-22 05:56
tontos evolución 7702ª episodio se ha lanzado
Ver originalesResponder0
StakeOrRegret
· 07-22 05:47
Está un poco seco, ¿puede haber un poco más de agua?
EIP-7702 transformará el ecosistema de Ethereum. La abstracción de cuentas entra en una nueva era.
Análisis en profundidad del pasado y 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 AA de 2015, sistematiza el contenido de las principales propuestas de EIP hasta la fecha, explora el desarrollo histórico de las propuestas de AA y realiza una evaluación integral de cada plan.
La segunda parte se centra en comparar la reacción del mercado tras el lanzamiento de EIP4337, así como en analizar en profundidad el EIP7702 que se incluirá en la próxima versión de actualización de Ethereum. Una vez que esta propuesta se combine, cambiará por completo la forma de las aplicaciones en la cadena.
EIP-7702 tiene un significado revolucionario, vamos a profundizar en ello.
1. El contexto de la abstracción de cuentas
1.1 la ubicación del significado de la abstracción de cuentas
El fundador de Ethereum, Vitalik, actualizó nuevamente la hoja de ruta de desarrollo de ETH a finales de 2023, pero la posición sobre la abstracción de cuentas no ha cambiado. El modelo principal actual está pasando de EIP-4337 a la próxima etapa de "conversión voluntaria de cuentas EOA".
1.2 estado 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 cadenas más populares es de solo 12 millones, de las cuales solo 6,764 son direcciones activas en la red principal de Ethereum, lo que representa una gran diferencia en comparación con el 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 el desarrollo de EIP4337 en la red principal ha sido lento.
Sin embargo, esto no afecta el valor esencial de AA. El diseño de EIP4337 predestina que sea difícil de ser compatible hacia adelante en la mainnet. Con la integración generalizada de AA nativa en varias cadenas L2, el número de direcciones de EIP4337 ha explotado en L2, con la actividad mensual de julio de las cadenas Base y Polygon alcanzando 1 millón y 3 millones respectivamente, mostrando un buen desempeño.
Por lo tanto, el diseño de EIP4337 no es erróneo, tiene muchas ventajas. La situación actual se debe a las diferencias entre la mainnet y L2, que requieren 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 EVM hay dos tipos de cuentas: cuenta externa ( EOA ) y cuenta de contrato ( CA ). En la cuenta externa, la propiedad 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 también el derecho a "firmar la transferencia de todos los activos".
Esto está determinado por la estructura de transacción de la cuenta de Ethereum. A partir de la estructura de la transacción, se puede ver que una transacción estándar en realidad no tiene el campo From. Al transferir fondos, la dirección específica de consumo se obtiene mediante el parámetro VRS (, es decir, la firma del usuario se resuelve a la inversa ).
El efecto central de EIP4337 es que se ha añadido la dirección del remitente en el campo de transacción, logrando así la separación entre 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 cuentas externas (EOA) dará lugar a muchos problemas:
Dificultad para proteger la clave privada: perder la clave privada significa perder todos los activos.
Algoritmo de firma único: la verificación de transacciones del protocolo nativo solo puede utilizar el algoritmo ECDSA.
Permisos de firma demasiado altos: sin función nativa de múltiples firmas, se puede ejecutar cualquier operación con una sola firma.
La tarifa de transacción solo se puede pagar con Ether, no se admite la negociación en lote.
La privacidad de las transacciones es fácil de filtrar: 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:
Primero, el usuario debe poseer Ether y asumir el riesgo de fluctuaciones de precios.
En segundo lugar, los usuarios necesitan manejar la lógica compleja de tarifas, como el precio del Gas, el límite de Gas y conceptos como el bloqueo de transacciones.
Por último, las billeteras o aplicaciones de blockchain intentan mejorar la experiencia del usuario a través de la optimización del producto, pero los efectos 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), lo que permitirá resolver gradualmente los problemas mencionados anteriormente.
A lo largo de la historia, ha habido varias propuestas, que finalmente se reducen a dos rutas.
3. Organización de la historia de las 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 problema considerado en las EIP no aprobadas se ha convertido en un punto de avance para las soluciones existentes.
3.1 Primera ruta: convertir la dirección EOA en una dirección CA
Desde noviembre de 2015, Vitalik propuso una nueva estructura de cuenta basada en contratos en el EIP-101. Cambiando la dirección para que solo contenga código y espacio de almacenamiento, soporta el pago de tarifas en ERC20, y a través de contratos precompilados convierte los tokens nativos en un saldo similar al de ERC20, simplificando los campos de transacción a to, startgas, data y code.
Este plan puede considerarse una revolución de gran salto, modificará significativamente el diseño subyacente, permitiendo que cada dirección de cuenta tenga su propia lógica de "código". ( es precisamente el efecto que EIP-7702 busca lograr ).
También puede derivar otras funciones, como:
Permitir que las transacciones utilicen más algoritmos criptográficos, especificando el método de verificación y autenticación a través del Código interno de cada dirección.
Tiene características de resistencia a ataques cuánticos, porque el código puede ser actualizado.
Hacer que Ether tenga las mismas funciones que un contrato ERC20, como la autorización de retención.
Mejorar el 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ó avanzando es principalmente porque se dieron pasos demasiado grandes, y no se consideraron adecuadamente los problemas actuales de colisión de hash en las transacciones y los riesgos de seguridad. Sin embargo, cada concepto positivo se ha convertido en una de las funciones clave de los posteriores EIP4337 y EIP7702.
Posteriormente, hay una serie de EIP que intentan perfeccionar esta lógica:
EIP-859: abstracción de cuentas de la cadena principal (2018-01-30)
Intentar resolver el problema de despliegue del código. La función principal es que, 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 monedero del contrato. También se propone un nuevo código de operación PAYGAS, que además de pagar el gas, también sirve como separador entre la parte de verificación y la parte de ejecución en los parámetros de la transacción.
Aunque no tuvo éxito en ese momento, esto se convirtió en una de las lógicas centrales de EIP7702. Cada transacción de EIP7702, combinada con una estructura de transacción especial, puede adjuntar un cierto código, permitiendo que la cuenta EOA tenga capacidades 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, propuesto por Vitalik como una alternativa a EIP-3074. EIP-3074 ha sido desechado, y EIP-7702 se incluirá en la próxima bifurcación dura ETH Prague/Electra(Pectra).
3.2 Segunda ruta: permitir que la dirección EOA impulse la dirección CA
EIP-3074: aumento de los códigos de operación AUTH y AUTHCALL (2020-10-15)
Agregar dos nuevos OpCode en EVM: AUTH y AUTHCALL, para que EOA pueda autorizar a contratos a llamar a otros contratos en lugar de utilizar la identidad de EOA mediante estos dos opcode.
En resumen, un EOA puede enviar un mensaje firmado ( y una transacción ) 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 emitir transacciones en lugar del EOA.
EIP-4337: implementar la abstracción de cuentas mediante el grupo de memoria de transacciones )2021-09-29(
Diseñado con inspiración 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 UserOperation, que los usuarios envían a la memoria, y los bundlers lo empaquetan en lotes desde la perspectiva de los mineros para entregar la ejecución de transacciones del contrato, esencialmente elevando las transacciones subyacentes y la operación de cuentas al nivel del contrato.
EIP-5189: a través de la operación de patrocinadores de abstracción de cuentas )2022-06-29(
Esta es una optimización de la lógica de EIP4337, que establece un mecanismo de respaldo de penalización de fondos para prevenir ataques de bloqueo DoS por parte de Bundlers maliciosos.
) 3.3 Otras propuestas que apoyan la abstracción de cuentas
EIP-2718: envoltura de nuevo tipo de transacción ###2020-06-13(
Esta es una propuesta que ya está Final, definiendo un nuevo tipo de transacción como el sobre para futuros tipos de transacciones que se añadirán.
El efecto final es que al introducir un nuevo tipo de transacción, se diferencia el tipo de transacción mediante una codificación específica, solo necesita ser compatible hacia atrás, sin necesidad de ser compatible 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: hacer que la dirección EOA no pueda desplegar contratos )2021-06-10(
Esta es una solución complementaria en la ruta AA, utilizada para prevenir conflictos 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 se despliegue código en direcciones que ya son direcciones EOA. Este riesgo es en realidad muy pequeño, 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, se estima que con toda la potencia de cálculo de Bitcoin también tomaría un año.
) 3.4 ¿Cómo entender la evolución de la abstracción de cuentas?
Primero hay que entender el valor que se convierte a CA, básicamente es el efecto real de EIP-4337:
Sin embargo, la principal desventaja de EIP-4337 es que va en contra del principio de motivación humana.
Parece mejor, pero cae en un ciclo vicioso del desarrollo del mercado: muchas Dapp aún no son compatibles, los usuarios no quieren usar direcciones de cuenta, usar cuentas en realidad tiene un costo de transacción más alto en comparación con ### escenarios de transferencias normales, las tarifas de transacción se duplican en (, y hay una dependencia excesiva de la compatibilidad de la Dapp en sí.
Por lo tanto, aún no se ha difundido en la red principal de Ethereum.
El costo es el criterio más importante para los usuarios, y debe reducirse.
Pero para reducir realmente el GAS, es necesario que Ethereum en sí realice una actualización de bifurcación suave, modificando el cálculo de GAS o el consumo de GAS de los códigos de operación, entre otros módulos. Dado que se necesita una bifurcación suave, ¿por qué no considerar directamente el EIP-7702?
![Análisis profundo del pasado y futuro de la abstracción de cuentas de Ethereum])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. Análisis completo de EIP-7702
) 4.1 ¿Qué es EIP-7702?
Permite que las EOA tengan temporalmente funciones de contratos inteligentes en una sola transacción a través de un nuevo tipo de transacción, soportando transacciones en lote, transacciones sin Gas y gestión de permisos personalizada, sin necesidad de introducir un nuevo opCode de EVM que afecte la compatibilidad hacia adelante ###.
Los usuarios pueden obtener la mayoría de las capacidades de AA sin necesidad de desplegar contratos inteligentes, e incluso pueden proporcionar a terceros la capacidad de 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, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s]###
Es importante que se haya añadido el 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 el código del contrato que se va a ejecutar, existiendo como una lista bidimensional, lo que permite almacenar múltiples informaciones de operación y realizar operaciones por lotes.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
( 4.3 ciclo de vida de la transacción
)# 4.3.1 fase de validación
Al comenzar la ejecución de la transacción, para cada tupla [chain_id, address, nonce, y_parity, r, s] de authorization_list:
(# 4.3.2 Fase de ejecución de operaciones
La "nueva" versión solo ha cambiado el comportamiento de implementación del código.
No se debe establecer account_code como contract_code, sino que se debe recuperar el código especificado por address de authorization_list y establecerlo como account_code.
Al ejecutar el código autorizado, carga el código desde el campo de dirección de authorization_list y ejecútalo en el contexto de la cuenta del firmante.
Esto significa que el código del contrato del usuario se almacena realmente en una dirección específica en la cadena, en lugar de estar contenido directamente en la transacción.