Understanding Precompiles in Ethereum
Justin Thaler, a Research Partner at a16z and Associate Professor at Georgetown University, has recently provided an in-depth discussion on precompiles in the context of zero-knowledge virtual machines (zkVMs). His insights aim to clarify misconceptions and explore the intricacies of benchmarking zkVMs, as detailed in a recent article by a16z crypto.
In the Ethereum Virtual Machine (EVM), precompiles are operations natively supported to enhance efficiency and reduce gas costs. These operations, such as the SHA-2 hash function, avoid the substantial overheads of executing through EVM opcodes. The distinction between precompiles and primitive instructions (opcodes) is mainly semantic. Both are frequently executed operations, with precompiles handling more complex tasks like cryptographic primitives.
Precompiles in zkVM Design
Thaler explains that in zkVM design, precompiles refer to special-purpose SNARKs (Succinct Non-interactive Arguments of Knowledge) targeted at specific functionalities, including cryptographic hashing or elliptic curve operations. Historically, zkVMs implemented primitive instructions via hand-optimized constraint systems, just like precompiles, making the difference between these terms purely semantic.
However, Jolt, a zkVM, implements primitive instructions using lookups instead of traditional constraints. Thaler notes that while using lookups can optimize certain processes, there are no significant issues with employing traditional constraints for some instructions.
Benchmarking zkVMs
Thaler stresses the importance of fair benchmarking in evaluating zkVMs. He argues that benchmarking various RISC-V zkVMs without precompiles ensures a level playing field. Adding precompiles to a zkVM alters its instruction set, thereby eroding the zkVM’s value proposition by increasing the complexity and potential for bugs.
Thaler also addresses concerns about the functional differences between EVM precompiles for zkEVMs and zkVMs. He notes that zkEVMs must support EVM precompiles to maintain parity with the EVM, whereas zkVMs like Jolt use precompiles to expand beyond the standard RISC-V instruction set.
Broader Benchmarking Considerations
Thaler’s broader thoughts on benchmarking highlight the goal of understanding the intrinsic performance profiles of different proof systems. He acknowledges the challenges posed by various confounding factors, such as engineering effort and the inclusion of features like precompiles.
Thaler anticipates that these confounding factors will diminish over time as tooling for building SNARKs matures, reducing the engineering effort required for decent performance. He suggests that convergence on a standard constraint system could simplify benchmarking, making it easier to compare different SNARKs based on simple measures like constraint-system size.
Ultimately, Thaler emphasizes the need for transparency and detailed context in benchmarking to foster understanding and informed discussions within the community.
Image source: Shutterstock
. . .
Tags
