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:

1. Shielded State Tree: Merkle tree storing all shielded notes

2. Zero-Knowledge Proof System: Cryptographic proofs for privacy

3. Nullifier System: Prevents double-spending

4. Settlement Engine: Handles multi-chain settlement

5. 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 Leaf8

State 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:

1. Input Circuit: Validates note selection

2. Output Circuit: Validates new note creation

3. Balance Circuit: Validates value conservation

4. 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:

1. Select input notes

2. Generate nullifiers

3. Create output notes

4. Calculate commitments

5. Build Merkle paths

6. Construct witness

Proof Creation:

1. Execute circuit

2. Generate proof using proving key

3. Verify proof locally

4. 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:

1. Select input notes

2. Create output notes

3. Generate nullifiers

4. Build Merkle paths

5. Generate proof

6. Sign transaction

Validation:

1. Verify proof

2. Check nullifiers

3. Validate Merkle paths

4. Verify signature

5. Check balance

Settlement:

1. Update state tree

2. Add nullifiers

3. Add new notes

4. Update state root

5. Broadcast to blockchain

Settlement Engine

Multi-Chain Settlement

Architecture:

• Unified shielded state

• Chain-specific adapters

• Atomic settlement

• Cross-chain support

Settlement Process:

1. Transaction validated

2. State updated

3. Settlement transaction created

4. Broadcast to blockchain

5. Confirmation received

6. 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:

1. Request state root

2. Compare with local

3. Request Merkle proofs

4. Verify proofs

5. 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.