Ситуация становится еще более интересной: способ, которым Etherscan был обманут, показывая неправильный контракт реализации, основан на установке 2 различных прокси-слотов в одной транзакции фронтраннинга. Таким образом, Etherscan использует определенную эвристику, которая включает различные слоты хранения для получения контракта реализации. Существует старый прокси от OpenZeppelin, который использовал следующий слот: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Теперь у нас также есть стандартный слот EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Таким образом, что произошло: старый слот прокси OpenZeppelin был записан с доброкачественным адресом реализации _и_ стандартный слот EIP-1967 также был записан с вредоносным адресом реализации. Поскольку Etherscan сначала запрашивает старый слот прокси, он сначала извлекает доброкачественный, и, таким образом, отображает его.

- старый слот прокси OZ: - старый блог Etherscan о поддержке прокси: - пример транзакции фронтран: