Ethereum Pectra en la actualización EIP-7702: una transformación significativa que empodera a EOA

Introducción

Ethereum se prepara para la actualización Pectra, que es una actualización significativa. Entre ellas, el EIP-7702 ha realizado 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 nativa tras el EIP-4337, y trae un nuevo modo de interacción al ecosistema de Ethereum.

Pectra 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 Protocolos

Resumen

EIP-7702 introduce un nuevo tipo de transacción que permite a un EOA especificar una dirección de contrato inteligente, permitiendo así establecer código para el mismo. De esta manera, un EOA puede ejecutar código como un contrato inteligente, mientras mantiene la capacidad de iniciar transacciones. Esta característica otorga al EOA programabilidad y composabilidad, 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 las billeteras de contrato inteligente implementadas por EIP-4337, y la integración sin fisuras de ambos simplifica enormemente el proceso de desarrollo y 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 chain_id indica la cadena en la que se efectúa esta autorización delegada.
• 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 autorizados firmados por la cuenta autorizada

En el campo authorization_list de una transacción se pueden incluir múltiples entradas de autorización firmadas por diferentes cuentas autorizadas (EOA), es decir, el iniciador de la transacción puede ser diferente del autorizado, para realizar operaciones de autorización con el pago del gas por parte del autorizado.

realizar

El autorizador, al firmar los datos de autorización, debe primero codificar chain_id, address y nonce utilizando RLP. Luego, se realiza una operación de hash keccak256 combinando los datos codificados con el número MAGIC. De este modo, se obtiene los datos a firmar. Finalmente, se utiliza la clave privada del autorizador para firmar los datos hash, 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 generen conflictos.

Es importante tener en cuenta que, cuando el chain_id autorizado por el autorizador es 0, esto 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).

Una vez que el autorizador haya firmado 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 se incluya en un bloque y se ejecute, el Proposer realizará una verificación previa de la transacción, en la cual 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. En otras palabras, 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 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.

Luego, 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), al firmar la transacción de autorización, el valor del nonce debería incrementarse en 1.

Al aplicar un elemento de autorización en los nodos, si se encuentra con 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 la aplicación autorizada se complete, 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 desplegar código de contrato que comience con bytes 0xef de manera convencional, lo que garantiza que este tipo de identificadores solo puedan ser desplegados por transacciones del tipo SET_CODE_TX_TYPE (0x04).

Una vez completada la autorización, si el otorgante desea revocar la autorización, solo necesita establecer la dirección objetivo delegada en 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 el EIP-7702 ha inyectado nueva vida al ecosistema de Ethereum, los nuevos casos de uso también pueden conllevar nuevos riesgos. A continuación se presentan los aspectos a los que los participantes del ecosistema deben estar atentos en el proceso práctico:

almacenamiento de claves privadas

Aunque 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 incorporada en 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 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 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 utilizar la cuenta después de la delegación, los usuarios aún deben priorizar la protección de su clave privada y estar siempre atentos: Not your keys, not your coins.

Repetición de múltiples cadenas

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 de chainId. Por supuesto, los usuarios también pueden optar por usar chainId como 0 para la delegación, lo que permite que la delegación se repita y entre en vigor en múltiples cadenas, facilitando así que los usuarios puedan delegar con una sola firma 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 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 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, en diferentes cadenas, las mismas direcciones de contrato 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 de vanguardia utilizan un modelo de proxy. Al desplegar la billetera proxy, se llama 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 problemas de inicialización anticipada. Sin embargo, cuando los usuarios utilizan 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 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 común de ERC-1967.

Para los desarrolladores, al combinar 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

Los usuarios que utilizan la función de delegación EIP-7702 pueden necesitar volver a delegar en diferentes direcciones de contrato debido a cambios en los requisitos de la función, actualizaciones de billetera y otras razones. 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 en el caso de una nueva delegación, es posible que el nuevo contrato reutilice accidentalmente los datos del viejo contrato, lo que podría resultar en el bloqueo de la cuenta, la pérdida de fondos y otros resultados adversos.

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 el ERC-7201, asignando variables a ubicaciones de almacenamiento independientes específicas para mitigar el riesgo de conflictos de almacenamiento. Además, el ERC-7779 (draft) también proporciona un proceso estándar de re-delegación específicamente para el EIP-7702: incluye el uso del 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 delegación anterior.

recarga falsa

Después de realizar la delegación, el EOA también podrá ser utilizado como un contrato inteligente, por lo que los intercambios centralizados (CEX) podrían 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 de contratos inteligentes.

conversión de cuenta

Después de implementar la delegación 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 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 en proyectos solo a EOA.

Para los desarrolladores de contratos, asumir 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 reingreso 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 en el contrato, lo que significa que el receptor debe implementar la función de callback correspondiente para recibir los tokens con éxito.

Para los desarrolladores, los contratos objetivo delegados por los usuarios deberían implementar las funciones de callback correspondientes para garantizar la compatibilidad con los tokens principales.

verificació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 una firma de delegación, se debe mostrar a los usuarios el contrato de destino de la delegación, para mitigar el riesgo de ataques de phishing que los usuarios puedan sufrir.

Además, un análisis automático más profundo de los contratos objetivo de la delegación de cuentas (verificación de código abierto, verificación de permisos, etc.) puede ayudar mejor a los usuarios a evitar tales riesgos.

Resumen

EIP-7702 introduce un nuevo tipo de transacción, permitiendo que las cuentas de usuario (EOA) tengan programabilidad y composibilidad, 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, diversos participantes del ecosistema, como usuarios, proveedores de servicios de billetera, desarrolladores, CEX, etc., se enfrentan a numerosos desafíos y oportunidades en la aplicación práctica. El contenido de las mejores prácticas descritas en este artículo no puede abarcar todos los riesgos potenciales, pero aún así vale la pena que todas las partes lo consideren en la práctica.