Diventa ancora più sofisticato: il modo in cui Etherscan è stato ingannato a mostrare il contratto di implementazione errato si basa sull'impostazione di 2 diversi slot proxy nella stessa transazione di frontrunning. Quindi Etherscan utilizza una certa euristica che incorpora diversi slot di archiviazione per recuperare il contratto di implementazione. C'è un vecchio proxy di OpenZeppelin che utilizzava il seguente slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Ora abbiamo anche lo slot standard EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Quindi, ciò che è successo è che il vecchio slot proxy di OpenZeppelin è stato scritto con l'indirizzo di implementazione benigno _e_ lo slot standard EIP-1967 è stato scritto anche con l'indirizzo di implementazione malevolo. Poiché Etherscan interroga prima il vecchio slot proxy, ha recuperato prima quello che sembrava benigno e quindi lo ha visualizzato.

- vecchio slot proxy OZ: - vecchio blog di Etherscan sul supporto proxy: - esempio di tx di frontrun: