Det blir enda mer fancy: måten Etherscan ble lurt på ved å vise feil implementeringskontrakt er basert på å sette 2 forskjellige proxy-spor i samme frontrunning tx. Så Etherscan bruker en viss heuristikk som inneholder forskjellige lagringsspor for å hente implementeringskontrakten. Det er en gammel proxy av OpenZeppelin som brukte følgende spor: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Vi har nå også standard EIP-1967-sporet 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Så det som skjedde er at det gamle OpenZeppelin-proxy-sporet ble skrevet til med den godartede implementeringsadressen _og_ standard EIP-1967-sporet ble også skrevet til med den ondsinnede implementeringsadressen. Siden Etherscan først spør etter det gamle proxy-sporet, hentet den den godartede utseendet først og viste den dermed.

- gammel OZ proxy-plass: - gammel Etherscan-blogg om proxy-støtte: - Eksempel på FrontRun TX: