Section II
Architecture Overview
Multi-Core World Computer with Heterogeneous Validation
Computation runs in parallel atomicity zones, like cores of a CPU: each keeps its own state, and two validator classes (heavy producers that prove, light validators that only verify) make verification far cheaper than execution.
multi core
Multi-Core World Computer
Processors stopped getting faster around 2005. The industry did not give up on performance — it stopped making one core faster and started adding cores. Blockchains never made that turn. They are still trying to make one core faster and calling it a roadmap.
An atomicity zone is a core. It holds its own state and its own order of events, and it does not wait on the others. Work that does not collide runs at the same time, in different places. Capacity grows by adding zones, so nobody has to buy a bigger machine for the network to speed up.
The comparison ends at coordination, and we will not pretend otherwise. Zones keep separate state, and talking between them costs something. That cost is the price of remaining one network instead of a pile of unrelated chains, and it is a price worth naming out loud.
validator classes
Two Validator Classes
Producing a block and making it final are different powers, and ring0 refuses to hand both to the same machine.
A producer runs the transactions on serious hardware and generates the proof. A validator checks that proof on a commodity machine and votes. The producer does the expensive thing; it does not get to declare its own output accepted.
That asymmetry is the entire scaling argument. If checking cost as much as executing, adding capacity would mean raising the floor for everyone, and the network would close quietly, one hardware upgrade at a time.
| Property | Block Producer | Block Validator |
|---|---|---|
| Role | Execute transactions + generate ZK proofs | Verify proofs + cast consensus votes |
| Hardware | High-performance: 128GB+ RAM, modern GPU | Commodity: 8GB+ RAM, any modern CPU |
| Operations | VM execution, ZK proof generation, state updates | Proof verification and consensus participation |
data flow
Execution, State, and Acceptance
Execution, state management, proof production, dissemination, and acceptance have distinct responsibilities. Their interfaces permit overlap; they are not six mandatory serial stages.
Follow a single transaction. RLNC spreads it across the network. APEX decides what can run beside it. Jolt Pro GR runs the program and proves the transition. MLE-DB binds that transition to the state the network had already accepted. If private data is involved, HSS-CoFHE keeps it closed. Then validators check the evidence and senators finalize.
If the transaction affects another zone, the message it produces carries the evidence of a finalized source transition. The destination verifies that evidence itself before applying anything. It never takes another zone's word for what happened.
- RLNC disseminates transaction, block, and proof data
- APEX schedules independent work and preserves required order
- Jolt Pro GR and MLE-DB connect execution proofs to authenticated state
- Validators verify evidence; senators finalize under consensus rules
- HSS-CoFHE supplies the confidentiality contract for eligible private work
- CHITA maintains custody of designated archival artifacts under separate obligations
dpos senators
Delegated Proof-of-Stake with Senators
Token holders delegate to senators. Senators finalize a block once a two-thirds supermajority of stake agrees.
The nesting matters more than the names. Every senator is a validator, and the producer for a slot is drawn from the eligible senators. So the machine that produced a block sits inside the set that checks it and outside the majority that finalizes it. It cannot finalize itself, and no vote turns an invalid proof into a valid one.
Storage providers sit entirely outside that hierarchy. They keep data and prove they kept it. They have no say in what becomes final, and no finalized record depends on any one of their private databases.
security targets
Security Profile
The 128-bit profile requires total composed error at most 2^-128 under its declared adversary model, query limits, and operating horizon. A subsystem’s local bound is not the network’s bound.
The budget accounts separately for polynomial-check error, commitment binding, authentication, and cryptographic reductions. Coding rank and storage availability have their own assumptions and deadlines. Hash output width is not a collision-security proof, and a classical work factor is not a post-quantum guarantee.
Machine-checked algebraic lemmas establish their stated conclusions under explicit premises. A complete protocol claim additionally requires the state anchors, challenge distribution, execution semantics, and composition contracts those lemmas rely on.
2^-128
Error Budget
Explicit
Assumptions
No Setup
Trusted Setup
Lean
Algebraic Lemmas
design principles
Three Design Principles
Three rules were held for every component, and they are the reason the parts fit together instead of merely shipping together.
Shared algebraic interfaces reduce conversion between state, proving, and private execution. Verification is separate from production, so participation does not require repeating the producer’s work. Security statements name their assumptions, their proof, and the boundary of what it establishes.
Each of these killed designs we liked. That is how you know they are rules and not slogans.
- DP1 Algebraic coherence: one shared foundation across all layers
- DP2 Verification asymmetry: proving costs far more than verifying; validators never re-execute
- DP3 Formal accountability: checked algebraic lemmas and explicit protocol reduction obligations
