Byzantine fault-tolerant Efficient Asynchronous consensus, Three-network edition.
BEAT is a family of five practical BFT consensus protocols (BEAT0–BEAT4) for fully asynchronous networks. It ships with a multi-network transport switch — clearnet, Tor, and I2P simultaneously — so consensus survives even when an adversary censors some paths.
Beyond the raw protocol, BEAT includes a complete deployment stack:
- Keystore — trusted-dealer key generation, ed25519 node identity, encrypted-at-rest storage
- State persistence — WAL + snapshots via
sled, automatic recovery after crashes - Generic app layer —
ConsensusApptrait +BeatNode<A>for plugging in any application - Market pipeline —
DataFeed → MarketBatch → BEAT → MarketStatereference implementation - Prometheus metrics — scrape endpoint, epoch latency, message counters
- Reconnect manager — exponential backoff with health-check pings
| Property | Description |
|---|---|
| Safety | All honest nodes deliver the same ordered output, even with up to f Byzantine nodes |
| Liveness | Output is eventually produced as long as n − f nodes are honest and reachable on at least one network |
| Censorship resilience | Messages are sent on all three networks at once; a censor must simultaneously block clearnet, Tor, and I2P |
| Fault tolerance | Tolerates f = ⌊(n−1)/3⌋ Byzantine nodes; minimum committee is 4 (n ≥ 3f + 1) |
| Input confidentiality | BEAT0–BEAT2 encrypt proposals with Ristretto255 ElGamal; no node learns another's input until the common set is fixed |
| Variant | Broadcast | Encryption | Best for |
|---|---|---|---|
| BEAT0 | RBC (Bracha) | Ristretto ElGamal | Baseline; general-purpose SMR |
| BEAT1 | AVID | Ristretto ElGamal | Lower bandwidth than BEAT0 |
| BEAT2 | AVID | Client-side causal ElGamal | Applications needing causal ordering |
| BEAT3 | AVID-FP | None (plaintext) | Storage-efficient BFT storage |
| BEAT4 | AVID-FP Pyramid | None (plaintext) | Flexible per-transaction reads |
BLS12-381 is retained exclusively for the ABA common coin (1-round threshold signatures require pairings). Encryption in BEAT0–BEAT2 uses Ristretto255 hybrid ElGamal, which is 10–30× faster and produces 3× smaller ciphertexts.
# Four terminals, one per node.
cargo run -- 0
cargo run -- 1
cargo run -- 2
cargo run -- 3Each node listens on 127.0.0.1:700<id>, connects to peers automatically, and exposes Prometheus metrics on port 9090 + id.
# Adjust log level via RUST_LOG.
RUST_LOG=beat=info cargo run -- 0docker compose up --buildStarts four BEAT nodes + a Prometheus instance. Ports:
| Service | Consensus | Metrics |
|---|---|---|
| beat-0 | 7000 | 9090 |
| beat-1 | 7001 | 9091 |
| beat-2 | 7002 | 9092 |
| beat-3 | 7003 | 9093 |
| prometheus | — | 9100 |
# Follow logs for a single node.
docker compose logs -f beat-0
# Check Prometheus targets.
open http://localhost:9100/targets# Build and push the image first.
docker build -t my-registry/beat:latest .
docker push my-registry/beat:latest
# Install into namespace "beat-system".
helm install beat ./helm/beat \
--namespace beat-system --create-namespace \
--set image.repository=my-registry/beat \
--set image.tag=latest
# Scale to 7 nodes (tolerates 2 Byzantine).
helm upgrade beat ./helm/beat --set replicaCount=7Pods get stable DNS names beat-0.beat-headless.beat-system.svc.cluster.local etc. The ConfigMap generates the peer list automatically from replicaCount.
All config can be provided via env vars (Docker/Kubernetes) or CLI positional args (local dev):
| Variable | CLI arg | Default | Description |
|---|---|---|---|
BEAT_NODE_ID |
arg 1 | 0 |
This node's ID (0-indexed) |
BEAT_PORT |
arg 2 | 7000 + id |
Consensus TCP port |
BEAT_METRICS_PORT |
arg 3 | 9090 |
Prometheus scrape port |
BEAT_PEERS |
— | localhost cluster | Comma-separated host:port ordered by node ID |
RUST_LOG |
— | warn |
Log filter (e.g. beat=info,warn) |
Example BEAT_PEERS:
BEAT_PEERS=10.0.0.1:7000,10.0.0.2:7000,10.0.0.3:7000,10.0.0.4:7000
| File | Contents |
|---|---|
docs/guide.md |
Integration guide: Rust services, Spring Boot, Express, Docker, Helm |
docs/modules.md |
Per-module reference: structs, methods, design notes |
src/
error.rs Error enum; Result<T> alias
config.rs Config, PeerConfig
crypto/
elgamal.rs Ristretto255 threshold ElGamal (Feldman VSS + DLEQ proofs)
threshold.rs BLS12-381 threshold signatures (ABA coin only)
erasure.rs Reed-Solomon (n-f, n) erasure coding
fpc.rs Fingerprinted cross-checksum for AVID
keystore/
dealer.rs Trusted-dealer key generation and distribution
identity.rs ed25519 node identity
storage.rs Encrypted-at-rest keystore (ChaCha20-Poly1305 + sled)
network/
clearnet.rs TCP transport
tor.rs Tor SOCKS5 transport
i2p.rs I2P SOCKS5 transport
switch.rs Fan-out switch (sends on all transports; deduplicates inbound)
router.rs MessageTag-based demultiplexer
reconnect.rs Exponential backoff reconnect manager with health-check pings
proto/ RBC, AVID, AVID-FP, ABA, ACS, message types
beat/ Beat0–Beat4 protocol structs
state/ ConsensusState trait, WAL, sled-backed StateStore
app.rs ConsensusApp trait + BeatNode<A> generic driver
market/
types.rs Tick, GreeksSnapshot, MarketBatch, MarketState
feed.rs DataFeed trait, SyntheticFeed, FlexbuffersFeed
node.rs MarketConsensusNode (reference implementation)
metrics/mod.rs Prometheus scrape endpoint
main.rs Standalone node binary
- Ristretto ElGamal is used for threshold encryption in BEAT0–BEAT2. The Feldman VSS commitments allow any node to verify a decryption share before combining. A Byzantine node that submits an invalid share is detected and rejected.
- BLS12-381 is retained only for the ABA common coin. The 1-round threshold signature property is essential here; Ristretto has no pairing so cannot replace it.
- Input confidentiality: in BEAT0–BEAT2 no node learns any other node's proposal until ACS has fixed the common set, preventing front-running.
- Key distribution uses a trusted dealer by default. Shares are encrypted with
ChaCha20-Poly1305before transit and encrypted again at rest in the keystore. A full interactive DKG can replace the dealer without changing the wire format. - Clearnet connections are unauthenticated TCP. For production, wrap with mutual TLS or authenticate at the protocol layer using node identity signatures.
This implementation is based on the BEAT paper by Duan, Zhang, et al. (PDF). The algorithms (BEAT0–BEAT4) are the researchers' contribution. This project is a practical implementation with extensions: multi-transport censorship resistance, market data pipeline integration, and deployment tooling.
The async BFT field has advanced significantly since BEAT (2018). Protocols of interest for future work:
| Protocol | Year | Key advance |
|---|---|---|
| Dumbo1/Dumbo2 | 2020 | Reduced n parallel BA instances to k or 1 MVBA, 3-10x throughput improvement |
| Speeding Dumbo | 2022 | Replaced MVBA with simpler crusader agreement |
| PACE | 2022 | Optimal MVBA at O(λn²), matches theoretical lower bound |
| Dumbo-NG | 2022 | Continuous broadcast/agree pipeline, near bandwidth-limit throughput |
| Bolt-Dumbo | 2022 | Optimistic fast-path bolted onto async BFT, 3-round latency |
| Narwhal/Tusk | 2022 | DAG-based consensus, >100k tx/s, powers Sui blockchain |
Potential directions being explored:
- Dumbo-NG continuous pipeline — adapting the decoupled broadcast/agree model into this codebase for improved throughput
- Bolt-Dumbo optimistic path — adding a fast-path for the common (honest leader) case while retaining full async safety as fallback
- Post-quantum cryptography — replacing Ristretto255 ElGamal and BLS12-381 with lattice-based threshold encryption and hash-based signatures. Both current primitives are vulnerable to Shor's algorithm. A post-quantum async BFT implementation would be novel territory.
- Small-committee applications — BEAT's complexity is well-suited to small groups (n=4-7). Use cases include family-scale fault-tolerant storage (e.g. 4 phones each contributing storage, consensus on state) and private coordination between trusted devices.
The BEAT protocols were designed by Sisi Duan, Haibin Zhang, et al. This implementation builds on their research. See the original paper for the theoretical foundations.
The multi-transport networking layer, market data pipeline, deployment tooling, and the extensions described above are original contributions of this implementation.