Actualización de Ethereum Pectra: Análisis profundo de EIP-7702 y guía de mejores prácticas
Introducción
Ethereum se prepara para la actualización Pectra, una actualización de gran importancia que introducirá múltiples propuestas de mejora significativas de Ethereum. Entre ellas, la EIP-7702 realiza una transformación revolucionaria de 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 nativas después de la EIP-4337, lo que trae un nuevo modo de interacción al ecosistema de Ethereum.
Pectra ha completado el 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 puede traer, y proporcionará guías prácticas para los 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, lo que a su vez le permite establecer código. De esta manera, EOA puede ejecutar código como un contrato inteligente y al mismo tiempo mantener la capacidad de iniciar transacciones. Esta característica otorga a EOA programabilidad y composibilidad, lo que permite a los usuarios implementar funciones como recuperación social, control de permisos, gestión de múltiples firmas, verificación zk, pagos por suscripción, patrocinio de transacciones y procesamiento por lotes de transacciones. Cabe mencionar que EIP-7702 es completamente compatible con la billetera de contrato inteligente implementada por EIP-4337, y la integración sin fisuras de ambos simplifica enormemente el desarrollo y la aplicación de nuevas funciones.
La implementación específica de EIP-7702 introduce 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, además del campo authorization_list, el resto sigue la misma semántica que EIP-4844. Este campo es de tipo lista, y la lista puede contener múltiples entradas de autorización, en cada entrada de autorización:
El campo chain_id indica la cadena en la que esta delegación de autorización es efectiva.
El campo de dirección indica la dirección objetivo de la delegación.
El campo nonce debe coincidir con el nonce de la cuenta autorizada actual.
Los campos y_parity, r, s son los datos de firma firmados por la cuenta autorizada.
El campo authorization_list en 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 realice operaciones de autorización con pago de gas.
implementación
El autorizador, al firmar los datos de autorización, necesita primero codificar el chain_id, address y nonce mediante RLP. Luego, los datos codificados se combinan con el número MAGIC para realizar el cálculo de hash keccak256, obteniendo así los datos a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hasheados, obteniendo así los datos y_parity, r, s. Donde, 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, esto significa que el autorizador permite repetir la autorización ( en todas las cadenas compatibles con EVM que soportan EIP-7702, siempre que el nonce también coincida exactamente con ).
Una vez que el autorizador firma los datos de autorización, el iniciador de la transacción agrupará esto en el campo authorization_list para firmarlo y lo transmitirá a través de RPC. Antes de que la transacción se ejecute al ser incluida en un bloque, el Proposer realizará una preevaluación 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 requerirán que el campo authorization_list en la transacción contenga al menos una entrada de autorización. Si hay múltiples entradas de autorización firmadas por el mismo autorizador, entonces solo la última entrada de autorización tendrá efecto.
Luego, durante el proceso de ejecución de la transacción, el nodo aumentará primero el valor nonce del iniciador de la transacción, y luego realizará la operación applyAuthorization en cada entrada de autorización en authorization_list. En la operación applyAuthorization, el nodo primero verificará el nonce del autorizador y luego aumentará el nonce del autorizador. Esto significa que si el iniciador de la transacción y el autorizador son el mismo usuario (EOA), al firmar la transacción de autorización, el valor del nonce debe aumentarse en 1.
Al aplicar un ítem de autorización en el nodo, si se encuentra cualquier error, este ítem de autorización será omitido, la transacción no fallará y otros ítems de autorización continuarán siendo aplicados, asegurando así que no se presente un riesgo de DoS en escenarios de autorización masiva.
Una vez que se complete la aplicación autorizada, el campo de código de la dirección del otorgante se establecerá en 0xef0100 || dirección, donde 0xef0100 es un identificador fijo y la dirección es la dirección objetivo delegada. 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 retirar la autorización, solo necesita establecer la dirección del objetivo delegado en la dirección 0.
El nuevo tipo de transacción introducido por EIP-7702 permite que los autorizadores (EOA) ejecuten código de la misma manera que los contratos inteligentes, mientras que también conservan 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 de cuentas nativas (Native AA), lo que reduce enormemente la barrera de entrada para los usuarios.
Mejores Prácticas
A pesar de que EIP-7702 ha inyectado nueva vitalidad al ecosistema de Ethereum, los nuevos casos de uso también traerán nuevos riesgos. A continuación se presentan los aspectos que los participantes del ecosistema deben tener en cuenta durante la práctica:
almacenamiento de clave privada
Aunque el EOA puede resolver el problema de la pérdida de fondos debido a la pérdida de la clave privada mediante métodos como la recuperación social integrada en contratos inteligentes después de la delegación, aún no puede evitar el riesgo de que la clave privada del EOA sea filtrada. Es importante aclarar que, tras ejecutar la delegación, la clave privada del EOA sigue teniendo el control más alto sobre la cuenta; poseer la clave privada permite disponer libremente de los activos en la cuenta. Los usuarios o los proveedores de servicios de billetera, después de completar la delegación para el EOA, aunque eliminen completamente la clave privada almacenada localmente, no pueden eliminar por completo el riesgo de filtración de la clave privada, especialmente en escenarios donde existe el riesgo de ataques a la cadena de suministro.
Para los usuarios, al usar la cuenta después de la delegación, los usuarios aún deben priorizar la protección de su clave privada y tener en cuenta en todo momento: Not your keys, not your coins.
Repetición de múltiples cadenas
Los usuarios pueden seleccionar la cadena en la que la autorización de la delegación puede ser efectiva a través de chainId al firmar la autorización de delegación. Por supuesto, los usuarios también pueden optar por usar un chainId de 0 para la delegación, lo que permite que la delegación se reproduzca en múltiples cadenas, facilitando a los usuarios realizar la delegación en varias cadenas con una sola firma. Sin embargo, es importante tener en cuenta que en la misma dirección de contrato en múltiples cadenas, también puede haber diferentes códigos de implementación.
Para los proveedores de servicios de billetera, al realizar una delegación por parte del usuario, se debe verificar si la cadena de activación de la delegación coincide con la red actualmente conectada y advertir al usuario sobre los riesgos que puede conllevar firmar una delegación con chainId igual a 0.
Los usuarios también deben tener en cuenta que las direcciones de contrato idénticas en diferentes cadenas no siempre tienen 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 más populares utilizan un modelo de proxy. Al desplegar la billetera proxy, se llamará a la función de inicialización del contrato a través de DELEGateCALL, logrando así una operación atómica entre la inicialización de la billetera y el despliegue de la billetera proxy, evitando el problema de ser inicializada prematuramente. Sin embargo, al usar EIP-7702 para la delegación, solo se actualizará el campo de código de su dirección, y no se podrá inicializar llamando a la dirección de delegación. 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 hace un contrato proxy ERC-1967 común.
Para los desarrolladores, al combinar y adaptar 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, mediante ecrecover para recuperar la dirección de firma y realizar la verificación de permisos ), para evitar el riesgo de que la operación de inicialización de la billetera sea adelantada.
gestión de almacenamiento
Al usar la función de delegación EIP-7702, los usuarios pueden necesitar volver a delegar a diferentes direcciones de contrato debido a cambios en los requisitos de la función, actualizaciones de billetera, etc. Sin embargo, la estructura de almacenamiento de diferentes contratos puede variar (, por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos ). En el caso de una nueva delegación, esto puede llevar a que el nuevo contrato reutilice accidentalmente los datos del antiguo contrato, lo que puede causar el bloqueo de cuentas, pérdidas de fondos y otras consecuencias negativas.
Para los usuarios, se debe manejar con precaución la situación de la redelegació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 verificar la compatibilidad de almacenamiento antes de la re-delegación, así como limpiar los datos antiguos de almacenamiento llamando a la interfaz de la antigua delegación.
recarga falsa
Después de que los usuarios realicen un encargo, la EOA también podrá usarse como un contrato inteligente, por lo que los intercambios centralizados (CEX) podrían enfrentar una situación de generalización de los depósitos 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 cambiar 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 ataques de reentrada también fallará.
Los desarrolladores deben asumir durante el proceso de desarrollo que los futuros participantes podrían ser contratos inteligentes.
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 exitosamente los tokens.
Para los desarrolladores, los contratos objetivo delegados por los usuarios deberían implementar las funciones de retorno correspondientes para asegurar la compatibilidad con los tokens principales.
Inspección de pesca
Después de implementar la delegación de EIP-7702, los activos en la cuenta del usuario pueden ser controlados por contratos inteligentes; una vez que el usuario delega 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 lo antes posible las transacciones del tipo EIP-7702, y al realizar la firma delegada, se debe mostrar al usuario 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, un análisis automático más profundo de los contratos objetivo delegados en la cuenta, como la verificación de código abierto, la verificación 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 introduce un nuevo tipo de transacción, lo que otorga a las Cuentas Externas (EOA) programabilidad y combinabilidad, difuminando la línea entre las EOA y las cuentas de contrato. Dado que actualmente no existe un estándar de contrato inteligente compatible con EIP-7702 que haya sido probado en la práctica, diferentes participantes del ecosistema, como usuarios, proveedores de servicios de billetera, desarrolladores, CEX, entre otros, enfrentan numerosos desafíos y oportunidades en la aplicación práctica. Las mejores prácticas descritas en este artículo no pueden abarcar todos los riesgos potenciales, pero aún son dignas de ser consideradas y aplicadas por todas las partes en la operación práctica.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
11 me gusta
Recompensa
11
3
Compartir
Comentar
0/400
LightningSentry
· hace21h
Este eip realmente va a volverme loco, han cambiado la arquitectura de nuevo.
Ver originalesResponder0
MevHunter
· 07-05 21:12
Solo sé que hay que hacer actualizaciones, la billetera tiene que actualizarse otra vez.
Ver originalesResponder0
FUD_Whisperer
· 07-05 20:52
¿Para qué sirve el 7702 que mencionas? ¿No es lo mismo que el 4337?
Profundidad de análisis de Ethereum EIP-7702: Nueva era de programación EOA y guía de mejores prácticas
Actualización de Ethereum Pectra: Análisis profundo de EIP-7702 y guía de mejores prácticas
Introducción
Ethereum se prepara para la actualización Pectra, una actualización de gran importancia que introducirá múltiples propuestas de mejora significativas de Ethereum. Entre ellas, la EIP-7702 realiza una transformación revolucionaria de 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 nativas después de la EIP-4337, lo que trae un nuevo modo de interacción al ecosistema de Ethereum.
Pectra ha completado el 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 puede traer, y proporcionará guías prácticas para los 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, lo que a su vez le permite establecer código. De esta manera, EOA puede ejecutar código como un contrato inteligente y al mismo tiempo mantener la capacidad de iniciar transacciones. Esta característica otorga a EOA programabilidad y composibilidad, lo que permite a los usuarios implementar funciones como recuperación social, control de permisos, gestión de múltiples firmas, verificación zk, pagos por suscripción, patrocinio de transacciones y procesamiento por lotes de transacciones. Cabe mencionar que EIP-7702 es completamente compatible con la billetera de contrato inteligente implementada por EIP-4337, y la integración sin fisuras de ambos simplifica enormemente el desarrollo y la aplicación de nuevas funciones.
La implementación específica de EIP-7702 introduce 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, además del campo authorization_list, el resto sigue la misma semántica que EIP-4844. Este campo es de tipo lista, y la lista puede contener múltiples entradas de autorización, en cada entrada de autorización:
El campo authorization_list en 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 realice operaciones de autorización con pago de gas.
implementación
El autorizador, al firmar los datos de autorización, necesita primero codificar el chain_id, address y nonce mediante RLP. Luego, los datos codificados se combinan con el número MAGIC para realizar el cálculo de hash keccak256, obteniendo así los datos a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hasheados, obteniendo así los datos y_parity, r, s. Donde, 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, esto significa que el autorizador permite repetir la autorización ( en todas las cadenas compatibles con EVM que soportan EIP-7702, siempre que el nonce también coincida exactamente con ).
Una vez que el autorizador firma los datos de autorización, el iniciador de la transacción agrupará esto en el campo authorization_list para firmarlo y lo transmitirá a través de RPC. Antes de que la transacción se ejecute al ser incluida en un bloque, el Proposer realizará una preevaluación 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 requerirán que el campo authorization_list en la transacción contenga al menos una entrada de autorización. Si hay múltiples entradas de autorización firmadas por el mismo autorizador, entonces solo la última entrada de autorización tendrá efecto.
Luego, durante el proceso de ejecución de la transacción, el nodo aumentará primero el valor nonce del iniciador de la transacción, y luego realizará la operación applyAuthorization en cada entrada de autorización en authorization_list. En la operación applyAuthorization, el nodo primero verificará el nonce del autorizador y luego aumentará el nonce del autorizador. Esto significa que si el iniciador de la transacción y el autorizador son el mismo usuario (EOA), al firmar la transacción de autorización, el valor del nonce debe aumentarse en 1.
Al aplicar un ítem de autorización en el nodo, si se encuentra cualquier error, este ítem de autorización será omitido, la transacción no fallará y otros ítems de autorización continuarán siendo aplicados, asegurando así que no se presente un riesgo de DoS en escenarios de autorización masiva.
Una vez que se complete la aplicación autorizada, el campo de código de la dirección del otorgante se establecerá en 0xef0100 || dirección, donde 0xef0100 es un identificador fijo y la dirección es la dirección objetivo delegada. 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 retirar la autorización, solo necesita establecer la dirección del objetivo delegado en la dirección 0.
El nuevo tipo de transacción introducido por EIP-7702 permite que los autorizadores (EOA) ejecuten código de la misma manera que los contratos inteligentes, mientras que también conservan 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 de cuentas nativas (Native AA), lo que reduce enormemente la barrera de entrada para los usuarios.
Mejores Prácticas
A pesar de que EIP-7702 ha inyectado nueva vitalidad al ecosistema de Ethereum, los nuevos casos de uso también traerán nuevos riesgos. A continuación se presentan los aspectos que los participantes del ecosistema deben tener en cuenta durante la práctica:
almacenamiento de clave privada
Aunque el EOA puede resolver el problema de la pérdida de fondos debido a la pérdida de la clave privada mediante métodos como la recuperación social integrada en contratos inteligentes después de la delegación, aún no puede evitar el riesgo de que la clave privada del EOA sea filtrada. Es importante aclarar que, tras ejecutar la delegación, la clave privada del EOA sigue teniendo el control más alto sobre la cuenta; poseer la clave privada permite disponer libremente de los activos en la cuenta. Los usuarios o los proveedores de servicios de billetera, después de completar la delegación para el EOA, aunque eliminen completamente la clave privada almacenada localmente, no pueden eliminar por completo el riesgo de filtración de la clave privada, especialmente en escenarios donde existe el riesgo de ataques a la cadena de suministro.
Para los usuarios, al usar la cuenta después de la delegación, los usuarios aún deben priorizar la protección de su clave privada y tener en cuenta en todo momento: Not your keys, not your coins.
Repetición de múltiples cadenas
Los usuarios pueden seleccionar la cadena en la que la autorización de la delegación puede ser efectiva a través de chainId al firmar la autorización de delegación. Por supuesto, los usuarios también pueden optar por usar un chainId de 0 para la delegación, lo que permite que la delegación se reproduzca en múltiples cadenas, facilitando a los usuarios realizar la delegación en varias cadenas con una sola firma. Sin embargo, es importante tener en cuenta que en la misma dirección de contrato en múltiples cadenas, también puede haber diferentes códigos de implementación.
Para los proveedores de servicios de billetera, al realizar una delegación por parte del usuario, se debe verificar si la cadena de activación de la delegación coincide con la red actualmente conectada y advertir al usuario sobre los riesgos que puede conllevar firmar una delegación con chainId igual a 0.
Los usuarios también deben tener en cuenta que las direcciones de contrato idénticas en diferentes cadenas no siempre tienen 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 más populares utilizan un modelo de proxy. Al desplegar la billetera proxy, se llamará a la función de inicialización del contrato a través de DELEGateCALL, logrando así una operación atómica entre la inicialización de la billetera y el despliegue de la billetera proxy, evitando el problema de ser inicializada prematuramente. Sin embargo, al usar EIP-7702 para la delegación, solo se actualizará el campo de código de su dirección, y no se podrá inicializar llamando a la dirección de delegación. 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 hace un contrato proxy ERC-1967 común.
Para los desarrolladores, al combinar y adaptar 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, mediante ecrecover para recuperar la dirección de firma y realizar la verificación de permisos ), para evitar el riesgo de que la operación de inicialización de la billetera sea adelantada.
gestión de almacenamiento
Al usar la función de delegación EIP-7702, los usuarios pueden necesitar volver a delegar a diferentes direcciones de contrato debido a cambios en los requisitos de la función, actualizaciones de billetera, etc. Sin embargo, la estructura de almacenamiento de diferentes contratos puede variar (, por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos ). En el caso de una nueva delegación, esto puede llevar a que el nuevo contrato reutilice accidentalmente los datos del antiguo contrato, lo que puede causar el bloqueo de cuentas, pérdidas de fondos y otras consecuencias negativas.
Para los usuarios, se debe manejar con precaución la situación de la redelegació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 verificar la compatibilidad de almacenamiento antes de la re-delegación, así como limpiar los datos antiguos de almacenamiento llamando a la interfaz de la antigua delegación.
recarga falsa
Después de que los usuarios realicen un encargo, la EOA también podrá usarse como un contrato inteligente, por lo que los intercambios centralizados (CEX) podrían enfrentar una situación de generalización de los depósitos 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 cambiar 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 ataques de reentrada también fallará.
Los desarrolladores deben asumir durante el proceso de desarrollo que los futuros participantes podrían ser contratos inteligentes.
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 exitosamente los tokens.
Para los desarrolladores, los contratos objetivo delegados por los usuarios deberían implementar las funciones de retorno correspondientes para asegurar la compatibilidad con los tokens principales.
Inspección de pesca
Después de implementar la delegación de EIP-7702, los activos en la cuenta del usuario pueden ser controlados por contratos inteligentes; una vez que el usuario delega 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 lo antes posible las transacciones del tipo EIP-7702, y al realizar la firma delegada, se debe mostrar al usuario 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, un análisis automático más profundo de los contratos objetivo delegados en la cuenta, como la verificación de código abierto, la verificación 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 introduce un nuevo tipo de transacción, lo que otorga a las Cuentas Externas (EOA) programabilidad y combinabilidad, difuminando la línea entre las EOA y las cuentas de contrato. Dado que actualmente no existe un estándar de contrato inteligente compatible con EIP-7702 que haya sido probado en la práctica, diferentes participantes del ecosistema, como usuarios, proveedores de servicios de billetera, desarrolladores, CEX, entre otros, enfrentan numerosos desafíos y oportunidades en la aplicación práctica. Las mejores prácticas descritas en este artículo no pueden abarcar todos los riesgos potenciales, pero aún son dignas de ser consideradas y aplicadas por todas las partes en la operación práctica.