Blockchain Data Structures and Transaction Lifecycle

Introduction

A blockchain is not merely a list of transactions. It is a replicated data system in which transactions are created by users, authenticated cryptographically, transmitted through a peer-to-peer network, checked against protocol rules, grouped into blocks, and accepted according to a consensus mechanism. Understanding this lifecycle is essential for developers, auditors, investigators, and blockchain users.

This chapter follows a transaction from its origin in a wallet to its inclusion in a block and eventual finality. It also explains the principal data structures used by blockchains and introduces practical methods for inspecting transactions and blocks with blockchain explorers.

Learning Objectives

By the end of this chapter, you should be able to:

• describe the principal data structures in a blockchain;
• distinguish transaction creation, signing, propagation, validation, inclusion, confirmation, and finality;
• explain how hashes, digital signatures, Merkle trees, and state models support integrity;
• compare probabilistic and deterministic finality;
• inspect transaction and block fields using an explorer;
• identify common failure modes, privacy risks, and operational best practices.

1. The Layered Structure of a Blockchain

A blockchain can be understood through four related layers:

1. Application layer: wallets, exchanges, decentralized applications, payment systems, and explorers.
2. Transaction layer: signed instructions that request a state change.
3. Block and ledger layer: ordered groups of transactions and the current ledger state.
4. Network and consensus layer: peer-to-peer communication and rules for agreeing on valid blocks.

A blockchain node commonly stores more than a sequence of blocks. It may maintain a block database, transaction pool, current state database, peer information, and indexes. The exact design varies between networks.

1.1 Blocks

A block normally contains a header and a body. The header identifies the block and commits to important information; the body contains transactions and, in some systems, other records.

Typical header fields include:

The previous-block hash creates a historical link. If a prior block is altered, its hash changes, causing the next block’s reference to become inconsistent. This does not make alteration mathematically impossible, but it makes undetected alteration computationally or economically difficult when combined with distributed consensus.

1.2 Transactions

A transaction is a structured message that requests an operation. Depending on the blockchain, it may transfer value, consume and create outputs, invoke a smart contract, deploy code, or change account state.

Common transaction fields include:

• sender identification or public-key information;
• recipient address or script;
• amount or execution parameters;
• nonce, sequence number, or input references;
• fee or fee-rate information;
• a digital signature;
• optional data or smart-contract call parameters.

The exact fields are protocol-specific. A Bitcoin transaction, for example, uses inputs that reference earlier unspent transaction outputs and outputs that create new spendable outputs. An account-based platform generally records a sender, recipient, value, nonce, fee parameters, and optional data.

1.3 Hashes and Commitments

A cryptographic hash function maps an input of arbitrary length to a fixed-length output. For an input message m, its digest may be written as h = H(m). A secure hash is designed to make it computationally infeasible to find a different message with the same digest, subject to the security assumptions of the selected algorithm.

Hashes are used for transaction identifiers, block identifiers, links between blocks, Merkle-tree nodes, and state commitments. A hash is not encryption: it is not intended to be reversible, and it does not provide confidentiality.

1.4 Merkle Trees

A Merkle tree summarizes a collection of transactions. Transaction hashes form the leaves. Pairs of hashes are repeatedly hashed until one root remains, called the Merkle root or transaction root.

For two child hashes h₁ and h₂, a parent may be calculated as:

Here, H is the protocol’s hash function and ∥ denotes concatenation in the specified order. The formula applies to binary Merkle trees; protocols must also define how an odd number of leaves is handled and how transaction serialization is performed.

A Merkle proof allows a verifier to establish that a transaction belongs to a committed set without receiving every transaction. The verifier combines the transaction hash with the required sibling hashes and checks whether the computed root equals the block’s committed root. Merkle trees improve verification efficiency, but they do not by themselves prove that a transaction is valid or that a block has achieved finality.

1.5 Ledger State

The state is the information needed to determine the result of future transactions. In an unspent-output model, state consists primarily of currently unspent outputs. In an account model, it may include account balances, nonces, contract code, and contract storage.

A useful conceptual relationship is:

S_t is the state before a transaction or transaction sequence, T_t is the valid transaction or sequence, F is the protocol-defined state-transition function, and S_t+1 is the resulting state. This is a model of deterministic execution, not a universal implementation formula. It assumes that all required inputs, execution rules, and environmental values are defined consistently by the protocol.

2. The Transaction Lifecycle

The lifecycle is best treated as a sequence of logical stages. In practice, stages can overlap: a node may validate a transaction while other nodes are receiving it, and a transaction may be included in a proposed block before every node has seen it independently.

Figure: The logical stages of a blockchain transaction lifecycle.

2.1 Creation

A wallet constructs a transaction from user instructions. It selects inputs or determines the account nonce, calculates or estimates fees, encodes the recipient, and prepares any contract data. The wallet should display the transaction in a human-readable form before signing.

At this stage, the transaction is not yet authorized. A malformed transaction may fail before signing, but a correctly formatted transaction can still be economically harmful if the user supplies the wrong address or approves a malicious contract call.

2.2 Signing

The wallet signs a defined transaction representation with a private key. In abstract form, the signature can be written as:

sk is the private key, m is the exact message or serialized transaction covered by the signature, and σ is the signature. Verification uses the corresponding public key and normally checks:

The private key must remain secret. A signature proves control of the relevant key under the protocol’s cryptographic assumptions; it does not prove that the transaction is wise, legal, or free from fraud. Hardware wallets reduce key-exposure risk by signing inside a protected device, but users must still verify transaction details and destination addresses.

2.3 Propagation

After signing, the wallet submits the transaction to a node, often through an RPC endpoint or wallet service. The node performs preliminary checks and, if accepted into its local transaction pool, forwards it to peers. Peers repeat the process. Propagation is a gossip process rather than a single broadcast event.

A transaction may fail to propagate because of an invalid signature, insufficient fee, incorrect nonce, policy restrictions, network congestion, or an unavailable endpoint. A transaction shown as “submitted” by a wallet is not necessarily accepted by the network.

2.4 Validation

Nodes validate transactions according to consensus rules and often additional local policy rules. Typical checks include:

• correct serialization and supported transaction version;
• valid signature and authorization;
• sufficient balance or valid unspent inputs;
• correct nonce or sequence constraints;
• no double spending;
• valid script or smart-contract execution;
• acceptable fee and resource limits;
• compliance with size, gas, and protocol constraints.

Validation is contextual. A transaction may be valid in isolation but invalid when another transaction has already consumed the same input or used the same account nonce. Nodes generally do not need to trust the submitting wallet; they independently recompute the required checks.

2.5 Selection and Block Inclusion

A block producer selects transactions from available candidates and orders them according to protocol rules and economic incentives. Selection may consider fee rate, transaction age, dependencies, resource limits, and application-specific policies.

The producer executes or verifies the selected transactions, constructs the block, computes the transaction commitment, and proposes or mines the block. Inclusion means that the transaction appears in a block accepted by the observer’s current chain. Inclusion is stronger than being in a mempool, but it is not always final.

Ordering matters. Two individually valid transactions may conflict, and only one may be accepted. In smart-contract systems, the order of non-conflicting transactions may still affect balances, prices, or contract state.

2.6 Confirmation

A confirmation is commonly counted as an accepted block containing the transaction, plus subsequent accepted blocks built on it. On a chain where the transaction is in the latest accepted block, users may call it confirmed once; after additional blocks, it has more confirmations.

Confirmation terminology is not universal. Some systems expose “block height,” “depth,” “finalized,” or “safe” statuses instead. Users should consult the relevant protocol’s definitions rather than assume that every confirmation has the same meaning.

2.7 Finality

Finality is the point at which a transaction is considered irreversible, or sufficiently irreversible, under a specified threat model.

• Probabilistic finality: the chance of reversal decreases as additional blocks accumulate, but is not normally zero. This is associated with many longest-chain or heaviest-chain systems.
• Deterministic or economic finality: a protocol rule, validator vote, checkpoint, or penalty mechanism makes reversal impossible or highly constrained under stated assumptions.

Finality depends on consensus, not merely on the transaction’s signature or its appearance in an explorer. A chain reorganization can remove a transaction from a previously observed block. Applications should wait for a policy-appropriate status, especially for high-value transfers.

3. Transaction Fees, Nonces, and Replacement

Fees compensate block producers and help allocate scarce block space or execution capacity. A fee may be represented as a total amount or a fee rate. The accounting differs by protocol, so a fee field should not be interpreted without knowing the network’s fee model.

In an account model, a nonce usually provides ordering and replay protection. If an account has nonce 12, a transaction requiring nonce 13 may wait for nonce 12 or be rejected, depending on the implementation. Two transactions with the same nonce may compete, with replacement rules determining whether a later transaction can supersede an earlier one.

In an unspent-output model, an input identifies a previous output. A transaction is invalid if an input has already been spent in the accepted chain. A transaction in a mempool can therefore disappear if a conflicting transaction is confirmed.

4. Inspecting Blocks and Transactions with Explorers

A blockchain explorer is a user interface over blockchain data, node APIs, indexers, and sometimes third-party analytics. It is useful for education and operational checking, but it is not itself the consensus mechanism. An explorer may be delayed, misconfigured, or connected to a different network.

4.1 A Practical Inspection Procedure

1. Identify the network. Confirm whether the record belongs to mainnet, testnet, a layer-two network, or another chain.
2. Search by transaction ID or block hash. Avoid relying solely on a shortened address display.
3. Check status. Look for pending, confirmed, failed, dropped, replaced, finalized, or equivalent terminology.
4. Inspect block information. Record block height, block hash, timestamp, and confirmation or finality status.
5. Inspect transaction fields. Check sender, recipient, value, fee, nonce or inputs, outputs, contract data, and event logs where available.
6. Verify the asset and units. Native currency and token amounts may use different decimal conventions.
7. Compare independently when important. Use another explorer or a trusted node query, particularly for settlement, compliance, or dispute investigation.

4.2 What an Explorer Can and Cannot Show

An explorer can show the public record encoded by a chain and information derived by an indexer. It generally cannot reveal a private key, prove the real-world identity of an address, or guarantee that a displayed label is accurate. “From” and “to” labels may be inferred from transaction structure and may not represent a person or legal entity.

A displayed timestamp may be a block timestamp rather than the exact moment a user clicked “send.” A token transfer may appear in event logs even though the transaction’s overall contract call failed; the explorer’s interpretation must be read carefully and checked against the transaction status and protocol semantics.

5. Worked Example: Tracing a Payment

Consider an illustrative account-based network. Alice sends 25 units to Bob and agrees to pay a fee of 0.02 units. The wallet constructs a transaction with Alice’s address, Bob’s address, value 25, a suitable nonce, fee parameters, and no contract data.

1. Creation: The wallet checks that Alice’s available balance covers 25.02 units and encodes the transaction.
2. Signing: Alice’s device signs the exact serialized transaction. The wallet can calculate a transaction identifier from the protocol-defined encoding.
3. Submission: The signed transaction is sent to a node. The node checks the signature, nonce, balance, format, and fee policy.
4. Propagation: Accepted peers relay the transaction. It appears in some mempools but not necessarily all of them.
5. Inclusion: A block producer selects it and places it at a particular position in a block. The state transition reduces Alice’s balance by the value and fee and increases Bob’s balance by 25 units.
6. Confirmation: Other blocks are added after the containing block. The transaction’s depth increases according to the network’s convention.
7. Finality: The application waits for the network’s required finalized or sufficiently confirmed status before treating the payment as settled.

If Alice’s transaction remains pending, possible causes include a low fee, a nonce gap, insufficient balance after an earlier transaction, temporary network congestion, or a node that did not relay it. If it is marked failed after inclusion, the fee may still be charged, depending on the protocol, even though the intended state change did not occur.

6. Applied Case: Investigating a Missing Transfer

This is an illustrative case. A logistics company pays a supplier using a stablecoin on a public blockchain. The supplier reports that the payment has not arrived.

Background and Problem

The finance team has a transaction identifier copied from the payment system. The supplier provides an address but does not specify the network. The payment dashboard shows “sent.”

Analysis

The investigator first identifies the network from the payment record and searches the transaction ID on a suitable explorer. The transaction is confirmed, but the recipient address displayed in the transaction differs from the supplier’s stated address. The transaction also transfers a token contract recognized by the company, so the issue is not a native-versus-token confusion. The explorer shows a successful transaction and a finality status accepted by the company’s policy.

The evidence indicates that the blockchain settlement succeeded, but the payment was sent to the wrong address. The explorer cannot identify who controls that address or reverse the transfer.

Approach and Outcome

The company preserves the transaction ID, block hash, screenshots or exported records, network name, token contract address, and timestamps. It checks the payment system’s address-book and approval logs, contacts the receiving service if the address belongs to an exchange or custodian, and begins its incident-response process. It does not claim that the explorer can recover the funds.

Learning Points

• “Sent” in an internal application is not the same as confirmed on-chain.
• The network and token contract must be verified.
• Address comparison should be exact and performed before signing.
• A successful transaction can still represent an operational error.
• Blockchain records provide evidence of state changes, not automatic identity or recovery.

7. Challenges, Governance, and Best Practices

7.1 Technical Limitations

Blockchains may experience congestion, delayed propagation, fee volatility, temporary forks, reorganization, smart-contract failures, and indexer outages. Different nodes can briefly present different transaction pools or chain tips. Explorers may simplify complex transactions and can mislabel addresses.

Scalability mechanisms also affect lifecycle interpretation. Layer-two systems may provide rapid local confirmation while posting compressed data or commitments to another chain. Users must distinguish the finality of the layer-two system from the finality of its settlement layer.

7.2 Privacy and Compliance

Public transaction data can be permanent and linkable. An address is not automatically anonymous; it is pseudonymous, and address clustering or external records may connect it to an individual or organization. Organizations should minimize unnecessary personal data in transaction payloads, apply access controls to internal address records, and assess data-protection obligations before embedding personal information on an immutable ledger.

Compliance teams should preserve evidence in a reproducible way: network identifier, transaction ID, block hash, relevant addresses, token contract, explorer URL, retrieval time, and the method used to verify the record. A screenshot alone may be insufficient for an audit.

7.3 Operational Best Practices

• Confirm the network, asset, recipient, amount, and fee before signing.
• Use hardware or otherwise protected key management for significant value.
• Test new destinations with a small transfer where appropriate.
• Treat mempool status as provisional.
• Define confirmation and finality thresholds by risk and network.
• Query more than one reliable data source for critical settlements.
• Maintain nonce, transaction, and approval records for business workflows.
• Never disclose seed phrases or private keys to an explorer, support agent, or application.
• Validate contract addresses and token decimals rather than trusting names alone.

Contemporary Developments

Modern blockchain systems increasingly separate execution, data availability, settlement, and consensus responsibilities. This modular architecture can alter what a user means by “confirmed.” A transaction may be executed by one component, ordered by another, and finalized through a settlement protocol. Wallets and explorers are consequently adding clearer labels such as pending, included, safe, and finalized.

Account abstraction and smart-contract wallets also change transaction creation. A user instruction may be transformed into a programmable operation, sponsored by another party, or authorized by multiple keys. The fundamental lifecycle remains—construct, authorize, propagate, validate, order, include, and finalize—but the signer, fee payer, and execution logic may no longer be the same entity.

Chapter Summary

Blockchain data structures provide commitments, ordering, and state representation. Transactions are signed instructions; blocks group transactions and link them through hashes; Merkle roots summarize transaction sets; and state-transition rules determine the ledger’s next state. A transaction progresses from creation and signing through propagation, validation, block inclusion, confirmation, and finality. Mempool presence is provisional, inclusion is stronger but may remain reversible, and finality depends on the network’s consensus model.

Explorers are valuable inspection tools, but they are interfaces to indexed public data rather than sources of consensus. Professional users should verify the network, transaction status, block information, asset contract, amount, recipient, and finality policy. Technical reliability must be combined with key security, privacy protection, governance controls, and careful operational procedures.

Key Terms

Block: An ordered protocol record containing a header and transaction or state data.

Block hash: A cryptographic digest identifying or committing to a block header.

Blockchain explorer: An interface for searching and interpreting public blockchain records.

Confirmation: Acceptance of a transaction in a block and, commonly, additional blocks built afterward.

Consensus: Rules and processes by which participants agree on an accepted chain or state.

Digital signature: Cryptographic evidence that a message was authorized by the holder of a private key.

Finality: The condition under which a transaction is considered irreversible under stated assumptions.

Fork: A divergence between competing chain histories or protocol rules.

Hash: A fixed-length digest produced from input data by a cryptographic hash function.

Mempool: A node’s collection of transactions awaiting possible block inclusion.

Merkle root: The top hash committing to a set or ordered structure of transaction hashes.

Nonce: A sequence value used for ordering or replay protection in many account-based systems.

Private key: Secret cryptographic material used to authorize transactions.

Propagation: Distribution of transactions or blocks among network peers.

Replay protection: Mechanisms preventing an authorized message from being reused improperly.

State: Ledger information required to evaluate future transactions.

State-transition function: Protocol logic mapping a valid prior state and transaction to a resulting state.

Transaction: A structured, authorized request to change blockchain state.

Unspent transaction output: A spendable output created by a prior transaction in an output-based ledger.

Review Questions

Short Answer Questions

1. What is the difference between a transaction pool and an accepted block?
2. Why does a blockchain use a previous-block hash?
3. What information does a digital signature establish?
4. Distinguish probabilistic finality from deterministic finality.
5. Name four fields that may be inspected in a blockchain explorer.

Long Answer Questions

1. Explain the complete transaction lifecycle from wallet creation to finality.
2. Describe how Merkle trees support efficient transaction inclusion proofs.
3. Compare account-based and unspent-output data models.
4. Explain why a transaction can be valid when created but later disappear from a mempool.
5. Discuss the limitations of blockchain explorers as evidence in an investigation.

Analytical / Application Questions

1. A payment dashboard says “sent,” but no explorer shows the transaction ID. Develop a structured diagnostic procedure and identify at least four possible causes.
2. An included transaction transfers tokens to an address different from the intended supplier address. Analyze what the blockchain proves, what it cannot prove, and what operational actions should follow.
3. Design a confirmation and finality policy for a business that processes both low-value retail payments and high-value international settlements. Explain how risk, network conditions, and reorganization possibilities affect the policy.

Multiple Choice Questions with Answers

Question 1

Which structure commits to an ordered set of transaction hashes using a single top-level digest?

A. Merkle tree

B. Mempool

C. Nonce table

D. Peer list

Correct Answer: A. Merkle tree

Question 2

What does a digital signature primarily demonstrate in a blockchain transaction?

A. That the transaction is legally valid

B. That the transaction was authorized by the relevant private key

C. That the transaction has achieved finality

D. That the recipient has received the funds

Correct Answer: B. That the transaction was authorized by the relevant private key

Question 3

Which event normally occurs before a transaction can be included in a block?

A. It must be displayed by every explorer

B. It must pass applicable validation rules

C. It must receive a second confirmation

D. It must be finalized by a regulator

Correct Answer: B. It must pass applicable validation rules

Question 4

What is the main purpose of a previous-block hash?

A. To conceal the transaction amount

B. To identify the wallet owner

C. To link the block to its predecessor

D. To calculate the user’s private key

Correct Answer: C. To link the block to its predecessor

Question 5

A transaction is visible in a node’s mempool but not in a block. What is the most accurate conclusion?

A. It is necessarily final

B. It is provisionally awaiting possible inclusion

C. It has already been permanently executed

D. It cannot be rejected by the network

Correct Answer: B. It is provisionally awaiting possible inclusion

Question 6

In the conceptual state equation S_t+1 = F(S_t, T_t), what does S_t represent?

A. The state before applying the transaction or sequence

B. The transaction signature

C. The block timestamp only

D. The explorer’s web address

Correct Answer: A. The state before applying the transaction or sequence

Question 7

Which item is especially important when investigating a token transfer?

A. Only the shortened token name

B. The token contract address and network

C. The color scheme of the explorer

D. The sender’s email password

Correct Answer: B. The token contract address and network

Question 8

What best describes probabilistic finality?

A. Reversal risk generally decreases as more blocks accumulate

B. A transaction is irreversible before validation

C. A regulator manually approves every block

D. A signature guarantees permanent inclusion

Correct Answer: A. Reversal risk generally decreases as more blocks accumulate

Question 9

Why can two individually valid transactions conflict in an account-based system?

A. They may use the same account nonce

B. They necessarily use different hash functions

C. They must belong to different blockchains

D. They cannot contain signatures

Correct Answer: A. They may use the same account nonce

Question 10

Which statement about a blockchain explorer is correct?

A. It is the consensus mechanism itself

B. It can reveal private keys when a transaction fails

C. It presents indexed blockchain data and may have interpretation limits

D. It can always reverse an incorrectly addressed transfer

Correct Answer: C. It presents indexed blockchain data and may have interpretation limits