Understanding Ethereum’s precompilation
Justin Thaler, a16z’s research partner and associate professor at Georgetown University, recently provided an in-depth discussion of precompilation in the context of zero-knowledge virtual machines (zkVM). His insights aim to clarify misconceptions and explore the complexities of zkVM benchmarking, as detailed in a recent article by a16z crypto.
In the Ethereum Virtual Machine (EVM), precompilation is a natively supported operation to increase efficiency and reduce gas costs. These operations, such as the SHA-2 hash function, avoid the significant overhead of executing via EVM opcodes. The differences between precompiled and basic instructions (opcodes) are mainly semantic. Both are frequently executed operations, and precompilation handles more complex tasks such as cryptographic primitives.
Pre-compilation of zkVM designs
Thaler explains that in the zkVM design, precompilation refers to special-purpose SNARKs (Succinct Non-interactive Arguments of Knowledge) that target specific functions, including cryptographic hashing or elliptic curve operations. Historically, zkVM, like precompilation, implemented its base instructions through a manually optimized constraint system, making the difference between these terms purely semantic.
However, Jolt, zkVM, implements default instructions using lookups instead of traditional constraints. Thaler points out that while queries can be used to optimize certain processes, there is no major problem with enforcing existing constraints on some instructions.
zkVM benchmarking
Thaler emphasizes the importance of fair benchmarking when evaluating zkVM. He argues that benchmarking various RISC-V zkVMs without precompilation ensures a level playing field. Adding precompilation to zkVM changes the instruction set, increasing complexity and bug potential, eroding the value proposition of zkVM.
Thaler also addresses concerns about functional differences between zkEVM and EVM precompilation for zkVM. He points out that zkEVM must support EVM precompilation to maintain parity with the EVM, while zkVMs like Jolt use precompilation to extend beyond the standard RISC-V instruction set.
Broad benchmarking considerations
Thaler’s broad thinking on benchmarking highlights the goal of understanding the intrinsic performance profiles of different proof systems. He acknowledges that problems arise from a variety of confounding factors, including engineering effort and the inclusion of features such as precompilation.
Thaler anticipates that these confounding factors will decrease over time as the tools for building SNARKs mature, reducing the engineering effort required for adequate performance. He suggests that convergence to a standard constrained system simplifies benchmarking, making it easier to compare different SNARKs based on simple measures such as constrained system size.
Ultimately, Thaler emphasizes the need for transparency and detailed context in benchmarking to foster understanding and informed discussion within the community.
Image source: Shutterstock
. . .
tag