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, que es una actualización significativa. Entre ellas, 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, lo que trae un nuevo modo de interacción al ecosistema de Ethereum.

Pectra ya 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, explorando las oportunidades y desafíos que podría traer, y proporcionará una guía práctica 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 y establecer código para ella. 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 composabilidad, 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 destacar que EIP-7702 es completamente compatible con la billetera de contrato inteligente implementada por EIP-4337, simplificando 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 transacción, aparte del campo authorization_list, el resto sigue la misma semántica que EIP-4844. authorization_list es de tipo lista y puede contener múltiples entradas de autorización. En cada entrada de autorización:

• chain_id representa la cadena en la que la autorización del delegado entra en vigor.
• 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 autorizada firmados por la cuenta autorizada

La lista de autorización de una transacción puede contener varias cuentas autorizadas diferentes. ( EOA ) firma los elementos de autorización, permitiendo que el pagador de gas realice operaciones de autorización sobre el autorizador.

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 combinan con MAGIC y se realiza una operación de hash keccak256 para obtener los datos a firmar. Finalmente, se firma los datos hash con la clave privada del autorizador, obteniendo los datos y_parity, r, s. MAGIC (0x05) se utiliza como delimitador de dominio para asegurar que los resultados de diferentes tipos de firma 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 soporten EIP-7702 (siempre que el nonce también coincida).

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 firmar y transmitirá la transacción a través de RPC. Antes de ejecutar la transacción, el Proposer realizará una verificación previa para asegurarse de que esta transacción no sea una transacción de creación de contrato, es decir, al enviar una transacción de tipo EIP-7702, la dirección to de la transacción no puede estar vacía.

Este tipo de transacciones requiere que el campo authorization_list contenga al menos una entrada de autorización. Si múltiples entradas de autorización son firmadas por el mismo autorizador, solo la última entrada de autorización será válida.

Al ejecutar la transacción, el nodo primero incrementa el valor nonce del iniciador de la transacción, y luego realiza la operación applyAuthorization en cada entrada de autorización en la authorization_list. En la operación applyAuthorization, el nodo primero verifica el nonce del autorizador y luego incrementa el nonce del autorizador. Esto significa que si el iniciador de la transacción y el autorizador son el mismo usuario (EOA), el valor del nonce al firmar la transacción de autorización debería incrementarse en 1.

Al aplicar entradas de autorización de nodos, si se encuentra algún error, esa entrada se omitirá, la transacción no fallará y otras entradas de autorización continuarán aplicándose para evitar el riesgo de DoS en escenarios de autorización por lotes.

Después de completar la autorización de la aplicación, el campo code de la dirección autorizadora se establecerá en 0xef0100 || address, donde 0xef0100 es un identificador fijo y address es la dirección objetivo delegada. La restricción de EIP-3541 asegura que tal identificador solo puede ser implementado 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 objetivo delegada en la dirección 0.

A través del nuevo tipo de transacción introducido por EIP-7702, el autorizador ( EOA ) puede ejecutar 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 de cuentas nativas ( Native AA ), reduciendo significativamente la barrera de entrada.

Mejores Prácticas

EIP-7702 inyecta nueva vitalidad al ecosistema de Ethereum, al mismo tiempo que los nuevos escenarios de aplicación también traen nuevos riesgos. A continuación se presentan los aspectos a los que los participantes del ecosistema deben estar atentos durante el proceso de práctica:

almacenamiento de claves privadas

Incluso si después de que se delegue el EOA se pueden utilizar métodos como la recuperación social incorporada en los contratos inteligentes para resolver el problema de la pérdida de fondos debido a la pérdida de la clave privada, aún no se puede evitar el riesgo de filtración de la clave privada del EOA. Después de ejecutar la delegación, la clave privada del EOA sigue teniendo el máximo control 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 por completo la clave privada almacenada localmente, no pueden eliminar completamente el riesgo de filtración de la clave privada, especialmente en escenarios donde hay riesgo de ataque a la cadena de suministro.

Para los usuarios, al usar la cuenta después de delegar, deben seguir priorizando la protección de la clave privada y estar siempre atentos: Not your keys, not your coins.

Reproducción multichain

Al firmar la autorización de delegación, el usuario puede seleccionar la cadena en la que la delegación tendrá efecto a través de chainId, o puede elegir un chainId de 0 para hacer la delegación, lo que permite que la delegación se reproduzca en múltiples cadenas, facilitando que el usuario delegue con una sola firma en múltiples cadenas. Sin embargo, es importante tener en cuenta que puede haber diferentes códigos de implementación en la misma dirección de contrato en múltiples cadenas.

Los proveedores de servicios de billetera deben verificar si la cadena de efectividad del encargo coincide con la red conectada actualmente cuando el usuario realiza un encargo, y advertir al usuario sobre los riesgos que puede conllevar firmar un encargo con chainId igual a 0.

Los usuarios también deben tener en cuenta que las mismas direcciones de contrato en diferentes cadenas no siempre tienen el mismo código de contrato, por lo que deben comprender claramente el objetivo de la delegación.

no se puede inicializar

Los monederos de contratos inteligentes más populares actualmente utilizan en su mayoría un modelo de proxy. El proxy del monedero, al ser desplegado, realiza la llamada 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 el usuario utiliza EIP-7702 para delegar, solo se actualizará el campo de código de su dirección, y no se podrá inicializar llamando a la dirección delegada. Esto hace que EIP-7702 no pueda llamar a la función de inicialización para la inicialización del monedero en la transacción de despliegue del contrato, como lo haría un contrato proxy común ERC-1967.

Los desarrolladores deben realizar una verificación de permisos (por ejemplo, mediante ecrecover para recuperar la dirección de firma) durante la operación de inicialización de la billetera al combinar EIP-7702 con la billetera EIP-4337 existente, para 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, pueden necesitar volver a delegar a una dirección de contrato diferente debido a cambios en los requisitos de la función, actualizaciones de billetera, entre otros. Sin embargo, la estructura de almacenamiento de diferentes contratos puede variar (por ejemplo, el slot0 de diferentes contratos puede representar diferentes tipos de datos), y la nueva delegación puede provocar que el nuevo contrato reutilice accidentalmente los datos del contrato anterior, lo que puede resultar en el bloqueo de la cuenta, pérdida de fondos y otros efectos adversos.

Los usuarios deben manejar con precaución las situaciones de delegación de nuevo.

Los desarrolladores deben seguir la Namespace Formula propuesta por ERC-7201 durante el proceso de desarrollo, 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, verificar la compatibilidad de almacenamiento antes de la re-delegación, y limpiar los datos antiguos de almacenamiento mediante la interfaz del antiguo delegado.

recarga falsa

Después de que el usuario realice un delegación, la EOA también podrá utilizarse como un contrato inteligente, por lo que los intercambios centralizados (CEX) pueden 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 de EIP-7702, el tipo de cuenta del usuario puede cambiar libremente entre EOA y SC, la cuenta puede iniciar transacciones y también ser 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.

Los desarrolladores de contratos no deben asumir que tx.origin siempre es EOA. 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 suponer que los futuros participantes pueden ser contratos inteligentes durante el proceso de desarrollo.

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.

Los desarrolladores deben asegurarse de que el contrato objetivo delegado por el usuario implemente las funciones de callback correspondientes para garantizar 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 un contrato inteligente, y una vez que el usuario delegue su cuenta a un contrato malicioso, será muy fácil para el atacante robar fondos.

Los proveedores de servicios de billetera deben apoyar rápidamente las transacciones del tipo EIP-7702 y, cuando los usuarios realicen firmas delegadas, 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 de los contratos objetivo delegados en la cuenta (inspección de código abierto, 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, otorgando a los EOA programabilidad y composabilidad, difuminando así la línea entre los EOA y las cuentas de contrato. Dado que actualmente no existe un estándar de contrato inteligente compatible con el tipo EIP-7702 probado en la práctica, diferentes participantes del ecosistema, como usuarios, proveedores de servicios de billeteras, desarrolladores y CEX, 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 así son dignas de ser consideradas y aplicadas por todas las partes en la operación práctica.