C'est encore plus sophistiqué : la façon dont Etherscan a été trompé en affichant le mauvais contrat d'implémentation repose sur la définition de 2 slots de proxy différents dans la même transaction de frontrunning. Ainsi, Etherscan utilise une certaine heuristique qui incorpore différents slots de stockage pour récupérer le contrat d'implémentation. Il existe un ancien proxy par OpenZeppelin qui utilisait le slot suivant : `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Nous avons maintenant aussi le slot standard EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Ce qui s'est passé, c'est que l'ancien slot de proxy OpenZeppelin a été écrit avec l'adresse d'implémentation bénigne _et_ le slot standard EIP-1967 a également été écrit avec l'adresse d'implémentation malveillante. Puisqu'Etherscan interroge d'abord l'ancien slot de proxy, il a récupéré le premier qui semblait bénin et l'a donc affiché.

- ancien slot de proxy OZ : - ancien blog Etherscan sur le support des proxies : - exemple de transaction de frontrun :