To staje się jeszcze bardziej wyszukane: sposób, w jaki Etherscan został oszukany, aby pokazać niewłaściwy kontrakt implementacji, opiera się na ustawieniu 2 różnych slotów proxy w tej samej transakcji frontrunning. Etherscan używa pewnej heurystyki, która uwzględnia różne sloty pamięci, aby pobrać kontrakt implementacji. Istnieje stary proxy od OpenZeppelin, który używał następującego slotu: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Mamy teraz również standardowy slot EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Co się stało, to to, że stary slot proxy OpenZeppelin został zapisany z benignym adresem implementacji _i_ standardowy slot EIP-1967 również został zapisany z złośliwym adresem implementacji. Ponieważ Etherscan najpierw zapytuje o stary slot proxy, najpierw pobrał ten wyglądający na nieszkodliwy i w ten sposób go wyświetlił.

- stary slot proxy OZ: - stary blog Etherscan na temat wsparcia proxy: - przykład transakcji frontrun: