Quantum-resistant cellular automaton tournaments meet zero-knowledge privacy in a protocol-local trust mesh

Rust License Version Status

"We don't mine blocks. We cultivate them in a Conway garden where only the fittest gliders survive."

BitCell is a blockchain where consensus is decided by Conway's Game of Life tournaments. Yes, really. No SHA-256 lottery. No boring PoS validators clicking buttons. Just pure, deterministic, beautiful cellular automaton combat.

Now in Release Candidate 1 with production-ready VRF, persistent state, hardware wallet support, light client implementation, and a complete ZKVM execution framework.

BitCell RC1 represents the first complete implementation of the core protocol:

• Production ECVRF: Real cryptographic VRF using Ristretto255 for fair proposer selection
• RocksDB Persistence: Full state management with pruning and block archival
• Light Client: Header-only sync with Merkle proofs (<100MB memory)
• Hardware Wallets: Complete support for Ledger/Trezor via abstraction layer
• Smart Contracts: BCL compiler + ZKVM with 22 opcodes and gas metering
• Admin Console: Production-ready dashboard with HSM integration and testnet faucet
• Security Hardening: DoS protection, gas limits, input validation, VRF race condition fixes
• Comprehensive Testing: 200+ tests passing across all crates

See RC1 Release Notes for complete details.

• 🎮 Tournament Consensus: Miners battle with gliders in a ×ばつ1024 CA arena
• 🎭 Ring Signature Anonymity: Your glider, your battle, not your identity
• 🧠 Protocol-Local EBSL: Reputation that actually means something
• 🔐 ZK-Everything: Private smart contracts via Groth16 circuits with Merkle gadgets
• ⚡ Deterministic Work: No lottery, no variance, just skill and creativity
• 🌐 Anti-Cartel by Design: Random pairings + ring sigs = coordination nightmare
• 🔗 Production VRF: ECVRF (Ristretto255) for fair block proposer selection
• 💾 Persistent State: RocksDB backend with state snapshots and pruning
• 🏦 Hardware Wallet Ready: Full support for Ledger, Trezor, and HSM integration

Because proof-of-work shouldn't be about who has the most GPUs. It should be about emergent complexity, creative strategy, and provable computation. BitCell replaces hash grinding with something actually interesting: designing glider patterns that survive CA evolution better than your opponents.

Plus, we needed a blockchain where "gas wars" could literally mean glider battles. 🚀

graph TB
 APP[Application Layer<br/>dApps, Wallets, Bridges]
 
 ZKVM[ZKVM: Private Smart Contracts<br/>• RISC-V-ish instruction set<br/>• Pedersen commitments<br/>• Groth16 execution proofs]
 
 CONSENSUS[Consensus: Tournament Protocol<br/>• Commit Phase: Ring-signed glider commitments<br/>• Reveal Phase: Pattern disclosure<br/>• Battle Phase: 1000-step CA simulation<br/>• Winner: Highest regional energy → proposes block]
 
 CA[CA Engine: ×ばつ1024 Toroidal Grid<br/>• Conway-like rules + energy<br/>• Glider patterns: Standard, LWSS, MWSS, HWSS<br/>• Parallel evolution with Rayon<br/>• Battle outcome via energy density]
 
 EBSL[EBSL: Evidence-Based Subjective Logic<br/>• r_m: positive evidence<br/>• s_m: negative evidence<br/>• Trust = b + α·u<br/>• Fast punish, slow forgive]
 
 CRYPTO[Crypto Primitives<br/>• ECDSA secp256k1<br/>• Ring Signatures<br/>• VRF randomness<br/>• Pedersen Commitments<br/>• Merkle Trees]
 
 APP --> ZKVM
 ZKVM --> CONSENSUS
 CONSENSUS --> CA
 CA --> EBSL
 EBSL --> CRYPTO
 
 style APP fill:#e1f5ff
 style ZKVM fill:#fff4e1
 style CONSENSUS fill:#ffe1f5
 style CA fill:#e1ffe1
 style EBSL fill:#f5e1ff
 style CRYPTO fill:#ffe1e1

# Clone the vibes
git clone https://github.com/Steake/BitCell
cd BitCell
# Build the future
cargo build --release
# Run tests (watch CA battles in real-time)
cargo test --all -- --nocapture
# Individual crate tests
cargo test -p bitcell-crypto # Cryptographic primitives
cargo test -p bitcell-ca # Cellular automaton engine
cargo test -p bitcell-ebsl # Trust & reputation system

Each block height runs a bracket-style tournament:

1. Eligibility Check: Protocol computes M_h (miners with bond ≥ B_MIN and trust ≥ T_MIN)
2. Commit Phase: Miners submit H(glider_pattern || nonce) with ring signatures
3. VRF Seed: Combine last k blocks' VRF outputs → seed_h
4. Pairing: Deterministic shuffle using seed_h → bracket structure
5. Reveal Phase: Miners reveal patterns; non-revealers forfeit
6. Battle Simulation: Each pair battles for 1000 CA steps
7. ZK Proof: Winner proves battle validity via Groth16 circuit
8. Block Proposal: Tournament winner executes contracts, generates proofs, proposes block
9. Full Verification: All validators check all proofs (no sampling in consensus)

Miner A: Heavyweight Spaceship (160 energy)
Miner B: Standard Glider (100 energy)
Grid: ×ばつ1024 toroidal
Steps: 1000
Spawn: A at (256, 512), B at (768, 512)
After 1000 steps:
 Region A energy: 5,847
 Region B energy: 3,291
Winner: Miner A 🎉

Every miner has evidence counters:

• r_m: Positive (good blocks, honest participation)
• s_m: Negative (invalid blocks, missed reveals, equivocation)

Trust score computed as:

R = r_m + s_m
T_m = r_m/(R+K) + α·K/(R+K)

With K=2, α=0.4:

• New miners: Start at T = 0.4 (below eligibility T_MIN = 0.75)
• Good behavior: Builds r_m, increases trust
• Bad behavior: Builds s_m faster, tanks trust quickly
• Equivocation: Instant T → 0, full slash, permanent ban

Decay per epoch:

• r_m *= 0.99 (positive decays faster)
• s_m *= 0.999 (negative decays slower - long memory)

Four circuit structures defined in RC1:

Public: commitments, winner, seed, positions
Private: initial grid, patterns, nonce
Verifies: CA evolution + commitment consistency + outcome
Status: Structure complete, full constraints in RC2

Public: old state root, new state root, gas used
Private: plaintext state, contract code, witness
Verifies: ZKVM execution correctness
Status: Structure complete, full constraints in RC2

Public: old root, new root, nullifiers
Private: Merkle paths, cleartext values
Verifies: State commitment updates
Status: ✅ Complete with non-equality constraints

Public: root, leaf, index
Private: path siblings
Verifies: Merkle inclusion proofs in R1CS
Status: ✅ Complete with Poseidon hash gadget

Each block carries N_h - 1 battle proofs + execution proofs + state proofs.

RC1: Circuit structures and mock proofs
RC2: Full R1CS constraints and real Groth16 proofs
RC3: Recursive aggregation via Plonk/STARK

Initial block reward: 50 CELL
Halving interval: 210,000 blocks (~4 years)
Maximum halvings: 64 (subsidy reaches 0)
Total supply: ~21 million CELL
block_reward = base_subsidy(h) + tx_fees + contract_fees
Distribution:
 60% → Tournament winner (proposer)
 30% → All participants (weighted by round reached)
 10% → Treasury / dev fund

The payout is deterministically computed from the tournament bracket. Proposer can't cheat it or the block is invalid.

// On-chain: Only commitments and proofs
let new_commitment = commit(new_state, random_nonce);
let exec_proof = prove_execution(old_state, new_state, function);
let state_proof = prove_state_transition(old_root, new_root);
// Off-chain: Prover decrypts and executes privately
let old_state = decrypt_with_user_key(old_commitment, secret);
let new_state = run_function(function, args, old_state);
// Validators: Never see plaintext, only verify proofs
verify_proof(exec_proof, public_inputs);
verify_proof(state_proof, public_inputs);

• Rust 1.82+ (minimum version specified in Cargo.toml)
• 8GB+ RAM (for ZK proving and CA simulations)
• Linux, macOS, or WSL2
• Optional: Hardware wallet for secure key management

# Clone the repository
git clone https://github.com/Steake/BitCell
cd BitCell
# Build all crates in release mode
cargo build --release
# Build time: ~5-10 minutes depending on hardware

# Run all tests (200+ tests)
cargo test --all
# With output (see CA evolution and logs)
cargo test --all -- --nocapture
# Specific crate tests
cargo test -p bitcell-crypto # Cryptographic primitives
cargo test -p bitcell-ca # Cellular automaton engine
cargo test -p bitcell-ebsl # Trust & reputation system
cargo test -p bitcell-zkp # ZK circuits and Merkle gadgets
cargo test -p bitcell-consensus # Tournament protocol
cargo test -p bitcell-state # State management
cargo test -p bitcell-node # Node implementation
cargo test -p bitcell-wallet # Wallet functionality
cargo test -p bitcell-light-client # Light client
# Property tests (slower but thorough)
cargo test --features proptest

# Run performance benchmarks
cargo bench
# Results saved to target/criterion/
# View HTML reports in target/criterion/report/index.html

# Start a validator node
cargo run --release --bin bitcell-node
# Start with custom config
cargo run --release --bin bitcell-node -- --config config.toml
# Run with admin console
cargo run --release --bin bitcell-admin

graph TB
 ROOT[BitCell/]
 
 CRATES[crates/]
 DOCS[docs/]
 SDK[sdk/]
 INFRA[infra/]
 SCRIPTS[scripts/]
 TESTS[tests/]
 
 ROOT --> CRATES
 ROOT --> DOCS
 ROOT --> SDK
 ROOT --> INFRA
 ROOT --> SCRIPTS
 ROOT --> TESTS
 
 CRATES --> C1[bitcell-crypto<br/>Hash, sigs, VRF, ring sigs]
 CRATES --> C2[bitcell-ca<br/>CA engine, grid, battles]
 CRATES --> C3[bitcell-ebsl<br/>Trust scores, slashing]
 CRATES --> C4[bitcell-zkp<br/>Groth16 circuits]
 CRATES --> C5[bitcell-consensus<br/>Tournament protocol]
 CRATES --> C6[bitcell-state<br/>State management, RocksDB]
 CRATES --> C7[bitcell-zkvm<br/>Smart contract execution]
 CRATES --> C8[bitcell-compiler<br/>BCL compiler]
 CRATES --> C9[bitcell-economics<br/>Rewards, fees, treasury]
 CRATES --> C10[bitcell-network<br/>Network interface]
 CRATES --> C11[bitcell-node<br/>Validator nodes, RPC]
 CRATES --> C12[bitcell-wallet<br/>CLI wallet]
 CRATES --> C13[bitcell-wallet-gui<br/>GUI wallet]
 CRATES --> C14[bitcell-admin<br/>Admin console, HSM]
 CRATES --> C15[bitcell-light-client<br/>Light client]
 CRATES --> C16[bitcell-explorer<br/>Block explorer]
 CRATES --> C17[bitcell-simulation<br/>Network simulation]
 
 DOCS --> D1[Architecture specs]
 DOCS --> D2[Release notes]
 
 SDK --> S1[Contract templates]
 SDK --> S2[Examples]
 
 INFRA --> I1[Production infra]
 INFRA --> I2[Monitoring]
 
 SCRIPTS --> SC1[Dev scripts]
 
 TESTS --> T1[Integration tests]
 
 style ROOT fill:#e1f5ff
 style CRATES fill:#fff4e1
 style DOCS fill:#e1ffe1
 style SDK fill:#ffe1f5
 style INFRA fill:#f5e1ff

# Format code
cargo fmt --all
# Lint
cargo clippy --all -- -D warnings
# Watch mode (requires cargo-watch)
cargo watch -x test
# Generate docs
cargo doc --no-deps --open

We're in alpha. Things break. PRs welcome.

• Recursive SNARK aggregation (Plonk migration for proof composition)
• Optimized CA simulation (SIMD, GPU acceleration with CUDA/OpenCL)
• Mobile wallet development (iOS/Android SDK)
• Block explorer UI (React/Vue frontend)
• More glider patterns and battle strategies
• Economic modeling and simulation tools
• Formal verification of EBSL properties
• Bridge implementations (Ethereum, other chains)
• Hardware wallet integration testing
• Documentation improvements and tutorials

• No god objects: Small, composable modules
• Test everything: Unit + property + integration
• Document the why: Not just the what
• Benchmarks matter: Performance is a feature

• Core crypto primitives (ECDSA, VRF, ring sigs, Pedersen commitments)
• CA engine with battles (×ばつ1024 grid, Conway rules, energy)
• EBSL trust scores (evidence tracking, decay, slashing)
• ZK circuits (battle verification, execution, state constraints, Merkle gadgets)
• Consensus structures (blocks, tournament, fork choice, VRF selection)
• P2P networking (libp2p Gossipsub, DHT, peer discovery)
• RocksDB persistence (blocks, state, transactions, pruning)
• JSON-RPC and WebSocket APIs (eth_* and bitcell_* methods)
• ZKVM execution framework (22 opcodes, gas metering, execution trace)
• Smart contract compiler (BCL language)
• Full validator implementation with transaction processing
• GUI Wallet with tournament visualization and hardware wallet support
• Admin console with metrics, HSM integration, and faucet
• Light client with header-only sync and Merkle proofs
• Block reward halving mechanism (Bitcoin-style economics)
• Security improvements (DoS protection, gas limits, input validation)
• Local testnet deployment

• Production ECVRF implementation (Completed in RC1 - Ristretto255-based)
• Real Groth16 circuits with full R1CS constraints
• CLSAG ring signatures (replacing mock implementation)
• Full libp2p integration (Gossipsub, Kademlia DHT, NAT traversal)
• RocksDB state snapshots and advanced pruning
• Hardware wallet integration (Ledger, Trezor with BIP44)
• HSM provider implementations (Vault, AWS CloudHSM, Azure KeyVault)
• WebSocket subscriptions (eth_subscribe, event filtering)
• Admin authentication (JWT, RBAC, audit logging)
• Mobile wallet SDK (iOS/Android)
• Performance benchmarking and optimization

• Security audit (cryptography, smart contracts, economics)
• Recursive SNARK aggregation (Plonk migration)
• GPU CA acceleration (CUDA/OpenCL)
• Block explorer with tournament visualization
• Governance system (proposals, voting, execution)
• Smart contract SDK with templates and dev tools
• Light client wallet integration
• BFT finality gadget with slashing
• Documentation portal with API reference
• Production infrastructure (multi-region, monitoring, chaos testing)
• 10-node testnet (1 month stability)

• Production-ready zkSNARKs (recursive aggregation)
• Third-party security audit completion
• Optimized CA performance (SIMD/GPU)
• Bridge to Ethereum
• DeFi primitives
• Mobile wallets
• Full documentation
• 🚀 Mainnet Launch

Q: Is this a joke?
A: No. We're dead serious about CA tournaments. RC1 is deployed and working.

Q: Can I win by just using the biggest glider?
A: Maybe initially, but strategy matters. Lightweight gliders can outmaneuver heavier ones.

Q: What's the TPS?
A: RC1 achieves approximately 50 TPS in local testing (tested with 3-node configuration, transaction batches of 100). Target is 100+ TPS in RC2 with optimizations. We're not trying to be Solana - we're optimizing for security and interesting consensus.

Q: Why not just use PoS?
A: Because clicking "stake" buttons is boring. Designing glider strategies is art.

Q: Is it quantum-resistant?
A: CA evolution is fundamentally quantum-resistant. We use classical crypto for signatures (ECDSA, ECVRF), which is upgradable to post-quantum algorithms.

Q: Can I run this on a Raspberry Pi?
A: Validator: probably not (ZK proving is heavy, requires 8GB+ RAM). Light client: yes (implemented in RC1).

Q: What's the energy consumption?
A: Way less than Bitcoin. CA simulation is deterministic and parallelizable, not hash grinding.

Q: When mainnet?
A: After completing RC2, RC3, and comprehensive security audits. Timeline depends on audit findings and meeting all production readiness criteria. Estimated 2026, subject to change.

Status: Release Candidate 1 - Pre-audit, not production ready.

DO NOT use in production until RC3 security audit completes.

• ✅ VRF-based block proposer selection (ECVRF with Ristretto255)
• ✅ Transaction signature verification (ECDSA secp256k1)
• ✅ Gas bounds validation (max 10,000 Gwei price, 30M limit)
• ✅ DoS protection (new account gas requirements)
• ✅ Input validation (address format, nonce, balance checks)
• ✅ Error handling with proper logging
• ✅ Hardware wallet support (security state management)
• ✅ HSM integration (admin wallet signing)

• Mock ring signatures (CLSAG implementation in RC2)
• Mock ZK proofs (full R1CS constraints in RC2)
• Basic network security (full libp2p hardening in RC2)
• Admin API restricted (requires explicit feature flags)

Found a vulnerability? Please report responsibly:

• Email: security@bitcell.network
• GitHub: Open a private security advisory
• Rewards: Bug bounty program coming in RC2

• RC2: Third-party cryptography review
• RC3: Full security audit (crypto, smart contracts, economics)
• v1.0: Penetration testing and mainnet security hardening

Dual-licensed under MIT / Apache 2.0.

Choose whichever makes your lawyer happier.

• Cellular Automata: John Conway (RIP, legend)
• Subjective Logic: Audun Jøsang
• zkSNARKs: The SCIPR Lab wizards
• Rust: The Rust Foundation & community
• You: For reading this far 🙏

• Release Notes: RC1 Release Notes
• Architecture: Architecture Overview
• RPC Spec: Full JSON-RPC and WebSocket API documentation
• Documentation: Comprehensive mdBook docs in docs/book/
• Discord: https://discord.gg/bitcell (coming soon)
• Twitter: https://twitter.com/bitcell_net (coming soon)
• GitHub: https://github.com/Steake/BitCell

Built with 🦀 Rust, ⚡ zkSNARKs, and 🎮 Conway's Game of Life

"In a world of hash lotteries, be a glider strategist."