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?

  • I would speculate that these were included as an idea about pegging to Bitcoin that may have been floating around in the early days, The hash algorithms are required to create a bitcoin address, although I am not sure what is meant by the public key recovery, or identity functions. – T9b May 11 '16 at 9:58

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.

  • 1
    Thanks, these are very good reasons! (Upvoted a long time ago; I haven't given the checkmark since hoping a core developer may answer one time.) – eth Aug 3 '16 at 10:42

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

  • Thanks Ben, I'll give it to you for quoting an authoritative source. However, I don't see how this actually "computational complexity" (Assuming that's what EVM overhead means). All miners and full nodes would still need to run the computation, whether it's initiative by an opcode, or a precompile... no? – maurelian Oct 17 '17 at 13:20
  • Maybe also reference this in your answer:, which provides a different reason... though Nick is a more recent arrival AFAIK. – maurelian Oct 17 '17 at 13:29
  • Most generous, but gratefully received @maurelian . I felt Nick's point was dealt with by #1 in the original answer. He did indeed join the Foundation in summer 2016, long after these design decisions were made. – benjaminion Oct 17 '17 at 15:12

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.