Blockchain Transaction Lifecycle: A Comprehensive Guide

Understanding Blockchain Transactions ¶

Transactions form the core of any blockchain system, serving as digital records for all on-chain activities. With the advent of smart contracts, transactions have evolved beyond simple "value transfers" to become verifiable records of complex operations. Every interaction—whether major or minor—requires transactional participation.

This guide explores the complete lifecycle of transactions in FISCO BCOS, covering all stages from creation to finalization.

Transaction Creation ¶

When users initiate requests through clients, the following components are assembled into valid transactions:

1. Sender Address: Identifies the user's account (transaction origin).

2. Recipient Address:

   • For contract deployment: Fixed as 0x0 (no specific recipient).
   • For contract calls: Specifies the target contract address.
3. Transaction Data: Binary-encoded inputs for executing intended operations.
4. Digital Signature: Generated using the sender's private key to authenticate the transaction.

Clients then augment transactions with additional fields like:

• Unique transaction IDs (preventing replay attacks)
• blockLimit parameters

👉 Explore advanced transaction structures

Transaction Pool Mechanics ¶

Upon reaching blockchain nodes, transactions undergo validation:

1. Signature Verification: Confirms transaction authenticity.
2. Duplicate Check: Filters previously processed transactions.
3. Pool Admission: Valid unique transactions enter the memory pool.

Invalid or duplicate transactions are immediately discarded.

Network Propagation ¶

Nodes employ optimized broadcast strategies:

• Initial receivers forward to all known nodes
• Subsequent relays use selective broadcasting (25% random nodes) to prevent network congestion
• Progressive propagation ensures eventual network-wide distribution

Block Assembly ¶

The Sealer process:

1. Extracts transactions from the pool (FIFO order)
2. Groups them into candidate blocks
3. Prepares blocks for consensus processing

👉 Understand blockchain consensus mechanisms

Execution Phase ¶

Block validators process transactions through:

1. Precompiled Contracts: Direct C++ function calls
2. EVM Processing: For complex smart contract logic

Execution outcomes are captured in transaction receipts, indicating success/failure states.

Consensus Mechanism ¶

FISCO BCOS utilizes PBFT for agreement:

1. Nodes independently execute identical blocks
2. Compare execution results
3. Confirm block validity upon ≥⅔ node consensus
4. Finalize block production

Finalization ¶

Post-consensus actions include:

1. Persistent Storage: Writing blocks to disk
2. Metadata Updates: Block height/hash mappings
3. Pool Maintenance: Removing finalized transactions
4. Query Availability: Enabling historical data searches via transaction hashes

FAQ: Blockchain Transactions

What determines transaction execution order?

Transactions are processed in First-In-First-Out (FIFO) sequence from the transaction pool.

How does PBFT prevent malicious blocks?

Requiring ⅔ node agreement makes it economically impractical for bad actors to control sufficient nodes.

Can failed transactions be reprocessed?

No - failed transactions are permanently recorded with their failure state in the blockchain.

Why use selective broadcasting?

The 25% relay strategy optimizes network efficiency while maintaining eventual consistency.

How long do transactions stay in the pool?

Until included in a finalized block, typically within seconds under normal network conditions.

What information do transaction receipts contain?

Execution status, gas usage, logs, and any return values from smart contract calls.