EIP-7702: Gran cambio en las cuentas externas de Ethereum

Ethereum se prepara para la actualización Pectra, en la cual la EIP-7702 ha realizado una transformación revolucionaria en la cuenta externa de Ethereum (EOA). Esta propuesta difumina la frontera entre EOA y la cuenta de contrato CA, siendo un paso clave hacia la abstracción nativa de cuentas, y aporta 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á guías prácticas para los diferentes participantes.

Análisis de protocolo

Resumen

EIP-7702 introduce un nuevo tipo de transacción que permite a la EOA especificar una dirección de contrato inteligente y establecer código para ella. Esto permite que la EOA ejecute código como un contrato inteligente, mientras conserva la capacidad de iniciar transacciones. Esta característica otorga a la 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. EIP-7702 es perfectamente compatible con las carteras de contrato inteligente implementadas 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 contiene el campo authorization_list, que puede incluir múltiples entradas de autorización. Cada entrada de autorización contiene chain_id, address, nonce y datos de firma.

implementación

Al firmar los datos de autorización, el autorizador debe codificar RLP chain_id, address y nonce, junto con el número MAGIC, y luego realizar el cálculo hash keccak256. MAGIC (0x05) se utiliza como delimitador de dominio para asegurar que los resultados de diferentes tipos de firma no entren en conflicto.

Cuando chain_id es 0, significa que la autorización se puede repetir en todas las cadenas compatibles con EVM que soporten EIP-7702. Antes de ejecutar la transacción, el Proposer realizará una verificación previa para asegurarse de que la transacción no sea una transacción de creación de contrato. El campo authorization_list en la transacción debe contener al menos un elemento de autorización.

Al ejecutar la transacción del nodo, primero se incrementa el nonce del iniciador, luego se realiza la operación applyAuthorization para cada entrada de autorización. Si ocurre un error, esa entrada de autorización se omitirá y las demás entradas continuarán aplicándose. Una vez completada la autorización, el campo code de la dirección del autorizador se establecerá en 0xef0100||address. El autorizador puede establecer la dirección objetivo del delegado como 0 para eliminar la autorización.

Mejores Prácticas

A pesar de que EIP-7702 inyecta nueva vitalidad en el ecosistema de Ethereum, también conlleva nuevos riesgos. A continuación se presentan los aspectos que los participantes del ecosistema deben tener en cuenta:

almacenamiento de clave privada

Incluso si después de delegar EOA se pueden resolver problemas de pérdida de fondos a través de métodos como la recuperación social, aún no se puede evitar el riesgo de filtración de claves privadas. Los usuarios deben priorizar la protección de sus claves privadas.

repetición multichain

Los usuarios pueden elegir el chainId 0 para delegar, lo que lo hace efectivo en múltiples cadenas. Sin embargo, la misma dirección de contrato en diferentes cadenas puede tener diferentes implementaciones. Los proveedores de servicios de billetera deben verificar si la cadena de delegación coincide con la red actual y advertir a los usuarios sobre los riesgos asociados.

no se puede inicializar

EIP-7702 no puede llamar a la función de inicialización al desplegarse como un contrato proxy ERC-1967. Los desarrolladores deben realizar una verificación de permisos durante la operación de inicialización de la cuenta, para evitar el riesgo de ser adelantados.

gestión de almacenamiento

Redelegar a una dirección de contrato diferente puede causar diferencias en la estructura de almacenamiento, lo que puede resultar en el bloqueo de la cuenta o la pérdida de fondos. Los desarrolladores deben seguir la Fórmula de Namespace ERC-7201, asignando variables a ubicaciones de almacenamiento independientes.

recarga falsa

Los exchanges centralizados pueden enfrentar la situación de la generalización de recargas de contratos inteligentes y deben verificar el estado de las transacciones de recarga a través de trace para prevenir el riesgo de recargas falsas.

conversión de cuenta

Las cuentas pueden convertirse libremente entre EOA y SC, rompiendo algunas suposiciones de seguridad que solo permiten que EOA participe en los proyectos. Los desarrolladores deben suponer que los futuros participantes pueden ser todos contratos inteligentes.

compatibilidad de contratos

Los desarrolladores deben asegurarse de que el contrato objetivo delegado por el usuario implemente las funciones de callback correspondientes para ser compatible con los tokens más utilizados.

chequeo de pesca

Los proveedores de servicios de billetera deben apoyar lo antes posible el tipo de transacción EIP-7702, destacando el contrato objetivo al momento de la firma delegada por el usuario, y realizando un análisis automático en profundidad para mitigar el riesgo de ataques de phishing.

Resumen

EIP-7702, a través de un nuevo tipo de transacción, otorga a EOA programabilidad y combinabilidad, difuminando la frontera entre EOA y cuentas de contrato. Los diferentes participantes del ecosistema enfrentan numerosos desafíos y oportunidades, y las mejores prácticas proporcionadas en este artículo son dignas de ser aplicadas en la práctica.