Shielded Balance Architecture
Understanding Shielded Balance Architecture in Roru
This document explains the technical architecture of shielded balances in Roru, how they work, and how they maintain privacy while enabling verification.
Overview
Shielded balances are the core privacy mechanism in Roru. Unlike traditional blockchain balances that are visible to everyone, shielded balances are cryptographically hidden while still allowing verification of transaction validity.
Core Concepts
Shielded Notes
A shielded note is a cryptographic representation of a balance:
Components:
Commitment: Pedersen commitment to an amount
Nullifier Key: Key for generating nullifier when spent
Viewing Key: Key for viewing the note
Memo Field: Optional encrypted memo
Properties:
Amount is cryptographically hidden
Owner is cryptographically hidden
Can be verified without revealing information
Can be spent to create new notes
Merkle Tree Structure
The shielded state is organized as a Merkle tree:
Root
/ \
Node1 Node2
/ \ / \
Leaf1 Leaf2 Leaf3 Leaf4
(Note) (Note) (Note) (Note)Tree Properties:
Leaves: Shielded notes (commitments)
Nodes: Hashes of child nodes
Root: Cryptographic hash of entire state
Depth: Logarithmic depth for efficiency
State Roots
Each state update creates a new state root:
State Root Properties:
Represents entire shielded state
Cryptographically commits to all notes
Efficient to verify (single hash)
Cannot be forged (cryptographically secure)
State Root Updates:
New notes added → new state root
Notes spent → new state root
Batch updates → single state root update
Epoch-based organization
Balance Representation
Commitment Scheme
Shielded balances use Pedersen commitments:
Commitment Formula:
C = r*G + v*HWhere:
C= Commitment (public)r= Random blinding factor (secret)v= Value/amount (secret)G, H= Generator points (public)
Properties:
Hiding: Commitment reveals nothing about value
Binding: Cannot change value without breaking commitment
Additive: Commitments can be added (C1 + C2 = C3)
Efficient: Fast to create and verify
Balance Calculation
Your shielded balance is the sum of your notes:
Process:
Wallet scans shielded state
Identifies notes you can view (using viewing key)
Decrypts note amounts (using viewing key)
Sums amounts to get total balance
Displays balance to you
Privacy:
Only you can view your notes
Others cannot see your balance
Balance calculation is private
No on-chain balance visibility
Transaction Architecture
Creating Shielded Notes
When you receive funds:
Deposit: Send assets to Roru deposit address
Conversion: Assets converted to shielded notes
Commitment: Note commitment created
State Update: Note added to Merkle tree
State Root: New state root published
Privacy:
Deposit transaction is public
Conversion to shielded is private
Note amount is hidden
Note owner is hidden
Spending Shielded Notes
When you send funds:
Note Selection: Select notes to spend
Nullifier Generation: Generate nullifier for each note
New Notes: Create new notes for recipient and change
Proof Generation: Generate zero-knowledge proof
State Update: Update Merkle tree
Settlement: Settle on target blockchain
Privacy:
Which notes spent is hidden
Amount sent is hidden
Recipient is hidden
Change amount is hidden
Zero-Knowledge Proofs
Proof Structure
Every shielded transaction includes a zk-SNARK proof:
Proof Components:
Public Inputs: State roots, nullifiers, commitments
Private Inputs: Note values, keys, randomness
Proof: Cryptographic proof of validity
Verification: Network verifies proof
What Proof Proves:
Sender has sufficient balance (without revealing amount)
No value created or destroyed
Sender authorized to spend (without revealing identity)
Notes haven't been spent before (nullifier check)
Proof Generation
Process:
Witness Creation: Create witness from private inputs
Circuit Execution: Execute zk-SNARK circuit
Proof Generation: Generate proof using proving key
Proof Verification: Network verifies proof
Efficiency:
Proof generation: ~1-5 seconds (device-dependent)
Proof size: ~1-2 KB
Verification: <100ms
Batch verification: Even faster
State Synchronization
Sync Process
Your wallet synchronizes with shielded state:
Connect: Connect to Roru Infra sync nodes
State Root: Get latest state root
Merkle Proofs: Get Merkle proofs for your notes
Verify: Verify state root and proofs
Update: Update local state cache
Balance: Recalculate balance
Efficiency:
Only syncs relevant parts of state
Uses Merkle proofs for efficiency
Incremental updates
Fast synchronization
Incremental Updates
New Transactions:
Only new state roots needed
Merkle proofs for new notes
Efficient updates
Fast sync
Privacy:
Sync doesn't reveal which notes you own
Merkle proofs don't reveal other notes
State root is public but reveals nothing
Efficient and private
Privacy Guarantees
Unlinkability
Transaction Unlinkability:
Transactions cannot be linked to each other
No correlation through amounts
No correlation through timing
No correlation through addresses
Note Unlinkability:
Notes cannot be linked to each other
Cannot determine note relationships
Cannot trace note history
Complete unlinkability
Amount Hiding
Commitment Hiding:
Commitments reveal nothing about amounts
Cryptographically secure hiding
Cannot extract amount from commitment
Mathematical guarantee
Transaction Hiding:
Transaction amounts are hidden
Sender amount hidden
Receiver amount hidden
Change amount hidden
Sender/Receiver Hiding
Identity Hiding:
Senders are cryptographically hidden
Receivers are cryptographically hidden
Cannot determine transaction parties
Complete anonymity set
Security Properties
Double-Spend Prevention
Nullifier System:
Each spent note generates unique nullifier
Nullifiers published to prevent double-spend
Network checks nullifiers
Cannot spend same note twice
Security:
Cryptographically secure
Cannot forge nullifiers
Efficient checking
Prevents double-spending
State Integrity
Merkle Tree Security:
State root commits to all notes
Cannot modify state without detection
Efficient verification
Cryptographically secure
Verification:
Anyone can verify state root
Merkle proofs verify note existence
Cannot forge proofs
Complete integrity
Performance Characteristics
Scalability
State Size:
Merkle tree depth: Logarithmic
Proof size: Constant (~1-2 KB)
Verification: Constant time
Scales to millions of notes
Efficiency:
Fast proof generation
Fast verification
Efficient state sync
Low computational overhead
Network Efficiency
Bandwidth:
Small proof size
Efficient Merkle proofs
Minimal data transfer
Optimized protocols
Advanced Features
Note Selection
Selection Algorithms:
Random selection for privacy
Amount matching
Fee optimization
Privacy optimization
Batch Transactions
Batching:
Multiple transactions in one proof
Reduced fees
Improved privacy
Efficient processing
Custom Memos
Memo Field:
Optional encrypted memo
Private to sender/receiver
Can include payment details
Encrypted with shared key
Implementation Details
Cryptographic Primitives
Curves:
BLS12-381 for zk-SNARKs
secp256k1 for signatures
Curve25519 for encryption
Hash Functions:
Poseidon for zk-SNARKs
SHA-256 for Merkle trees
Blake2b for general hashing
Key Management
Key Types:
Spending keys: Authorize spending
Viewing keys: View transactions
Nullifier keys: Generate nullifiers
Derived from recovery phrase
Conclusion
Shielded balance architecture provides:
Privacy: Cryptographically guaranteed privacy
Security: Double-spend prevention and state integrity
Efficiency: Scalable and efficient implementation
Verifiability: Can verify without revealing information
Flexibility: Supports various transaction types
This architecture enables Roru to provide private transactions while maintaining the security and verifiability of public blockchains.
Last updated