What's a precompiled contract and how are they different from native opcodes?

Question

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?

Answer 1

Even though I do not know the real reason, I will try to guess. There would be the following considerations:

1. 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.

2. 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.

3. 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.

4. 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.

Answer 2

Not an authority, but I know of someone who is...

From Vitalik's article, A Prehistory of the Ethereum Protocol

The second was the idea of “precompiles”, solving the problem of allowing complex cryptographic computations to be usable in the EVM without having to deal with EVM overhead. We had also gone through many more ambitious ideas about “native contracts”, where if miners have an optimized implementation of some contracts they could “vote” the gasprice of those contracts down, so contracts that most miners could execute much more quickly would naturally have a lower gas price; however, all of these ideas were rejected because we could not come up with a cryptoeconomically safe way to implement such a thing. An attacker could always create a contract which executes some trapdoored cryptographic operation, distribute the trapdoor to themselves and their friends to allow them to execute this contract much faster, then vote the gasprice down and use this to DoS the network. Instead we opted for the much less ambitious approach of having a smaller number of precompiles that are simply specified in the protocol, for common operations such as hashes and signature schemes.

I don't think there's a "right answer" to whether any given functionality must be a pre-compile or native. It looks like it came down to a design judgement for all the reasons stated earlier. Unless VB or gavofyork themselves weigh in, we'll never know for sure...