~/notes / consensus and blocks
Precompiles and Why They Exist
Some operations are too expensive to run as contract code, so they are implemented natively. The list is short and tells you what the chain considers important.
Certain cryptographic operations would cost an impractical amount of gas if implemented in ordinary contract code. Precompiles implement them natively at fixed addresses.
What they are
Special addresses that behave like contracts but are implemented in the client software rather than in bytecode.
Calling one costs a defined amount of gas, far less than the equivalent implemented in contract code would consume.
What they typically include
Signature recovery. Recovering a signer’s address from a signature. Used constantly, and prohibitively expensive if written as contract code.
Hash functions beyond the default, including those used by other chains, which makes cross-chain verification practical.
Elliptic curve operations for pairing-based cryptography, which is what makes zero knowledge proof verification and signature aggregation feasible on-chain.
Modular exponentiation, used in several cryptographic constructions.
Identity and data copying, a trivial one used for cheap memory operations.
Why the list matters
The set of precompiles determines what is economically possible on a chain.
Verifying a zero knowledge proof on-chain requires pairing operations. Without a precompile for them, it would cost more gas than a block contains. With one, it costs a manageable amount, which is what makes proof-verifying rollups possible.
So the precompile list is a statement about which cryptographic constructions the chain intends to support.
How they are added
Through the protocol upgrade process, like any other consensus change. A new precompile requires every client to implement it identically, which is why additions are infrequent and carefully specified.
The specification must be exact, because a discrepancy between client implementations is a consensus failure.
The trade-off
Efficiency. Operations that would be impossible become routine.
Rigidity. A precompile is fixed until an upgrade changes it. A contract implementation can be replaced by anyone at any time.
Surface area. Each precompile is code in every client that must be correct. Bugs in precompile implementations have caused consensus issues on some networks.
The reader’s takeaway
When you read that a chain supports a particular proof system or signature scheme efficiently, a precompile is usually the reason.
And when a proposed feature is described as too expensive to implement on-chain, the question is frequently whether a precompile for it exists, which is a governance question rather than a technical impossibility.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.