Se vuelve aún más sofisticado: la forma en que Etherscan fue engañado para mostrar el contrato de implementación incorrecto se basa en establecer 2 slots de proxy diferentes en la misma transacción de frontrunning. Así que Etherscan utiliza una cierta heurística que incorpora diferentes slots de almacenamiento para recuperar el contrato de implementación. Hay un antiguo proxy de OpenZeppelin que utilizó el siguiente slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Ahora también tenemos el slot estándar EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Entonces, lo que sucedió es que el antiguo slot de proxy de OpenZeppelin se escribió con la dirección de implementación benigna _y_ el slot estándar EIP-1967 también se escribió con la dirección de implementación maliciosa. Dado que Etherscan consulta primero el antiguo slot de proxy, recuperó primero el que parecía benigno y, por lo tanto, lo mostró.

- antiguo slot de proxy OZ: - antiguo blog de Etherscan sobre soporte de proxy: - ejemplo de tx de frontrun: