Skip to main content

RotorTree

RotorTree is an experimental nullifier database building on first principles of architecting and specializing databases. This project makes MANY tradeoffs and is not suitable for production use.

What is RotorTree?

RotorTree is a specialized database implementation focused on append-only n-ary Merkle trees. Unlike traditional privacy protocols that rely on general-purpose databases like RocksDB or PostgreSQL, RotorTree is designed from the ground up for high-throughput nullifier tracking. The tree design is heavily inspired by lean-imt from PSE, adapted to an n-ary structure to reduce depth while maintaining the same total leaf capacity. This approach efficiently uses on-disk storage blocks by grouping leaves together.

Key Features

Configurable Branching

N-ary tree structure with configurable branching factor and max depth

Flexible Storage

Pure in-memory mode or persistent storage with WAL and checkpointing

Memory Tiering

Pin hot levels in memory while cold levels use memory-mapped storage

High Performance

Peak throughput up to ~190M leaves/sec with parallel batch operations

Proof Generation

Lock-free snapshots for concurrent proof generation and verification

no_std Support

Works in embedded environments without the standard library

Design Philosophy

RotorTree makes specific tradeoffs optimized for its use case:
  • Append-only: No support for updating leaves in-place
  • Prehashed leaves: Assumes leaves are already hashed before insertion
  • Generic hasher: Blake3 by default, but supports any hasher implementation
  • Batteries included: Preconfigured for different branching factors and depths
  • Minimal dependencies: ~65 transitive dependencies, zero for just the algorithm
You should maintain a separate key-value database alongside RotorTree to prevent duplicate nullifier insertion. RotorTree does not perform this check internally.

Capacity Examples

With the right configuration, RotorTree can handle billions of nullifiers:
  • N=4, MAX_DEPTH=16: ~4.3B nullifiers in 41 GiB
  • N=8, MAX_DEPTH=10: ~1B nullifiers in 37 GiB
For most use cases, keeping the tree in memory without crash persistence (with a bootstrapping sync mechanism) provides the best performance.

Next Steps

Installation

Add RotorTree to your Rust project

Quickstart

Get started with your first tree

Core Concepts

Understand the architecture

API Reference

Explore the complete API

Build docs developers (and LLMs) love