ring0 is currently in active development. Follow our progress. Read the docs

Ring0Ring0

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.

PropertyBlock ProducerBlock Validator
RoleExecute transactions + generate ZK proofsVerify proofs + cast consensus votes
HardwareHigh-performance: 128GB+ RAM, modern GPUCommodity: 8GB+ RAM, any modern CPU
OperationsVM execution, ZK proof generation, state updatesProof 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