Blocks and Transactions
Blocks and transactions are the fundamental data structures of every blockchain. Understanding their anatomy helps you reason about performance, security, and costs.
What Is a Transaction?
A transaction is a signed message that requests a state change on the blockchain.
Anatomy of a Transaction
Every blockchain transaction contains:
Transaction Lifecycle
Solana Transaction Structure
Solana transactions have a unique structure optimized for parallel processing:
Why Solana Declares Accounts Upfront
This is crucial for parallelism:
Transaction Code Example
What Is a Block?
A block is a batch of transactions bundled together with metadata that links it to previous blocks.
Block Structure
Block Chaining
Each block references the previous block's hash, forming a chain:
Why Blocks Exist
Why not just chain individual transactions?
- Efficiency: Batching amortizes consensus overhead
- Atomicity: All transactions in a block are ordered
- Finality: Entire block is confirmed at once
- Merkle proofs: Efficiently prove transaction inclusion
Solana Block Structure
Solana has a unique block structure with slots and entries:
Merkle Trees: Efficient Transaction Verification
A Merkle tree is a hash-based data structure that allows efficient proof of data inclusion.
Building a Merkle Tree
Merkle Proofs
To prove Tx1 is in the block, you only need:
Merkle Tree Implementation
Transaction Finality
Finality refers to when a transaction becomes irreversible.
Types of Finality
Solana Finality
Solana has multiple confirmation levels:
Block Size and Throughput
The Scalability Trilemma
Block Size Trade-offs
Throughput Comparison
Solana achieves higher throughput through:
- Parallel execution (Sealevel)
- Proof of History (no waiting for consensus on time)
- Gulf Stream (transaction forwarding)
- Turbine (block propagation)
Deep Dive: Transaction Ordering
Why Order Matters
This enables MEV (Maximal Extractable Value)—validators can profit by reordering transactions.
Solana's Approach
Solana uses a leader schedule known in advance:
Key Takeaways
- Transactions are signed requests for state changes
- Blocks batch transactions with cryptographic links to previous blocks
- Merkle trees enable efficient verification without downloading everything
- Finality varies by blockchain—understand your chain's guarantees
- Solana requires upfront account declaration for parallel execution
Common Mistakes
- Not waiting for finality: Don't consider a transaction complete until sufficiently confirmed
- Ignoring reorgs: On probabilistic finality chains, recent blocks can be reverted
- Hardcoding block times: Block times are averages, not guarantees
- Ignoring MEV: On-chain order != submission order
Try It Yourself
-
Explore block structure: Use Solana Explorer to examine a recent block. Identify the slot number, transactions, and parent slot.
-
Calculate Merkle proof size: For a block with 4,096 transactions, how many hashes would a Merkle proof contain?
-
Compare confirmation times: Send a transaction on devnet and measure time to "processed", "confirmed", and "finalized".
Next: UTXO vs Account Model - A deeper comparison of the two fundamental approaches to tracking blockchain state.