WTF is a pre-compile?
The term “pre-compiles” is currently making the rounds in the crypto space, cropping up in conversations at conferences, on social media platforms such as Twitter Spaces, Discord, and Reddit posts. In the realm of SmartContracts and the Ethereum Virtual Machine, this term is gaining traction, and it’s not just limited to Ethereum. People in the Avalanche space and those working with Cosmos AppChains, which are based on Ethermint, are also discussing pre-compiles with increasing frequency.
We’ll shed some light on this here. You don’t need to be a professional developer to understand this article. At least I try hard to keep this promise.
Pre-compiles are almost as old as the Ethereum Virtual Machine. They were already part of the early days of the protocol and can be found in the code base from years ago: https://github.com/ethereum/go-ethereum/commit/bbc4ea4ae8e8a962deae3d5693d9d4a9376eab88
So, what is a pre-compile?
In most simplified words, a pre-compile is like a built-in function (or, in other words: a built-in Macro-function) that can be used in SmartContract-development.
Pre-compiles are functions that are built directly into the Ethereum Virtual Machine. They provide complex or mathematically sophisticated tasks that can be used in Solidity or any other programming language used to write SmartContracts. And since this affects the heart of the Ethereum Virtual Machine (EVM), the term pre-compile is also often used in the space of Avalanche. This is because the C-Chain of the Avalanche blockchain is based on the EVM and thus has the same range of functions as Ethereum.
An excellent example of pre-compiles are cryptographic functions in Solidity: they are not built-in in the Solidity compiler. Instead, they are part of the internal Virtual Machine of Ethereum and just exported in a way that Solidity can execute them.
Frequently used candidates are functions like “ecrecover” or “sha256hash”. The current implementation of “ecrecover” inside the EVM looks like this:
Why is this called a pre-compile?
The Ethereum Virtual Machine (EVM) is the runtime environment in which Smart Contracts are executed on the Ethereum blockchain. Before a smart contract can be executed on the EVM, it needs to be compiled from its high-level programming language (such as Solidity) into bytecode, which is the machine-readable language of the EVM.
The process of compiling a Smart Contract into bytecode involves several steps, including lexical analysis, parsing, semantic analysis, and code generation. This process results in a compiled binary file containing the bytecode of the Smart Contract.
However, before the compiled bytecode can be executed on the EVM, it needs to be further processed in a pre-compile step. This step involves verifying that the bytecode is valid and meets certain security and optimization criteria.
Once the bytecode has passed the pre-compile step, it is ready to be executed on the EVM. The bytecode is deployed to the Ethereum network, and users can interact with the smart contract by sending transactions to its address.
With a custom pre-compile, new bytecodes can be added to this process to make custom functions available for Smart Contract developers. Over the last years, further pre-compiles have been added on some upgrades to Ethereum. The nature of a pre-compile allows protocol developers to add new functions without putting too much overhead on the primary internal core of the EVM.
Vitalik Buterin summarized the decision-making process that led to Pre-Compiles in its current form as follows:
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.
What is the advantage of having pre-compiles?
Pre-compiles offer a significant benefit by allowing the addition of new functions to the EVM protocol without necessitating internal modifications. This separate approach is comprised of three essential components:
- the registration process within the EVM
- the gas usage calculation
- and the execution of the pre-compile
Unlocking New Possibilities: Pre-Compiles in Ethereum Virtual Machine Offer Custom Gas Fee Scheme and Enhanced Functionality
While the third aspect enables the inclusion of additional functionality that Solidity currently lacks, it is the second point that holds particular intrigue. Pre-compiles empower us to perform operations that would otherwise be expensive if implemented solely in Solidity, transforming them into cost-effective procedures. The price of each pre-compile can be determined to our preference, whether by establishing a fixed rate or calculating it based on input parameters, such as the length of a string, for instance. By leveraging pre-compiles, we can establish a custom gas fee scheme tailored to our specific requirements.
Achieving Custom Functions in an Immutable Blockchain
But isn’t the EVM immutable and incapable of being extended by SmartContract developers at such a deep level?” It is indeed true that the EVM remains immutable, limiting the ability to make direct modifications. However, pre-compiles offer a solution by allowing for additions at the VM layer, nestled deep within the core of the EVM (we will explore practical use cases later on).
Over time, the Ethereum Virtual Machine has undergone significant upgrades, resulting in an expanded repertoire of pre-compiles. For instance, with the Byzantium upgrade, the implementation of cryptographic functions was revamped, introducing more advanced alternatives. In 2020, a series of Elliptic curve wrappers for BLS signatures were added as pre-compiles, further enhancing the EVM’s capabilities.
By continually expanding the list of pre-compiles, Ethereum paves the way for the integration of custom functions, pushing the boundaries of what can be achieved within the immutable blockchain paradigm.
Power feature for EVM based App-chains:
The utlimate killer feature of pre-compiles is that EVM-based App-Chains like Cosmos Zones or Avalanche SubNets can extend the functionality of EVM with native libraries for SmartContract development. This can be done at the protocol level or, depending on the architecture and perspective, at the network level.
A simple example: Solidity has poor support for string manipulation functions. But we could add them as pre-compiles to have such functions with a lower gas fee as it would cost to provide such functions with Solidity. This is possible because every pre-compile defines its own gas costs that will be used to pay for the execution eventually.
However, this also means that a new blockchain will be deployed that already contains all these pre-compiles. Avalanche EVM-based SubNets are good candidates for that because Avalanche already provides all the necessary infrastructure.
Conclusion
On the EVM Layer, pre-compiles allow protocol developers or VM developers to add new complex functions as native but isolated code blocks without touching the actual VM code.
When providing new App-chains like an Avalanche SubNet, developers are able to extend the existing EVM with new complex functions natively built-in on the network layer without modifying any existing source code of the EVM. Only the code block, where all the pre-compiles will be registered, must be touched.
