Autor: Shijunjun
Prefacio
Este artículo se divide en dos módulos principales:
En la primera mitad, a partir de la primera propuesta de AA en 2015, clasificaremos sistemáticamente los contenidos principales de las propuestas de EIP hasta el momento. Esperamos excavar la historia de las propuestas históricas de AA y evaluar de manera integral las ventajas y desventajas de cada plan.
En la segunda mitad, nos centramos en comparar los comentarios sobre la caída del mercado que enfrentó EIP4337 después de su propuesta, y luego realizamos un análisis en profundidad de EIP7702, que está a punto de incluirse en la próxima versión de actualización de Ethereum. La propuesta se fusiona, cambiará completamente el formulario de solicitud en la cadena.
EIP-7702 tiene cambios que marcan época, escuche la explicación detallada del Sr. Shishi
1. Antecedentes abstractos de la cuenta
1.1 El significado de la abstracción de cuentas
Vitalik, el fundador de Ethereum, actualizó una vez más la hoja de ruta de desarrollo de ETH a finales de 2023, pero la configuración de abstracción de la cuenta no ha cambiado. El modelo principal actual también ha entrado en la siguiente etapa desde EIP-4337, Conversión Voluntaria de EOA (conversión voluntaria de cuenta EOA).
Más de un año desde el lanzamiento de EIP4337 (en WalletCon en Denver el 1 de marzo de 2023, se anunció oficialmente que el contrato central de ERC-4337 diseñado e implementado por los desarrolladores de la Fundación Ethereum pasó la auditoría de OpenZeppelin y se considera el lanzamiento oficial del nodo de historia).
Siempre ha sido ampliamente reconocido por los usuarios, pero no se utiliza ampliamente en un entorno de mercado tan contradictorio, el progreso de EIP-7702 ha avanzado mucho e incluso se ha confirmado que se incorporará en la próxima actualización.
1.2 Estado actual del mercado de abstracción de cuentas
Sin más, veamos los datos.
Después de un año y medio de desarrollo, EIP4337 solo tiene 12 millones de direcciones en la colección de cuentas de la cadena principal. Lo más sorprendente es que en la red principal de Ethereum, solo hay 6,764 direcciones activas. Quizás haya algún problema con la dimensión estadística. , pero al menos hay una gran diferencia entre la cantidad de direcciones en EOA y CA. Debe saber que la cantidad de direcciones independientes en la red principal de Ethereum ha alcanzado los 270 millones (fuente de datos: https://etherscan.io/chart/). DIRECCIÓN).
Se puede decir que EIP4337 no tiene un desarrollo sustancial en la red principal.
Sin embargo, esto no elimina el valor esencial de AA, porque estaba destinado desde el principio del diseño de EIP4337 a que no podría funcionar bien frente a problemas graves de compatibilidad con versiones posteriores en la red principal, por lo que con el desarrollo de varios Cadenas de capa L2 Universalmente integradas en AA nativo, la cantidad de direcciones EIP4337 se ha disparado en L2. Los usuarios activos mensuales de las cadenas base y poligonal en julio fueron 1 millón y 3 millones respectivamente, lo cual es bastante impresionante.
Por lo tanto, no es que el diseño de EIP4337 sea incorrecto. Tiene muchas ventajas. Lo resumiremos sistemáticamente en un momento. La situación actual se debe a las diferencias entre la red principal y L2. .
2. ¿Qué es la abstracción de cuenta?
La abstracción de cuentas suena confusa, pero en realidad resuelve esencialmente el problema de la separación de los derechos de propiedad.
Hay dos tipos de cuentas en la arquitectura EVM (es decir, la máquina virtual Ethereum), la cuenta externa (EOA) y la cuenta de contrato (Cuenta de contrato). Los derechos de propiedad y firma de la cuenta externa en realidad pertenecen al mismo individuo. unidad. La persona que posee la clave privada no sólo tiene la "propiedad" de la cuenta, sino que también tiene derecho a "firmar y transferir todos los activos".
Esto está determinado por la estructura de transacciones de la cuenta Ethereum.
Como se puede ver en la estructura de la figura siguiente, de hecho, no hay una parte de origen en las transacciones estándar de Ethereum. Entonces, ¿qué dirección consumió específicamente los fondos? De hecho, la dirección De se decodifica a través de su parámetro VRS (es decir, la firma del usuario).
Esto implica cifrado asimétrico como ECDSA, función de umbral unidireccional y otros conceptos. No lo ampliaremos. En resumen, la criptografía se utiliza para garantizar la seguridad. Por supuesto, esto también ha causado el dilema de la dirección EOA de los derechos de propiedad actuales. fusión.
El efecto principal de EIP4337 es agregar el campo Dirección del remitente al campo de transacción, separando así la clave privada de la dirección operada.
Entonces, ¿por qué es tan importante la separación de los derechos de propiedad?
Porque el diseño de la cuenta externa (EOA) dará lugar a más problemas:
Las claves privadas son difíciles de proteger: la pérdida de sus claves privadas por parte de los usuarios (pérdida, ataque de piratas informáticos, craqueo criptográfico) significa perder todos sus activos.
Pocos algoritmos de firma: el protocolo nativo solo puede utilizar algoritmos de firma ECDSA y de verificación de firma para verificar transacciones.
Alta autoridad de firma: no existe una firma múltiple nativa (la firma múltiple solo puede colaborar a través de contratos inteligentes) y cualquier operación se puede realizar con una sola firma.
Las tarifas de transacción solo se pueden pagar a través de ETH y no se admiten transacciones por lotes.
Fuga de privacidad de transacciones: las transacciones uno a uno facilitan el análisis de la información privada del titular de la cuenta.
Las limitaciones de atractivo dificultan que los usuarios comunes utilicen Ethereum:
En primer lugar, para utilizar cualquier aplicación en Ethereum, los usuarios deben tener ether (y asumir el riesgo de fluctuaciones en el precio del ether).
En segundo lugar, los usuarios deben lidiar con una lógica de costos compleja. Los conceptos de precio del gas, límite del gas y bloqueo de transacciones (orden Nonce) son demasiado complejos para los usuarios.
Finalmente, aunque muchas billeteras o aplicaciones blockchain intentan mejorar la experiencia del usuario mediante la optimización del producto, sus efectos reales son mínimos.
Por lo tanto, la forma de solucionar esta situación es implementar la abstracción de cuentas y desacoplar la propiedad (propietario) y los derechos de firma (firmante), de modo que los problemas anteriores puedan resolverse uno por uno.
De hecho, existen muchos planes históricos y eventualmente convergerán en dos rutas.
3. Revisar el historial de las propuestas de AA.
Parece haber muchas propuestas de EIP para resolver el problema, pero en última instancia, hay dos ideas centrales. Por lo tanto, las cuestiones consideradas en cada EIP que no se aprobaron en el pasado han convergido en la solución del plan actual.
3.1 La primera ruta es cambiar la dirección EOA a una dirección CA
Ya el 15 de noviembre de 2015, en torno a EIP-101, Vitalik propuso una nueva estructura utilizando contratos como cuentas. Cambie la dirección a solo código y espacio de almacenamiento, cambie la tarifa de manejo para admitir el pago mediante ERC20, cambie el token nativo a tipo ERC20 para ahorrar saldo a través de un contrato precompilado (puede tener funciones como retención de autorización), agilice los campos de transacción solo a, gas de arranque, datos y código.
Ahora parece que es simplemente un cambio al estilo del Gran Salto Adelante, que cambiará significativamente el diseño subyacente para que cada dirección de cuenta tenga su propia lógica de "código" (de hecho, esto es exactamente lo que EIP-7702 está tratando de lograr ahora). ).
También se pueden derivar otras funciones, como
Permita que las transacciones utilicen más algoritmos de cifrado y el método de verificación de firma se puede especificar mediante el código interno de cada dirección.
Es resistente a ataques cuánticos porque el código tiene características de actualización.
Deje que Ethereum tenga las mismas características funcionales que el contrato ERC20, y el efecto central es la retención de autorización, por lo que no hay necesidad de perder la moneda nativa.
Mejorar el espacio de personalización de la cuenta, compatible con recuperación social, soporte sbt, recuperación de claves, etc.
La razón para no continuar avanzando también es muy simple: obviamente, el ritmo es demasiado grande. En cuanto al problema actual del conflicto de hash de las transacciones y los riesgos de seguridad, se ha dejado de lado debido a una consideración insuficiente. Se ha convertido en una de las funciones principales de los siguientes EIP4337 y EIP7702.
Posteriormente, hubo una serie de EIP que intentaron mejorar esta lógica.
EIP-859: abstracción de la cuenta de la cadena principal--2018-01-30
Para intentar resolver el problema de la implementación del código, la función principal es que si el contrato de la parte de la transacción no se implementa, los parámetros del código adjuntos a la transacción se utilizan para ejecutar la implementación de la billetera del contrato. En segundo lugar, también se propone un nuevo código de operación PAYGAS. Además de pagar el gas, también se convierte en una transacción. El separador entre la parte de verificación y la parte de ejecución de los parámetros de la transacción.
Aunque terminó en vano en ese momento, ahora se ha convertido en una de las lógicas centrales de EIP7702. Cada transacción de EIP7702 se combina con una estructura de transacción especial y puede ir acompañada de un código determinado, de modo que la dirección EOA tenga capacidades de contrato. esta transacción.
EIP-7702: Establecer código de cuenta EOA 2024-05-07
Este es también el EIP principal del mecanismo que se analiza más adelante en este artículo. EIP-7702 fue publicado por Vitalik como alternativa a EIP-3074 (2024-05-07). Por lo tanto, se abandona EIP-3074 y se determina que EIP-7702 se incluirá en la próxima bifurcación dura de ETH Praga/Electra (Pectra). Ampliaremos los detalles a continuación.
3.2 La segunda ruta es dejar que la dirección EOA controle la dirección CA
EIP-3074: Agregar códigos de operación AUTH y AUTHCALL--2020-10-15
Se agregan dos nuevos códigos de operación AUTH y AUTHCALL al EVM, lo que permite a EOA llamar a otros contratos a través de estos dos contratos de autorización de código de operación en lugar de la identidad de EOA.
Combinado con la figura siguiente, en resumen, un EOA puede enviar un mensaje firmado (transacción) a un contrato en el que confía (llamado Invoker). Este contrato de Invoker puede usar los códigos de operación AUTH y AUTHCALL para reemplazar este EOA y enviar esta transacción. comercio.
EIP-4337: Uso del grupo de memoria de transacciones para implementar la abstracción de cuentas--2021-09-29
Ya he escrito muchos artículos al respecto que analizan profundamente su mecanismo. Puedes leer más:
https://research.web3caff.com/zh/archives/3212，
Interpretación del plan de revisión para la abstracción de cuentas Ethereum ERC4337 (Parte 1)
Informe de investigación abstracto de 10,000 palabras de la cuenta Ethereum: desmantelamiento de 10 propuestas EIP relacionadas y el viaje de siete años para romper el cuello de botella de decenas de millones de usuarios activos diarios
Dedique una hora a explicar el tema de la abstracción de cuentas.
En resumen, su diseño se inspiró en MEV y su valor fundamental es que los cambios en el protocolo de la capa de consenso se pueden evitar por completo.
eip4337 propuso un nuevo objeto de transacción UserOperation. Los usuarios envían este objeto al grupo de memoria y los paquetes empaquetan y entregan contratos en lotes desde la dimensión del minero para ejecutar transacciones de transacciones. En esencia, las transacciones subyacentes y las operaciones de cuenta se llevan al nivel de contrato. ejecución.
EIP-5189: Operación de cuentas abstractas a través de endosantes—2022-06-29
Esto puede considerarse como una optimización de la lógica de EIP4337 frente a Bundler malicioso, y establece un mecanismo de aprobación de sanciones financieras para evitar ataques de bloqueo DoS.
3.3 Otras propuestas para apoyar AA
EIP-2718: Envoltura de sobres para nuevos tipos de transacciones--2020-06-13
Esta es una propuesta final que define un nuevo tipo de transacción como sobre para nuevos tipos de transacciones en el futuro.
El efecto neto es que cuando se introduce un nuevo tipo de transacción, se utiliza una codificación específica para distinguir qué tipo de transacción es, de modo que solo necesita compatibilidad con versiones anteriores, pero no con versiones anteriores. El ejemplo más común es EIP1559, que diferencia las tarifas de transacción y utiliza nuevos códigos de tipo de transacción sin afectar el tipo de transacción heredado original.
EIP-3607: Hacer que las direcciones EOA no estén disponibles para la implementación del contrato--2021-06-10
Esta es una solución complementaria en la ruta AA para evitar conflictos entre las direcciones de implementación del contrato y las direcciones EOA. Controlará el método de generación de contratos para que el sistema no permita que se implemente código en una dirección que ya sea una dirección EOA. Este riesgo es en realidad muy pequeño. Después de todo, la dirección de Ethereum tiene una longitud de 160 bits. Aunque existe un método para usar la clave privada para colisionar con la clave privada de la dirección del contrato especificada, aún tomará un año según el total. potencia informática de Bitcoin.
3.4 ¿Cómo entender el proceso de desarrollo de la abstracción de cuentas?
Primero, debe comprender el valor de la conversión a CA
Básicamente, es el efecto real de EIP-4337, él puede lograrlo.
Sin embargo, la principal deficiencia de EIP-4337 es que viola los principios de la motivación humana.
Parece ser mejor, pero ha caído en un ciclo interminable de desarrollo del mercado. Muchas Dapps no son compatibles, por lo que los usuarios no están dispuestos a usar direcciones de CA, e incluso el uso de CA tiene costos de transacción más altos (los escenarios de transferencia normales también tendrán tarifas de transacción). double), y también depende demasiado de la compatibilidad del propio Dapp.
Por lo tanto, hasta ahora no se ha popularizado en la red principal de Ethereum.
El coste es el criterio más importante para los usuarios y es necesario reducirlo.
Pero para reducir realmente el GAS, el propio Ethereum debe realizar una actualización de bifurcación suave, modificar el cálculo de GAS o modificar el consumo de GAS del código de operación y otros módulos. Sin embargo, dado que se requiere una bifurcación suave, ¿por qué no considerar directamente EIP-7702?
4. Análisis completo de EIP-7702
4.1 ¿Qué es EIP-7702?
Se distingue por nuevos tipos de transacciones, lo que permite a EOA tener temporalmente la función de un contrato inteligente en una sola transacción, admitiendo así transacciones por lotes, transacciones sin gas, gestión de permisos personalizados, etc. en el negocio, sin la necesidad de introducir un nuevo código de operación EVM (que afecta la compatibilidad futura).
Permite a los usuarios obtener la mayoría de las capacidades de AA sin implementar contratos inteligentes e incluso puede brindar a un tercero la capacidad de iniciar transacciones en nombre de los usuarios. No requiere que los usuarios proporcionen claves privadas, solo información de autorización de firma.
4.2 Estructura de datos
Define un nuevo tipo de transacción 0x04. La TransactionPayload de este tipo de transacción es el resultado de la serialización de codificación RLP del siguiente contenido.
rp([
Chain_id, // ID de cadena, utilizado para evitar ataques de repetición.
nonce, // Contador de transacciones para garantizar la unicidad de la transacción.
max_priority_fee_per_gas, //tarifa de transacción de 1559
max_fee_per_gas, //tarifa de transacción de 1559
límite_de_gas,
destino, //Dirección de destino de la transacción
valor,
datos,
access_list, //Lista de acceso, utilizada para la optimización de gas en EIP-2929.
lista_de_autorizaciones,
Signature_y_parity, // 3 parámetros de firma, utilizados para verificar la firma de la transacción.
firma_r,
firma_s
])
Lo importante es que se agrega el objeto Authorization_list para almacenar el código que el firmante quiere ejecutar en su EOA. Cuando el usuario firma la transacción, también firma el código del contrato que se ejecutará. Existe como una lista bidimensional. lo que indica que se puede almacenar información de múltiples operaciones en lotes y realizar operaciones por lotes.
lista_autorizaciones = [[id_cadena, dirección, nonce, paridad_y, r, s], ...]
4.3 Ciclo de vida de la transacción
4.3.1 Fase de verificación
Al comienzo de la ejecución de una transacción, para cada tupla lista_autorización [id_cadena, dirección, nonce, paridad_y, r, s]:
Utilice ecrecover para recuperar la dirección del firmante a partir de las firmas r y s (tenga en cuenta que este es el mecanismo del propio Ethereum, por lo que este EIP no cambia el algoritmo de firma). Authority = ecrecover(keccak(MAGIC || rlp([chain_id, dirección, nonce])), y_parity, r, s] (Similar al descifrado anterior de la firma para obtener la dirección de remitente, lo que se obtiene aquí es la firma local dirección para esta lista)
Verificar ID de cadena (repetición de cadena anti-horquilla).
Verifique si el código del firmante de autoridad está vacío o ha sido delegado (verifique si la transacción es una transacción 7702 válida y el mecanismo de delegación se utilizará para ejecutar la transacción más adelante).
Verifique el nonce del firmante de la autoridad (para evitar que se reproduzca la firma de la autoridad).
Establezca el código del firmante de autoridad en 0xef0100 || dirección (utilizada para omitir la política anticolisión EIP3607)
Aumente el nonce del firmante autorizado (para evitar la repetición parcial de la firma).
Agregue la cuenta del firmante de la autoridad a la lista de direcciones visitadas (transfiera direcciones activas para reducir las tarifas de gas para el almacenamiento de consultas)
4.3.2 Fase de operación de ejecución
¿Dónde se ejecutarán el código del contrato y las instrucciones de operación?
La versión "nueva" solo cambia el comportamiento con respecto a la implementación del código.
En lugar de configurar el código de cuenta en código_contrato, recupera la dirección del código de la lista_autorización y establece ese código como código de cuenta.
Entonces, cuando es necesario ejecutar el código de autorización, el código se carga desde la dirección especificada en el campo de dirección de Authorization_list y se ejecuta en el contexto de la cuenta del firmante.
Esto significa que el código de contrato del usuario en realidad se almacena en una dirección específica de la cadena, en lugar de incluirse directamente en la transacción.
Las instrucciones de operación y los parámetros relacionados se almacenan en el campo de datos de la carga de la transacción.
4.4 ¿Cuál es el valor de EIP-7702?
Habrá cambios en todo el enlace de la billetera Web3 y la experiencia del usuario también cambiará drásticamente porque las transacciones ordinarias iniciadas por EOA también pueden ejecutar una variedad de lógica similar a los contratos, como las transferencias por lotes. Para escenarios CeFi, afectará la identificación de transacciones y las tarifas de cobro de retiros.
Debido a su surgimiento se han roto muchos estereotipos anteriores, como por ejemplo:
Rompe la invariante de que el saldo de una cuenta solo puede reducirse mediante transacciones que se originen en esa cuenta.
Rompe la invariante de que el nonce EOA aumenta en 1 después de que comienza la ejecución de la transacción (posiblemente aumentando varios al mismo tiempo).
La lógica de protección de la comparación entre tx.origin y msg.sender está rota y muchos contratos anteriores están en riesgo.
Rompe el status quo de que la EOA por sí misma no puede emitir eventos. Puede que sea necesario prestar atención a la identificación y el seguimiento de algunos eventos en cadena.
Rompe el status quo de que las direcciones de EOA deben lograr aceptar ERC20, 721, 1155 y otros activos (puede fallar debido al mecanismo de devolución de llamada).
4.5 Comparación entre EIP-7702 y EIP-4337
1. Ventajas de EIP-7702
El gas es menor porque no es necesario pasar por el módulo de punto de entrada, lo que reduce las operaciones en cadena.
Los costos de migración de usuarios son más bajos y no es necesario implementar contratos en cadena como tema por adelantado.
En comparación con Eip4337, también habrá ejecución de delegación de código y también habrá dos métodos:
Delegación completa
La delegación completa se refiere a delegar todos los permisos para una operación a una dirección específica. Por ejemplo, los usuarios pueden delegar los derechos de administración de todos los tokens ERC-20 a una dirección de contrato inteligente, de modo que este contrato inteligente pueda realizar todas las operaciones relacionadas en nombre del usuario.
Delegación Protegida
La delegación protegida se refiere a agregar algunas restricciones y medidas de protección durante el proceso de delegación para garantizar la seguridad y controlabilidad de la operación de la delegación.
Por ejemplo, los usuarios pueden delegar la gestión de solo algunos tokens ERC-20 a un contrato inteligente o establecer algunas restricciones (como un gasto diario máximo del 1% del saldo total).
2. Desventajas de EIP-7702
Su principal defecto es que se trata de una actualización de bifurcación suave, que requiere el consenso de todos para promoverla, y los cambios son enormes, lo que tendrá un gran impacto en la ecología de la cadena. Según la evaluación inicial del Decimocuarto Rey, hay. Son los siguientes desafíos, pero los desafíos también son oportunidades de mercado:
El grado de libertad es extremadamente alto y es difícil de auditar. Los usuarios necesitarán billeteras más confiables para brindar protección de seguridad.
La estructura original ha cambiado demasiado. Aunque se distingue por diferentes tipos de transacciones, muchas infraestructuras, especialmente los contratos inmutables en la cadena, no se pueden adaptar directamente.
Se proporcionan capacidades de contrato para direcciones EOA, pero no se puede retener el espacio de almacenamiento correspondiente.
El costo de una transacción separada es ligeramente mayor porque la parte de Calldata aumentará considerablemente. El costo total estimado de la llamada será 16 (gas) * 15 (bytes) = 240 (gas) de costo de datos de llamada, más el costo de EIP-. 3860 2 * 15 = 30, más un costo de tiempo de ejecución aproximado de 150. Por lo tanto, simplemente preparar la cuenta, incluso si no haces nada, aumentará el gas en 500.
"Si el destinatario firma el código sin recibir la funcionalidad, el remitente puede enfrentar DoS al intentar enviar el activo". En realidad, el problema es que EOA A firmó algo que no debería: un archivo reproducible con una implementación incorrecta configurada (sin recepción()).
La lógica de retiro en cadena puede ser inconsistente. Por ejemplo, al transferir tokens ERC-20, si la cuenta del destinatario tiene un código, el contrato del token llamará a onERC20Received para la cuenta del destinatario. Si onERC20Received revierte o devuelve un valor incorrecto, la transferencia del token se revertirá.
Además, si EOA puede emitir eventos, ¿habrá algún problema? Es posible que algunas infraestructuras necesiten atención.
Estas son solo algunas de las deficiencias resumidas por Shishijun según el contenido actual de la propuesta EIP7702 y las correspondientes discusiones del foro oficial. Al final, es necesario analizarlo completamente en función del código de implementación final.
La referencia es la siguiente:
https://eips.ethereum.org/EIPS/eip-7702
https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
https://github.com/ethereum/EIPs/pull/8527
5. Resumen de texto completo
Este artículo parece ser muy extenso, pero en realidad el contenido del texto tiene solo unas 6.000 palabras. Muchas interpretaciones anteriores de EIP involucradas en él se pueden ampliar a través de enlaces en el artículo, por lo que no volveré a él.
En la actualidad, la abstracción de cuentas solo se puede colocar en el sexto módulo, que es para arreglar todo, es decir, finalmente se está implementando. Ahora que el progreso de EIP7702 se ha acelerado enormemente, traerá más desafíos a la seguridad del sistema. Se puede esperar que al final se dé cuenta. Después de todo, pueden ocurrir eventos disruptivos como la fusión de Ethereum y la modificación del algoritmo de consenso, entonces, ¿qué pasa con los nuevos tipos de transacciones?
Pero esta vez hubo demasiada subversión, rompiendo las reglas ocultas imposibles en múltiples cadenas y rompiendo la lógica de la aplicación de la mayoría de las Dapps. Sin embargo, ocupó firmemente el punto central, que es que el costo para los usuarios es menor. En comparación con el costo de transacción casi duplicado de EIP4337.
El propio usuario sigue siendo una dirección EOA y solo maneja y utiliza la lógica de CA cuando es necesario, por lo que el costo de mantenimiento es bajo. No es necesario convertir la identidad de CA en la cadena antes de realizar operaciones, lo que significa que los usuarios no necesitan registrarse.
Los usuarios pueden usar fácilmente EOA para realizar múltiples transacciones en paralelo, como autorizar retenciones y ejecutar retenciones en una sola, lo que reduce el costo de transacción para los usuarios de Dapps, especialmente aquellas que requieren gestión de partes del proyecto a nivel empresarial en cadena, como los intercambios. , han realizado optimizaciones disruptivas una vez que se realiza la agregación de lotes en la ecología original, el costo de intercambio básico se puede reducir a más de la mitad en un instante, lo que en última instancia puede beneficiar a los usuarios.
Por lo tanto, aunque ha cambiado mucho, la dimensión del costo es digna de investigación y adaptación por parte de todas las Dapps, porque esta vez los usuarios deben estar del lado de EIP7702.
