Blockchain Architecture and Transaction Lifecycle

Introduction

A blockchain is a distributed system for maintaining an ordered, tamper-evident record of state transitions. Unlike a conventional database, in which a trusted administrator controls writes, a blockchain uses cryptographic techniques, peer-to-peer communication, and a consensus protocol to enable multiple independent participants to agree on a shared history.

This architecture is foundational to Web3 and decentralised finance (DeFi). A token transfer, smart-contract interaction, lending operation, or decentralised exchange trade is ultimately represented as a transaction that is validated, ordered, executed, and recorded by a blockchain network. Understanding this lifecycle is essential for developers, auditors, analysts, and governance professionals.

A blockchain should not be understood simply as a database copied many times. Its design also addresses questions of identity, ordering, authority, incentives, fault tolerance, privacy, and finality. Different networks make different trade-offs among openness, performance, decentralisation, confidentiality, and governance.

Learning Objectives

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

1. Explain distributed ledgers, blocks, hashes, digital signatures, nodes, and consensus.
2. Describe the lifecycle of a blockchain transaction from creation to finality.
3. Distinguish deterministic transaction execution from consensus.
4. Explain gas, fees, state changes, and smart-contract execution.
5. Compare public, private, permissioned, and consortium blockchain models.
6. Evaluate finality, scalability, security, governance, and operational risks.

1. Distributed Ledgers and Blockchain State

A distributed ledger is a replicated record maintained by multiple network participants. Each participant may store all or part of the ledger and may independently verify proposed updates. Replication improves resilience, but replication alone does not create agreement. The network also requires rules determining which updates are valid and which ordering is authoritative.

A blockchain is a particular type of distributed ledger in which validated records are grouped into blocks. Blocks are linked cryptographically, normally by including the hash of the preceding block. The resulting chain makes unauthorised historical modification detectable.

A useful abstraction is:

Here, S_t is the ledger state before execution, T_t is an ordered transaction or transaction set, Γ is the deterministic state-transition function, and S_t+1 is the resulting state. The equation applies only when transactions are valid and the protocol specifies the same execution rules for all honest nodes.

The state may include account balances, smart-contract storage, ownership records, validator information, and other protocol data. The ledger history records how the state changed; the current state is the result of applying valid transitions in order.

Replication, validation, and agreement

Three ideas should be separated:

• Replication: multiple nodes hold copies or views of ledger data.
• Validation: nodes check whether transactions and blocks satisfy protocol rules.
• Consensus: nodes use a protocol to agree on the accepted ordering or canonical chain.

A network can replicate invalid data, so replication is not sufficient. Similarly, a transaction may be correctly signed but still rejected because it attempts to overspend, violates a contract condition, or uses an invalid nonce.

2. Blocks and Hash Linking

A block normally contains a header and a body. The header may include a parent-block hash, timestamp or slot information, transaction-root commitment, state-root commitment, and consensus-specific fields. The body contains transactions and, depending on the protocol, execution receipts, validator attestations, or other records.

A cryptographic hash function maps input data of arbitrary length to a fixed-length digest:

where m is the input message, H is the hash function, and h is the resulting digest. A secure hash function is expected to provide preimage resistance, second-preimage resistance, and collision resistance within its security assumptions.

Hashing does not encrypt information. A hash is generally public and one-way in practical conditions, although low-entropy inputs can sometimes be guessed by repeated hashing. Hashes provide integrity commitments: if a block’s contents change, its hash should change unpredictably.

If block B_i stores the hash of B_i-1, then changing an earlier block invalidates the link to its successor. In a proof-of-work system, an attacker may also need to redo computational work. In proof-of-stake and other systems, the attacker faces different protocol and economic barriers. Hash linking therefore provides tamper evidence, not an absolute guarantee that history can never change.

Merkle trees

Transactions are frequently committed through a Merkle tree. Transactions are hashed as leaves; pairs of hashes are repeatedly combined until one root remains. A Merkle proof can demonstrate that a transaction belongs to a committed set without transmitting every transaction.

If a parent node is calculated as H(h₁ ∥ h₂), where ∥ denotes concatenation, changing either child changes the parent and ultimately the root. The exact tree construction, handling of odd numbers of leaves, and proof format depend on the blockchain protocol.

3. Keys, Addresses, and Digital Signatures

Blockchain ownership is normally represented by control of a private key rather than by a legal name. A key pair consists of a private key and a mathematically related public key. An address is usually derived from the public key or from a script or account identifier; the derivation differs across platforms.

A digital signature provides evidence that the holder of a private key authorised particular data. Conceptually:

and verification checks:

Here, sk is the private key, pk is the public key, m is the signed message, and σ is the signature. The signature normally authenticates the transaction data, not the real-world identity of the signer. Identity attribution requires additional evidence and governance.

A valid signature does not prove that a transaction is economically sensible or legally authorised. It proves possession of the relevant signing key at the time of signing, subject to the cryptographic scheme and implementation. Private-key loss, theft, phishing, malicious approvals, and unsafe custody are therefore major operational risks.

Replay protection is also important. A transaction intended for one network or one sequence position should not be freely reused elsewhere. Mechanisms include chain identifiers, account nonces, transaction counters, and domain separation.

4. Nodes and Network Roles

A full node independently verifies protocol rules and maintains sufficient data to validate the chain. An archival node retains extensive historical state and can answer deeper queries. A light client verifies selected commitments or relies on proofs and trusted data sources rather than storing the complete ledger.

Other roles include:

• Block producer: proposes blocks under the consensus protocol.
• Validator: participates in proposing, attesting to, or voting on blocks.
• Peer or relay node: propagates transactions and blocks.
• RPC provider: exposes an interface through which applications submit transactions or query data.
• Indexer: transforms blockchain data into searchable application-oriented records.

These roles may be performed by separate infrastructure or combined by one operator. An application using a single RPC provider may appear decentralised while depending operationally on a central service. Infrastructure concentration is therefore a practical decentralisation concern.

5. Consensus and Fault Models

Consensus is the process by which network participants select an accepted history despite delays, failures, and potentially malicious actors. Consensus protocols normally specify leader selection, proposal, validation, voting or work, conflict resolution, and finality rules.

Proof of work

In proof-of-work systems, participants compete to find a value satisfying a computational target. The winning participant proposes a block, and the network follows a chain-selection rule. Security depends on the cost of computation and the assumption that an attacker cannot sustainably control sufficient mining power. Energy use, specialised hardware, probabilistic confirmation, and mining concentration are important considerations.

Proof of stake

In proof-of-stake systems, participants lock or are associated with stake and are selected to propose or attest to blocks. Protocol penalties may apply to provable misbehaviour, such as conflicting votes. Security depends on stake distribution, validator incentives, key management, network synchrony assumptions, and the design of slashing or recovery mechanisms.

Byzantine fault tolerance

Permissioned systems may use Byzantine fault-tolerant protocols in which known validators exchange messages and vote. A common family tolerates up to f Byzantine nodes when the total validator count is at least 3f + 1, under the protocol’s assumptions. This is not a universal rule for every consensus design; it describes a common bound for asynchronous or partially synchronous BFT models. A network with four validators can therefore commonly tolerate one Byzantine validator under such a model, but only if communication and protocol assumptions hold.

Consensus does not make false external data true. If an oracle submits an incorrect exchange rate, the blockchain may reach perfect agreement on that incorrect value. This is known as the oracle problem.

6. Transaction Lifecycle

A transaction typically passes through the following stages.

6.1 Construction

A wallet or application constructs transaction fields such as sender, recipient or contract address, value, calldata, nonce, fee parameters, chain identifier, and resource limit. The exact fields differ among protocols.

For a smart-contract call, calldata identifies the target function and encodes its arguments. Users should understand that signing calldata may authorise token transfers, approvals, governance votes, or other effects.

6.2 Signing and submission

The wallet signs the transaction with the private key. The signed transaction is sent to a node, often through an RPC endpoint. The receiving node checks basic validity, including signature, format, chain identifier, nonce, and fee-related requirements.

6.3 Mempool admission and propagation

A valid transaction may enter the node’s mempool, a temporary holding area for transactions awaiting inclusion. Mempools are local rather than universally identical. Different nodes may receive different transactions, apply different policies, or remove transactions at different times.

Transactions can be replaced, dropped, delayed, censored, or reordered according to protocol and node policies. A transaction visible in a wallet is not necessarily included in a block.

6.4 Proposal and ordering

A block producer selects transactions and proposes a block. Selection may consider fees, age, protocol rules, private order flow, or other policies. Ordering matters because transactions can interact. For example, a trade placed before another trade may obtain a different price, and an approval may need to precede a transfer.

6.5 Validation and execution

Other nodes verify the block, transaction signatures, ordering rules, resource limits, and resulting state transition. Smart-contract execution is normally deterministic: given identical initial state, transaction input, and protocol rules, honest nodes should calculate the same result.

Execution can succeed, revert, or exhaust its resource limit. A reverted transaction may still consume resources because nodes performed computation and the failure itself is part of the protocol outcome. A failed transaction generally does not apply its intended state changes, but exact behaviour depends on the platform and failure point.

6.6 Confirmation and finality

A block may first be considered included or confirmed according to local rules. It may later become final under a consensus mechanism. These concepts must be distinguished:

• Inclusion: the transaction appears in a proposed or accepted block.
• Probabilistic confirmation: the likelihood of reversal decreases as additional blocks build on it.
• Economic finality: reversing the transaction would impose substantial protocol or financial cost.
• Deterministic or protocol finality: under stated assumptions, the protocol declares the block irreversible except through exceptional governance or failure conditions.

Proof-of-work chains often provide probabilistic finality. Many proof-of-stake or BFT systems provide explicit finality after sufficient attestations. Finality is never independent of assumptions: network partitions, software defects, governance intervention, cryptographic compromise, or validator collusion can still create exceptional risks.

6.7 Settlement and application response

After inclusion, wallets and applications update their displayed status. Indexers may require additional time to process events. A merchant or DeFi protocol should define the finality threshold appropriate to the value and risk of the operation rather than relying solely on a user-interface label.

7. Gas, Fees, and Execution Economics

Gas is a unit of computational or operational work used by some blockchain platforms. It prevents unrestricted computation and helps allocate scarce block capacity. A transaction may specify a gas limit, the maximum resource units it is permitted to consume.

A simplified fee relationship is:

where G_used is gas consumed, measured in gas units, and P_gas is the price per gas unit. If gas is priced in a native currency denomination, the fee is denominated in that currency. Some networks separate a base fee from a priority fee; the exact mechanism is protocol-specific.

For example, if a transaction consumes 50,000 gas units at 20 gwei per unit, its fee is 1,000,000 gwei. Since 1 ether equals 1,000,000,000 gwei, the fee equals 0.001 ether. This calculation assumes the quoted gas price applies to all consumed gas and ignores any protocol-specific refund or fee-burning rules.

Gas is not the same as transaction value. A transaction transferring zero tokens may consume gas, while a transaction transferring a large value may consume relatively little gas. Contract complexity, storage writes, cryptographic operations, and network congestion influence resource consumption.

Users face a trade-off: too low a fee may delay inclusion, while too high a fee increases cost. Developers should minimise unnecessary storage writes, avoid unbounded loops, estimate gas conservatively, and test failure paths.

8. Public, Private, Permissioned, and Consortium Models

The labels overlap in industry usage, so classification should specify both access and governance.

A private chain may also be permissioned; a consortium chain is normally permissioned, but its governance is shared rather than controlled by one firm. The important analytical dimensions are read access, write access, validator admission, identity requirements, data visibility, finality, and dispute resolution.

Choosing a model

A public chain is appropriate when open participation, public verifiability, and composability are central. A permissioned or consortium chain may be preferable where participants are known, transactions contain commercially sensitive information, throughput requirements are predictable, or legal accountability requires identified operators. However, privacy is not automatically achieved by permissioning; replicated data may still be visible to every member. Techniques such as channels, private transactions, encryption, zero-knowledge proofs, or off-chain storage may be required.

9. Applied Case: A DeFi Lending Transaction

The following is an illustrative case, not a report of a specific company.

Background

A decentralised lending application allows users to deposit a stable-value token and borrow another asset against collateral. Smart contracts maintain balances, collateral ratios, interest calculations, and liquidation rules.

Problem

A borrower submits a transaction to deposit collateral and borrow funds. The borrower wants to know when the loan is safely established and what risks arise during execution.

Analysis

The wallet constructs a transaction calling the lending contract. It includes calldata, a nonce, a gas limit, a fee setting, and the chain identifier. The borrower signs it. Nodes verify the signature and nonce before propagating it.

A block producer includes the transaction. The contract checks that the collateral token transfer succeeds, updates the borrower’s position, reads an oracle price, calculates borrowing capacity, and records the debt. If the collateral ratio is insufficient, the transaction reverts. If the oracle data is stale or manipulated, the protocol may make an unsafe decision even though every node executes the same code correctly.

Suppose the transaction uses 180,000 gas at 15 gwei. The fee is:

The borrower must distinguish this execution fee from the borrowed amount, collateral value, interest, and possible liquidation penalty.

Approach and outcome

The application waits for the network’s appropriate finality threshold, verifies the transaction receipt and emitted events, and independently checks the updated contract state. A successful receipt indicates execution status, but risk management also requires checking the oracle source, collateral ratio, contract upgrade authority, and whether the transaction is final under the network’s consensus rules.

Learning points

1. A valid signature does not guarantee successful execution.
2. Gas pays for network execution, not for the economic value transferred.
3. Deterministic execution cannot correct inaccurate oracle data.
4. Finality policy should reflect transaction value and protocol risk.
5. Users and institutions must assess smart-contract, governance, custody, and infrastructure risks together.

10. Challenges, Governance, and Best Practices

Security and operational challenges

Major risks include private-key compromise, malicious smart contracts, re-entrancy, incorrect access controls, oracle manipulation, denial-of-service, bridge vulnerabilities, validator concentration, chain reorganisations, and RPC outages. Immutability can make errors difficult to reverse, so prevention, testing, monitoring, and incident response are essential.

Governance and regulatory considerations

Blockchain governance may involve protocol developers, validators, token holders, consortium members, service providers, and regulators. Upgrade keys and emergency controls create accountability questions: who can change the code, under what threshold, with what notice, and subject to what audit?

Permissionless networks may create obligations relating to anti-money-laundering controls, sanctions, consumer protection, custody, tax, data protection, and financial licensing. Legal treatment varies by jurisdiction. A blockchain record is not automatically a legal title, and code execution does not eliminate contractual or regulatory responsibilities.

Professional best practices

• Use hardware-backed or institutional key custody for significant assets.
• Verify chain identifiers, contract addresses, calldata, and permissions before signing.
• Run an independent node or use multiple RPC providers for critical systems.
• Define confirmation and finality thresholds by risk category.
• Audit contracts and test adversarial, failure, and upgrade scenarios.
• Monitor events, balances, oracle freshness, gas conditions, and chain health.
• Document governance, validator roles, data retention, and incident procedures.
• Minimise sensitive on-chain data; remember that public ledgers are usually permanent and observable.
• Treat bridges, oracles, indexers, and wallets as part of the application’s trust boundary.

Contemporary Developments

Current blockchain architecture increasingly separates execution, consensus, data availability, and settlement into specialised layers. Rollups execute transactions outside a base layer while publishing data or proofs for verification. Zero-knowledge systems can provide compact validity proofs and selective privacy. Account abstraction can make wallets programmable and support alternative authentication and fee-payment arrangements. These developments improve usability or scalability but introduce new assumptions involving sequencers, proving systems, data availability, bridges, and upgrade governance.

Artificial intelligence can assist with code review, anomaly detection, transaction classification, and operational monitoring. It should not be treated as a replacement for deterministic validation, formal security analysis, or human governance. An AI system may identify suspicious patterns, but the underlying blockchain still requires explicit protocol rules and accountable decision-making.

Chapter Summary

Blockchain architecture combines distributed replication, cryptographic commitments, digital signatures, peer-to-peer networking, consensus, and deterministic state-transition execution. Blocks group transactions and link to prior blocks through hashes; Merkle structures efficiently commit to transaction sets. Signatures authenticate control of keys but do not establish real-world identity or guarantee successful execution.

A transaction moves from construction and signing through propagation, mempool admission, block inclusion, validation, execution, confirmation, and finality. Gas allocates scarce computational capacity and produces fees, while smart-contract execution changes shared state according to protocol rules. Inclusion, probabilistic confirmation, and finality are distinct concepts.

Public, private, permissioned, and consortium models make different trade-offs among openness, privacy, performance, accountability, and governance. Effective blockchain design requires attention not only to cryptography and consensus but also to keys, oracles, bridges, RPC infrastructure, legal obligations, and organisational controls.

Key Terms

Distributed ledger: A replicated record maintained by multiple participants.

Blockchain: A distributed ledger that groups records into cryptographically linked blocks.

State: The current values maintained by a blockchain, including balances and contract storage.

State-transition function: The deterministic rule that maps prior state and valid transactions to new state.

Hash: A fixed-length digest produced from input data.

Merkle tree: A hash-based tree that commits efficiently to a collection of records.

Digital signature: Cryptographic evidence that a private key authorised particular data.

Private key: Secret cryptographic material used to create signatures.

Public key: Key used to verify signatures associated with a private key.

Node: Software or infrastructure that participates in storing, validating, relaying, or querying blockchain data.

Mempool: A node’s temporary pool of transactions awaiting inclusion.

Consensus: A protocol for agreeing on an accepted ledger history.

Validator: A participant that proposes, attests to, or votes on blocks.

Finality: The degree or condition under which an accepted transaction is not expected to be reversed.

Gas: A unit of computational or operational work used by certain blockchain protocols.

Nonce: A sequence or replay-protection value associated with transactions.

Oracle: A mechanism that supplies external data to a blockchain application.

Permissioned blockchain: A blockchain in which participation or validator roles require authorisation.

Consortium blockchain: A jointly governed blockchain operated by multiple organisations.

Smart contract: Program code deployed on a blockchain that executes according to protocol rules.

Review Questions

Short Answer Questions

1. What is the difference between replication and consensus in a blockchain network?
2. Why does changing a transaction usually alter a block’s hash?
3. What does a digital signature prove, and what does it not prove?
4. Distinguish transaction inclusion from finality.
5. Why can a transaction consume gas even when its intended contract operation reverts?

Long Answer Questions

1. Explain the complete lifecycle of a smart-contract transaction, from wallet construction to application settlement.
2. Compare proof of work, proof of stake, and permissioned Byzantine fault-tolerant consensus.
3. Evaluate the advantages and limitations of public, private, permissioned, and consortium blockchain models.
4. Explain how hashes, Merkle trees, signatures, and state roots contribute to blockchain integrity.
5. Discuss governance, privacy, oracle, key-management, and regulatory risks in a DeFi application.

Analytical / Application Questions

1. A lending transaction is signed successfully but reverts because the borrower’s collateral ratio is too low. Analyse which lifecycle stages succeeded and which state changes should occur.
2. An enterprise consortium requires identified participants, predictable finality, and restricted data visibility. Recommend an architecture and justify the trade-offs.
3. A high-value payment appears in a block but the network is experiencing a possible reorganisation. Design a confirmation and risk-management policy for the payment recipient.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a blockchain’s state from its transaction history?

A. State describes current ledger values, while history records the transitions that produced them.

B. State is stored only by wallets, while history is stored only by validators.

C. State is encrypted, while history is always unencrypted.

D. State refers only to block timestamps, while history refers only to signatures.

Correct Answer: A. State describes current ledger values, while history records the transitions that produced them.

Question 2

What is the primary purpose of including a previous block’s hash in a block header?

A. To encrypt all transactions in the block

B. To make alteration of linked historical data detectable

C. To identify the real-world owner of every transaction

D. To guarantee that the block has reached finality

Correct Answer: B. To make alteration of linked historical data detectable

Question 3

A valid digital signature primarily demonstrates that:

A. The transaction complies with every smart-contract condition

B. The signer is a government-verified person

C. The corresponding private key authorised the transaction data

D. The transaction will certainly be included in the next block

Correct Answer: C. The corresponding private key authorised the transaction data

Question 4

A transaction uses 50,000 gas units at 20 gwei per gas unit. Ignoring protocol-specific refunds, what is the fee?

A. 0.0001 ether

B. 0.001 ether

C. 0.01 ether

D. 1 ether

Correct Answer: B. 0.001 ether

Question 5

Which event most directly represents deterministic smart-contract execution?

A. A wallet displays an unsigned transaction

B. A node relays a transaction to a peer

C. Nodes apply the same transaction and protocol rules to calculate the same state result

D. A user estimates the market value of a token

Correct Answer: C. Nodes apply the same transaction and protocol rules to calculate the same state result

Question 6

What is the principal difference between probabilistic and deterministic finality?

A. Probabilistic finality depends on decreasing reversal likelihood, while deterministic finality is explicitly declared under protocol assumptions.

B. Probabilistic finality uses signatures, while deterministic finality uses no cryptography.

C. Probabilistic finality exists only on private chains, while deterministic finality exists only on public chains.

D. There is no meaningful difference between them.

Correct Answer: A. Probabilistic finality depends on decreasing reversal likelihood, while deterministic finality is explicitly declared under protocol assumptions.

Question 7

Which blockchain model is generally governed jointly by several participating organisations?

A. Public permissionless blockchain

B. Single-operator private blockchain

C. Consortium blockchain

D. Unreplicated local database

Correct Answer: C. Consortium blockchain

Question 8

What is a major limitation of a mempool as a representation of network-wide pending transactions?

A. Every node is required to have exactly the same mempool contents

B. Mempool contents are local and can differ across nodes

C. Mempools contain only transactions that are already final

D. Mempools cannot contain smart-contract transactions

Correct Answer: B. Mempool contents are local and can differ across nodes

Question 9

Why are oracle systems important in DeFi?

A. They generate users’ private keys

B. They provide external information to blockchain applications

C. They replace the consensus mechanism

D. They prevent all smart-contract bugs

Correct Answer: B. They provide external information to blockchain applications

Question 10

Under a common BFT model requiring at least 3f + 1 validators, how many Byzantine validators can a four-validator network commonly tolerate?

A. Zero

B. One

C. Two

D. Four

Correct Answer: B. One