Section II
Architecture Overview
Multi-Core World Computer with Heterogeneous Validation
Ring0 organizes computation into atomicity zones that execute in parallel — like cores of a CPU. Each zone maintains its own state representation via MLE-DB. Cross-zone communication follows a message-passing model. Two distinct validator classes — high-performance block producers and lightweight block validators — enable extreme verification asymmetry.
multi core
Multi-Core World Computer
Ring0 models its execution environment as a multi-core world computer. Each atomicity zone operates as an independent core, maintaining its own state via MLE-DB. Intra-zone transactions achieve single-slot finality. Cross-zone messages use a message-passing model and settle within two slots. This architecture enables massive parallelism without the contention overhead of shared-state systems.
validator classes
Two Validator Classes
The heterogeneous architecture separates execution from verification through two distinct validator classes with radically different hardware requirements.
| 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 |
| Annual Cost | High-performance infrastructure | <$1M/year vs Ethereum's >$50M/year |
data flow
Six-Stage Data Flow
Every transaction flows through six sequential stages, from network ingestion to consensus finality. Each stage is handled by a dedicated subsystem built on the shared unified mathematical foundation.
- Stage 1 — Optimum Gossip: Bandwidth-optimal data dissemination via network coding
- Stage 2 — FAFO Scheduling: Ahead-of-formation parallel scheduling with automatic conflict detection
- Stage 3 — Jolt Pro GR Proving: Zero-knowledge proof generation for executed transactions
- Stage 4 — MLE-DB State Update: ZK-native state commitment updates
- Stage 5 — HSS-CoFHE Privacy: Secret-shared validation where no single party sees plaintext
- Stage 6 — Consensus: Delegated Proof-of-Stake with stake-weighted finality
dpos senators
Delegated Proof-of-Stake with Senators
Ring0 uses Delegated Proof-of-Stake (DPoS) where token holders delegate to stake-weighted senators. Senators participate in consensus by verifying proofs and casting votes. A two-thirds supermajority of stake-weighted votes finalizes each epoch. This design keeps the validator set lean (senators only verify proofs, never re-execute) while allowing broad token-holder participation through delegation.
security targets
Security Targets
Ring0's composed security achieves 127-bit soundness across all subsystems — meaning a malicious actor would need to perform more than 2^127 operations to forge a proof. Every component is designed to meet or exceed this threshold, and the composed security of the full system has been formally verified.
127-bit
Composed Soundness
128-bit
Hash Security
No Setup
Trusted Setup
Verified
Formal Proofs
design principles
Three Design Principles
Every architectural decision in Ring0 follows three core principles that ensure coherence across the stack.
- DP1 — Algebraic Coherence: All primitives share a common unified mathematical foundation and core operation
- DP2 — Verification Asymmetry: Prover cost >> Verifier cost. Validators never re-execute transactions.
- DP3 — Formal Provability: Every core claim is machine-checked via Lean 4 or EasyCrypt