Actualización de Ethereum Pectra: Análisis profundo de EIP-7702 y mejores prácticas
Introducción
Ethereum se está preparando para la actualización Pectra, que es una actualización significativa, con varias propuestas de mejora importantes de Ethereum que se introducirán. Entre ellas, la EIP-7702 realiza una transformación revolucionaria en la cuenta externa de Ethereum (EOA). Esta propuesta difumina la línea entre la EOA y la cuenta de contrato CA, siendo un paso clave hacia la abstracción de cuentas nativas, después de la EIP-4337, y trae un nuevo modo de interacción al ecosistema de Ethereum.
Pectra ya ha completado el despliegue en la red de prueba 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á una guía práctica para los diferentes participantes.
Análisis de protocolo
Resumen
EIP-7702 introduce un nuevo tipo de transacción que permite a un EOA especificar una dirección de contrato inteligente para establecer su código. Esto permite que un EOA ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. Esta característica otorga al EOA programabilidad y composibilidad, permitiendo 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. Es importante señalar que EIP-7702 es completamente compatible con la billetera de contrato inteligente implementada por EIP-4337, y la integración sin problemas de ambos simplifica enormemente el proceso de desarrollo y 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 transacción, excepto por el campo authorization_list, los demás siguen la misma semántica que EIP-4844. Este campo es de tipo lista y puede contener múltiples entradas de autorización, cada entrada de autorización contiene:
chain_id indica la cadena en la que se efectúa esta delegación de autorización
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 firma autorizados 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 pague el gas.
implementación
Cuando el autorizador firma los datos de autorización, primero debe codificar chain_id, address y nonce utilizando RLP. Luego, los datos codificados se someten a un cálculo de hash keccak256 junto con el número MAGIC, obteniendo así los datos que se van a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hash, obteniendo los datos y_parity, r, s. MAGIC (0x05) se utiliza como delimitador de dominio, con el fin de asegurar que los resultados de diferentes tipos de firmas no entren en conflicto.
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 coincida exactamente con ).
Después de que el autorizador firme los datos de autorización, el iniciador de la transacción los agrupará en el campo authorization_list para firmarlos y transmitir la transacción a través de RPC. Antes de que la transacción sea ejecutada en un bloque, el Proposer realizará una verificación previa de la transacción, donde se llevará a cabo una verificación obligatoria de la dirección to para asegurar 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 requieren que el campo authorization_list contenga al menos un elemento de autorización; si hay varios elementos de autorización firmados por el mismo autorizador, solo el último elemento de autorización tendrá efecto.
Durante el proceso de ejecución de la transacción, el nodo primero aumentará 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), el valor nonce debería aumentarse en 1 al firmar la transacción de autorización.
Al aplicar una entrada de autorización en un nodo, si se encuentra algún error, esa entrada de autorización se omitirá, la transacción no fallará y otras entradas de autorización continuarán aplicándose, asegurando así que no se presente un riesgo de DoS en escenarios de autorización masiva.
Una vez completada la aplicación de autorizació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 delegada. Debido a las limitaciones de EIP-3541, los usuarios no pueden desplegar código de contrato que comience con bytes 0xef de manera convencional, lo que garantiza que tal identificador solo pueda ser desplegado por transacciones de 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 objetivo 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, al mismo tiempo que 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 de cuentas nativas ( Native AA ), reduciendo significativamente la barrera de uso para los usuarios.
Mejores Prácticas
A pesar de que EIP-7702 inyecta nueva vitalidad en el ecosistema de Ethereum, los nuevos escenarios de aplicación también traerán nuevos riesgos. A continuación se presentan los aspectos que los participantes del ecosistema deben tener en cuenta durante el proceso práctico:
almacenamiento de claves privadas
A pesar de que el EOA puede resolver problemas de pérdida de fondos debido a la pérdida de claves privadas 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 se filtre. Es importante aclarar que, después de ejecutar la delegación, la clave privada del EOA sigue teniendo 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 el EOA, incluso si eliminan 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, aún se debe priorizar la protección de la clave privada, prestando atención en todo momento: Not your keys, not your coins.
Repetición multichain
Los usuarios, al firmar la autorización de delegación, pueden seleccionar la cadena en la que la delegación puede entrar en vigor a través del chainId. 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 y entre en vigor en múltiples cadenas, facilitando así que los usuarios realicen la delegación con una sola firma en varias cadenas. Sin embargo, es importante tener en cuenta que en la misma dirección de contrato de 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 efectividad de la delegación coincide con la red a la que está conectada actualmente, y advertir al usuario sobre los riesgos de 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, por lo que deben entender claramente el objetivo de la delegación.
no se puede inicializar
Los monederos de contratos inteligentes más comunes actualmente utilizan en su mayoría un modelo de proxy. Cuando se despliega el proxy del monedero, este 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 del monedero y el despliegue del monedero proxy, evitando el problema de ser inicializado antes. Sin embargo, cuando los usuarios utilizan EIP-7702 para hacer una delegación, solo se actualizará el campo de código de su dirección, sin poder inicializar llamando a la dirección delegada. Esto hace que EIP-7702 no pueda llamar a la función de inicialización en la transacción de despliegue del contrato como lo hace un contrato proxy ERC-1967 común.
Para los desarrolladores, al combinar EIP-7702 con la billetera EIP-4337 existente, se debe tener en cuenta realizar una verificación de permisos durante la operación de inicialización de la billetera (, por ejemplo, verificando la dirección de firma a través de ecrecover para realizar la verificación de permisos ), con el fin de evitar el riesgo de que la operación de inicialización de la billetera sea adelantada.
gestión de almacenamiento
Los usuarios al utilizar la función de delegación EIP-7702, pueden necesitar volver a delegar a diferentes direcciones de contrato debido a cambios en los requisitos de funcionalidad, actualizaciones de billetera, etc. Sin embargo, la estructura de almacenamiento de diferentes contratos puede tener diferencias (, por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos ). En el caso de una nueva delegación, es posible que el nuevo contrato reutilice accidentalmente los datos del contrato antiguo, lo que puede provocar bloqueos de cuentas, pérdidas de fondos y otros resultados negativos.
Para los usuarios, deben manejar con precaución 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 mediante la invocación de la interfaz de la delegación anterior.
recarga falsa
Después de que los usuarios realicen un depósito, EOA también podrá usarse como un contrato inteligente, por lo que los intercambios centralizados (CEX) podrían enfrentar la situación de la generalización de los 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 de contratos inteligentes.
conversión de cuenta
Después de implementar la delegación EIP-7702, el tipo de cuenta de los usuarios puede convertir 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 de proyectos solo a EOA.
Para los desarrolladores de contratos, suponer que tx.origin siempre es EOA ya no será viable. De manera similar, la verificación a través de msg.sender == tx.origin para defenderse de ataques de reentrada también fallará.
Los desarrolladores deben suponer 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 la 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 retorno correspondientes para asegurar la compatibilidad con los tokens principales.
Verificación de pesca
Después de implementar la delegación 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 una firma delegada, se debe mostrar a los usuarios el contrato objetivo de la delegación para mitigar el riesgo de posibles ataques de phishing.
Además, realizar un análisis automático más profundo de los contratos objetivo delegados de 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 discute la propuesta EIP-7702 en la próxima actualización Pectra de Ethereum. EIP-7702 introduce nuevos tipos de transacciones, permitiendo que las EOA tengan programabilidad y combinabilidad, 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 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. El contenido de las mejores prácticas expuestas en este artículo no puede abarcar todos los riesgos potenciales, pero aún así es digno de consideración y aplicación por parte de todas las partes en la operación práctica.
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.
14 me gusta
Recompensa
14
5
Compartir
Comentar
0/400
ser_ngmi
· 07-21 20:33
Copiar tareas se ha vuelto aburrido, ¿no es solo por querer obtener un eoa y un ca?
Ver originalesResponder0
ParanoiaKing
· 07-20 23:50
Otra serie de actualizaciones difíciles de entender, estoy sin palabras.
Ver originalesResponder0
YieldHunter
· 07-20 23:49
técnicamente hablando, este eip parece un poco sospechoso... ¿tienes datos sobre los costos de tx en testnet?
Ver originalesResponder0
EyeOfTheTokenStorm
· 07-20 23:26
¿Otra oportunidad de posicionarse anticipadamente? Según los datos históricos, después de una actualización similar, ETH siempre tiende a Gran aumento, pero el mercado está un poco burbujeante.
Ver originalesResponder0
SchrodingerPrivateKey
· 07-20 23:23
Ya hay un nuevo EIP, ha llegado la cuenta de contrato de versión básica.
EIP-7702解析:Ethereum Pectra升级如何赋予EOA Programabilidad
Actualización de Ethereum Pectra: Análisis profundo de EIP-7702 y mejores prácticas
Introducción
Ethereum se está preparando para la actualización Pectra, que es una actualización significativa, con varias propuestas de mejora importantes de Ethereum que se introducirán. Entre ellas, la EIP-7702 realiza una transformación revolucionaria en la cuenta externa de Ethereum (EOA). Esta propuesta difumina la línea entre la EOA y la cuenta de contrato CA, siendo un paso clave hacia la abstracción de cuentas nativas, después de la EIP-4337, y trae un nuevo modo de interacción al ecosistema de Ethereum.
Pectra ya ha completado el despliegue en la red de prueba 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á una guía práctica para los diferentes participantes.
Análisis de protocolo
Resumen
EIP-7702 introduce un nuevo tipo de transacción que permite a un EOA especificar una dirección de contrato inteligente para establecer su código. Esto permite que un EOA ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. Esta característica otorga al EOA programabilidad y composibilidad, permitiendo 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. Es importante señalar que EIP-7702 es completamente compatible con la billetera de contrato inteligente implementada por EIP-4337, y la integración sin problemas de ambos simplifica enormemente el proceso de desarrollo y 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 transacción, excepto por el campo authorization_list, los demás siguen la misma semántica que EIP-4844. Este campo es de tipo lista y puede contener múltiples entradas de autorización, cada entrada de autorización contiene:
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 pague el gas.
implementación
Cuando el autorizador firma los datos de autorización, primero debe codificar chain_id, address y nonce utilizando RLP. Luego, los datos codificados se someten a un cálculo de hash keccak256 junto con el número MAGIC, obteniendo así los datos que se van a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hash, obteniendo los datos y_parity, r, s. MAGIC (0x05) se utiliza como delimitador de dominio, con el fin de asegurar que los resultados de diferentes tipos de firmas no entren en conflicto.
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 coincida exactamente con ).
Después de que el autorizador firme los datos de autorización, el iniciador de la transacción los agrupará en el campo authorization_list para firmarlos y transmitir la transacción a través de RPC. Antes de que la transacción sea ejecutada en un bloque, el Proposer realizará una verificación previa de la transacción, donde se llevará a cabo una verificación obligatoria de la dirección to para asegurar 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 requieren que el campo authorization_list contenga al menos un elemento de autorización; si hay varios elementos de autorización firmados por el mismo autorizador, solo el último elemento de autorización tendrá efecto.
Durante el proceso de ejecución de la transacción, el nodo primero aumentará 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), el valor nonce debería aumentarse en 1 al firmar la transacción de autorización.
Al aplicar una entrada de autorización en un nodo, si se encuentra algún error, esa entrada de autorización se omitirá, la transacción no fallará y otras entradas de autorización continuarán aplicándose, asegurando así que no se presente un riesgo de DoS en escenarios de autorización masiva.
Una vez completada la aplicación de autorizació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 delegada. Debido a las limitaciones de EIP-3541, los usuarios no pueden desplegar código de contrato que comience con bytes 0xef de manera convencional, lo que garantiza que tal identificador solo pueda ser desplegado por transacciones de 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 objetivo 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, al mismo tiempo que 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 de cuentas nativas ( Native AA ), reduciendo significativamente la barrera de uso para los usuarios.
Mejores Prácticas
A pesar de que EIP-7702 inyecta nueva vitalidad en el ecosistema de Ethereum, los nuevos escenarios de aplicación también traerán nuevos riesgos. A continuación se presentan los aspectos que los participantes del ecosistema deben tener en cuenta durante el proceso práctico:
almacenamiento de claves privadas
A pesar de que el EOA puede resolver problemas de pérdida de fondos debido a la pérdida de claves privadas 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 se filtre. Es importante aclarar que, después de ejecutar la delegación, la clave privada del EOA sigue teniendo 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 el EOA, incluso si eliminan 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, aún se debe priorizar la protección de la clave privada, prestando atención en todo momento: Not your keys, not your coins.
Repetición multichain
Los usuarios, al firmar la autorización de delegación, pueden seleccionar la cadena en la que la delegación puede entrar en vigor a través del chainId. 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 y entre en vigor en múltiples cadenas, facilitando así que los usuarios realicen la delegación con una sola firma en varias cadenas. Sin embargo, es importante tener en cuenta que en la misma dirección de contrato de 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 efectividad de la delegación coincide con la red a la que está conectada actualmente, y advertir al usuario sobre los riesgos de 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, por lo que deben entender claramente el objetivo de la delegación.
no se puede inicializar
Los monederos de contratos inteligentes más comunes actualmente utilizan en su mayoría un modelo de proxy. Cuando se despliega el proxy del monedero, este 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 del monedero y el despliegue del monedero proxy, evitando el problema de ser inicializado antes. Sin embargo, cuando los usuarios utilizan EIP-7702 para hacer una delegación, solo se actualizará el campo de código de su dirección, sin poder inicializar llamando a la dirección delegada. Esto hace que EIP-7702 no pueda llamar a la función de inicialización en la transacción de despliegue del contrato como lo hace un contrato proxy ERC-1967 común.
Para los desarrolladores, al combinar EIP-7702 con la billetera EIP-4337 existente, se debe tener en cuenta realizar una verificación de permisos durante la operación de inicialización de la billetera (, por ejemplo, verificando la dirección de firma a través de ecrecover para realizar la verificación de permisos ), con el fin de evitar el riesgo de que la operación de inicialización de la billetera sea adelantada.
gestión de almacenamiento
Los usuarios al utilizar la función de delegación EIP-7702, pueden necesitar volver a delegar a diferentes direcciones de contrato debido a cambios en los requisitos de funcionalidad, actualizaciones de billetera, etc. Sin embargo, la estructura de almacenamiento de diferentes contratos puede tener diferencias (, por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos ). En el caso de una nueva delegación, es posible que el nuevo contrato reutilice accidentalmente los datos del contrato antiguo, lo que puede provocar bloqueos de cuentas, pérdidas de fondos y otros resultados negativos.
Para los usuarios, deben manejar con precaución 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 mediante la invocación de la interfaz de la delegación anterior.
recarga falsa
Después de que los usuarios realicen un depósito, EOA también podrá usarse como un contrato inteligente, por lo que los intercambios centralizados (CEX) podrían enfrentar la situación de la generalización de los 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 de contratos inteligentes.
conversión de cuenta
Después de implementar la delegación EIP-7702, el tipo de cuenta de los usuarios puede convertir 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 de proyectos solo a EOA.
Para los desarrolladores de contratos, suponer que tx.origin siempre es EOA ya no será viable. De manera similar, la verificación a través de msg.sender == tx.origin para defenderse de ataques de reentrada también fallará.
Los desarrolladores deben suponer 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 la 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 retorno correspondientes para asegurar la compatibilidad con los tokens principales.
Verificación de pesca
Después de implementar la delegación 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 una firma delegada, se debe mostrar a los usuarios el contrato objetivo de la delegación para mitigar el riesgo de posibles ataques de phishing.
Además, realizar un análisis automático más profundo de los contratos objetivo delegados de 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 discute la propuesta EIP-7702 en la próxima actualización Pectra de Ethereum. EIP-7702 introduce nuevos tipos de transacciones, permitiendo que las EOA tengan programabilidad y combinabilidad, 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 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. El contenido de las mejores prácticas expuestas en este artículo no puede abarcar todos los riesgos potenciales, pero aún así es digno de consideración y aplicación por parte de todas las partes en la operación práctica.