Blockchain Platforms and Protocol Selection

Introduction and Context

A decentralized application (dApp) is not defined only by its user interface or smart contracts. Its performance, security, governance, cost, legal exposure, and user experience are strongly determined by the blockchain platform on which it operates. Selecting a platform is therefore an architectural decision rather than a branding preference.

Blockchain platforms differ in several fundamental ways. Some are open to anyone and use economic incentives to coordinate unknown participants. Others restrict participation to approved organizations and prioritize confidentiality, predictable performance, and institutional governance. Platforms also differ in how they represent ownership, execute programs, reach agreement, charge fees, and establish finality.

This chapter develops a framework for comparing public, private, and consortium networks; account and unspent transaction output (UTXO) models; virtual machines; consensus mechanisms; transaction fees; finality; and platform-selection criteria. The objective is not to identify one universally superior blockchain. Rather, it is to match technical and organizational requirements with an appropriate protocol design.

Learning Objectives

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

1. Compare public, private, and consortium blockchain networks.
2. Explain account-based and UTXO-based state models.
3. Describe the role of virtual machines and smart-contract execution environments.
4. Distinguish major consensus mechanisms and their trade-offs.
5. Explain transaction fees, throughput, latency, and finality.
6. Apply a structured framework to select a blockchain platform.
7. Evaluate governance, privacy, regulatory, and operational implications.

1. Network Classes and Trust Assumptions

The most useful first distinction concerns who may participate in the network and who controls protocol decisions.

Public networks

A public, or permissionless, blockchain allows broad participation. In principle, an individual may read the ledger, submit transactions, and—subject to protocol rules—help validate blocks. Bitcoin and Ethereum are prominent examples.

Public networks are appropriate when:

• participants do not have a pre-existing trust relationship;
• censorship resistance and open verifiability are important;
• the application benefits from a large external ecosystem;
• digital assets must be transferable without a central operator.

Their costs include variable fees, public data exposure, uncertain governance, and the need to defend against Sybil attacks, in which one actor creates many identities. Public networks usually address Sybil resistance through resource expenditure, such as proof of work, or economic stake, as in proof of stake.

Private networks

A private blockchain is controlled by one organization or a tightly managed administrative authority. Participation, validation, and data access are restricted.

Private networks may provide:

• predictable transaction costs;
• high throughput and low latency;
• stronger confidentiality controls;
• simpler identity and compliance management.

However, a private network may provide limited decentralization. If one organization can rewrite records, exclude participants, or alter rules unilaterally, the system's trust model resembles a conventional database with additional replication and audit features. A private blockchain is justified when shared integrity and multi-system coordination are needed, but open participation is not.

Consortium networks

A consortium, or federated, network is governed by several identified organizations. Banks, logistics firms, universities, or government agencies may jointly operate validator nodes. No single member should normally control the ledger, although the consortium agreement defines admission, voting, upgrades, liability, and dispute resolution.

Consortium networks are especially useful when:

• participants are known but do not fully trust one another;
• business confidentiality is required;
• legal accountability is essential;
• members need shared infrastructure without surrendering governance to one firm.

The consortium model transfers some security responsibility from cryptographic incentives to legal, institutional, and operational arrangements.

A common design error is to select a public network merely because it is popular, even when the application requires confidential customer records. The opposite error is to call a replicated enterprise database a blockchain without identifying what decentralized trust problem it solves.

2. Ledger State Models

A blockchain must represent ownership and the current state of assets. Two influential approaches are the account model and the UTXO model.

Account model

An account-based ledger stores a state for each account. An account may contain a balance, a nonce, and—on programmable platforms—contract code and storage. A transaction changes the state from one valid configuration to another.

A simplified account transfer is:

where B_sender and B_receiver are the sender's and receiver's balances before the transaction, V is the transferred value, and F is the transaction fee. The equations assume a valid signature, sufficient funds, and successful execution. The prime symbol indicates the post-transaction balance. All values must use the same currency unit.

A nonce, or sequence number, prevents accidental replay of an old transaction and normally enforces an ordering of transactions from one account. Account models are intuitive for applications involving persistent identities, balances, and smart contracts. They also support a shared global state that contracts can read and modify.

Their challenges include state contention, more complex parallel execution, and the need to manage account nonces. If two transactions attempt incompatible updates to the same account or storage location, ordering matters.

UTXO model

In a UTXO ledger, value is represented by discrete outputs created by earlier transactions. An unspent output can be consumed exactly once as an input to a later transaction. The transaction must satisfy the rule:

The summation includes all input and output values in the transaction. The equality assumes no newly issued coins are being created; coinbase or issuance transactions require a modified conservation rule. Any difference between inputs and outputs is the fee.

For example, if a transaction consumes outputs worth 3.0 and 2.0 units, pays 4.2 units to a recipient, and returns 0.6 units as change, then:

3.0 + 2.0 = 4.2 + 0.6 + F

Therefore, F = 0.2 units.

UTXO designs make ownership transitions explicit and can support transaction validation in parallel when transactions use disjoint outputs. They also offer useful privacy patterns because a transaction may use newly generated addresses. However, users and wallets must manage change outputs, coin selection, and fragmented balances. Complex shared state is less direct than in an account model.

Comparison

Neither model is inherently more secure. Security depends on the complete protocol, implementation, wallet design, execution rules, and governance.

3. Virtual Machines and Smart-Contract Execution

A virtual machine (VM) is a deterministic execution environment that processes transactions or contract calls according to protocol rules. In blockchain systems, determinism is essential: honest validators must obtain the same result from the same input. A contract that depends on local time, random hardware behavior, or an external database without a consensus mechanism could produce divergent states.

A blockchain VM typically provides:

• an instruction set or bytecode format;
• persistent storage rules;
• a gas or resource accounting system;
• isolation between contracts;
• limits on computation and memory;
• rules for errors, reversion, and state changes.

Ethereum's Ethereum Virtual Machine (EVM) is a widely adopted stack-based execution environment. Other platforms use WebAssembly-based runtimes, transaction scripts, or purpose-built execution engines. EVM compatibility can reduce migration costs because developers may reuse languages, tools, wallets, and auditing practices. Compatibility does not eliminate differences in fees, finality, governance, precompiles, or security assumptions.

Determinism and resource limits

A validator must not be able to execute an unbounded loop indefinitely. Resource pricing limits computation. A simplified transaction-fee relationship is:

where F is the fee, G is the amount of computational resource consumed (for example, gas units), and P is the price per resource unit. The formula assumes one resource type and excludes additional data or priority charges. In systems with several resource types, the total fee may be modeled as:

where q_i is the quantity of resource i and p_i is its unit price. Resources may include computation, storage, bandwidth, and transaction data.

Suppose a call consumes 80,000 gas units at 25 gwei per gas unit. The fee is 2,000,000 gwei, or 0.002 native currency units because 1 native unit equals 1,000,000,000 gwei. This calculation assumes the transaction is included at the quoted price and that no separate priority or data fee applies.

Developers must also consider contract upgradeability, access control, re-entrancy, arithmetic errors, oracle manipulation, and denial-of-service risks. A powerful VM increases expressiveness but also expands the attack surface.

4. Consensus Mechanisms

Consensus is the process by which distributed participants agree on the order and validity of transactions. It should be distinguished from governance: consensus determines ledger agreement under protocol rules, while governance determines how those rules are selected or changed.

Proof of work

Proof of work requires participants to perform computational work to propose blocks. The probability of finding a block is related to computational power, and rewriting history requires substantial cumulative work. Its strengths include a long-established open-participation model and strong resistance to arbitrary identity creation. Its disadvantages include energy consumption, specialized hardware, probabilistic confirmation, and possible mining concentration.

Proof of stake

Proof of stake assigns proposal or validation responsibilities according to locked economic stake, often with penalties for conflicting or dishonest behavior. It avoids proof-of-work mining and can support explicit finality protocols. Risks include stake concentration, complex incentive design, governance capture, and implementation complexity.

Byzantine fault-tolerant protocols

Permissioned networks commonly use Byzantine fault-tolerant (BFT) protocols. Validators exchange messages and agree despite a bounded number of faulty or malicious participants. A classical Byzantine quorum model tolerates up to f faulty validators when:

where n is the total number of validators and f is the maximum number of Byzantine validators assumed by the protocol. The condition applies to a particular class of partially synchronous BFT protocols and is not a universal requirement for every consensus design. If n = 4, the system can tolerate f = 1 faulty validator under the stated assumptions.

BFT protocols can provide rapid, deterministic finality when communication and validator membership remain within designed limits. They may scale less effectively in very large open networks and depend on reliable identity management.

Delegated and authority-based systems

Delegated proof of stake and proof-of-authority systems use elected or approved validators. They can improve throughput and governance clarity but reduce the number of independent block producers. Their security depends heavily on validator selection, accountability, and resistance to collusion.

5. Fees, Performance, and Finality

Throughput and latency

Throughput is often expressed as transactions per second (TPS), but raw TPS is an incomplete measure. A platform may process simple transfers rapidly while handling complex contract calls slowly. Meaningful benchmarking should specify transaction type, payload size, validator configuration, concurrency, hardware, and whether the measurement concerns peak or sustained performance.

Latency is the elapsed time between submission and inclusion, or between submission and a confidence threshold. Congestion, propagation delay, fee bidding, and validator scheduling affect latency.

Finality

Finality describes when a transaction can be treated as irreversible under the protocol's assumptions.

• Probabilistic finality: the probability of reversal decreases as more blocks build on a transaction. This is common in proof-of-work systems.
• Economic finality: reversal would impose a substantial economic penalty, as in some proof-of-stake systems.
• Deterministic or absolute protocol finality: once a quorum commits a block, the protocol does not normally permit a conflicting finalized block unless assumptions are violated or governance intervenes.

Finality is not identical to inclusion. A transaction may be included in a block yet remain reversible. Applications should define a settlement policy based on value, threat model, and business consequences.

Fee markets

Fees may be fixed, administratively allocated, or market-based. In a market-based system, users compete for limited block space. A high fee may improve inclusion probability during congestion, but it does not guarantee execution if the transaction is invalid or the contract reverts. Enterprise networks may replace visible fees with quotas, subscriptions, or internal cost allocation; this changes the user experience but does not remove resource scarcity.

6. A Platform-Selection Framework

A disciplined selection process begins with requirements rather than platform popularity.

Step 1: Define the trust and governance model

Identify all participants, their incentives, legal identities, and ability to collude. Ask whether an independent operator is acceptable. If all validators belong to one company, a database may be cheaper and simpler. If several firms require shared control, a consortium may be appropriate. If unknown users must participate, a public network may be necessary.

Step 2: Classify data and privacy requirements

Determine which data must be public, restricted to members, encrypted, or kept off-chain. Never place personal data on an immutable ledger without considering data-protection obligations. A common architecture stores hashes, proofs, or references on-chain while retaining sensitive records in controlled systems.

Step 3: Specify execution requirements

Assess whether the application needs general-purpose smart contracts, simple validation scripts, asset issuance, private computation, cross-chain communication, or specialized cryptography. Examine VM maturity, language safety, debugging tools, audit experience, and upgrade mechanisms.

Step 4: Quantify workload and service levels

Estimate transaction volume, peak bursts, payload size, read/write ratio, acceptable latency, and settlement finality. The application should be tested under realistic conditions rather than relying on marketing claims.

Step 5: Evaluate economics

Estimate transaction fees, node operation, custody, monitoring, development, audits, upgrades, and incident response. For public networks, model fee volatility and currency-price exposure. For consortium systems, include membership and governance costs.

Step 6: Evaluate security and resilience

Review validator diversity, client diversity, key management, smart-contract vulnerabilities, oracle dependencies, bridge exposure, disaster recovery, and history of incidents. Consider whether the network can continue if one organization, cloud provider, or geographic region fails.

Step 7: Evaluate governance and compliance

Document who can upgrade the protocol, freeze assets, reverse transactions, admit validators, and resolve disputes. Assess jurisdiction, sanctions obligations, consumer protection, data retention, financial regulation, and auditability. Technical decentralization does not remove legal responsibility.

A weighted decision model can support comparison. If platform j receives score s_ij on criterion i, and criterion weight w_i satisfies Σ_i w_i = 1, then:

The score is a decision aid, not proof of technical suitability. Scores are only meaningful when criteria are defined consistently and critical constraints are treated as exclusion conditions rather than averaged away.

7. Illustrative Case: Inter-Organizational Pharmaceutical Traceability

Background

A group of pharmaceutical manufacturers, distributors, and hospitals wants to trace high-value medicines. Counterfeit detection and recall coordination are slow because organizations maintain separate databases. Participants require an auditable history, but commercial quantities and patient information must remain confidential.

Problem

A public ledger would expose commercially sensitive events and could create data-protection problems. A single private ledger would give one firm excessive control. The system also needs rapid confirmation and clear legal accountability.

Analysis

The participants are known organizations with partially aligned interests. They do not need anonymous global participation, but they do need shared control. A consortium network with identified validators is therefore more suitable than a permissionless chain. Product events can be represented as signed records, while personal data and detailed invoices remain off-chain. A hash or commitment can link an off-chain document to an on-chain integrity proof.

Approach and solution

The consortium establishes rules for validator admission, software upgrades, incident response, and dispute resolution. A BFT-style consensus protocol is selected because the validator set is known and the application needs rapid deterministic settlement. Each product unit receives a digitally signed identifier. Smart contracts validate authorized transfers and prevent a product record from being assigned simultaneously to incompatible owners.

The design uses an account-like registry for organizational identities and asset records, rather than treating confidential documents as public contract storage. Role-based permissions restrict who may read or submit particular event types. Independent audits test the contracts and key-management procedures.

Outcome

The architecture improves recall coordination and provides tamper-evident shared records without publishing sensitive business data. It does not eliminate the need for trusted physical inspections: a blockchain can preserve a claim that an event was recorded, but it cannot by itself prove that a physical shipment was genuine. Governance and audit procedures remain essential.

Learning points

1. The correct platform follows the trust model and data requirements.
2. Consortium governance is as important as consensus selection.
3. On-chain integrity does not guarantee off-chain truth.
4. Privacy is an architectural property, not merely a VM feature.
5. A database comparison should always be included in the business case.

8. Challenges, Limitations, and Best Practices

Blockchain projects face limitations that are sometimes obscured by performance claims. Decentralized replication increases coordination costs. Immutability can conflict with correction, deletion, and privacy rights. Oracles introduce external trust assumptions. Bridges and interoperability layers may become major attack surfaces. Smart contracts can make errors persistent and financially exploitable.

Best practices include:

• write a precise threat model before selecting a protocol;
• compare the proposed chain with a conventional database;
• separate public proofs from confidential business data;
• use independent smart-contract audits and formal reasoning where justified;
• design key rotation, recovery, and emergency procedures;
• test realistic workloads and failure scenarios;
• define finality operationally for each transaction class;
• document validator responsibilities and upgrade authority;
• monitor dependencies such as oracles, bridges, wallets, and cloud infrastructure;
• provide accessible user controls and avoid making users bear unexplained fee volatility.

Artificial intelligence may assist with code review, anomaly detection, test generation, and transaction monitoring, but AI-generated contract code must not be trusted without expert review. AI systems can reproduce insecure patterns, misunderstand protocol semantics, or produce unverifiable changes. Accountability remains with the developers and operators who deploy the system.

Contemporary Developments

Current platform design increasingly emphasizes modularity. Execution, consensus, settlement, and data availability may be separated into specialized layers. Layer-2 systems can execute transactions away from a base layer while periodically committing proofs or summaries to it. Rollups and other scaling designs may reduce costs, but they introduce new assumptions concerning sequencers, fraud proofs, validity proofs, withdrawal delays, and data availability.

Interoperability protocols are also becoming central to platform selection. A chain should not be evaluated only by its internal features; the security model of every bridge, messaging protocol, oracle, and custody system must be included. Likewise, environmental assessment should consider validator hardware, data-center operation, and the actual workload rather than relying on simplistic labels.

Chapter Summary

Blockchain platform selection is a structured architectural decision. Public networks maximize open participation and censorship resistance but may expose data and impose variable fees. Private networks provide administrative control and predictable operation, while consortium networks distribute governance among identified organizations.

Account models represent persistent balances and shared state; UTXO models represent discrete outputs consumed and recreated by transactions. Virtual machines make programmable execution possible but require determinism, resource limits, and careful security engineering. Consensus mechanisms differ in their assumptions about identity, economic resources, validator communication, and failure tolerance.

Fees reflect scarce computational, storage, and bandwidth resources. Throughput and latency must be measured using realistic workloads. Finality may be probabilistic, economic, or deterministic, and application designers must define what level of settlement is sufficient. A sound selection framework considers trust, privacy, execution, workload, economics, security, governance, compliance, and alternatives such as conventional databases.

Key Terms

Public network: A blockchain open to broad participation.

Private network: A blockchain controlled by one organization or authority.

Consortium network: A blockchain governed by multiple identified organizations.

Permissionless: Allowing participation without prior institutional approval.

Permissioned: Restricting participation through identity or authorization rules.

Account model: A state model that records balances and account storage.

UTXO: An unspent transaction output that can be consumed as a future transaction input.

Virtual machine: A deterministic environment for executing blockchain programs.

Smart contract: Program logic enforced by blockchain execution rules.

Gas: A unit measuring computational or other protocol resources.

Consensus: The process of agreeing on valid transaction order and state.

Proof of work: Consensus based on computational expenditure.

Proof of stake: Consensus based on economically committed stake.

Byzantine fault: Arbitrary or malicious participant behavior.

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

Throughput: The amount of work processed per unit of time.

Latency: Time between submission and inclusion or settlement.

Oracle: A mechanism that supplies external information to a blockchain.

Governance: Processes for making and changing protocol decisions.

Data availability: The ability of participants to obtain the data needed to verify state.

Review Questions

5 Short Answer Questions

1. What distinguishes a consortium network from a private network?
2. Why is determinism important in a blockchain virtual machine?
3. What is a UTXO?
4. Distinguish transaction inclusion from finality.
5. State two limitations of public blockchain networks.

5 Long Answer Questions

1. Compare public, private, and consortium networks in terms of trust, governance, privacy, and performance.
2. Explain account-based and UTXO-based state models, including their implications for smart-contract design.
3. Compare proof of work, proof of stake, and Byzantine fault-tolerant consensus.
4. Explain how fees, resource limits, throughput, latency, and finality interact in dApp design.
5. Develop a platform-selection framework for an enterprise blockchain project.

3 Analytical / Application Questions

1. A consortium of banks requires confidential settlement, identified validators, and rapid deterministic confirmation. Which network class and consensus approach would you recommend, and what risks remain?
2. An application stores personal records on a public blockchain. Analyze the privacy, governance, and regulatory concerns and propose an alternative architecture.
3. Two platforms have similar throughput: one has probabilistic finality and volatile fees; the other has deterministic finality and consortium governance. Explain which business requirements would determine the selection.

Multiple Choice Questions with Answers

Question 1

Which network type is governed by several identified organizations rather than one organization?

A. Public network

B. Private network

C. Consortium network

D. Personal database

Correct Answer: C. Consortium network

Question 2

In a UTXO model, an unspent transaction output is best described as:

A. A validator identity

B. A discrete value output available to be consumed

C. A smart-contract programming language

D. A block-finality certificate

Correct Answer: B. A discrete value output available to be consumed

Question 3

A transaction consumes inputs worth 5 units and creates outputs worth 4.6 units. Assuming no issuance, what is the fee?

A. 0.04 units

B. 0.4 units

C. 4.6 units

D. 9.6 units

Correct Answer: B. 0.4 units

Question 4

What is the primary reason blockchain virtual machines require resource accounting such as gas?

A. To guarantee anonymous identities

B. To prevent unbounded resource consumption

C. To replace digital signatures

D. To make all data confidential

Correct Answer: B. To prevent unbounded resource consumption

Question 5

Which consensus mechanism relies primarily on computational expenditure?

A. Proof of work

B. Proof of stake

C. Byzantine fault tolerance

D. Proof of authority

Correct Answer: A. Proof of work

Question 6

Under the stated classical BFT assumption, how many validators are required to tolerate one Byzantine validator?

A. 2

B. 3

C. 4

D. 5

Correct Answer: C. 4

Question 7

Which statement correctly describes probabilistic finality?

A. A transaction is irreversible immediately in every circumstance

B. Reversal probability generally decreases as additional blocks are added

C. Only consortium members can view the transaction

D. The transaction never requires a fee

Correct Answer: B. Reversal probability generally decreases as additional blocks are added

Question 8

If a transaction uses 80,000 gas units at 25 gwei per unit, what is the fee?

A. 0.0002 native units

B. 0.002 native units

C. 0.02 native units

D. 2 native units

Correct Answer: B. 0.002 native units

Question 9

Which factor should be considered when evaluating a blockchain platform?

A. Only the platform's brand recognition

B. Only its advertised peak TPS

C. Trust model, privacy, governance, workload, and security

D. Whether it uses the newest programming language

Correct Answer: C. Trust model, privacy, governance, workload, and security

Question 10

Why may a consortium pharmaceutical-traceability system keep detailed records off-chain?

A. Because hashes cannot be computed on blockchains

B. To reduce exposure of confidential and personal information

C. Because consensus cannot record any product event

D. To prevent validators from verifying transactions

Correct Answer: B. To reduce exposure of confidential and personal information