A next-generation BFT consensus framework — built from scratch in Rust, combining Tendermint's battle-tested architecture with HotStuff-2's optimal two-chain commit protocol.
Every critical layer — from the consensus state machine down to the on-disk LSM-Tree storage engine — is independently developed, giving the project complete sovereignty over its entire technology stack.
CometBFT (formerly Tendermint) has served as the backbone of the Cosmos ecosystem for years, proving the viability of BFT consensus for production blockchains. Its clean separation of consensus and application (ABCI) set the gold standard for developer ergonomics. However, years of evolution have surfaced fundamental limitations:
- Three-phase voting (Propose → Pre-vote → Pre-commit) imposes an inherent extra round-trip on every block
- Go runtime — garbage collection causes tail-latency jitter that is structurally impossible to eliminate in a latency-sensitive consensus protocol
- RocksDB dependency — the storage layer relies on a massive C++ codebase, introducing cross-language build complexity, C memory safety risks, and limited control over the most critical data path
- Accumulated technical debt — organic growth over many years makes deep architectural changes increasingly costly
In 2023, Dahlia Malkhi and Ling Ren published HotStuff-2, proving that two-chain commit is sufficient for optimal BFT consensus — achieving the same safety guarantees as Tendermint's three phases while eliminating an entire voting round. Confirmation latency drops, and view-change mechanics simplify dramatically: from complex Nil-vote collection to a linear Wish → TimeoutCert aggregation.
Hotmint was born from the convergence of three insights:
- HotStuff-2's two-chain commit eliminates Tendermint's latency overhead while preserving its proven safety properties (f < n/3 Byzantine tolerance)
- Rust's zero-cost abstractions deliver C-level performance with compile-time memory safety — no GC pauses, no data races, no use-after-free
- A fully self-developed storage stack eliminates the RocksDB/LevelDB dependency entirely — pure Rust from the application API down to the LSM-Tree write path
The result: a consensus framework where every performance-critical path is written in safe Rust, and the team has complete control from the consensus commit decision down to the on-disk byte layout.
Hotmint is not just a consensus engine. It is the foundation for a next-generation full-stack blockchain framework.
A battle-hardened BFT consensus engine that any Rust developer can embed to build application-specific blockchains, with the same ABCI-style ergonomics that made Tendermint successful — but with lower latency, stronger type safety, and zero C/C++ dependencies in the critical path.
Phase 2 — EVM-Compatible Chain (complete — lives in nbnet)
A production-grade EVM-compatible chain built on Hotmint consensus. Extracted into its own repository:
- nbnet — Ethereum-compatible chain: revm execution, Ethereum JSON-RPC, EVM tx pool, custom precompiles
- alloy — modern Ethereum primitives, RLP codec, and Web3 RPC types
- AI-ported Substrate Pallets — battle-tested economic models (staking, governance, multi-asset) ported into Hotmint's
std + vsdb + serdeenvironment
The long-term goal is a "hexagonal warrior" (六边形战士) — a framework that excels across every dimension of blockchain infrastructure:
| Dimension | Advantage |
|---|---|
| Consensus | HotStuff-2 — lower latency than Tendermint, simpler than PBFT |
| Execution | revm — world's fastest EVM engine |
| Storage | vsdb + mmdb — pure-Rust, zero C deps, Git-model versioning + Merkle proofs |
| Networking | litep2p — lightweight, from Polkadot ecosystem |
| Business Logic | AI-ported Substrate Pallets — type-safe Rust, audited by top security firms |
| Developer Experience | ABCI-style trait API, Go SDK, cross-language IPC, cluster management tooling |
Unlike frameworks that aggregate third-party C/C++ components for their most critical paths, Hotmint's deepest layers are independently developed under the same organization (rust-util-collections):
HotStuff-2 two-chain commit protocol, implemented from scratch. The consensus state machine has zero I/O dependencies — all storage, networking, and application logic is injected through four pluggable traits. Domain-separated signing (chain_id_hash + epoch + view + block_hash) prevents all cross-chain, cross-epoch, and cross-message replay attacks.
vsdb (Version-controlled Storage Database) is a high-performance embedded key-value database with a standard-collections API:
Mapx/MapxOrd— persistentHashMap/BTreeMapreplacementsVerMap— Git-model versioning: branching, commits, three-way merge, rollback, garbage collection over a COW B+ tree with structural sharingMptCalc/SmtCalc— stateless Merkle Patricia Trie and Sparse Merkle Tree computation layersVerMapWithProof— integratesVerMapwithMptCalcfor versioned 32-byte Merkle root commitments
mmdb is the storage engine underneath vsdb — a pure-Rust LSM-Tree that replaces RocksDB/LevelDB:
- WAL with group commit and crash recovery
- SST files with prefix compression, bloom filters, leveled compaction
- MVCC snapshots, block cache (moka LRU), multi-threaded background compaction
- Performance comparable to RocksDB in typical workloads; 250+ tests
This gives Hotmint 100% control over the entire data path — from the consensus commit decision down to the on-disk compaction strategy — with zero C/C++ dependencies.
🔷 Error Handling — ruc
Chained error tracing library, also independently developed. Provides rich error context propagation throughout the entire stack.
Hotmint implements the HotStuff-2 two-chain commit protocol (arXiv:2301.03253):
Block ←── QC (2f+1 votes) ←── Double Cert (2f+1 votes on QC) ──→ Commit
Each view follows a 5-step protocol:
Enter → Propose → Vote → Prepare (QC) → Vote2 → [DC triggers Commit]
- Safety: Locking rule (
justify.rank ≥ locked_qc.rank) prevents conflicting commits; double certificate commits the block and all uncommitted ancestors - Liveness: Timeout → Wish → TimeoutCert mechanism with exponential backoff (1.5×, capped at 30s)
- Epochs: Validator set changes take effect at
commit_view + 2, ensuring all honest nodes agree on the transition point
📖 Full protocol specification →
| Crate | Description |
|---|---|
| hotmint | Library facade — re-exports all crates; includes hotmint-node binary |
| hotmint-types | Core data types: Block, QC, DC, TC, Vote, ValidatorSet, Epoch |
| hotmint-crypto | Ed25519 signing + batch verification, Blake3 hashing |
| hotmint-consensus | Consensus state machine: engine, pacemaker, vote collector, sync |
| hotmint-storage | Persistent storage backends (vsdb) |
| hotmint-network | P2P networking (litep2p): 4 sub-protocols (consensus, reqresp, sync, PEX) |
| hotmint-mempool | Priority mempool with RBF, gas-aware selection, deduplication |
| hotmint-api | HTTP/WebSocket JSON-RPC + TCP JSON-RPC server |
| hotmint-abci | IPC proxy for out-of-process apps (Unix socket + protobuf) |
| hotmint-staking | Staking toolkit: validator registration, delegation, slashing, rewards |
| hotmint-light | Light client: header verification and validator set tracking |
| hotmint-mgmt | Cluster management library: init, start, stop, deploy (local + SSH) |
The consensus engine is fully decoupled from all I/O through pluggable traits:
| Trait | Purpose | Built-in Implementations |
|---|---|---|
Application |
ABCI-like app lifecycle | NoopApplication, IpcApplicationClient |
BlockStore |
Block persistence | MemoryBlockStore, VsdbBlockStore |
NetworkSink |
Message transport | Litep2pNetworkSink |
MempoolAdapter |
Pluggable transaction pool | Mempool (priority-based) |
Signer |
Cryptographic signing | Ed25519Signer |
📖 Architecture → · Core types → · Wire protocol →
# build and test
cargo build --workspace && cargo test --workspace
# run the 4-node in-process demo
cargo run --bin hotmint-demo
# or initialize and run a production node
cargo run --bin hotmint-node -- init
cargo run --bin hotmint-node -- node| Example | Description | Run |
|---|---|---|
| demo | Minimal 4-node cluster with a counting app | cargo run --bin hotmint-demo |
| utxo-chain | Bitcoin-style UTXO chain with ed25519 sigs + SMT proofs | cargo run --bin hotmint-utxo-chain |
| cluster-node | Production-style P2P node with persistent storage, sync, PEX | cargo run --bin hotmint-cluster-node |
| bench-consensus | Raw consensus throughput benchmark | make bench-consensus |
| bench-ipc | ABCI IPC overhead benchmark (Unix socket + protobuf) | make bench-ipc |
| Component | Description |
|---|---|
| Go SDK | Out-of-process application framework for Go — Application interface + Unix socket IPC server |
| hotmint-mgmt | Cluster management library: init / start / stop / deploy / logs (local + remote SSH) |
Add hotmint as a dependency:
[dependencies]
hotmint = "0.8"
tokio = { version = "1", features = ["full"] }
ruc = "9.3"Implement the Application trait — all methods have default no-op implementations:
use ruc::*;
use hotmint::prelude::*;
use hotmint::consensus::application::Application;
struct MyApp;
impl Application for MyApp {
fn execute_block(&self, txs: &[&[u8]], ctx: &BlockContext) -> Result<EndBlockResponse> {
println!("height {} — {} txs", ctx.height.as_u64(), txs.len());
Ok(EndBlockResponse::default())
}
fn on_commit(&self, block: &Block, _ctx: &BlockContext) -> Result<()> {
println!("committed height {}", block.height.as_u64());
Ok(())
}
}Build a cluster and run:
// see examples/demo for the complete working code
let engine = ConsensusEngine::new(state, store, network, app, signer, rx, config);
tokio::spawn(async move { engine.run().await });Three deployment modes — all interoperable in the same cluster:
| Mode | Application Language | Communication |
|---|---|---|
| Embedded | Rust (same process) | Direct trait calls |
| Go ABCI | Go | Unix socket + protobuf |
| Rust ABCI | Rust (separate process) | Unix socket + protobuf |
📖 Application trait guide → · Storage guide → · Networking guide → · Mempool & API →
| Component | Implementation | Origin |
|---|---|---|
| Consensus Protocol | HotStuff-2 (arXiv:2301.03253) | Self-developed |
| Storage Engine | vsdb + mmdb (pure-Rust LSM-Tree) | Self-developed |
| Error Handling | ruc | Self-developed |
| Signatures | Ed25519 (ed25519-dalek) | Community |
| Hashing | Blake3 | Community |
| Networking | litep2p (Polkadot ecosystem) | Community |
| Async Runtime | Tokio | Community |
| Serialization | serde + postcard / Protobuf | Community |
| Metrics | prometheus-client | Community |
| Guide | Description |
|---|---|
| Getting Started | Installation, quick start, first integration |
| Protocol | HotStuff-2 two-chain commit, view protocol, pacemaker |
| Architecture | Module structure, dependency graph, design decisions |
| Application | Application trait — ABCI-like lifecycle, epoch transitions, evidence |
| Consensus Engine | Engine internals: state machine, event loop, vote collection |
| Core Types | Block, QC, DC, TC, Vote, ValidatorSet, signing bytes, wire format |
| Cryptography | Signer/Verifier traits, Ed25519, aggregate signatures, custom signers |
| Storage | BlockStore trait, vsdb persistence, crash recovery, Merkle proofs |
| Networking | NetworkSink trait, litep2p P2P, PEX, block sync, dynamic peers |
| Mempool & API | Priority mempool, JSON-RPC (TCP + HTTP + WebSocket) |
| Metrics | Prometheus metrics, health interpretation, Grafana queries |
| Wire Protocol | Codec framing, postcard format, ABCI IPC protocol, block hash spec |
| Security Audit & Roadmap | Security audit findings and resolution history |
| Project | Description |
|---|---|
| nbnet | EVM-compatible blockchain built on Hotmint — revm execution, Ethereum JSON-RPC, EIP-1559 tx pool |
| Paper | Link |
|---|---|
| HotStuff-2: Optimal Two-Chain BFT (2023) | arXiv:2301.03253 |
| HotStuff: BFT Consensus (PODC 2019) | arXiv:1803.05069 |
| Tendermint: Latest Gossip on BFT (2018) | arXiv:1807.04938 |
GPL-3.0