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

- antigua ranura de proxy OZ: - antiguo blog de Etherscan sobre soporte de proxy: - Ejemplo de FrontRun TX: