Actualización de Ethereum Pectra: EIP-7702 trae una transformación revolucionaria para EOA
Introducción
Ethereum se prepara para la actualización Pectra, que es una actualización significativa, se introducirán varias propuestas de mejora importantes. Entre ellas, la EIP-7702 ha realizado una transformación revolucionaria en la cuenta externa de Ethereum (EOA). Esta propuesta difumina la línea entre EOA y la cuenta de contrato CA, siendo un paso clave hacia la abstracción de cuentas nativa después de la EIP-4337, trayendo un nuevo modo de interacción al ecosistema de Ethereum.
Pectra ha completado su despliegue en la red de pruebas y se espera que pronto se lance en la red principal. Este artículo analizará en profundidad el mecanismo de implementación de EIP-7702, explorará las oportunidades y desafíos que podría traer, y proporcionará una guía práctica para diferentes participantes.
Análisis del Protocolo
Resumen
EIP-7702 introduce un nuevo tipo de transacción que permite a EOA especificar una dirección de contrato inteligente para establecer su código. Esto permite que EOA ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. Esta característica otorga a EOA programabilidad y composición, permitiendo a los usuarios implementar funciones como recuperación social, control de permisos, gestión de firmas múltiples, verificación zk, pagos por suscripción, patrocinio de transacciones y procesamiento por lotes de transacciones. Cabe destacar que EIP-7702 es perfectamente compatible con las billeteras de contratos inteligentes implementadas por EIP-4337, y la integración sin fisuras de ambos simplifica enormemente el desarrollo y la aplicación de nuevas funciones.
EIP-7702 introdujo un tipo de transacción SET_CODE_TX_TYPE (0x04), cuya estructura de datos se define a continuación:
En la nueva estructura de transacciones, salvo el campo authorization_list, el resto sigue la misma semántica que EIP-4844. Este campo es de tipo lista y puede contener múltiples entradas de autorización, cada una de las cuales:
chain_id indica la cadena en la que esta autorización de delegación es efectiva
address representa la dirección objetivo de la delegación
nonce debe coincidir con el nonce de la cuenta autorizada actual
y_parity, r, s son los datos de la firma autorizada firmados por la cuenta autorizada
El campo authorization_list dentro de una transacción puede contener múltiples entradas de autorización firmadas por diferentes cuentas autorizadas ( EOA ), es decir, el iniciador de la transacción puede ser diferente del autorizador, para permitir que el autorizador pague el gas.
implementación
Al firmar los datos de autorización, el autorizador debe primero codificar chain_id, address y nonce usando RLP. Luego, los datos codificados se combinan con el número MAGIC y se realiza una operación de hash keccak256 para obtener los datos a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hashados, obteniendo los datos y_parity, r y s. MAGIC (0x05) se utiliza como delimitador de dominio, con el objetivo de asegurar que los resultados de diferentes tipos de firmas no entren en conflicto.
Es importante tener en cuenta que cuando el chain_id autorizado por el autorizador es 0, significa que el autorizador permite la repetición de la autorización ( en todas las cadenas compatibles con EVM que soportan EIP-7702, siempre que el nonce también coincida con ).
Después de que el autorizador firme los datos de autorización, el iniciador de la transacción los reunirá en el campo authorization_list para firmarlos y difundir la transacción a través de RPC. Antes de que la transacción se ejecute en el bloque, el Proponente realizará una verificación previa de la transacción, en la que se llevará a cabo una verificación obligatoria de la dirección to para asegurarse de que esta transacción no sea una transacción de creación de contrato, es decir, al enviar una transacción del tipo EIP-7702, la dirección to de la transacción no puede estar vacía.
Al mismo tiempo, este tipo de transacciones requiere que el campo authorization_list contenga al menos un ítem de autorización; si hay múltiples ítems de autorización firmados por el mismo autorizador, solo el último ítem de autorización será efectivo.
Durante el proceso de ejecución de la transacción, el nodo primero incrementará el valor de nonce del iniciador de la transacción, y luego realizará la operación applyAuthorization en cada entrada de autorización de la authorization_list. En la operación applyAuthorization, el nodo primero verificará el nonce del autorizador y luego incrementará el nonce del autorizador. Esto significa que si el iniciador de la transacción y el autorizador son el mismo usuario (EOA), el valor de nonce debería incrementarse en 1 al firmar la transacción de autorización.
Al aplicar un elemento de autorización en un nodo, si se encuentra algún error, ese elemento de autorización será omitido, la transacción no fallará, y otros elementos de autorización continuarán aplicándose para asegurar que no haya riesgo de DoS en escenarios de autorización masiva.
Una vez completada la autorización de la aplicación, el campo code de la dirección del autorizador se establecerá en 0xef0100 || address, donde 0xef0100 es un identificador fijo y address es la dirección objetivo del encargo. Debido a las restricciones de EIP-3541, los usuarios no pueden desplegar código de contrato que comience con bytes 0xef de manera convencional, lo que garantiza que dicho identificador solo pueda ser desplegado por transacciones del tipo SET_CODE_TX_TYPE (0x04).
Una vez completada la autorización, si el autorizador desea revocar la autorización, solo necesita establecer la dirección de destino delegada en la dirección 0.
El nuevo tipo de transacción introducido por EIP-7702 permite que el autorizador ( EOA ) ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. En comparación con EIP-4337, esto ofrece a los usuarios una experiencia más cercana a la abstracción nativa de cuentas ( Native AA ), lo que reduce considerablemente la barrera de entrada para los usuarios.
Mejores Prácticas
A pesar de que el EIP-7702 ha inyectado nueva vitalidad en el ecosistema de Ethereum, los nuevos escenarios de aplicación también pueden traer nuevos riesgos. A continuación se presentan aspectos a los que los participantes del ecosistema deben estar atentos durante el proceso práctico:
almacenamiento de claves privadas
Incluso si la EOA puede resolver problemas de pérdida de fondos debido a la pérdida de la clave privada mediante métodos como la recuperación social incorporada en el contrato inteligente después de la delegación, aún no se puede evitar el riesgo de filtración de la clave privada de la EOA. Es importante aclarar que, después de ejecutar la delegación, la clave privada de la EOA todavía tiene el control máximo sobre la cuenta; poseer la clave privada permite disponer libremente de los activos en la cuenta. Después de que el usuario o el proveedor de servicios de billetera complete la delegación para la EOA, incluso si se elimina por completo la clave privada almacenada localmente, no se puede eliminar completamente el riesgo de filtración de la clave privada, especialmente en escenarios donde existe el riesgo de ataque a la cadena de suministro.
Para los usuarios, al usar la cuenta después de la delegación, aún se debe priorizar la protección de la clave privada, y siempre tener en cuenta: Not your keys, not your coins.
reinicio multichain
Al firmar la autorización de delegación, el usuario puede seleccionar la cadena en la que la delegación puede ser efectiva mediante chainId, o puede optar por usar chainId igual a 0 para la delegación, lo que permite que la delegación se reproduzca y sea efectiva en múltiples cadenas, facilitando al usuario realizar la delegación en múltiples cadenas con una sola firma. Sin embargo, es importante tener en cuenta que en la misma dirección del contrato en múltiples cadenas, puede haber diferentes implementaciones del código.
Para los proveedores de servicios de billetera, al realizar un depósito, se debe verificar si la cadena de efectividad del depósito coincide con la red actualmente conectada y advertir al usuario sobre los riesgos que puede conllevar firmar un depósito con chainId igual a 0.
Los usuarios también deben tener en cuenta que la misma dirección de contrato en diferentes cadenas no siempre tiene el mismo código de contrato, y deben comprender claramente el objetivo de la delegación.
no se puede inicializar
La mayoría de las billeteras de contratos inteligentes de uso común actualmente adoptan un modelo de proxy. Al desplegar la billetera proxy, se llama a la función de inicialización del contrato a través de DELEGateCALL para lograr una operación atómica entre la inicialización de la billetera y el despliegue de la billetera proxy, evitando problemas de inicialización prematura. Sin embargo, al usar EIP-7702 para delegar, solo se actualizará el campo de código de la dirección del usuario, y no se podrá inicializar llamando a la dirección delegada. Esto hace que EIP-7702 no pueda invocar la función de inicialización para la inicialización de la billetera en la transacción de despliegue del contrato, como lo hacen los contratos proxy ERC-1967 comunes.
Para los desarrolladores, al combinar EIP-7702 con la billetera existente EIP-4337, se debe tener en cuenta realizar una verificación de permisos durante la operación de inicialización de la billetera (, por ejemplo, a través de ecrecover para recuperar la dirección de la firma y llevar a cabo la verificación de permisos ), a fin de evitar el riesgo de que la operación de inicialización de la billetera sea adelantada.
gestión de almacenamiento
Cuando los usuarios utilizan la función de delegación EIP-7702, es posible que debido a cambios en la demanda de funciones, actualizaciones de billetera, etc., necesiten volver a delegar en una dirección de contrato diferente. Sin embargo, la estructura de almacenamiento de diferentes contratos puede presentar diferencias, ( como que el slot0 de diferentes contratos puede representar diferentes tipos de datos, ) en el caso de una nueva delegación, lo que puede llevar a que el nuevo contrato reutilice accidentalmente los datos del antiguo contrato, causando así el bloqueo de la cuenta, pérdida de fondos y otras consecuencias negativas.
Para los usuarios, se debe manejar con cuidado la situación de la re-delegación.
Para los desarrolladores, durante el proceso de desarrollo se debe seguir la Namespace Formula propuesta por ERC-7201, asignando variables a ubicaciones de almacenamiento independientes designadas para mitigar el riesgo de conflictos de almacenamiento. Además, ERC-7779 (draft) también proporciona un proceso estándar de re-delegación específicamente para EIP-7702: incluye el uso de ERC-7201 para prevenir conflictos de almacenamiento, y la verificación de la compatibilidad de almacenamiento antes de la re-delegación, así como la limpieza de los datos antiguos de almacenamiento llamando a la interfaz de la delegación anterior.
recarga falsa
Después de que el usuario realice una delegación, el EOA también podrá usarse como un contrato inteligente, por lo que el intercambio centralizado (CEX) podría enfrentar una situación de generalización de recargas de contratos inteligentes.
CEX debe verificar el estado de cada transacción de recarga a través de trace, para prevenir el riesgo de recargas falsas en contratos inteligentes.
conversión de cuenta
Después de implementar la delegación EIP-7702, el tipo de cuenta del usuario puede convertirse libremente entre EOA y SC, lo que permite que la cuenta inicie transacciones y también sea llamada. Esto significa que cuando la cuenta se llama a sí misma y realiza una llamada externa, su msg.sender también será tx.origin, lo que romperá algunas suposiciones de seguridad que limitan la participación del proyecto solo a EOA.
Para los desarrolladores de contratos, suponer que tx.origin siempre es EOA ya no será viable. Del mismo modo, la verificación a través de msg.sender == tx.origin para defenderse de los ataques de reentrada también fallará.
Los desarrolladores deben suponer que los futuros participantes podrían ser contratos inteligentes durante el proceso de desarrollo.
compatibilidad de contratos
Los tokens ERC-721 y ERC-777 existentes tienen una función Hook al realizar transferencias de contratos, lo que significa que el receptor debe implementar la función de callback correspondiente para recibir los tokens con éxito.
Para los desarrolladores, el contrato objetivo delegado por el usuario debería implementar las funciones de devolución de llamada correspondientes para garantizar la compatibilidad con los tokens más utilizados.
chequeo de pesca
Después de implementar la delegación EIP-7702, los activos en la cuenta del usuario pueden estar controlados por contratos inteligentes. Una vez que el usuario delegue su cuenta a un contrato malicioso, será muy fácil para el atacante robar fondos.
Para los proveedores de servicios de billetera, es especialmente importante apoyar rápidamente las transacciones del tipo EIP-7702, y cuando los usuarios realicen la firma delegada, se debe mostrar de manera destacada el contrato objetivo de la delegación, para mitigar el riesgo de que los usuarios puedan ser víctimas de ataques de phishing.
Además, realizar un análisis automático más profundo del contrato objetivo de la delegación de cuentas, como revisiones de código abierto, verificaciones de permisos, etc., ( puede ayudar mejor a los usuarios a evitar tales riesgos.
Resumen
Este artículo explora la propuesta EIP-7702 en la próxima actualización Pectra de Ethereum. EIP-7702, al introducir nuevos tipos de transacciones, otorga a las cuentas de usuario (EOA) programabilidad y composabilidad, difuminando la línea entre EOA y cuentas de contrato. Dado que actualmente no existe un estándar de contrato inteligente compatible con EIP-7702 que haya sido probado en el campo, diferentes participantes del ecosistema, como usuarios, proveedores de servicios de billetera, desarrolladores y CEX, enfrentan numerosos desafíos y oportunidades en la práctica. Las mejores prácticas descritas en este artículo no pueden abarcar todos los riesgos potenciales, pero aún así son dignas de ser consideradas y aplicadas por todas las partes en su operación real.
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
9
Republicar
Compartir
Comentar
0/400
notSatoshi1971
· 07-26 08:08
Antes de que el mercado se abra, ¡preparar una emboscada! 7702必起飞
Ver originalesResponder0
0xSunnyDay
· 07-24 10:37
Esta actualización es demasiado brutal 8 ¡Vamos!
Ver originalesResponder0
BasementAlchemist
· 07-23 13:37
¿Otra ola de innovación en la cuenta de contratos? Es muy absurdo.
Ver originalesResponder0
MEVHunterX
· 07-23 13:21
Es otra historia del 4337, ¡huele bien! Vamos a dar un impulso.
Ver originalesResponder0
PanicSeller69
· 07-23 13:20
Una vez que lo mires, ¡hay que bomba! ¿Cuándo empezamos a comprar la caída, V神?
Ver originalesResponder0
FastLeaver
· 07-23 13:14
Otra actualización?? Rug Pull
Ver originalesResponder0
PerennialLeek
· 07-23 13:12
Ha subido varias veces, los que entienden, entienden.
Ver originalesResponder0
WinterWarmthCat
· 07-23 13:12
¡La máquina de retiro habla! ¿Actualización nueva? Hablaremos de la retirada después.
Ver originalesResponder0
Web3ExplorerLin
· 07-23 13:07
fascinante... eip-7702 podría ser el salto cuántico que eth necesita ahora mismo
Actualización de Ethereum Pectra: EIP-7702 difumina los límites entre EOA y CA, abriendo una nueva era de abstracción de cuentas nativa.
Actualización de Ethereum Pectra: EIP-7702 trae una transformación revolucionaria para EOA
Introducción
Ethereum se prepara para la actualización Pectra, que es una actualización significativa, se introducirán varias propuestas de mejora importantes. Entre ellas, la EIP-7702 ha realizado una transformación revolucionaria en la cuenta externa de Ethereum (EOA). Esta propuesta difumina la línea entre EOA y la cuenta de contrato CA, siendo un paso clave hacia la abstracción de cuentas nativa después de la EIP-4337, trayendo un nuevo modo de interacción al ecosistema de Ethereum.
Pectra ha completado su despliegue en la red de pruebas y se espera que pronto se lance en la red principal. Este artículo analizará en profundidad el mecanismo de implementación de EIP-7702, explorará las oportunidades y desafíos que podría traer, y proporcionará una guía práctica para diferentes participantes.
Análisis del Protocolo
Resumen
EIP-7702 introduce un nuevo tipo de transacción que permite a EOA especificar una dirección de contrato inteligente para establecer su código. Esto permite que EOA ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. Esta característica otorga a EOA programabilidad y composición, permitiendo a los usuarios implementar funciones como recuperación social, control de permisos, gestión de firmas múltiples, verificación zk, pagos por suscripción, patrocinio de transacciones y procesamiento por lotes de transacciones. Cabe destacar que EIP-7702 es perfectamente compatible con las billeteras de contratos inteligentes implementadas por EIP-4337, y la integración sin fisuras de ambos simplifica enormemente el desarrollo y la aplicación de nuevas funciones.
EIP-7702 introdujo un tipo de transacción SET_CODE_TX_TYPE (0x04), cuya estructura de datos se define a continuación:
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])
El campo authorization_list se define como:
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
En la nueva estructura de transacciones, salvo el campo authorization_list, el resto sigue la misma semántica que EIP-4844. Este campo es de tipo lista y puede contener múltiples entradas de autorización, cada una de las cuales:
El campo authorization_list dentro de una transacción puede contener múltiples entradas de autorización firmadas por diferentes cuentas autorizadas ( EOA ), es decir, el iniciador de la transacción puede ser diferente del autorizador, para permitir que el autorizador pague el gas.
implementación
Al firmar los datos de autorización, el autorizador debe primero codificar chain_id, address y nonce usando RLP. Luego, los datos codificados se combinan con el número MAGIC y se realiza una operación de hash keccak256 para obtener los datos a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hashados, obteniendo los datos y_parity, r y s. MAGIC (0x05) se utiliza como delimitador de dominio, con el objetivo de asegurar que los resultados de diferentes tipos de firmas no entren en conflicto.
Es importante tener en cuenta que cuando el chain_id autorizado por el autorizador es 0, significa que el autorizador permite la repetición de la autorización ( en todas las cadenas compatibles con EVM que soportan EIP-7702, siempre que el nonce también coincida con ).
Después de que el autorizador firme los datos de autorización, el iniciador de la transacción los reunirá en el campo authorization_list para firmarlos y difundir la transacción a través de RPC. Antes de que la transacción se ejecute en el bloque, el Proponente realizará una verificación previa de la transacción, en la que se llevará a cabo una verificación obligatoria de la dirección to para asegurarse de que esta transacción no sea una transacción de creación de contrato, es decir, al enviar una transacción del tipo EIP-7702, la dirección to de la transacción no puede estar vacía.
Al mismo tiempo, este tipo de transacciones requiere que el campo authorization_list contenga al menos un ítem de autorización; si hay múltiples ítems de autorización firmados por el mismo autorizador, solo el último ítem de autorización será efectivo.
Durante el proceso de ejecución de la transacción, el nodo primero incrementará el valor de nonce del iniciador de la transacción, y luego realizará la operación applyAuthorization en cada entrada de autorización de la authorization_list. En la operación applyAuthorization, el nodo primero verificará el nonce del autorizador y luego incrementará el nonce del autorizador. Esto significa que si el iniciador de la transacción y el autorizador son el mismo usuario (EOA), el valor de nonce debería incrementarse en 1 al firmar la transacción de autorización.
Al aplicar un elemento de autorización en un nodo, si se encuentra algún error, ese elemento de autorización será omitido, la transacción no fallará, y otros elementos de autorización continuarán aplicándose para asegurar que no haya riesgo de DoS en escenarios de autorización masiva.
Una vez completada la autorización de la aplicación, el campo code de la dirección del autorizador se establecerá en 0xef0100 || address, donde 0xef0100 es un identificador fijo y address es la dirección objetivo del encargo. Debido a las restricciones de EIP-3541, los usuarios no pueden desplegar código de contrato que comience con bytes 0xef de manera convencional, lo que garantiza que dicho identificador solo pueda ser desplegado por transacciones del tipo SET_CODE_TX_TYPE (0x04).
Una vez completada la autorización, si el autorizador desea revocar la autorización, solo necesita establecer la dirección de destino delegada en la dirección 0.
El nuevo tipo de transacción introducido por EIP-7702 permite que el autorizador ( EOA ) ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. En comparación con EIP-4337, esto ofrece a los usuarios una experiencia más cercana a la abstracción nativa de cuentas ( Native AA ), lo que reduce considerablemente la barrera de entrada para los usuarios.
Mejores Prácticas
A pesar de que el EIP-7702 ha inyectado nueva vitalidad en el ecosistema de Ethereum, los nuevos escenarios de aplicación también pueden traer nuevos riesgos. A continuación se presentan aspectos a los que los participantes del ecosistema deben estar atentos durante el proceso práctico:
almacenamiento de claves privadas
Incluso si la EOA puede resolver problemas de pérdida de fondos debido a la pérdida de la clave privada mediante métodos como la recuperación social incorporada en el contrato inteligente después de la delegación, aún no se puede evitar el riesgo de filtración de la clave privada de la EOA. Es importante aclarar que, después de ejecutar la delegación, la clave privada de la EOA todavía tiene el control máximo sobre la cuenta; poseer la clave privada permite disponer libremente de los activos en la cuenta. Después de que el usuario o el proveedor de servicios de billetera complete la delegación para la EOA, incluso si se elimina por completo la clave privada almacenada localmente, no se puede eliminar completamente el riesgo de filtración de la clave privada, especialmente en escenarios donde existe el riesgo de ataque a la cadena de suministro.
Para los usuarios, al usar la cuenta después de la delegación, aún se debe priorizar la protección de la clave privada, y siempre tener en cuenta: Not your keys, not your coins.
reinicio multichain
Al firmar la autorización de delegación, el usuario puede seleccionar la cadena en la que la delegación puede ser efectiva mediante chainId, o puede optar por usar chainId igual a 0 para la delegación, lo que permite que la delegación se reproduzca y sea efectiva en múltiples cadenas, facilitando al usuario realizar la delegación en múltiples cadenas con una sola firma. Sin embargo, es importante tener en cuenta que en la misma dirección del contrato en múltiples cadenas, puede haber diferentes implementaciones del código.
Para los proveedores de servicios de billetera, al realizar un depósito, se debe verificar si la cadena de efectividad del depósito coincide con la red actualmente conectada y advertir al usuario sobre los riesgos que puede conllevar firmar un depósito con chainId igual a 0.
Los usuarios también deben tener en cuenta que la misma dirección de contrato en diferentes cadenas no siempre tiene el mismo código de contrato, y deben comprender claramente el objetivo de la delegación.
no se puede inicializar
La mayoría de las billeteras de contratos inteligentes de uso común actualmente adoptan un modelo de proxy. Al desplegar la billetera proxy, se llama a la función de inicialización del contrato a través de DELEGateCALL para lograr una operación atómica entre la inicialización de la billetera y el despliegue de la billetera proxy, evitando problemas de inicialización prematura. Sin embargo, al usar EIP-7702 para delegar, solo se actualizará el campo de código de la dirección del usuario, y no se podrá inicializar llamando a la dirección delegada. Esto hace que EIP-7702 no pueda invocar la función de inicialización para la inicialización de la billetera en la transacción de despliegue del contrato, como lo hacen los contratos proxy ERC-1967 comunes.
Para los desarrolladores, al combinar EIP-7702 con la billetera existente EIP-4337, se debe tener en cuenta realizar una verificación de permisos durante la operación de inicialización de la billetera (, por ejemplo, a través de ecrecover para recuperar la dirección de la firma y llevar a cabo la verificación de permisos ), a fin de evitar el riesgo de que la operación de inicialización de la billetera sea adelantada.
gestión de almacenamiento
Cuando los usuarios utilizan la función de delegación EIP-7702, es posible que debido a cambios en la demanda de funciones, actualizaciones de billetera, etc., necesiten volver a delegar en una dirección de contrato diferente. Sin embargo, la estructura de almacenamiento de diferentes contratos puede presentar diferencias, ( como que el slot0 de diferentes contratos puede representar diferentes tipos de datos, ) en el caso de una nueva delegación, lo que puede llevar a que el nuevo contrato reutilice accidentalmente los datos del antiguo contrato, causando así el bloqueo de la cuenta, pérdida de fondos y otras consecuencias negativas.
Para los usuarios, se debe manejar con cuidado la situación de la re-delegación.
Para los desarrolladores, durante el proceso de desarrollo se debe seguir la Namespace Formula propuesta por ERC-7201, asignando variables a ubicaciones de almacenamiento independientes designadas para mitigar el riesgo de conflictos de almacenamiento. Además, ERC-7779 (draft) también proporciona un proceso estándar de re-delegación específicamente para EIP-7702: incluye el uso de ERC-7201 para prevenir conflictos de almacenamiento, y la verificación de la compatibilidad de almacenamiento antes de la re-delegación, así como la limpieza de los datos antiguos de almacenamiento llamando a la interfaz de la delegación anterior.
recarga falsa
Después de que el usuario realice una delegación, el EOA también podrá usarse como un contrato inteligente, por lo que el intercambio centralizado (CEX) podría enfrentar una situación de generalización de recargas de contratos inteligentes.
CEX debe verificar el estado de cada transacción de recarga a través de trace, para prevenir el riesgo de recargas falsas en contratos inteligentes.
conversión de cuenta
Después de implementar la delegación EIP-7702, el tipo de cuenta del usuario puede convertirse libremente entre EOA y SC, lo que permite que la cuenta inicie transacciones y también sea llamada. Esto significa que cuando la cuenta se llama a sí misma y realiza una llamada externa, su msg.sender también será tx.origin, lo que romperá algunas suposiciones de seguridad que limitan la participación del proyecto solo a EOA.
Para los desarrolladores de contratos, suponer que tx.origin siempre es EOA ya no será viable. Del mismo modo, la verificación a través de msg.sender == tx.origin para defenderse de los ataques de reentrada también fallará.
Los desarrolladores deben suponer que los futuros participantes podrían ser contratos inteligentes durante el proceso de desarrollo.
compatibilidad de contratos
Los tokens ERC-721 y ERC-777 existentes tienen una función Hook al realizar transferencias de contratos, lo que significa que el receptor debe implementar la función de callback correspondiente para recibir los tokens con éxito.
Para los desarrolladores, el contrato objetivo delegado por el usuario debería implementar las funciones de devolución de llamada correspondientes para garantizar la compatibilidad con los tokens más utilizados.
chequeo de pesca
Después de implementar la delegación EIP-7702, los activos en la cuenta del usuario pueden estar controlados por contratos inteligentes. Una vez que el usuario delegue su cuenta a un contrato malicioso, será muy fácil para el atacante robar fondos.
Para los proveedores de servicios de billetera, es especialmente importante apoyar rápidamente las transacciones del tipo EIP-7702, y cuando los usuarios realicen la firma delegada, se debe mostrar de manera destacada el contrato objetivo de la delegación, para mitigar el riesgo de que los usuarios puedan ser víctimas de ataques de phishing.
Además, realizar un análisis automático más profundo del contrato objetivo de la delegación de cuentas, como revisiones de código abierto, verificaciones de permisos, etc., ( puede ayudar mejor a los usuarios a evitar tales riesgos.
Resumen
Este artículo explora la propuesta EIP-7702 en la próxima actualización Pectra de Ethereum. EIP-7702, al introducir nuevos tipos de transacciones, otorga a las cuentas de usuario (EOA) programabilidad y composabilidad, difuminando la línea entre EOA y cuentas de contrato. Dado que actualmente no existe un estándar de contrato inteligente compatible con EIP-7702 que haya sido probado en el campo, diferentes participantes del ecosistema, como usuarios, proveedores de servicios de billetera, desarrolladores y CEX, enfrentan numerosos desafíos y oportunidades en la práctica. Las mejores prácticas descritas en este artículo no pueden abarcar todos los riesgos potenciales, pero aún así son dignas de ser consideradas y aplicadas por todas las partes en su operación real.