Handling Retroactive Changes (e.g. EIP-2681)

[lightclient]

There was no dissent in moving EIP-2681 forward during ACD 101. The problem is, what does that mean? With the separation of EIPs and network upgrades, "Final" doesn't mean mainnet.

Typically this isn't a major issue, because we can use the upgrade tracker and once its scheduled in an upgrade it is recorded during that transition. But EIP-2681 sets a limit on account nonces retroactively from genesis. My guess is that a modification should be made to the Yellow Paper as it is the most canonical spec for Ethereum?

cc: @axic, @MadeofTin, @Souptacular

[timbeiko]

@lightclient is this still relevant? Would this proposal help with it? ethereum/pm#295

[lightclient]

I suppose we can close this. I think this plays into the long term vision of moving to and eth2-like spec definition for ethereum. In that case, this question is trivial: just update the spec. Today, it is less trivial because "Final" on an EIP doesn't mean included on mainnet. But retroactive changes are confusing because they aren't included in a fork, so it's unclear how to signal that they are "canonical".

[axic]

Here's one solution: #401

And here's another: ethereum/yellowpaper#813

[timbeiko]

Just Do It ™️