Skip to content

Latest commit

 

History

History
117 lines (87 loc) · 4.09 KB

block.md

File metadata and controls

117 lines (87 loc) · 4.09 KB

block.go - Block Processing and distribution

This file contains the high-level functionality for block processing, proposal creation, and consensus management in the Canopy blockchain. It handles how blocks are received, validated, proposed, and committed to the blockchain.

Overview

The block.go file implements important blockchain operations including:

  • Listening for and processing incoming blocks from the network
  • Creating and validating block proposals
  • Committing finalized blocks to the blockchain
  • Gossiping blocks to other nodes in the network
  • Managing the consensus process

Core Components

Block Listener

The block listener continuously monitors the network for incoming block messages. When a new block is received, it:

  • Validates the block to ensure it follows network rules
  • Processes the block if valid
  • Gossips the block to other peers in the network
  • Handles synchronization if the node falls out of sync with the network

Block Proposal System

The proposal system is responsible for creating new blocks when a node is selected as a leader. It:

  • Collects transactions from the mempool
  • Creates a block with valid transactions
  • Applies the block against the state machine to generate results
  • Produces certificate results that include rewards, slashes, and other consensus information
  • Prepares the block for validation by other nodes

Block Validation

When a node receives a block proposal, it must validate it before accepting it. The validation process:

  • Checks the basic structure of the block
  • Verifies the block against the current state
  • Ensures the block's results match what would be produced locally
  • Validates any Byzantine fault evidence included in the proposal
  • Confirms the block follows all consensus rules

Block Commitment

Once a block has been validated by a quorum of validators (a supermajority of two-thirds of the network), it can be committed to the blockchain. The commitment process:

  • Applies the block to the state machine
  • Indexes the block and its transactions
  • Removes the block's transactions from the mempool
  • Atomically writes all changes to the database
  • Sets up the controller for the next block height

Certificate Management

Certificates are cryptographic proofs that a block has been validated by a quorum of validators. The system:

  • Creates certificates for valid blocks
  • Validates certificates from other nodes
  • Uses certificates to finalize blocks
  • Handles certificate results which include rewards and penalties

Processes

flowchart TD
    A[Receive Block] --> B{Validate Block}
    B -->|Valid| C[Apply Block to State]
    B -->|Invalid| D[Reject Block]
    C --> E[Commit Block]
    E --> F[Set Up for Next Height]

    G[Leader Selected] --> H[Create Block Proposal]
    H --> I[Include Transactions from Mempool]
    I --> J[Apply Block to State]
    J --> K[Create Certificate Results]
    K --> L[Send Proposal to Network]
Loading

Component Interactions

The block processing system interacts with several other components:

  • Finite State Machine (FSM): Applies blocks to the state and validates transactions
  • Mempool: Provides transactions for new blocks and removes committed transactions
  • P2P Network: Receives and sends blocks to other nodes
  • BFT Consensus: Manages the Byzantine Fault Tolerant consensus process
  • Store: Persists blocks and state changes to the database
flowchart LR
    A[Block Processing] <--> B[FSM]
    A <--> C[Mempool]
    A <--> D[P2P Network]
    A <--> E[BFT Consensus]
    A <--> F[Store]
Loading

Security Features

The block processing system includes several security features:

  • Byzantine Fault Tolerance: Can tolerate up to 1/3 of nodes being malicious
  • Reputation System: Penalizes peers that send invalid blocks
  • Verifiable Delay Functions (VDF): Provides unpredictable but verifiable randomness
  • Checkpoints: Protects against long-range attacks during synchronization
  • Quorum Certificates: Ensures blocks are only committed when validated by a supermajority of two-thirds of the network
  • Committee Validation: Ensures only authorized validators participate in consensus