The Yellow Paper states:
These are four so-called ‘precompiled’ contracts, meant as a
preliminary piece of architecture that may later become native
extensions. The four contracts in addresses 1, 2, 3 and 4 execute the
elliptic curve public key recovery function, the SHA2 256-bit hash
scheme, the RIPEMD 160-bit hash scheme and the identity function
respectively.
What's a precompiled contract and how are they different from native opcodes? If a precompiled contract becomes a native extension, what does it gain? Given widespread usage of SHA2-256, why wasn't it implemented natively?
Best Answer
Even though I do not know the real reason, I will try to guess. There would be the following considerations:
Size of the namespace. There are not so many possible opcodes, so these need to be allocated very sparingly. The space of contract addresses, on the other hand, is practically unlimited for all practical purposes.
Risk of name re-use. It is a good software engineering principle not to reuse names (or opcodes), especially in the system where one does not control the upgrades.
Utility. There are some operations that are always useful, like arithmetic operations, bit twiddling, flow control and others. Cryptographic primitives, on the other hand, may be in the future proven inadequate, and something else will be used instead. Making such primitives into opcodes is taking a risk of spending valuable namespace on something that could become obsolete.
Gentle promotion of popular/useful code. If certain things, for instance, zkSNARKs operations, or Dogecoin PoW verification, starting with solidity code, then being partially optimised, become very useful and popular, they might become pre-compiled contract. Such promotion is a much gentler change to the network than introducing a new opcode.