Protocol Architecture
Roru Protocol Architecture - Technical Deep Dive
This document provides a comprehensive technical overview of the Roru Protocol architecture, including its core components, data structures, and operational principles.
Architecture Overview
Core Components
The Roru Protocol consists of five primary components:
Shielded State Tree: Merkle tree storing all shielded notes
Zero-Knowledge Proof System: Cryptographic proofs for privacy
Nullifier System: Prevents double-spending
Settlement Engine: Handles multi-chain settlement
Adapter Layer: Interfaces with different blockchains
System Design Principles
Privacy First:
All transaction data is encrypted
Zero-knowledge proofs hide amounts and identities
No linkability between transactions
Metadata protection
Security:
Cryptographic guarantees
Hardware security integration
Tamper-resistant design
Audit-friendly structure
Scalability:
Logarithmic proof sizes
Efficient state updates
Batch operations
Horizontal scaling
Shielded State Architecture
Merkle Tree Structure
Tree Properties:
Type: Binary Merkle tree
Depth: 32 levels
Capacity: 2^32 notes (4+ billion)
Hash function: SHA-256
Leaf nodes: Note commitments
Tree Organization:
Root (State Root)
/ \
Node 1 Node 2
/ \ / \
Node 3 Node 4 Node 5 Node 6
/ \ / \ / \ / \
Leaf1 Leaf2 Leaf3 Leaf4 Leaf5 Leaf6 Leaf7 Leaf8State Root:
Commits to entire tree
Updated with each transaction
Verifiable by anyone
Cannot be forged
Note Structure
Note Components:
Value: Transaction amount (hidden in proof)
Recipient: Shielded address (encrypted)
Randomness: Random value for commitment
Nullifier Key: Used to generate nullifier
Commitment: Pedersen commitment to note
Note Format:
pub struct Note {
pub value: u64,
pub recipient: ShieldedAddress,
pub randomness: Scalar,
pub nullifier_key: Scalar,
pub commitment: Commitment,
}Commitment Scheme
Pedersen Commitments:
Base points: G, H (on elliptic curve)
Commitment: C = vG + rH
Properties: Hiding, binding
Curve: BLS12-381
Commitment Generation:
fn commit(value: u64, randomness: Scalar) -> Commitment {
value * G + randomness * H
}Zero-Knowledge Proof System
Proof Architecture
Circuit Types:
Input Circuit: Validates note selection
Output Circuit: Validates new note creation
Balance Circuit: Validates value conservation
Authorization Circuit: Validates spending authorization
Proof System:
Type: Groth16 zk-SNARKs
Curve: BLS12-381
Proof size: ~1-2 KB
Verification time: <100ms
Circuit Design
Input Circuit:
Verifies note exists in tree
Validates nullifier generation
Checks authorization
Ensures note hasn't been spent
Output Circuit:
Validates new note creation
Ensures commitment correctness
Checks recipient format
Validates value range
Balance Circuit:
Verifies value conservation
Input sum = Output sum
No value creation/destruction
Range checks
Authorization Circuit:
Validates spending key
Checks signature
Verifies device attestation (if used)
Ensures authorization
Proof Generation
Witness Construction:
Select input notes
Generate nullifiers
Create output notes
Calculate commitments
Build Merkle paths
Construct witness
Proof Creation:
Execute circuit
Generate proof using proving key
Verify proof locally
Package proof bundle
Nullifier System
Nullifier Generation
Purpose: Prevent double-spending
Generation:
fn generate_nullifier(note: &Note, nullifier_key: &Scalar) -> Nullifier {
hash(note.commitment || nullifier_key)
}Properties:
Unique per note
Cannot be linked to note
Deterministic
Verifiable
Nullifier Set
Storage:
Sparse Merkle tree
Efficient lookups
Fast verification
Compact representation
Verification:
Check if nullifier exists
Prevent double-spending
Fast lookup: O(log n)
Transaction Structure
Transaction Components
Transaction Format:
pub struct Transaction {
pub inputs: Vec<Input>,
pub outputs: Vec<Output>,
pub proof: Proof,
pub nullifiers: Vec<Nullifier>,
pub public_data: PublicData,
pub signature: Signature,
}Input Structure:
pub struct Input {
pub note_commitment: Commitment,
pub merkle_path: MerklePath,
pub nullifier: Nullifier,
}Output Structure:
pub struct Output {
pub commitment: Commitment,
pub encrypted_note: EncryptedNote,
}Transaction Lifecycle
Creation:
Select input notes
Create output notes
Generate nullifiers
Build Merkle paths
Generate proof
Sign transaction
Validation:
Verify proof
Check nullifiers
Validate Merkle paths
Verify signature
Check balance
Settlement:
Update state tree
Add nullifiers
Add new notes
Update state root
Broadcast to blockchain
Settlement Engine
Multi-Chain Settlement
Architecture:
Unified shielded state
Chain-specific adapters
Atomic settlement
Cross-chain support
Settlement Process:
Transaction validated
State updated
Settlement transaction created
Broadcast to blockchain
Confirmation received
Finalization
Adapter Layer
Adapter Interface:
pub trait ChainAdapter {
async fn create_settlement(&self, tx: &SettlementTx) -> Result<TxHash>;
async fn get_confirmation(&self, hash: &TxHash) -> Result<Confirmation>;
async fn estimate_fees(&self, tx: &SettlementTx) -> Result<Fees>;
}Adapter Responsibilities:
Format transactions for chain
Handle chain-specific logic
Manage gas/fees
Handle confirmations
State Synchronization
Sync Protocol
Incremental Updates:
Only changed state
Merkle proofs
Efficient bandwidth
Fast synchronization
Sync Process:
Request state root
Compare with local
Request Merkle proofs
Verify proofs
Update local state
Merkle Proof Format
Proof Structure:
pub struct MerkleProof {
pub leaf: Commitment,
pub path: Vec<(Hash, bool)>, // (hash, is_right)
pub root: Hash,
}Verification:
Reconstruct path to root
Compare with state root
Verify correctness
Privacy Guarantees
Privacy Properties
Unlinkability:
Transactions cannot be linked
Addresses are unlinkable
No transaction graph
Complete privacy
Confidentiality:
Amounts hidden
Recipients hidden
Senders hidden
Complete confidentiality
Anonymity:
Sender anonymity
Recipient anonymity
Transaction anonymity
Full anonymity set
Privacy Mechanisms
Zero-Knowledge Proofs:
Hide all private data
Prove validity
No information leakage
Mathematical guarantees
Encryption:
Encrypted notes
Encrypted addresses
End-to-end encryption
Secure channels
Performance Characteristics
Scalability
State Tree:
Logarithmic depth
Efficient updates
Fast lookups
Scales to billions
Proof System:
Constant proof size
Fast verification
Efficient generation
Batch support
Efficiency
Proof Generation:
Optimized circuits
Efficient witness
Parallel processing
1-5 seconds typical
State Updates:
Incremental updates
Batch operations
Efficient algorithms
Fast synchronization
Security Model
Security Guarantees
Cryptographic Security:
Based on discrete log
Secure hash functions
Secure commitments
Secure signatures
Privacy Security:
Zero-knowledge guarantees
Encryption security
No information leakage
Mathematical proofs
Threat Model
Protected Against:
Double-spending
State tampering
Privacy breaches
Network attacks
Security Assumptions:
Cryptographic assumptions
Secure randomness
Secure key management
Trusted setup (if used)
Conclusion
The Roru Protocol provides:
Privacy: Complete transaction privacy
Security: Cryptographic guarantees
Scalability: Efficient and scalable
Flexibility: Multi-chain support
Performance: Fast and efficient
Understanding this architecture is essential for protocol-level development and integration.
Last updated