Ethereum Precompiles | Composable and distributed systems study group
Mon, 2026-06-01
Sharing our experimental call summaries.
LLM-generated digests of Yak Collective study groups.
Reading: https://study.epf.wiki/mod/hvp/view.php?id=46
Precompiles Technical Deep Dive
This section explores the fundamental nature of precompiles, their current limitations, and emerging challenges as Ethereum evolves toward zero-knowledge architectures.
One participant’s initial observations from reviewing research materials
Surprised precompiles aren’t used more widely despite their efficiency benefits
“I’m surprised this isn’t used more”
Second reaction: “of course, it makes sense this isn’t used more because of client diversity”
Client diversity creates significant implementation challenges
Figuring out precompiles “across all possible edge cases, really, really tough”
Would need to keep implementations “very, very minimal” to manage complexity
Future contracts with swappable/pre-compiled functionality raise questions
Concept mentioned in chats about contracts providing swappable functionality
Uncertainty whether this is real development or “hallucination”
Gas efficiency concerns: “given that the purpose of some of these is because of the gas inefficiency of some of these operations in the evm, particularly some of these cryptographic operations”
May provide “less of a benefit because you need to keep the gas the same or you would need to do a hard fork”
ZK chain complications introduce new constraints
Precompiles need to be provable in zero-knowledge environments
“In some of the ZK chains you want to have these pre compiled also be provable”
“Reintroduces some of the difficulties from a different perspective”
Circuit-building limitations create bottlenecks
Limited by “different set of tooling” because “you have to build certain circuits”
“The inability to have good circuits for some of the cryptographic proofs does break some of your evm compatibility”
Open question about Ethereum’s ZK direction
“Given that moving ethereum and more of a ZK direction seems to be like a thing right now, I’m not really sure what the Ethereum developers are thinking about this”
Another participant’s pattern recognition insights from broader software principles
“Put the work in the right place” as fundamental optimization pattern
Asked notebook LM “what does the pre the word precompile itself emphasize?”
Answer: “put the work ahead up put the work in the right place”
Universal principle: “for the rest of our lives will always be true”
Handoffs create attack surfaces with dual risk vectors
“Anytime you move the work somewhere else the handoff becomes an attack surface”
US football analogy: “when you hand the ball off, you totally risk a fumble or a hijack”
Question: “how are they going to have those handoffs be safe”
Deterministic vs stochastic tension creates fundamental trade-offs
Research mentioned “keeping things deterministic and provable within a blockchain context”
Deterministic provides “predictable outcomes” but acts as “golden handcuffs that will screw you up”
Edge cases are inevitable: “you’ll never be able to anticipate every possible situation that might come up”
“Some stochasticity will always be in the mix”
Implementation Architecture & Trade-offs
This section examines the technical implementation details of precompiles, hardware analogies, and alternative architectural approaches that could improve efficiency and composability.
One participant’s technical understanding of precompile mechanics
Precompiles as “special functions built into ethereum that are vastly cheaper than they would otherwise be if they were written in evm”
Examples: “basic hash functions pre-compile allows you to actually do a hash in a meaningful way”
Implementation constraints and governance challenges
“Only this limited number of basically pre compiled set by the network”
“Adding precompiles is a hard fork”
Political dynamics: “there’s been politics around that”
Node-side implementation creates maintenance burden
Precompiles “much harder to upkeep for ethereum because they’re basically hard coded into the node itself”
“They’re not using the evm” but “expose themselves to the VM as like a virtual contract”
“Actual implementation has to be done node side”
Risk of network splits from implementation divergence
Can’t ship without “ability to arbitrarily change those node side codes for everyone”
“These are all implemented in different languages and if they’re ever even slightly off the network is going to split”
Universal demand vs operational caution
“Everyone wants to be a precompile, obviously”
“Node operators don’t want to do too many pre compiles”
Hardware analogy from another participant’s embedded systems experience
Microcontroller optimization strategies
“If microcontroller doesn’t have a floating point unit, what you do is basically you pre-calculate the function values”
Example: “sinusoidal wave functions, which you know you are going to use”
“Calculate the values and store it in memory, and then you just take those values from memory”
System-on-chip architectural decisions
“If you are doing a system on chip, you could do a lot of the calculation in hardware itself”
“The main question becomes which part of the entire computation you put it in actual Hardware, because that increases the cost”
Becomes “a human problem” and “people issue” about “which part of the compute stack actually becomes hardware”
Blockchain scaling implications
Enables “different l2s or other compute stuff to exist without actually being on the chain itself”
“You could have lots of other kinds of processing going on, then you could just submit a small proof to the main chain”
Key question: “what needs to be on the blockchain and what needs to be what if there needs to be a consensus about that compute or not?”
Alternative “Lego precompiles” architecture concept
Current EVM limitations stem from original design decisions
“The original evm was sort of an abstraction of what kind of computer we can put on this chain”
“It was made very slapdash” with “256 big words” that “make a lot of sense” for hashes/addresses
“They obviously hadn’t looked like we, wait, hold on. Is that actually remotely efficient when actually simulated on a real 64-bit CPU?”
Precompiles as workaround for EVM inefficiencies
“Precompiles are almost like a hack around that”
“Things that ethereum needs to be able to do cheaply, so we’ll just make those into pre compiles”
Proposed building-block approach
“More actually interested in version of ethereum where there’s a lot more precompiles”
“Precompiles were a lot more like building blocks” - “pre-compiled Lego”
“Instead of writing EVM code to do what you wanted, maybe you could Lego these precompiles together”
Potential for “order of magnitude more efficient”
Requires “much more precompiles, much more powerful pre compiles” but “Lego analogies, they should be very simple”
Trust & Consensus Models
This section explores fundamental computer science questions about trust in layered systems and how Ethereum’s consensus model differs from traditional centralized architectures.
RISC vs CISC analogy and better alternatives
Initial comparison to “old risk versus debates” about instruction set complexity
“Keep the instructions small and minimal and extremely atomic instructions versus support lots of complex instructions”
Precompiles “generally pop up as a solution when you’re trying to provide more complex functionality”
Superior analogy: ISA hardware vs operating system division
ChatGPT suggested “better analogy was not risk versus CIS, but the division between what the chip does at the ISA level on the hardware versus what the operating system does on top of it”
Trade-off between expressing “full range of simple to complex operations at the same low level of abstraction” vs performance
“Complex operations actually do take more resources” so “putting them at the lowest level of abstraction usually means you’re sacrificing performance”
Fundamental trust problem across computational layers
Universal uncertainty about execution path
“You never really know how your computation request is actually being handled”
“You issue that instruction” but “there’s lots of basically middleman characters along the way”
“You actually don’t know” the full execution path
Multiple interception points in traditional systems
Even “systems programmer” faces “many layers in between that can intercept and do something else”
Example: “add to registers” goes through “operating system API, which is then talking to low level kernels” with “probably six other layers”
“You’re trusting that each one is actually going to pass through to the advertised target layer”
Perfect emulation problem from computer science fundamentals
“This is not just thing you can design an architecture way around. It’s fundamental to computer science and the basics of universal turing machines”
“There’s literally no way to tell” because “perfect emulation is possible except for a few very subtle heat signatures like execution time”
Reference to Ken Thompson’s Turing Award lecture: “on trusting trust” about hacking compilers
EVM’s unique consensus-based trust model
No reference implementation creates different trust dynamics
“There is no actual Standard target hardware” for EVM
“What you actually have is the consensus overlap of all the clients”
“There is no such thing as a reference machine running the reference EVM”
Truth emerges from “intersection of actual clients who do consensus”
Contrast with centralized architectures
Intel x86: “there is kind of like a source of truth which is Intel and the way Intel chooses to implement it”
“At least some notion of authoritative truth backed by one entity”
Java VM: “centralized computing virtual machines” with “spec that was started by sun”
EVM as “hallucinated machine”
“It’s kind of like a hallucinated machine that doesn’t exist”
“Abstraction layer above hardware that exists only as a function of the consensus”
“Behavioral consensus between the various clients”
Clients agree to “implement in good faith in kind of like similar ways”
Common law comparison for robustness
“The ethereum evm is something like common law”
“Has the robustness of emerging from the consensus of multiple client behaviors”
Stronger than “claims of a single vendor like Intel or son or arm”
Even Linux “kind of has run like a corporate group” with “Linus and the core committers”
Social consensus challenges for upgrades
“The social part is more difficult than the actual technical part”
Current example: “talk about upgrading it to rest five”
One participant noted upgrade difficulty stems from social consensus requirements
Next Steps
Read Ken Thompson’s Turing Award paper “Trusting Trust” to understand fundamental trust issues in computing systems
Continue exploring computer science foundations of trust and verification across abstraction layers
Call chat on Yak Collective Discord:
https://discord.com/channels/692111190851059762/1511012362780545216
Interested in distributed and composable systems? We meet weekly on Mondays, at 1600 UTC: https://www.yakcollective.org/join
New here? Start here for some background context:
1) About Yak Collective
2) Online Governance Primer