Es wird noch ausgefallener: Die Art und Weise, wie Etherscan getäuscht wurde, um den falschen Implementierungsvertrag anzuzeigen, basiert darauf, dass in derselben Frontrunning-Transaktion 2 verschiedene Proxy-Slots gesetzt werden. Etherscan verwendet eine bestimmte Heuristik, die verschiedene Speicher-Slots einbezieht, um den Implementierungsvertrag abzurufen. Es gibt einen alten Proxy von OpenZeppelin, der den folgenden Slot verwendet hat: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Wir haben jetzt auch den Standard-EIP-1967-Slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Was passiert ist, dass der alte OpenZeppelin-Proxy-Slot mit der harmlosen Implementierungsadresse _und_ der Standard-EIP-1967-Slot ebenfalls mit der bösartigen Implementierungsadresse beschrieben wurde. Da Etherscan zuerst den alten Proxy-Slot abfragt, wurde zuerst die harmlos aussehende Adresse abgerufen und somit angezeigt.

- alter OZ-Proxy-Slot: - alter Etherscan-Blog über Proxy-Unterstützung: - Beispiel für Frontrun-Transaktion: