🌌 BitCell

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

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

What Even Is This?

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.

🎉 RC1 Highlights (v0.1.0-rc1)

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.

Core Vibes

🎮 Tournament Consensus: Miners battle with gliders in a 1024×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

Why Though?

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. 🚀

Architecture Aesthetic

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×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

Quick Start (For The Impatient)

# 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

The Tournament Protocol (The Good Stuff)

Each block height runs a bracket-style tournament:

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

Example Battle

Miner A: Heavyweight Spaceship (160 energy)
Miner B: Standard Glider (100 energy)

Grid: 1024×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 🎉

Protocol-Local EBSL (Trust Without Oracles)

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)

ZK-SNARK Circuits (Modular by Design)

Four circuit structures defined in RC1:

1. Battle Circuit `C_battle`

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

2. Execution Circuit `C_exec`

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

3. State Transition Circuit `C_state`

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

4. Merkle Path Circuit `C_merkle`

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

Economics (Bitcoin-Style Halving)

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.

Smart Contracts (Privacy Native)

// 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);

Installation

Prerequisites

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

Build

# 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 Tests

# 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

Benchmarks

# Run performance benchmarks
cargo bench

# Results saved to target/criterion/
# View HTML reports in target/criterion/report/index.html

Run a Local Node

# 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

Project Structure

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

Development

# 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

Contributing

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

Areas We Need Help

Coding Style

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

Roadmap

v0.1 (RC1) ✅ (Current Release)

v0.2 (RC2) 🚧 (In Progress)

v0.3 (RC3) 📋 (Planned)

v1.0 (Mainnet) 🎯 (Future)

FAQ

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.

Security

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

DO NOT use in production until RC3 security audit completes.

RC1 Security Features

✅ 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)

Known Limitations (RC1)

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)

Reporting Security Issues

Found a vulnerability? Please report responsibly:

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

Security Roadmap

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

License

Dual-licensed under MIT / Apache 2.0.

Choose whichever makes your lawyer happier.

Credits

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 🙏

Links

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."

Name		Name	Last commit message	Last commit date
Latest commit History 206 Commits
.github		.github
ceremony		ceremony
crates		crates
docs		docs
examples		examples
infra		infra
keys		keys
scripts		scripts
sdk		sdk
tests		tests
.gitignore		.gitignore
AGENT_PLAN.md		AGENT_PLAN.md
Cargo.toml		Cargo.toml
README.md		README.md
rust-toolchain.toml		rust-toolchain.toml
todo_now.md		todo_now.md

Steake/BitCell

Folders and files

Latest commit

History

Repository files navigation

🌌 BitCell

What Even Is This?

🎉 RC1 Highlights (v0.1.0-rc1)

Core Vibes

Why Though?

Architecture Aesthetic

Quick Start (For The Impatient)

The Tournament Protocol (The Good Stuff)

Example Battle

Protocol-Local EBSL (Trust Without Oracles)

ZK-SNARK Circuits (Modular by Design)

1. Battle Circuit C_battle

2. Execution Circuit C_exec

3. State Transition Circuit C_state

4. Merkle Path Circuit C_merkle

Economics (Bitcoin-Style Halving)

Smart Contracts (Privacy Native)

Installation

Prerequisites

Build

Run Tests

Benchmarks

Run a Local Node

Project Structure

Development

Contributing

Areas We Need Help

Coding Style

Roadmap

v0.1 (RC1) ✅ (Current Release)

v0.2 (RC2) 🚧 (In Progress)

v0.3 (RC3) 📋 (Planned)

v1.0 (Mainnet) 🎯 (Future)

FAQ

Security

RC1 Security Features

Known Limitations (RC1)

Reporting Security Issues

Security Roadmap

License

Credits

Links

About

Topics

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors 3

Uh oh!

Languages

1. Battle Circuit `C_battle`

2. Execution Circuit `C_exec`

3. State Transition Circuit `C_state`

4. Merkle Path Circuit `C_merkle`

Packages