Consensus Layer Overview
The consensus layer (blvm-consensus) provides a pure mathematical implementation of Bitcoin consensus rules from the Orange Paper. All functions are deterministic, side-effect-free, and directly implement the mathematical specifications without interpretation.
Architecture Position
Tier 2 of the 6-tier Bitcoin Commons architecture:
1. Orange Paper (mathematical foundation)
2. blvm-consensus (pure math implementation) ← THIS LAYER
3. blvm-protocol (Bitcoin abstraction)
4. blvm-node (full node implementation)
5. blvm-sdk (developer toolkit)
6. blvm-commons (governance enforcement)
Core Functions
Implements major Bitcoin consensus functions from the Orange Paper:
Transaction Validation
CheckTransaction: Transaction structure and limit validationCheckTxInputs: Input validation against UTXO setEvalScript: Script execution engineVerifyScript: Script verification with witness data
Code: transaction.rs
Block Validation
ConnectBlock: Block connection and validationApplyTransaction: Transaction application to UTXO setCheckProofOfWork: Proof of work verificationShouldReorganize: Chain reorganization logic
Code: block.rs
Economic Model
GetBlockSubsidy: Block reward calculation with halvingTotalSupply: Total supply computationGetNextWorkRequired: Difficulty adjustment calculation
Code: economic.rs
Mempool Protocol
AcceptToMemoryPool: Transaction mempool validationIsStandardTx: Standard transaction checksReplacementChecks: RBF (Replace-By-Fee) logic
Code: mempool.rs
Mining Protocol
CreateNewBlock: Block creation from mempoolMineBlock: Block mining and nonce findingGetBlockTemplate: Block template generation
Code: mining.rs
Advanced Features
- SegWit: Witness data validation and weight calculation
- Taproot: P2TR output validation and key aggregation
Code: segwit.rs
Design Principles
- Pure Functions: All functions are deterministic and side-effect-free
- Mathematical Accuracy: Direct implementation of Orange Paper specifications
- Optimization Passes: LLVM-like optimization passes transform specifications into optimized code
- Exact Version Pinning: All consensus-critical dependencies pinned to exact versions
- Comprehensive Testing: Extensive test coverage with unit tests, property-based tests, and integration tests
- No Consensus Rule Interpretation: Only mathematical implementation
- Formal Verification: BLVM Specification Lock and property-based testing ensure correctness
Formal Verification
Implements mathematical verification of Bitcoin consensus rules:
Recent Improvements
- Strong Tier System: Critical proofs prioritized with AWS spot instance integration
- Spam Filtering: Always available (removed feature gate dependency)
- Parallel Proof Execution: Tiered scheduling for efficient verification
Code: block.rs
Verification Coverage
Chain Selection: should_reorganize, calculate_chain_work verified
Block Subsidy: get_block_subsidy halving schedule verified
Proof of Work: check_proof_of_work, target expansion verified
Transaction Validation: check_transaction structure rules verified
Block Connection: connect_block UTXO consistency verified
Code: VERIFICATION.md
BIP Implementation
Critical Bitcoin Improvement Proposals (BIPs) implemented:
- BIP30: Duplicate coinbase prevention (integrated in
connect_block()) - BIP34: Block height in coinbase (integrated in
connect_block()) - BIP66: Strict DER signatures (enforced via script verification)
- BIP90: Block version enforcement (integrated in
connect_block()) - BIP147: NULLDUMMY enforcement (enforced via script verification)
Code: block.rs
Performance Optimizations
Profile-Guided Optimization (PGO)
For maximum performance:
./scripts/pgo-build.sh
Expected gain: Significant performance improvement
Optimization Passes
LLVM-like optimization passes transform Orange Paper specifications:
- Constant Folding: Compile-time constant evaluation
- Memory Layout Optimization: Cache-friendly data structures
- SIMD Vectorization: Parallel processing where applicable
- Bounds Check Optimization: Eliminate unnecessary checks
- Dead Code Elimination: Remove unused code paths
Code: mod.rs
Mathematical Lock
Implementation is mathematically locked to the Orange Paper:
Chain of Trust:
Orange Paper (Math Spec) → BLVM Specification Lock (Z3 Proof) → Implementation → Bitcoin Consensus
Every function implements a mathematical specification, every critical function has a Z3 proof (via BLVM Specification Lock), and all proofs reference Orange Paper sections.
Dependencies
All consensus-critical dependencies are pinned to exact versions:
# Consensus-critical cryptography - EXACT VERSIONS
secp256k1 = "=0.28.2"
sha2 = "=0.10.9"
ripemd = "=0.1.3"
bitcoin_hashes = "=0.11.0"
Code: Cargo.toml
See Also
- Consensus Architecture - Consensus layer design
- Formal Verification - Verification methodology
- Mathematical Correctness - Verification approach and coverage
- UTXO Commitments - UTXO commitment system
- Orange Paper - Mathematical foundation