La distinción importa para las billeteras calientes de los exchanges y los fondos de tesorería cuyos controles dan por sentado que solo firman transacciones ordinarias. Como informó anteriormente The Defiant, el codirector ejecutivo de Binance, Richard Teng, dijo que el atacante de la brecha de seguridad usó EIP-7702 para obtener autorización de ejecución sobre una billetera caliente. «Esa delegación no pasó por nuestros controles de aprobación habituales», dijo.
Una transacción on-chain registrada por Etherscan muestra una sola llamada a Binance 14 que transfirió aproximadamente 167464 ETH y 1615 millones de USDT, junto con otros tokens, al atacante.
Un interruptor de un solo sentido
La especificación del borrador reutilizaría una forma actualmente no válida de la transacción tipo 4 de EIP-7702: una transacción dirigida a la propia dirección, con valor cero, sin datos y con listas de acceso y autorización vacías. Instalaría un marcador no ejecutable de tres bytes, provisionalmente `0xef0200`, sin ejecutar ningún código delegado existente.
Una vez instalado, el marcador haría que se omitieran las autorizaciones de delegación futuras, incluidos los intentos de eliminarlo. La cuenta conservaría su dirección, las transferencias ordinarias y las llamadas a contratos, mientras que las llamadas entrantes no ejecutarían código. El costo fijo propuesto es de 33500 gas, una cifra que, según el autor, no se ha sometido a pruebas de rendimiento.
La protección se limita a la delegación. Una clave privada comprometida aún podría transferir fondos, otorgar aprobaciones de tokens o firmar autorizaciones de contratos. Las aprobaciones existentes no se revocarían. El borrador también advierte que excluirse podría desactivar mecanismos de recuperación que dependen de la delegación o hacer inaccesibles los activos que requieren el código del delegado anterior.
La expiración aborda un riesgo distinto
Otro borrador de Joseph Delong, en la PR #12601, exigiría que cada autorización firmara una referencia a un bloque que estuviera entre los 256 antecesores anteriores al bloque de inclusión. Esto limitaría el plazo para aplicar autorizaciones no utilizadas, sin hacer expirar la delegación ya instalada.
Otro borrador, EIP-7851, adopta un enfoque distinto: desactivar permanentemente la autoridad de la clave de firma original a nivel de protocolo, dejando que el código de la billetera pueda actualizar la delegación. La nueva opción de exclusión, en cambio, conserva las facultades habituales de la clave para realizar transacciones y elimina la capacidad de delegación.
El diseño de la opción de exclusión aún necesita trabajo de compatibilidad. La codificación del marcador es provisional, y los contratos o las billeteras que identifican las cuentas ordinarias porque carecen de código podrían rechazar las cuentas marcadas. Las billeteras y los firmantes de hardware también tendrían que reconocer el nuevo tipo de transacción y presentarlo como irreversible.