Blockchain

Chapter 4
Blockchain Architecture and Transaction Processing

Bachelors Program in IT
Blockchain   •   Bachelor

Blockchain Architecture and Transaction Processing

Introduction and Context

A blockchain is a distributed ledger maintained by a network of independently operated computers. Its architecture combines peer-to-peer networking, cryptographic authentication, transaction validation, consensus, and replicated data storage. Understanding transaction processing is essential because a blockchain is not simply a database: it is a protocol for deciding which state changes are acceptable and in what order they become authoritative.

A typical transaction moves through several stages:

  1. A user creates and digitally signs a transaction.
  2. A node receives and propagates it through the peer-to-peer network.
  3. Nodes validate it and place it in a mempool if it is currently acceptable but not yet included in a block.
  4. A block producer selects transactions and constructs a candidate block.
  5. The consensus protocol determines whether the block is accepted.
  6. Other nodes verify and append the block to their local ledger.
  7. Additional blocks increase confidence that the transaction will not be reversed.

This chapter compares major blockchain architectures and explains how transactions affect ledger state.

Learning Objectives

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

  • explain the roles of peers, full nodes, mempools, validators, and block producers;
  • describe transaction validation and block creation;
  • distinguish probabilistic and deterministic finality;
  • analyze forks, confirmations, fees, and ledger state;
  • compare UTXO and account-based models;
  • compare public, private, permissioned, layer-1, and layer-2 architectures;
  • evaluate practical, governance, security, and performance trade-offs.

1. The Blockchain System as a Layered Architecture

Blockchain systems are commonly analyzed in layers, although particular platforms organize these functions differently.

LayerMain responsibilityTypical examples
ApplicationUser-facing services and smart contractswallets, exchanges, decentralized applications
ExecutionRules for interpreting transactions and updating statevirtual machines, script interpreters
ConsensusAgreement about valid ordering and stateproof of work, proof of stake, Byzantine fault-tolerant protocols
DataBlocks, transactions, hashes, and state databasesMerkle trees, chain data, state tries
NetworkPeer discovery, propagation, and communicationgossip protocols, peer-to-peer connections

A blockchain node may perform several roles. A full node independently downloads and verifies relevant blockchain data. A lightweight client usually verifies only selected evidence, such as block headers or inclusion proofs. A validator or miner participates in block production according to the consensus protocol. A wallet manages keys and constructs transactions, but it need not store the complete ledger.

The distinction between verification and production is important. Every full node can verify a proposed block, whereas only selected participants may be authorized or economically motivated to produce one.

2. Peer-to-Peer Networking and Data Propagation

In a peer-to-peer network, nodes communicate directly rather than relying on one central server. Nodes discover peers, establish authenticated or semi-authenticated connections, exchange inventories of known objects, and request missing transactions or blocks.

Transactions and blocks are often disseminated using a gossip process. A node announces that it knows an object; neighboring nodes request it, validate it, and relay it to their own peers. Gossip improves resilience because there is no single distribution point, but it does not guarantee identical arrival times. Network delay can cause two honest nodes to see different transactions or competing blocks temporarily.

Important networking concerns include:

  • Latency: the time required for data to reach other nodes;
  • Bandwidth: the amount of data that can be transmitted;
  • Connectivity: the number and quality of a node's peers;
  • Eclipse attacks: attempts to isolate a node from honest peers;
  • Denial-of-service resistance: mechanisms that limit abusive traffic;
  • Privacy: the possibility of linking transactions to network identities.

A node should not treat receipt of a transaction as proof that it is valid or final. Reception is only the beginning of verification.

3. Transactions, Signatures, and Validation

A transaction is a signed instruction requesting a state transition. Its exact structure depends on the ledger model, but it commonly contains inputs or references, outputs or recipients, an amount, a fee, a nonce or sequence value, and a digital signature.

A digital signature provides authentication and integrity. If a private key signs a transaction, other participants can use the corresponding public key to verify that the transaction was authorized. Signatures do not by themselves prove that the sender has sufficient balance or that the transaction has not already been spent.

A node may apply the following validation sequence:

  1. Check that the transaction is correctly encoded.
  2. Verify the digital signature or signatures.
  3. Check that referenced inputs exist and are unspent, or that the sender's account nonce is correct.
  4. Verify sufficient funds and fee payment.
  5. Check script, smart-contract, or protocol rules.
  6. Check size, resource, and policy limits.
  7. Reject conflicts, such as double spending, according to the ledger model.

Validation has two dimensions. Consensus validity concerns rules that all conforming nodes must enforce. Relay policy concerns local choices about which valid transactions a node is willing to forward or store. A transaction can be valid under consensus rules but not relayed by a particular node because its fee is low or its format is considered risky.

UTXO and Account-Based Models

The unspent transaction output (UTXO) model represents value as discrete outputs. Each output specifies an amount and a spending condition. An input consumes a previous output, and new outputs are created. A UTXO can normally be spent only once.

For a transaction with inputs I and outputs O, conservation is expressed as:

Σ value(inputs) = Σ value(outputs) + fee

The summation applies to the transaction's selected inputs and outputs. The fee is the difference between input and output values. This identity assumes that no protocol rule creates additional value in that transaction; block rewards, if any, are handled separately.

Example: a wallet controls UTXOs worth 0.70 and 0.50 units. It pays 0.90 units to a recipient and specifies a fee of 0.01 units. The change output is:

change = 0.70 + 0.50 − 0.90 − 0.01 = 0.29 units

The account-based model stores a balance and commonly a transaction sequence number, or nonce, for each account. A state transition can be represented conceptually as:

statet+1 = Apply(statet, transactiont)

The function Apply is valid only when protocol rules are satisfied. For a simple transfer, the sender balance decreases by the amount and fee, while the recipient balance increases by the amount. The nonce prevents accidental or malicious replay of an old transaction and establishes an order for transactions from the same account.

FeatureUTXO modelAccount model
Fundamental objectUnspent outputAccount balance and state
Double-spend checkInput must be unspentBalance and nonce must be valid
Parallel verificationOften natural for unrelated outputsMay be limited by shared account state
ChangeUsually explicit change outputUsually unnecessary
Privacy potentialDifferent output addresses can improve separationActivity is often associated with an account
Smart-contract stateCommonly encoded in scripts and outputsOften represented directly in contract storage

Neither model is universally superior. UTXO systems offer explicit ownership objects and useful transaction-level parallelism, while account systems are often intuitive for programmable applications.

4. Mempools and Fee Markets

A mempool is a node's temporary collection of transactions that have passed local checks but have not yet been included in an accepted block. Mempools are not normally identical across the network because nodes receive transactions at different times, apply different policies, and may have different capacity limits.

A transaction in a mempool is not final. It may be evicted, replaced under permitted rules, or rendered invalid when another transaction spends the same resource. Applications should therefore distinguish between:

  • broadcast: sent to one or more nodes;
  • seen: observed by a node;
  • pending: accepted into a local mempool;
  • included: recorded in a block;
  • confirmed: included in a block with subsequent blocks extending the chain;
  • final: protected by the protocol's finality mechanism.

Fees compensate block producers and help allocate scarce block space. In a simple transaction, the fee is the difference between input and output value. In account-based systems, it is commonly specified explicitly in the transaction and deducted from the sender's balance.

Fee markets may be analyzed using fee rate rather than fee alone. For a transaction with fee F and size S:

fee rate = F ÷ S

If F is measured in the smallest currency unit and S in bytes or protocol-defined weight units, the fee rate has corresponding units such as units per byte. The fee rate is useful when block space is constrained, but actual inclusion also depends on transaction dependencies, local policy, and protocol rules.

High fees can exclude low-value users, while very low fees can increase delay. Good wallet software estimates fees transparently, allows users to select urgency, and prevents accidental overpayment.

5. Block Creation and Commitment to State

A block generally contains a header and a transaction body. The header may include a reference to the previous block, a timestamp or time-related field, a commitment to the transactions, consensus-specific data, and other metadata.

Transactions are often summarized using a Merkle tree. Hashes of transaction records are paired and hashed repeatedly until one root remains. If the number of records is not a power of two, the protocol must specify how the tree is constructed. The resulting Merkle root commits the block header to the transaction set, while a Merkle proof allows a verifier to check inclusion without downloading every transaction.

A block producer typically:

  1. selects transactions from its mempool;
  2. checks dependencies and resource limits;
  3. orders transactions according to protocol and economic incentives;
  4. constructs the transaction commitment;
  5. creates a candidate header;
  6. performs the required proof or obtains the required validator authorization;
  7. broadcasts the block.

Other nodes independently verify the block. They check the parent reference, transaction validity, state transition, commitment, consensus evidence, block size or weight, and any reward or fee rules. If valid, the node updates its local chain and state database.

In proof-of-work systems, a producer searches for a header satisfying a difficulty target. In proof-of-stake systems, a protocol selects or assigns proposers and uses attestations, votes, or certificates. Permissioned systems may use Byzantine fault-tolerant protocols in which known validators exchange messages and commit a block when a quorum is reached.

6. Forks, Confirmations, and Finality

A fork occurs when competing valid histories or rules produce different chain views. Forks can be temporary or intentional.

  • A temporary consensus fork may occur when two valid blocks are produced close together. The protocol later selects one history, and transactions in the other block may return to a mempool or become invalid.
  • A protocol fork changes the rules. A hard fork is not necessarily backward compatible; a soft fork tightens rules in a way designed to preserve compatibility for non-upgraded nodes under specified conditions.
  • A contention or governance fork may reflect disagreement about rules, upgrades, or chain identity.

A confirmation usually means that a transaction is included in a block and that additional blocks have been added after it. If a transaction is in block height h and the latest accepted block is at height H, a common convention counts confirmations as:

confirmations = H − h + 1

The formula is a convention; systems and explorers may display the count differently. It assumes a linear height-based chain and counts the transaction's own block as one confirmation.

In longest-chain or heaviest-chain systems, additional confirmations reduce but do not mathematically eliminate reversal risk. In a finality-based protocol, a transaction may become finalized after a protocol-defined certificate or quorum, subject to the protocol's assumptions. Finality depends on the consensus design, validator honesty, network assumptions, and possible governance intervention.

7. Ledger State and State Transitions

The ledger state is the information needed to determine which future transactions are valid. In a UTXO system it is the set of all currently unspent outputs. In an account system it includes balances, nonces, contract code, and contract storage.

A block transforms state according to an ordered sequence of transactions:

Si+1 = Ti(Si)

Here S_i is the state before transaction i, and T_i is the state-transition function for that transaction. For a block containing n transactions:

Sfinal = Tn(Tn−1(...T2(T1(S0))...))

The notation emphasizes that order can matter. Two transactions that touch independent UTXOs may commute safely, but two account transactions that update the same balance may produce different results in different orders. Smart contracts can create further dependencies through shared storage.

A state commitment, such as a root hash, allows nodes or clients to verify that a claimed state corresponds to a particular block history. It does not make an incorrect state correct; the transition rules and inputs must still be validated.

8. Architectural Comparisons

Public and Permissioned Networks

A public blockchain permits broad participation in reading data and often in submitting transactions. Validator participation may be open, subject to economic requirements, or delegated. Public systems emphasize censorship resistance and open verification, but they may face lower throughput, variable fees, public traceability, and difficult governance.

A permissioned blockchain restricts participation through organizational or administrative controls. It can provide known identities, faster finality, privacy controls, and predictable performance. However, it introduces trust in membership authorities and governance arrangements. A permissioned network is not automatically decentralized merely because it uses a replicated ledger.

Private and Consortium Networks

A private network is controlled by one organization. A consortium network is governed by several organizations. Both may use permissioned validators. These designs can suit inter-organizational workflows where participants need a shared record but cannot or do not wish to use a public chain.

Layer 1 and Layer 2

A layer-1 network provides the base ledger, consensus, data availability, and settlement. A layer-2 system processes some activity outside the base chain and uses the layer 1 for settlement, security, dispute resolution, or data publication.

Examples of layer-2 patterns include payment channels, rollups, and other state-transition systems. A rollup generally executes transactions away from the base layer and posts transaction data or commitments to it. Its security depends on the precise mechanism for data availability, fraud or validity proofs, withdrawals, operators, and upgrade authority. Layer 2 can improve throughput and reduce costs, but it adds bridging, operational, and composability risks.

ArchitectureMain strengthMain limitation
Public layer 1Open verification and broad neutralityCongestion, fees, and scalability constraints
Permissioned layer 1Governance and predictable performanceMembership and trust concentration
Layer 2Higher capacity or lower costAdditional protocol and bridge complexity
Private ledgerOrganizational control and confidentialityLimited external verifiability

9. Applied Case: University Credential Verification

The following is an illustrative case. A university wants employers to verify degree awards without exposing students' full academic records.

Background. The university currently issues paper certificates. Employers spend time checking authenticity, and forged documents occasionally appear.

Problem. The university needs integrity, selective disclosure, revocation, and a process that does not publish sensitive student information.

Analysis. Publishing a student's name, grades, and identifier on a public blockchain would create privacy and data-protection risks. A better design stores the credential off-chain in a digitally signed format and records only a cryptographic commitment or revocation reference on a permissioned or public settlement network. The student controls a wallet containing the credential. An employer verifies the university's signature and checks whether the commitment remains valid.

Approach. The university operates an issuing service. It signs a credential containing the degree, award date, and a student-controlled identifier. A hash or commitment is anchored to the ledger. Revocation status is represented by an updateable registry, subject to governance controls. The employer receives the credential directly from the student and verifies the signature, commitment, issuer identity, and revocation status.

Outcome. Verification becomes faster and paper forgery becomes more difficult. Nevertheless, the ledger does not solve every problem: the university must protect signing keys, define recovery procedures, comply with privacy law, and maintain the revocation service.

Learning points. A blockchain is most valuable when multiple parties need to verify a shared commitment. It should not be used as an excuse to publish personal data. Off-chain storage, key management, governance, and legal accountability remain essential.

10. Challenges, Governance, and Best Practices

Blockchain transaction processing faces several limitations:

  • throughput and latency may conflict with decentralization;
  • public ledgers can expose behavioral and financial patterns;
  • smart-contract errors may be irreversible or expensive to correct;
  • fee volatility complicates user experience;
  • bridges and layer-2 exit mechanisms create additional attack surfaces;
  • consensus systems consume resources and distribute influence unevenly;
  • governance disputes can produce contentious upgrades or forks.

Organizations should define who may operate nodes, who can upgrade software, how keys are secured, how incidents are handled, and how disputes are resolved. Regulatory requirements may include anti-money-laundering controls, consumer protection, data protection, financial licensing, and records retention. Immutability must be interpreted carefully: a ledger may make historical entries difficult to alter, but it does not guarantee that the original data was truthful, lawful, or correctly entered.

Best practices include:

  1. Select a blockchain only after identifying the trust and coordination problem.
  2. Keep confidential or personally identifying data off-chain unless there is a compelling, lawful reason otherwise.
  3. Run independent validation and monitoring infrastructure.
  4. Use hardware-backed key protection and documented recovery procedures.
  5. Test transaction replacement, reorganization, failure, and recovery scenarios.
  6. Display pending, included, and finalized states distinctly to users.
  7. Audit smart contracts and constrain upgrade authority.
  8. Measure capacity using realistic workloads rather than headline throughput.
  9. Document assumptions about validators, data availability, bridges, and finality.
  10. Treat AI-assisted coding or monitoring as support, not as a substitute for security review and human accountability.

Contemporary Developments

Current blockchain engineering increasingly emphasizes modularity. Execution, consensus, settlement, and data availability may be supplied by different components. This can improve specialization but makes system boundaries and trust assumptions harder to evaluate. Account abstraction seeks to make transaction authorization more flexible, including programmable recovery and sponsored fees. Zero-knowledge proofs can demonstrate that a computation or state transition was performed correctly without revealing all underlying data, although proving costs, trusted setup choices, and implementation complexity must be considered.

These developments do not remove the fundamental questions: who validates the state, who can change the rules, what information is available to users, and what happens when participants or components fail?

Chapter Summary

Blockchain architecture combines peer-to-peer networking, cryptographic authorization, transaction validation, consensus, and replicated state. Nodes propagate transactions through gossip and temporarily store acceptable transactions in local mempools. A block producer selects transactions, creates a commitment to them, and proposes a block. Other nodes independently validate the block and update their state.

The UTXO model tracks discrete unspent outputs, while the account model tracks balances, nonces, and often programmable storage. Fees allocate scarce block space, and confirmations indicate inclusion and subsequent chain extension; finality depends on the consensus mechanism. Forks may be temporary or arise from protocol and governance disagreements.

Public, private, permissioned, layer-1, and layer-2 architectures make different trade-offs among openness, performance, privacy, governance, and complexity. Effective blockchain design requires more than choosing a data structure: it requires explicit assumptions about trust, security, privacy, regulation, operations, and failure recovery.

Key Terms

Blockchain: A replicated ledger maintained by a network under defined validation and consensus rules.

Peer-to-peer network: A network in which nodes communicate directly without one central server.

Full node: A node that independently verifies blockchain data and protocol rules.

Mempool: A node's temporary collection of valid, unconfirmed transactions.

Digital signature: Cryptographic evidence that a transaction was authorized by a private key.

UTXO: An unspent transaction output that can be consumed by a later transaction.

Account model: A ledger model based on balances, nonces, and often contract storage.

Nonce: A sequence value used to order transactions or prevent replay.

Block: A structured group of transactions and metadata accepted by the consensus process.

Merkle root: A hash commitment summarizing a block's transaction set.

Consensus: The process by which nodes agree on an accepted ledger history.

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

Confirmation: Inclusion of a transaction in a block and, conventionally, subsequent block depth.

Finality: The degree to which a committed transaction is protected from reversal.

Fee market: The process through which users compete for limited block space.

Ledger state: The information required to determine valid future transactions.

Permissioned blockchain: A blockchain whose participation is restricted by access controls.

Layer 1: The base blockchain providing core settlement and consensus.

Layer 2: A system that processes activity above or outside the base layer while relying on it in specified ways.

State transition: The transformation of one valid ledger state into another by applying a transaction.

Review Questions

Short Answer Questions

  1. What is the purpose of a blockchain mempool?
  2. How does a digital signature contribute to transaction validation?
  3. Define a temporary consensus fork.
  4. What is the difference between a public and a permissioned blockchain?
  5. Why is a Merkle root included in a block?

Long Answer Questions

  1. Explain the complete lifecycle of a transaction from wallet creation to confirmation.
  2. Compare UTXO and account-based models, including their treatment of double spending, ordering, and state.
  3. Explain how block producers and full nodes perform different but complementary roles.
  4. Discuss the advantages and limitations of layer-2 architectures.
  5. Analyze the governance, privacy, and security issues in the university credential case.

Analytical / Application Questions

  1. A transaction has inputs of 2.4 and 1.1 units, outputs of 2.8 and 0.5 units, and no other issuance. Determine whether it satisfies the conservation rule and calculate the implied fee.
  2. Design a transaction-processing policy for a busy public network that must balance fee revenue, fairness to low-value users, and resistance to denial-of-service attacks.
  3. An organization is considering either a public blockchain or a consortium blockchain for inter-company invoice settlement. Recommend a choice and justify it using trust, privacy, governance, finality, and operational criteria.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a mempool?

A. A permanent archive of every historical transaction

B. A node's temporary collection of acceptable but unconfirmed transactions

C. A cryptographic key used to sign blocks

D. A list of only finalized transactions

Correct Answer: B. A node's temporary collection of acceptable but unconfirmed transactions

Question 2

In a UTXO transaction, inputs total 5 units and outputs total 4.97 units. Assuming no special issuance, what is the fee?

A. 0.03 units

B. 0.97 units

C. 4.97 units

D. 5.03 units

Correct Answer: A. 0.03 units

Question 3

Which item primarily prevents replay of an old account-based transaction?

A. Merkle root

B. Nonce

C. Block timestamp

D. Peer address

Correct Answer: B. Nonce

Question 4

What does a Merkle root primarily provide?

A. A commitment to the transactions in a block

B. A guarantee that every transaction is final

C. A replacement for digital signatures

D. A list of validator identities

Correct Answer: A. A commitment to the transactions in a block

Question 5

A transaction is in block height 120, and the latest accepted block is height 124. Using the convention in this chapter, how many confirmations does it have?

A. 4

B. 5

C. 120

D. 124

Correct Answer: B. 5

Question 6

Which statement correctly compares consensus validity and relay policy?

A. They are always identical for every node

B. Relay policy may reject or delay a transaction that consensus rules would permit

C. Consensus validity applies only to wallets

D. Relay policy determines the blockchain's cryptographic hash function

Correct Answer: B. Relay policy may reject or delay a transaction that consensus rules would permit

Question 7

Which architecture normally restricts participation through organizational access controls?

A. Permissioned blockchain

B. Open public blockchain

C. Unmanaged peer-to-peer file system

D. UTXO model

Correct Answer: A. Permissioned blockchain

Question 8

What is a principal risk of publishing personal academic records directly on a public blockchain?

A. The records become too easy to delete

B. Permanent or broadly visible exposure can conflict with privacy requirements

C. Digital signatures stop working

D. The network cannot calculate fees

Correct Answer: B. Permanent or broadly visible exposure can conflict with privacy requirements

Question 9

What is a key characteristic of a layer-2 system?

A. It always replaces the layer-1 consensus mechanism

B. It processes some activity above or outside layer 1 while relying on it in specified ways

C. It cannot use cryptographic proofs

D. It is necessarily permissioned

Correct Answer: B. It processes some activity above or outside layer 1 while relying on it in specified ways

Question 10

Which statement about additional confirmations in a longest-chain system is most accurate?

A. They always make reversal mathematically impossible

B. They generally reduce reversal risk but do not necessarily eliminate it

C. They invalidate the transaction's signature

D. They remove the transaction from the ledger

Correct Answer: B. They generally reduce reversal risk but do not necessarily eliminate it
Blockchain
Chapter 4 of 15