Update EIP-4788: set nonce of beacon root history address to nonzero

[holiman]

This is a not-yet approved specification-change for EIP 4788. I put it up for discussion on next ACD.

[eth-bot]

File EIPS/eip-4788.md

Requires 1 more reviewers from @adietrichs, @djrtwo, @ralexstokes

[ralexstokes]

this works and should alleviate the issues people have had testing this

one downside is that we will need to remember to do something like this for each stateful precompile we decide to deploy in the future (e.g. EIP-7002)

which suggests a more general solution (update EIP-161 to exclude precompiles?) would be less of a foot gun in the future

but I am fine w/ this change to move things along if everyone else is satisfied w/ it

[jochem-brouwer]

this works and should alleviate the issues people have had testing this

one downside is that we will need to remember to do something like this for each stateful precompile we decide to deploy in the future (e.g. EIP-7002)

which suggests a more general solution (update EIP-161 to exclude precompiles?) would be less of a foot gun in the future

but I am fine w/ this change to move things along if everyone else is satisfied w/ it

@ralexstokes I do not think this is a good idea. This means that the weird pre-Spurious Dragon behavior prior to EIP 161 (state trie clearing) that it is possible to create empty accounts in the trie, now gets back. This now means that for a precompile, it is possible to create an empty account in the trie at that precompile address. This empty account is thus an account with no code, no balance and no nonce (per EIP 161 storage does not matter). This has the weird logic that if you request an account over RPC, it can return the empty account, but this empty account can or cannot exist in the trie. I do not think we should return this. (If you would request a proof of the existence of these empty-but-in-trie account or the existence of this empty-but-not-in-trie account, you would get different proofs).

I would more be in favor to do a one-time upgrade of all precompiles (as defined by a precompile range EIP, for instance https://eips.ethereum.org/EIPS/eip-1352) where we just set the nonce of these precompiles to 1. We now should never (i.e. in the reasonable future) have the problem that we "forget" to set the nonce to 1 for a precompile. We have had testnets in the past (I think Baikal?) where we forgot to set the nonce to nonzero in this genesis. If we would create this EIP, we can just make it mandatory that upon activation of this EIP, the nonce is set to nonzero and the account can thus never be empty/dead regarding the precompiles. This would also reduce the size of genesis files for testnets.

[Demuirgos]

can't we just set the account to some clear state without conditions, so we can say

• Set the HISTORY_STORAGE_ADDRESS's nonce to 1 and balance to 0

[holiman]

Empty:

An account is considered empty when it has no code and zero nonce and zero balance.

If we make the account hold code, then the change in this PR becomes moot.