Glossary
Key terms and concepts used throughout the BLVM documentation.
BLVM Components
BLVM (Bitcoin Low-Level Virtual Machine) - Compiler-like infrastructure for Bitcoin implementations. Transforms the Orange Paper (IR) through optimization passes into optimized code, with formal verification ensuring correctness. Similar to how LLVM provides compiler infrastructure, BLVM provides Bitcoin implementation infrastructure.
Orange Paper - Mathematical specification of Bitcoin’s consensus protocol, serving as the “intermediate representation” (IR) in BLVM’s compiler-like architecture. Transformed through optimization passes into optimized code. See Orange Paper.
Optimization Passes - Runtime optimization passes in blvm-consensus that transform the Orange Paper specification into optimized code: Pass 2 (Constant Folding), Pass 3 (Memory Layout Optimization), Pass 5 (SIMD Vectorization), plus bounds check optimization, dead code elimination, and inlining hints. See Optimization Passes.
blvm-consensus - Optimized mathematical implementation of Bitcoin consensus rules with formal verification. Includes optimization passes that transform the Orange Paper specification into production-ready code. Foundation layer with no dependencies. See Consensus Overview.
blvm-protocol - Protocol abstraction layer for multiple Bitcoin variants (mainnet, testnet, regtest) while maintaining consensus compatibility. See Protocol Overview.
blvm-node - Bitcoin node implementation with storage, networking, RPC, and mining capabilities. Production-ready reference implementation. See Node Overview.
blvm-sdk - Developer toolkit providing governance cryptographic primitives, module composition framework, and CLI tools for key management and signing. See SDK Overview.
Governance
Bitcoin Commons - Forkable governance framework applying Elinor Ostrom’s commons management principles through cryptographic enforcement. See Governance Overview.
5-Tier Governance Model - Constitutional governance system with graduated signature thresholds (3-of-5 to 6-of-7) and review periods (7 days to 365 days) based on change impact. See Layer-Tier Model.
Forkable Governance - Governance rules can be forked by users if they disagree with decisions, creating exit competition and preventing capture. See Governance Fork.
Cryptographic Enforcement - All governance actions require cryptographic signatures from maintainers, making power visible and accountable. See Keyholder Procedures.
Technical Concepts
Formal Verification - Mathematical proof of code correctness. BLVM uses formal verification for critical consensus paths.
Proofs Locked to Code - Formal verification proofs are embedded in the code itself, ensuring correctness is maintained as code changes.
Spec Drift Detection - Automated detection when implementation code diverges from the Orange Paper mathematical specification.
Compiler-Like Architecture - Architecture where Orange Paper (IR) → optimization passes → blvm-consensus → blvm-node, similar to source code → IR → optimization passes → machine code in compilers. See System Overview.
Process Isolation - Module system design where each module runs in a separate process with isolated memory, preventing failures from propagating to the base node.
IPC (Inter-Process Communication) - Communication mechanism between modules and the node using Unix domain sockets with length-delimited binary messages. See Module IPC Protocol.
Storage & Networking
Storage Backends - Database backends for blockchain data: redb (default, production-ready), sled (beta, fallback), auto (auto-select based on availability). See Storage Backends.
Pruning - Storage optimization that removes old block data while keeping the UTXO set. Configurable to keep last N blocks.
Transport Abstraction - Unified abstraction supporting multiple transport protocols: TCP (default, Bitcoin P2P compatible) and Iroh/QUIC (experimental). See Transport Abstraction.
Network Variants - Bitcoin network types: Mainnet (BitcoinV1, production), Testnet3 (test network), Regtest (regression testing, isolated).
Consensus & Protocol
Consensus Rules - Mathematical rules that all Bitcoin nodes must follow to maintain network consensus. Defined in the Orange Paper and implemented in blvm-consensus.
BIP (Bitcoin Improvement Proposal) - Standards for Bitcoin protocol changes. BLVM implements numerous BIPs including BIP30, BIP34, BIP66, BIP90, BIP147, BIP141/143, BIP340/341/342. See Protocol Specifications.
SegWit (Segregated Witness) - BIP141/143 implementation separating witness data from transaction data, enabling transaction malleability fixes and capacity improvements.
Taproot - BIP340/341/342 implementation providing Schnorr signatures, Merkle tree scripts, and improved privacy.
RBF (Replace-By-Fee) - BIP125 implementation allowing transaction replacement with higher fees before confirmation.
Development
Module System - Process-isolated system supporting optional features (Lightning, merge mining, privacy enhancements) without affecting consensus or base node stability.
Module Manifest (module.toml) - Configuration file defining module metadata, capabilities, dependencies, and entry point.
Capabilities - Permissions system for modules. Capabilities use snake_case in module.toml and map to Permission enum variants. Core capabilities include: read_blockchain, read_utxo, read_chain_state, subscribe_events, send_transactions, read_mempool, read_network, network_access, read_lightning, read_payment, read_storage, write_storage, manage_storage, read_filesystem, write_filesystem, manage_filesystem, register_rpc_endpoint, manage_timers, report_metrics, read_metrics, discover_modules, publish_events, call_module, register_module_api. See Permission System for complete list.
RPC (Remote Procedure Call) - JSON-RPC 2.0 interface for interacting with the node. BLVM implements Bitcoin Core-compatible methods.
Governance Phases
Phase 1 (Infrastructure Building) - All core components are implemented. Governance is not activated. Test keys are used.
Phase 2 (Governance Activation) - Governance rules are enforced with real cryptographic keys and keyholder onboarding.
Phase 3 (Full Operation) - Mature, stable system with battle-tested governance and production deployment.