Regarding breaking invariants, here’s another example. Even since the Devcon in Mexico, I’ve been trying to raise awareness of the fact that
CREATE2 will break an invariant: a contract
A which has code
C at one point in time might have code
D at another point in time. (Back then, it was another EIP but same effect).
This is something that @AlexeyAkhunov also found out indedependently, despite the discussion having taken place in various places. Do contract developers know about this? It’s really hard to say. Despite all the discussions, I still believe that a lot of devs aren’t aware of this. It might not make any difference in 99.9% of all cases, but OTOH might make all the difference in 0.1% of the cases.
My take is that we need to produce an ‘Audit’, which should be based on a common template, which focuses on things like this. That audit should be performed by people who are both evm-nerds (and I don’t mean that derogatory, I count myself as one) and also know contract-development. The audit should be commissioned as soon as an EIP is accepted, and when done, it should be stored in the EIP repository and published far and wide.
Things that I would like to see in focus for such an audit would be
- Invariants broken / changed,
- Potential edgecases that need to be handled
- Important testcases for edgecases
- Consequences for existing contracts
- Consequences for future contracts
- Potential for DoS-attacks due to this change