Precompiled Contracts

Precompiled contracts are specialized, “native” functions built directly into the blockchain protocol at specific, reserved addresses. Unlike standard smart contracts, which consist of bytecode that must be executed by the EVM’s interpreter loop, precompiled contracts are implemented in the host language (such as Go) for maximum efficiency.

Purpose and Functionality

The primary purpose of precompiled contracts is to perform complex or computationally intensive tasks that would be prohibitively expensive or too slow to run as standard EVM bytecode. By executing as native code, they provide high-performance operations while maintaining a deterministic gas cost.

Common use cases for these contracts include:

• Cryptographic Operations: Tasks like recovering the sender of a signature (ecrecover at address 0x01) or performing specific cryptographic hashing like sha256 and ripemd160.
• Mathematical Complexity: Large-number operations such as modular exponentiation (bigModExp) used in various encryption schemes.
• Privacy and Scaling: Advanced elliptic curve math, such as BN256 and BLS12-381 operations (addition, scalar multiplication, and pairing), which are essential for zero-knowledge proofs and Layer 2 scaling.
• Data Availability: Specialized tasks like kzgPointEvaluation for verifying blob data in post-Cancun networks.

How They Work (Protocol View)

When the protocol initiates a Call to an address, it first checks if that address maps to a known precompile for the current network epoch.

1. Bypassing the Interpreter: If the address is a precompile, the EVM bypasses the standard bytecode interpreter (EVM.Run) entirely.
2. Native Execution: The system instead calls RunPrecompiledContract, which directly invokes the native implementation of the logic.
3. Gas Calculation: Every precompiled contract has its own RequiredGas function that calculates the fee based on the size or complexity of the input data provided.
4. Protocol Rules: The specific set of active precompiles is determined by the active hard fork rules (e.g., Istanbul, Cancun, or Jovian), as some precompiles are added or repriced over time to reflect hardware improvements or network needs.