Fica ainda mais sofisticado: a maneira como o Etherscan foi enganado mostrando o contrato de implementação errado é baseada na configuração de 2 slots de proxy diferentes no mesmo frontrunning tx. Portanto, o Etherscan usa uma certa heurística que incorpora diferentes slots de armazenamento para recuperar o contrato de implementação. Há um proxy antigo do OpenZeppelin que usou o seguinte slot: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Agora também temos o slot padrão EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Então, o que aconteceu é que o antigo slot de proxy OpenZeppelin foi gravado com o endereço de implementação benigno _e_ o slot padrão EIP-1967 também foi gravado com o endereço de implementação malicioso. Como o Etherscan consulta primeiro o slot de proxy antigo, ele recuperou o de aparência benigna primeiro e, portanto, o exibiu.

- slot de proxy OZ antigo: - antigo blog do Etherscan sobre suporte a proxy: - Exemplo de FrontRun TX: