2

First of all: I'm aware of the fact that only EOAs sign/create txs in Ethereum, that the public address of an EOA and the address of a Smart Contract are calculated differently and that it's infinitely improbable to "guess" the private key associated with a public address.

Now, because the public address of an EOA and the address of a Smart Contract, ultimately, respect the same format, it should be possible for someone to pick a private key that happens to correspond to a public address which is precisely the address of a Smart Contract (and this probability grows as more and more contracts are deployed to more and more EVM-compatible blockchains).

If/when the above happens, what if our lucky guesser tries submitting a tx on behalf of the Smart Contract address (say, transferring its ETH balance somewhere), just like they'd do for an EOA public address?

Are there any safeguards set in Ethereum to stop this from happening?

3
  • 1
    Good question. I think the only situation in which this becomes feasible is quantum computing. Someone could use a quantum computer to find the private key associated with a smart contract's address. Commented Apr 28 at 8:17
  • @PaulRazvanBerg, right... The question is what happens after that!
    – Iaroslav
    Commented Apr 28 at 18:31
  • 1
    This is a duplicate, could you please remove your bounty? This was called out in the yellow paper of Ethereum. Yes, address collisions of this type are possible and yes you'd be able to send money out of the contract. It's considered impossible due to how mathematically rare it is. The duplicate question is here: ethereum.stackexchange.com/questions/217/… Commented May 1 at 21:27

1 Answer 1

6
+50

If/when the above happens, what if our lucky guesser tries submitting a tx on behalf of the Smart Contract address (say, transferring its ETH balance somewhere), just like they'd do for an EOA public address?

Are there any safeguards set in Ethereum to stop this from happening?

The transaction would be rejected in accordance with EIP-3607 ("Reject transactions from senders with deployed code"). EIP-3607 has been implemented in Ethereum clients since 2021, e.g.:


Your question describes the scenario where a new EOA is found for an existing smart contract, but there are also two other collision scenarios. Addressing these scenarios for completeness:

1. Deploying a new smart contract to an existing EOA (the reverse of your scenario)

In this scenario, there is no additional risk created:

... [this] would be stupid, because it being a contract address will (with the implementation of EIP-3607) strictly reduce their capabilities. So there is no attack surface here.

Source: "Discussion for EIP-3607: Reject transactions from senders with deployed code"

2. Deploying a new smart contract to an existing smart contract

This scenario is already blocked by EIP-684 ("Revert creation in case of collision"):

If a contract creation is attempted due to a creation transaction, the CREATE opcode, the CREATE2 opcode, or any other reason, and the destination address already has either a nonzero nonce, or a nonzero code length, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.

1
  • Thank you for the detailed and insightful answer!
    – Iaroslav
    Commented May 3 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.