Actualización de Ethereum Pectra: Transformaciones y desafíos traídos por EIP-7702

Introducción

Ethereum se prepara para la actualización Pectra, que es una actualización significativa, se introducirán varias propuestas importantes de mejora de Ethereum. Entre ellas, la EIP-7702 ha transformado la cuenta externa de Ethereum (EOA). Esta propuesta difumina los límites 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, trayendo nuevos modos de interacción al ecosistema de Ethereum.

Pectra ha completado su implementación 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á consejos prácticos para diferentes participantes.

Análisis del protocolo

Resumen

EIP-7702 introduce un nuevo tipo de transacción que permite a EOA especificar una dirección de contrato inteligente y establecer código para ella. Esto permite que EOA ejecute código como un contrato inteligente, manteniendo al mismo tiempo 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 destacar que EIP-7702 es completamente compatible con las billeteras de contratos inteligentes implementadas por EIP-4337, y la integración sin problemas de ambos simplifica enormemente el desarrollo y la 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 una de las cuales incluye:

• chain_id indica la cadena en la que esta autorización delegada es efectiva
• address indica la dirección objetivo de la delegación
• el 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 que se realicen operaciones de autorización con el pago de gas por parte del autorizador.

implementación

Cuando el autorizador firme los datos de autorización, primero debe codificar chain_id, address y nonce usando RLP. Luego, los datos codificados se combinan con el número MAGIC para realizar una operación de hash keccak256, obteniendo así los datos 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, asegurando 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).

Después de que el otorgante firme los datos de autorización, el iniciador de la transacción los recopilará 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 e incluida en el bloque, el Proposer realizará una pre-verificación de la transacción, en la que 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.

Al mismo tiempo, este tipo de transacciones requiere que el campo authorization_list contenga al menos un elemento de autorización; si hay múltiples 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 autorizada de la 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.

Cuando un nodo aplica un determinado elemento de autorización, si se encuentra con un error, este elemento de autorización se omite, 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 por lotes.

Una vez completada la autorización de la aplicación, el campo code de la dirección del autorizador se establecerá en 0xef0100 || address, donde 0xef0100 es un identificador fijo y address es la dirección objetivo del delegado. Debido a las restricciones de EIP-3541, los usuarios no pueden implementar código de contrato que comience con el byte 0xef de manera convencional, lo que garantiza que dicho identificador solo pueda ser implementado 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 a la dirección 0.

El nuevo tipo de transacción introducido por EIP-7702 permite al autorizador ( EOA ) ejecutar código como un contrato inteligente, al 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 el 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 claves privadas

Incluso si 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 incorporada en el contrato inteligente 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 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. Después de que el usuario o el proveedor de servicios de billetera complete la delegación para el EOA, incluso si se elimina completamente la clave privada almacenada localmente, no se puede 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, la protección de la clave privada debe ser la prioridad, y siempre recordar: Not your keys, not your coins.

Repetición múltiple de cadena

Los usuarios, al firmar la autorización de mandato, pueden seleccionar la cadena en la que el mandato puede ser efectivo a través de chainId, y también pueden optar por usar chainId como 0 para que el mandato pueda ser reproducido y ser efectivo en múltiples cadenas, lo que facilita a los usuarios realizar un único firmar para delegar en múltiples cadenas. Sin embargo, es importante tener en cuenta que en la misma dirección de contrato en múltiples cadenas, también pueden existir 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 advertir al usuario sobre los riesgos que pueden surgir al firmar una delegación con chainId 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 actualmente adoptan un modelo de proxy. El proxy de la billetera, al desplegarse, llamará al método de inicialización del contrato a través de DELEGateCALL, para lograr una operación atómica de inicialización de la billetera y despliegue de la billetera proxy, evitando el problema de ser inicializado primero. Sin embargo, al usar EIP-7702 para delegar, solo se actualizará el campo code de su dirección, y no se podrá inicializar llamando a la dirección delegada. Esto hace que EIP-7702 no pueda llamar al método de inicialización durante la transacción de despliegue del contrato, como lo haría un contrato proxy común ERC-1967 para la inicialización de la billetera.

Para los desarrolladores, al combinar EIP-7702 con la billetera existente EIP-4337, se debe 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

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 motivos. 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 provocar que el nuevo contrato reutilice accidentalmente los datos del antiguo contrato, lo que a su vez podría llevar a bloqueos de cuentas, pérdidas de fondos y otras consecuencias negativas.

Para los usuarios, se debe manejar con precaución la situación de la delegación de nuevo.

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: que incluye el uso de ERC-7201 para prevenir conflictos de almacenamiento y la verificación de la compatibilidad de almacenamiento antes de la re-delegación, así como la limpieza de los datos antiguos de almacenamiento llamando a la interfaz de la antigua delegación.

recarga falsa

Después de que los usuarios realicen un encargo, EOA también podrá usarse como un contrato inteligente, por lo que algunos intercambios pueden enfrentar 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 de contratos inteligentes.

conversión de cuenta

Después de implementar la delegación EIP-7702, el tipo de cuenta del usuario puede convertirse libremente entre EOA y SC, lo que permite que la cuenta inicie transacciones y también sea llamada. Esto significa que cuando la cuenta se llama a sí misma y realiza una llamada externa, su msg.sender también será tx.origin, lo que romperá algunas suposiciones de seguridad que limitan la participación de proyectos solo a EOA.

Para los desarrolladores de contratos, asumir que tx.origin siempre es un 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 deberían asumir que los futuros participantes podrían ser contratos inteligentes durante el proceso de desarrollo.

compatibilidad de contratos

Los tokens ERC-721 y ERC-777 existentes tienen una función Hook al realizar transferencias de contratos, lo que significa que el receptor debe implementar la función de callback correspondiente para recibir los tokens con éxito.

Para los desarrolladores, el contrato objetivo delegado por el usuario debería implementar las funciones de devolución de llamada correspondientes para asegurar la compatibilidad con los tokens principales.

chequeo 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, se vuelve 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 que puedan ser víctimas de ataques de phishing.

Además, realizar un análisis automático más profundo de los contratos objetivo delegados a 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 explora la propuesta EIP-7702 en la próxima actualización Pectra de Ethereum. EIP-7702 introduce nuevos tipos de transacciones, dotando a las cuentas de origen (EOA) de programabilidad y composabilidad, difuminando la línea entre EOA y cuentas de contrato. Dado que actualmente no existe un estándar de contrato inteligente compatible con EIP-7702 que haya sido probado en condiciones reales, diferentes participantes del ecosistema, como usuarios, proveedores de servicios de billetera, desarrolladores y exchanges, enfrentan numerosos desafíos y oportunidades en la práctica. El contenido de las mejores prácticas expuesto en este artículo no puede cubrir todos los riesgos potenciales, pero sigue siendo valioso para que todas las partes lo consideren y apliquen en la práctica.