Ethereum account versioning

EIPs EIPs core
,
4

I can see in EIP-1702 that no account versioning is scheduled for the precompiled contracts.
See Section Precompiled Contract and Externally-owned Address of EIP-1702: Generalized Account Versioning Scheme

Precompiled contracts and externally-owned addresses do not have version

Why such a decision has been taken?

I see several benefits to have version numbers for the precompiled contracts.

  1. It could allow forks of Ethereum to define their set of precompiled without interfering with the addressing scheme used on the main chain (and without needing to allocate/reserve a range of addresses of precompiled for “forks’ custom precompiled” which IMHO does not provide an elegant solution). That way, the precompiled version would always be 0 on the main chain, while it could be set to be =/= 0 on forks so that the same address can be used to call a different/custom precompiled. This makes it easier for forks of Ethereum to define their precompiled and makes it trivial to keep a forked client in sync with the parent project.
  2. I also see a benefit of using precompiled versioning on main chain as it could be used to introduce newer versions of the precompiled, and could thus be used to provide backward compatibility. Eg: We could define a new snark/pairing friendly curve on Ethereum and introduce the corresponding precompiled contracts as an upgraded version of the current bn256 precompiled. We know that the bn256 package used on Ethereum was initially claiming to provide 128 bits of security. However, recent work (Kim–Barbulescu variant of the Number Field Sieve to compute discrete logarithms in finite fields | ellipticnews) suggest this is not the case anymore. For this reason, it would make sense to either replace the bn precompiled by precompiled for another curve (BLS12-381?) but this would break backward compatibility (I think it’s a good thing actually), or we could add a new version for the point addition, scalar multiplication and pairing check precompiled such that arithmetic is done over the new curve. As the set of precompiled grows (blake2b has just been introduced which is great) and as new cryptographic primitives and curves are added I think we should think about the event in which new attacks on these are published which could affect the security promises - or even worst - break some of these. For this reason, supporting versioning would make sense I think.

Hopefully this makes sense, and please let me know if I missed something!

[EDIT] I proposed an EIP to address some of the matters mentioned above. A thread is dedicated to discuss it here: EIP-2274: Multiple address spaces for Precompiled contracts happy to discuss this further :slight_smile: