Protocol Layer Overview

The protocol layer (blvm-protocol) abstracts Bitcoin protocol for multiple variants and protocol evolution. It sits between the pure mathematical consensus rules (blvm-consensus) and the Bitcoin node implementation (blvm-node), supporting mainnet, testnet, regtest, and future protocol variants.

Architecture Position

Stack layer 3: protocol abstraction between blvm-consensus and blvm-node.

1. Orange Paper (mathematical foundation)
2. blvm-consensus (pure math implementation)
3. blvm-protocol (Bitcoin abstraction) ← THIS CRATE
4. blvm-node (full node implementation)
5. blvm-sdk (developer toolkit)
6. blvm-commons (governance enforcement)

Full stack: Stack overview.

Protocol Variants

The protocol layer supports multiple Bitcoin network variants:

VariantNetwork NameMagic (hex)Default P2PDefault RPC (blvm)Purpose
BitcoinV1mainnetf9beb4d983338332Production Bitcoin network
Testnet3testnet0b1109071833318332Bitcoin test network
Regtestregtestfabfb5da1844418443Regression testing network

Network Parameters

Each variant also defines genesis block hash, difficulty targets, halving interval (210,000 blocks), and feature activation heights (SegWit, Taproot).

Core Components

Protocol Engine

The BitcoinProtocolEngine is the main interface:

#![allow(unused)]
fn main() {
pub struct BitcoinProtocolEngine {
 version: ProtocolVersion,
 network_params: NetworkParams,
 config: ProtocolConfig,
}
}

Features:

  • Protocol variant selection
  • Network parameter access
  • Feature flag management
  • Validation rule enforcement

Network Messages

Supports Bitcoin P2P protocol messages:

Core Messages:

  • Version, VerAck - Connection handshake
  • Addr, GetAddr - Peer address management
  • Inv, GetData, NotFound - Inventory management
  • Block, Tx - Block and transaction relay
  • GetHeaders, Headers, GetBlocks - Header synchronization
  • Ping, Pong - Connection keepalive
  • MemPool, FeeFilter - Mempool synchronization

BIP152 (Compact Block Relay):

  • SendCmpct - Compact block negotiation
  • CmpctBlock - Compact block transmission
  • GetBlockTxn, BlockTxn - Transaction reconstruction

FIBRE Protocol:

  • FIBREPacket - High-performance relay protocol
  • Packet format and serialization
  • Performance optimizations

Governance Messages:

  • Governance messages via P2P protocol
  • Message format and routing
  • Integration with governance system

Commons Extensions:

  • GetUTXOSet, UTXOSet - UTXO commitment protocol
  • GetFilteredBlock, FilteredBlock - Spam-filtered blocks
  • GetBanList, BanList - Distributed ban list sharing

Service Flags

Service flags indicate node capabilities:

Standard Flags:

  • NODE_NETWORK - Full node with all blocks
  • NODE_WITNESS - SegWit support
  • NODE_COMPACT_FILTERS - BIP157/158 support
  • NODE_NETWORK_LIMITED - Pruned node

Commons Flags:

  • NODE_UTXO_COMMITMENTS - UTXO commitment support
  • NODE_BAN_LIST_SHARING - Ban list sharing
  • NODE_FIBRE - FIBRE protocol support
  • NODE_DANDELION - Dandelion++ privacy relay
  • NODE_PACKAGE_RELAY - BIP331 package relay

Validation Rules

Protocol-specific validation rules:

  • Size Limits: Block (4MB), transaction (1MB), script (10KB)
  • Feature Flags: SegWit, Taproot, RBF support
  • Fee Rules: Minimum and maximum fee rates
  • DoS Protection: Message size limits, address count limits

Commons-Specific Extensions

UTXO Commitments

Protocol messages for UTXO set synchronization:

  • GetUTXOSet - Request UTXO set at specific height
  • UTXOSet - UTXO set response with merkle proof

Filtered Blocks

Spam-filtered block relay for efficient syncing:

  • GetFilteredBlock - Request filtered block
  • FilteredBlock - Filtered block with spam transactions removed

Ban List Sharing

Distributed ban list management:

  • GetBanList - Request ban list
  • BanList - Ban list response with signatures

BIP Support

Compact block relay (BIP152)

Short transaction IDs and block reconstruction (SendCmpct, CmpctBlock). See Network messages above.

Client-side block filtering (BIP157/158)

GCS compact block filters and filter header chain. Node handlers and UTXO-commitment integration: BIP158 in UTXO Commitments.

Implemented Bitcoin Improvement Proposals:

  • BIP152: Compact Block Relay: above
  • BIP157: Client-side Block Filtering: above
  • BIP158: Compact Block Filters: above
  • BIP173/350/351: Bech32/Bech32m Address Encoding
  • BIP70: Payment Protocol

Protocol Evolution

The protocol layer supports protocol evolution:

  • Version Support: Multiple protocol versions
  • Feature Management: Enable/disable features based on version
  • Breaking Changes: Track and manage protocol evolution
  • Backward Compatibility: Maintain compatibility with existing nodes
  • Wire and transport: P2P message formats and Bitcoin-compatible peer behavior live in blvm-protocol; the reference node delivers them over transports (TCP by default; optional QUIC-based paths where features enable them). Treat encrypted Bitcoin P2P (BIP324) and other transport experiments as build- and release-specific, see blvm-protocol and blvm-node features and release notes rather than assuming one global default.

Usage Example

#![allow(unused)]
fn main() {
use blvm_protocol::{BitcoinProtocolEngine, ProtocolVersion};

// Create a mainnet protocol engine
let engine = BitcoinProtocolEngine::new(ProtocolVersion::BitcoinV1)?;

// Get network parameters
let params = engine.get_network_params();
println!("Network: {}", params.network_name);
println!("Port: {}", params.default_port);

// Check feature support
if engine.supports_feature("segwit") {
 println!("SegWit is supported");
}
}

Source

See Also