Actualización de Ethereum Pectra: Análisis profundo de EIP-7702
Introducción
Ethereum está a punto de recibir la actualización Pectra, que es una actualización significativa que introducirá 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 nativas después de la EIP-4337, y 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 podría 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 EOA especificar una dirección de contrato inteligente y establecer código para ella. Esto permite que EOA ejecute código como un contrato inteligente, al mismo tiempo que conserva la capacidad de iniciar transacciones. Esta característica otorga a 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 perfectamente compatible con las billeteras de contratos inteligentes implementadas 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 el 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 puede contener múltiples entradas de autorización, cada entrada de autorización contiene:
chain_id indica la cadena en la que se aplica esta autorización delegada
address indica 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 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, permitiendo así la operación de autorización para que el autorizador pague el gas.
implementación
El autorizador, al firmar los datos de autorización, debe primero codificar chain_id, address y nonce utilizando RLP. Luego, los datos codificados se someten a una operación de hash keccak256 junto con el número MAGIC, para obtener los datos que se firmarán. 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 un 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 exactamente con (.
Una vez que el autorizador haya firmado los datos de autorización, el iniciador de la transacción los reunirá en el campo authorization_list para firmarlos y los transmitirá mediante RPC. Antes de que la transacción se ejecute al ser incluida en un bloque, el Proposer realizará una pre-verificación de la transacción, donde se llevará a cabo una verificación estricta 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á que el campo authorization_list en la transacción contenga al menos un elemento de autorización. Si hay múltiples elementos de autorización firmados por el mismo autorizador, entonces solo el último elemento 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 nonce debería aumentarse en 1.
Al aplicar un elemento de autorización en un nodo, si se encuentra algún error, este elemento de autorización será omitido, la transacción no fallará y otros elementos de autorización continuarán aplicándose, asegurando así que no haya riesgo de DoS en escenarios de autorización masiva.
Después de que se complete la aplicación autorizada, el campo code de la dirección del autorizador se establecerá en 0xef0100 || address, donde 0xef0100 es una identificación fija 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 el byte 0xef de manera convencional, lo que garantiza que tal identificación solo pueda ser desplegada por transacciones del tipo SET_CODE_TX_TYPE )0x04(.
Una vez que se complete la autorización, si el autoriza desea eliminar 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, al mismo tiempo que conserva la capacidad de iniciar transacciones. En comparación con EIP-4337, esto brinda a los usuarios una experiencia más cercana a la abstracción de cuentas nativas ) Native AA (, lo que reduce significativamente 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 aspectos a los que los participantes del ecosistema deben prestar atención en el proceso práctico:
) almacenamiento de clave privada
A pesar de que el 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 los contratos inteligentes después de la delegación, aún no puede evitar el riesgo de filtración de la clave privada del EOA. Es importante aclarar que, después de realizar la delegación, la clave privada del EOA todavía tiene el control máximo sobre la cuenta; poseer la clave privada permite disponer libremente de los activos en la cuenta. Los usuarios o proveedores de servicios de billetera, después de completar 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 ataque a la cadena de suministro.
Para los usuarios, al utilizar la cuenta después de la delegación, todavía deben priorizar la protección de la clave privada y estar atentos: Not your keys, not your coins.
Repetición de múltiples cadenas
Los usuarios al firmar una autorización de delegación pueden elegir la cadena en la que la delegación puede ser efectiva a través de chainId. Por supuesto, los usuarios también pueden optar por usar chainId como 0 para delegar, lo que permite que la delegación se reproduzca de manera efectiva en múltiples cadenas, facilitando así que los usuarios puedan delegar 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 actualmente conectada y recordar al usuario 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 iguales 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
La mayoría de las billeteras de contratos inteligentes más populares actualmente adoptan un modelo de proxy. Al desplegar la billetera proxy, se llama a la función de inicialización del contrato mediante 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 antes. Sin embargo, cuando los usuarios utilizan EIP-7702 para delegar, solo se actualiza el campo de código de su dirección, y no se puede 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 comunes ERC-1967.
Para los desarrolladores, al combinar EIP-7702 con las carteras existentes de EIP-4337, se debe prestar atención a realizar chequeos de permisos durante la operación de inicialización de la cartera ###, por ejemplo, verificando la dirección de firma a través de ecrecover para realizar el chequeo de permisos (, con el fin de evitar el riesgo de que la operación de inicialización de la cartera sea adelantada.
) Gestión de Almacenamiento
Los usuarios que utilizan 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 variar, por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos. En el caso de una nueva delegación, esto podría llevar a que el nuevo contrato reutilice accidentalmente los datos del contrato antiguo, lo que a su vez podría causar el bloqueo de cuentas, pérdidas de fondos y otros efectos adversos.
Para los usuarios, se debe 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 interfaz de la antigua delegación.
) recarga falsa
Después de que el usuario realice una delegación, la EOA también podrá utilizarse como un contrato inteligente, por lo que el intercambio podría enfrentarse a una situación de generalización de recargas de contratos inteligentes.
El intercambio 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 de EIP-7702, el tipo de cuenta de los usuarios puede convertirse libremente entre EOA y SC, lo que permite que la cuenta inicie transacciones y también sea llamada. Esto significa que cuando una 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 un EOA ya no será viable. De la misma manera, la verificación a través de msg.sender == tx.origin para defenderse de ataques de reentrada también fallará.
Los desarrolladores deberían 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 la funcionalidad Hook al realizar transferencias en el contrato, lo que significa que el receptor debe implementar la función de retorno correspondiente para recibir los tokens con éxito.
Para los desarrolladores, el contrato objetivo delegado por el usuario debe implementar las funciones de callback correspondientes para garantizar la compatibilidad con los tokens más utilizados.
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 la cuenta a un contrato malicioso, se volverá 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 firmas delegadas, se debe mostrar a los usuarios el contrato objetivo de la delegación para mitigar el riesgo de ataques de phishing que podrían sufrir.
Además, un análisis automático más profundo de los contratos objetivo de la delegación de cuentas, 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 que otorga a las 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, intercambios, entre otros, se enfrentan a muchos desafíos y oportunidades en la aplicación práctica. El contenido de las mejores prácticas expuesto en este artículo no puede cubrir todos los riesgos potenciales, pero aún así es digno de referencia y aplicación por 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.
6 me gusta
Recompensa
6
5
Compartir
Comentar
0/400
PermabullPete
· hace19h
sumar just卷 Libro de pedidos又得炸咯
Ver originalesResponder0
StablecoinEnjoyer
· hace19h
Un poco adelantado, siento que Vitalik Buterin está haciendo algo grande nuevamente.
Ver originalesResponder0
Token_Sherpa
· hace19h
meh... otra propuesta que no solucionará los verdaderos problemas de eth, para ser honesto
Ver originalesResponder0
RektRecorder
· hace20h
Preparar una emboscada en el mercado bajista para enriquecerse en el bull run
EIP-7702 Profundidad análisis: la actualización Pectra de Ethereum difuminará los límites entre EOA y CA
Actualización de Ethereum Pectra: Análisis profundo de EIP-7702
Introducción
Ethereum está a punto de recibir la actualización Pectra, que es una actualización significativa que introducirá 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 nativas después de la EIP-4337, y 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 podría 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 EOA especificar una dirección de contrato inteligente y establecer código para ella. Esto permite que EOA ejecute código como un contrato inteligente, al mismo tiempo que conserva la capacidad de iniciar transacciones. Esta característica otorga a 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 perfectamente compatible con las billeteras de contratos inteligentes implementadas 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 el 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 puede contener múltiples entradas de autorización, cada entrada de autorización contiene:
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, permitiendo así la operación de autorización para que el autorizador pague el gas.
implementación
El autorizador, al firmar los datos de autorización, debe primero codificar chain_id, address y nonce utilizando RLP. Luego, los datos codificados se someten a una operación de hash keccak256 junto con el número MAGIC, para obtener los datos que se firmarán. 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 un 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 exactamente con (.
Una vez que el autorizador haya firmado los datos de autorización, el iniciador de la transacción los reunirá en el campo authorization_list para firmarlos y los transmitirá mediante RPC. Antes de que la transacción se ejecute al ser incluida en un bloque, el Proposer realizará una pre-verificación de la transacción, donde se llevará a cabo una verificación estricta 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á que el campo authorization_list en la transacción contenga al menos un elemento de autorización. Si hay múltiples elementos de autorización firmados por el mismo autorizador, entonces solo el último elemento 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 nonce debería aumentarse en 1.
Al aplicar un elemento de autorización en un nodo, si se encuentra algún error, este elemento de autorización será omitido, la transacción no fallará y otros elementos de autorización continuarán aplicándose, asegurando así que no haya riesgo de DoS en escenarios de autorización masiva.
Después de que se complete la aplicación autorizada, el campo code de la dirección del autorizador se establecerá en 0xef0100 || address, donde 0xef0100 es una identificación fija 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 el byte 0xef de manera convencional, lo que garantiza que tal identificación solo pueda ser desplegada por transacciones del tipo SET_CODE_TX_TYPE )0x04(.
Una vez que se complete la autorización, si el autoriza desea eliminar 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, al mismo tiempo que conserva la capacidad de iniciar transacciones. En comparación con EIP-4337, esto brinda a los usuarios una experiencia más cercana a la abstracción de cuentas nativas ) Native AA (, lo que reduce significativamente 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 aspectos a los que los participantes del ecosistema deben prestar atención en el proceso práctico:
) almacenamiento de clave privada
A pesar de que el 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 los contratos inteligentes después de la delegación, aún no puede evitar el riesgo de filtración de la clave privada del EOA. Es importante aclarar que, después de realizar la delegación, la clave privada del EOA todavía tiene el control máximo sobre la cuenta; poseer la clave privada permite disponer libremente de los activos en la cuenta. Los usuarios o proveedores de servicios de billetera, después de completar 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 ataque a la cadena de suministro.
Para los usuarios, al utilizar la cuenta después de la delegación, todavía deben priorizar la protección de la clave privada y estar atentos: Not your keys, not your coins.
Repetición de múltiples cadenas
Los usuarios al firmar una autorización de delegación pueden elegir la cadena en la que la delegación puede ser efectiva a través de chainId. Por supuesto, los usuarios también pueden optar por usar chainId como 0 para delegar, lo que permite que la delegación se reproduzca de manera efectiva en múltiples cadenas, facilitando así que los usuarios puedan delegar 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 actualmente conectada y recordar al usuario 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 iguales 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
La mayoría de las billeteras de contratos inteligentes más populares actualmente adoptan un modelo de proxy. Al desplegar la billetera proxy, se llama a la función de inicialización del contrato mediante 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 antes. Sin embargo, cuando los usuarios utilizan EIP-7702 para delegar, solo se actualiza el campo de código de su dirección, y no se puede 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 comunes ERC-1967.
Para los desarrolladores, al combinar EIP-7702 con las carteras existentes de EIP-4337, se debe prestar atención a realizar chequeos de permisos durante la operación de inicialización de la cartera ###, por ejemplo, verificando la dirección de firma a través de ecrecover para realizar el chequeo de permisos (, con el fin de evitar el riesgo de que la operación de inicialización de la cartera sea adelantada.
) Gestión de Almacenamiento
Los usuarios que utilizan 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 variar, por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos. En el caso de una nueva delegación, esto podría llevar a que el nuevo contrato reutilice accidentalmente los datos del contrato antiguo, lo que a su vez podría causar el bloqueo de cuentas, pérdidas de fondos y otros efectos adversos.
Para los usuarios, se debe 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 interfaz de la antigua delegación.
) recarga falsa
Después de que el usuario realice una delegación, la EOA también podrá utilizarse como un contrato inteligente, por lo que el intercambio podría enfrentarse a una situación de generalización de recargas de contratos inteligentes.
El intercambio 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 de EIP-7702, el tipo de cuenta de los usuarios puede convertirse libremente entre EOA y SC, lo que permite que la cuenta inicie transacciones y también sea llamada. Esto significa que cuando una 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 un EOA ya no será viable. De la misma manera, la verificación a través de msg.sender == tx.origin para defenderse de ataques de reentrada también fallará.
Los desarrolladores deberían 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 la funcionalidad Hook al realizar transferencias en el contrato, lo que significa que el receptor debe implementar la función de retorno correspondiente para recibir los tokens con éxito.
Para los desarrolladores, el contrato objetivo delegado por el usuario debe implementar las funciones de callback correspondientes para garantizar la compatibilidad con los tokens más utilizados.
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 la cuenta a un contrato malicioso, se volverá 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 firmas delegadas, se debe mostrar a los usuarios el contrato objetivo de la delegación para mitigar el riesgo de ataques de phishing que podrían sufrir.
Además, un análisis automático más profundo de los contratos objetivo de la delegación de cuentas, 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 que otorga a las 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, intercambios, entre otros, se enfrentan a muchos desafíos y oportunidades en la aplicación práctica. El contenido de las mejores prácticas expuesto en este artículo no puede cubrir todos los riesgos potenciales, pero aún así es digno de referencia y aplicación por todas las partes en la operación práctica.