Actualización de Ethereum Pectra y EIP-7702: un importante paso para difuminar la línea entre cuentas EOA y cuentas de contrato

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 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 tras la EIP-4337, lo que trae un nuevo modo de interacción al ecosistema de Ethereum.

Pectra ya ha completado el despliegue en la red de pruebas y se espera que pronto esté en la red principal. Este artículo analizará a fondo 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 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 para establecer su código. 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. EIP-7702 es completamente compatible con la billetera de contrato inteligente implementada por EIP-4337, y la integración sin problemas de ambas 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, 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 una de las cuales incluye:

• chain_id: la cadena en la que esta autorización delegada entra en vigor
• dirección: dirección objetivo delegada
• nonce: debe coincidir con el nonce de la cuenta autorizada actual
• y_parity, r, s: cuenta autorizada firma los datos de firma autorizados

El campo authorization_list dentro de una transacción puede contener múltiples entradas de autorización firmadas por diferentes cuentas autorizadas ( EOA ). El iniciador de la transacción puede ser diferente del autorizador, permitiendo que la operación de autorización del autorizador se realice con el pago de gas.

implementación

Cuando el otorgante firma los datos de autorización, primero debe codificar chain_id, address y nonce utilizando RLP. Luego, los datos codificados se combinan con MAGIC para realizar una operación de hash keccak256, obteniendo los datos a firmar. Finalmente, utilizando la clave privada del otorgante, se firma los datos hash obtenidos, obteniendo los datos y_parity, r, s. MAGIC (0x05) se utiliza como un 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 soportan EIP-7702, siempre que el nonce también 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 firmar y transmitirá la transacción a través de RPC. Antes de que la transacción se incluya en un bloque para su ejecución, el Proposer realizará una verificación previa de la transacción, llevando a cabo una verificación obligatoria 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 requieren que el campo authorization_list contenga al menos un ítem de autorización; si hay múltiples ítems de autorización firmados por el mismo autorizador, solo el último ítem de autorización tendrá efecto.

Durante el proceso de ejecución de la transacción, el nodo aumentará primero el valor de nonce del iniciador de la transacción y luego realizará la operación applyAuthorization en cada entrada de autorización en 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), el valor de nonce debe incrementarse en 1 al firmar la transacción de autorización.

Al aplicar un determinado elemento de autorización en el nodo, si se encuentra algún error, este elemento de autorización se omitirá, la transacción no fallará y otros elementos de autorización continuarán aplicándose, asegurando así que no se presente el riesgo de DoS en escenarios de autorización masiva.

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 una identificación fija, y address es la dirección objetivo del apoderamiento. Debido a las restricciones de EIP-3541, los usuarios no pueden desplegar el código de contrato que comienza con el byte 0xef de manera convencional, lo que garantiza que tal identificación solo pueda ser desplegada por transacciones de tipo SET_CODE_TX_TYPE (0x04).

Una vez completada la autorización, si el autorizador desea eliminarla, solo necesita establecer la dirección objetivo del delegado a 0.

El nuevo tipo de transacción introducido por EIP-7702 permite al autorizador ( EOA ) ejecutar código como un contrato inteligente, al mismo tiempo que mantiene 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 ), reduciendo significativamente el umbral de uso para los usuarios.

Mejores Prácticas

A pesar de que EIP-7702 ha inyectado 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 la práctica:

almacenamiento de claves privadas

Incluso si el EOA puede resolver los 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 el contrato inteligente después de la delegación, aún no se 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 de los activos en la cuenta a voluntad. Los usuarios o proveedores de servicios de billetera, después de completar la delegación para el EOA, incluso si eliminan por completo la clave privada almacenada localmente, no pueden eliminar completamente 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, siempre se debe priorizar la protección de la clave privada, prestando atención: Not your keys, not your coins.

multi-chain replay

Los usuarios, al firmar la autorización de delegación, pueden seleccionar la cadena en la que la delegación puede ser efectiva a través de chainId, también pueden elegir usar chainId como 0 para delegar, lo que permite que la delegación sea reproducible y efectiva 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 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 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 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

La mayoría de las carteras de contratos inteligentes predominantes actualmente adoptan un modelo de proxy. Al desplegar, el proxy de la cartera 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 cartera y el despliegue de la cartera proxy, evitando problemas de inicialización anticipada. Sin embargo, cuando los usuarios utilizan EIP-7702 para delegar, solo actualizarán el campo de código de su dirección, y no podrán inicializar a través de la dirección delegada. Esto significa que EIP-7702 no puede invocar la función de inicialización para la inicialización de la cartera en la transacción de despliegue del contrato como lo haría un contrato proxy ERC-1967 común.

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

Al utilizar la función de delegación EIP-7702, los usuarios pueden necesitar volver a delegar en diferentes direcciones de contrato debido a cambios en los requisitos de la función, actualizaciones de la 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 provocar el bloqueo de la cuenta, la pérdida de fondos y otros efectos negativos.

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 especialmente para EIP-7702: incluye el uso de ERC-7201 para prevenir conflictos de almacenamiento y validar 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 el usuario realice un encargo, la EOA también podrá usarse como un contrato inteligente, por lo que el intercambio (CEX) podría enfrentar una situación de generalización de recargas a través 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 EIP-7702, el tipo de cuenta del usuario puede cambiar libremente entre EOA y SC, lo que permite que la cuenta inicie transacciones y también sea invocada. Esto significa que cuando la cuenta se invoca 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, suponer que tx.origin siempre es EOA ya no será viable. De igual 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 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 la función Hook al realizar transferencias de contratos, lo que significa que el receptor debe implementar la función de devolución de llamada correspondiente para recibir tokens con éxito.

Para los desarrolladores, el contrato objetivo delegado por el usuario debería implementar las funciones de retorno correspondientes para garantizar 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 podrían estar controlados por contratos inteligentes. Una vez que el usuario delegue la 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 la firma delegada, se debe mostrar al usuario el contrato objetivo de la delegación, para mitigar el riesgo de que el usuario pueda sufrir un ataque de phishing.

Además, un análisis automático más profundo de los contratos objetivo delegados a la cuenta, como 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, permitiendo que las EOA tengan 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, 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 cubrir todos los riesgos potenciales, pero aún así es digno de ser considerado y aplicado por todas las partes en la operación real.