Skip to content

tx.md

Latest commit

 

History

History
98 lines (76 loc) · 3.51 KB

tx.md

File metadata and controls

98 lines (76 loc) · 3.51 KB

tx.go - Transaction Processing and Memory Pool Management

This file implements the logic for transaction sending, handling, and memory pooling in the Canopy blockchain. It's a critical component that manages how transactions flow through the network and are stored before being included in blocks.

Overview

The transaction handling system is designed to:

  • Process locally generated transactions
  • Listen for and validate incoming transactions from the network
  • Maintain a memory pool (mempool) of valid transactions
  • Gossip valid transactions to peers
  • Track failed transactions for reporting
  • Prioritize transactions based on fees

Core Components

Controller

The Controller manages the overall transaction flow in the blockchain. It:

  • Sends locally generated transactions to the network
  • Listens for incoming transactions from peers
  • Validates transactions before adding them to the mempool
  • Manages peer reputation based on transaction validity
  • Gossips valid transactions to other peers
  • Prevents duplicate transaction processing

Mempool

The Mempool is a temporary storage area for valid but unconfirmed transactions. It:

  • Maintains an ordered list of transactions (typically by fee)
  • Validates transactions against the current blockchain state
  • Evicts invalid transactions when state changes
  • Prioritizes transactions with higher fees
  • Handles special transaction types (like certificate results)
  • Maintains a txn of transaction results for efficient verification
  • Tracks failed transactions for reporting purposes

Transaction Validation

The validation system ensures only valid transactions enter the mempool:

  • Checks if transactions already exist in the blockchain
  • Verifies transactions against the current state
  • Uses an ephemeral copy of the state machine to validate without affecting the main chain
  • Rechecks all mempool transactions when necessary
  • Evicts transactions that become invalid due to state changes

Processes

flowchart TD
    A[Local Transaction] -->|SendTxMsg| B[Controller]
    C[Network Transaction] -->|ListenForTx| B
    B -->|HandleTransaction| D{Already in blockchain?}
    D -->|Yes| E[Reject as Duplicate]
    D -->|No| F{Already in mempool?}
    F -->|Yes| G[Reject as Already Pending]
    F -->|No| H[Mempool]
    H -->|HandleTransaction| I{Valid against state?}
    I -->|No| J[Cache as Failed]
    I -->|Yes| K[Add to Mempool]
    K -->|If needed| L[Recheck Mempool]
    L -->|For each tx| M{Still valid?}
    M -->|No| N[Evict from Mempool]
    M -->|Yes| O[Keep in Mempool]
    B -->|If valid| P[Gossip to Peers]
Loading

Component Interactions

The transaction handling system interacts with several other components:

flowchart TD
    A[Controller] <-->|Transaction Handling| B[Mempool]
    A <-->|Network Communication| C[P2P Layer]
    B <-->|State Validation| D[State Machine/FSM]
    A <-->|Transaction Lookup| E[Blockchain Store]
    A <-->|Reputation Management| C
    F[RPC Interface] -->|Transaction Queries| A
Loading

Security Features

The transaction handling system includes several security measures:

  • Reputation system for peers that penalizes those sending invalid transactions
  • Duplicate transaction detection to prevent replay attacks
  • Fee-based prioritization to prevent spam
  • Transaction validation against current state to prevent invalid state transitions
  • Mempool rechecking to ensure only valid transactions remain when state changes
  • Caching of failed transactions for monitoring and debugging
  • Thread safety through locking mechanisms