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

Six-Stage Data Flow

Six stages, and every one of them is a component we replaced rather than inherited.

Follow a single transaction. Optimum 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.

  • Stage 1, Optimum: bandwidth-optimal data spread
  • Stage 2, APEX: parallel, conflict-free execution
  • Stage 3, Jolt Pro GR: a proof per transaction
  • Stage 4, MLE-DB: hash-free state commitment
  • Stage 5, HSS-CoFHE: no party sees plaintext
  • Stage 6, Consensus: stake-weighted finality

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 Targets

ring0 targets 128-bit security across the stack, and "across the stack" is doing real work in that sentence.

A chain is only as strong as the weakest of its parts, and the parts are usually analyzed separately, by different people, under assumptions that were never checked against each other. We budget the error of every subsystem into a single number and verify that the sum still clears the target. That is a harder exercise than proving each piece alone, and it is the only one that describes what an attacker actually faces.

The core theorems are machine-checked, not argued in prose.

128-bit

Composed Soundness

128-bit

Hash Security

No Setup

Trusted Setup

Verified

Formal Proofs

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.

One shared algebraic core, so no layer has to translate into another's language. Verification far cheaper than proving, so the network can grow without closing itself. And a machine-checked proof behind every security claim, because a claim nobody can check is a claim nobody should trust.

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 provability: every core security claim is machine-checked