Scalability and Performance Engineering

Introduction

A blockchain network is useful only when it can process transactions reliably, quickly, affordably, and with acceptable resource requirements. Scalability is therefore not simply a question of achieving a high transaction-per-second (TPS) figure. It involves a set of engineering trade-offs among throughput, latency, decentralisation, security, storage, bandwidth, computation, and cost.

A network that processes many transactions but requires every validator to operate expensive hardware may be fast but poorly decentralised. A network with low fees but delayed finality may be unsuitable for payments or trading. Similarly, increasing block size may improve short-term throughput while increasing propagation delays and the probability that smaller nodes fall behind.

This chapter develops a practical framework for evaluating blockchain performance. It examines key metrics, bottlenecks, block and fee design, and major scaling approaches: sharding, sidechains, state channels, rollups, plasma-like systems, validiums, and other Layer 2 architectures.

Learning Objectives

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

1. Distinguish throughput, latency, confirmation time, and finality.
2. Calculate and interpret basic blockchain capacity and fee metrics.
3. Explain how block size, block interval, propagation, computation, and state growth affect performance.
4. Evaluate scalability solutions, including sharding, sidechains, state channels, and rollups.
5. Compare Layer 1 and Layer 2 designs using security, cost, latency, and data-availability criteria.
6. Recommend a scaling architecture for a practical application while recognising its limitations and risks.

1. What Scalability Means in Blockchain Systems

In a conventional database, performance can often be improved by adding servers, using replication, caching, or partitioning. Public blockchains face an additional constraint: many independent nodes must be able to verify the same history. This creates a decentralisation–security–scalability tension.

A useful engineering model evaluates four dimensions:

• Throughput: how many transactions or computational units are processed per unit of time.
• Latency: how long a transaction takes to be included or confirmed.
• Finality: when reversal becomes impossible or sufficiently impractical.
• Resource efficiency: the bandwidth, storage, memory, computation, and energy required by nodes.

The term TPS must be used carefully. A simple payment transaction and a complex smart-contract transaction consume very different resources. Consequently, transactions per second is meaningful only when the transaction type, block limits, and measurement method are stated.

Throughput and capacity

If a block has a usable capacity of C transaction units, and blocks are produced every T_b seconds, the ideal capacity is:

where R_ideal is measured in transaction units per second. If average transaction size is s bytes and block payload capacity is B bytes, then:

These are upper bounds. Actual throughput is lower when blocks are not full, transactions have variable sizes, invalid or duplicated transactions consume processing effort, or the network experiences congestion.

For a workload with transaction arrival rate λ and sustainable service rate μ, stable operation generally requires:

If demand persistently exceeds capacity, a mempool grows, fees rise, and confirmation latency increases. This is a queueing effect rather than a defect specific to blockchain.

Latency and finality

A transaction may experience several delays:

1. Local creation and signature generation.
2. Propagation through the peer-to-peer network.
3. Waiting in the mempool.
4. Inclusion in a block.
5. Additional blocks, epochs, or attestations before finality.

For a simple probabilistic chain, a rough confirmation estimate is:

where L_wait is mempool and propagation waiting time, k is the number of confirmations required, and T_b is the block interval. This is an approximation, not a universal finality law. Some consensus systems provide deterministic or economic finality after a protocol-specific event, while others rely on increasing confirmation depth.

Latency has multiple meanings. Inclusion latency measures time to enter a block. Settlement latency measures time until a transaction is considered final. User-perceived latency includes wallet, bridge, exchange, and application processing time.

2. Performance Metrics and Measurement

Professional performance evaluation requires a defined workload and measurement boundary. A credible benchmark should specify:

• transaction type and average resource consumption;
• offered load and percentage of capacity used;
• block interval and consensus configuration;
• number and geographic distribution of nodes;
• hardware, network bandwidth, and storage system;
• inclusion, execution, and finality measurements;
• whether failed, reverted, or batched transactions are counted.

Core metrics

A benchmark should report distributions, not only averages. The 95th-percentile latency, for example, indicates the delay experienced by 95% of observations and can reveal congestion hidden by a mean value.

3. Sources of Blockchain Bottlenecks

Block size and block interval

Larger blocks can contain more transactions, but they require more time to transmit, validate, store, and recover after failure. Let B be block size in bits and W be effective link bandwidth in bits per second. The minimum transmission time is:

This excludes protocol overhead, competing traffic, validation, and network topology. If block propagation approaches the block interval, some nodes may receive a new block after another block has already been proposed. In some consensus systems, this increases stale-block or missed-vote risk.

A smaller block interval reduces waiting time in an uncongested network, but gives nodes less time to propagate and validate each block. Thus, block size and interval must be evaluated together rather than optimised independently.

Computation and execution limits

Smart-contract networks impose computation limits to prevent denial-of-service attacks. A transaction may be small in bytes yet expensive to execute. Ethereum-style systems express computational work using gas or a related execution unit. A block has a maximum execution budget, so capacity is constrained by the most limiting resource:

This is a conceptual bottleneck equation. The terms represent the sustainable capacity imposed by data, computation, bandwidth, state access, and storage. They must not be added as if they were identical units.

State access and storage

Reading and updating large state databases may cause random-access input/output, cache misses, and memory pressure. State growth also raises the cost of initial synchronisation. A protocol may have high transaction throughput but still be difficult to operate if its state expands rapidly.

Consensus overhead

Consensus requires communication, voting, signature verification, leader selection, or proof computation. In a permissionless network, security often requires redundancy. More validators may improve resilience but increase communication and coordination costs, especially when messages must be exchanged among many participants.

4. Block Size, Fees, and Resource Economics

A blockspace market allocates scarce inclusion capacity. When demand is below capacity, fees may be low. When demand exceeds capacity, users compete through fees, priority prices, or application-specific mechanisms.

If a transaction consumes g units of a resource and the price is p currency units per resource unit, then:

For a transaction with a base fee and a priority component, a simplified expression is:

The exact fee mechanism varies by protocol. The formula assumes the transaction is executed and that the quoted resource amounts are measured consistently. Some systems charge for bytes, signatures, execution steps, storage deposits, or combinations of these.

Worked example: capacity and fees

Suppose a block can contain 2,000,000 execution units, the block interval is 5 seconds, and an average transaction consumes 20,000 units.

If the resource price is 0.00002 tokens per execution unit, the resource fee is:

If demand rises to 30 transactions per second, required capacity is 600,000 units per second, while sustainable capacity is 400,000 units per second. The difference accumulates as queue growth unless demand falls, transactions are rejected, or the system scales.

Fee design and user experience

A good fee mechanism should make resource consumption visible, discourage spam, and provide predictable inclusion incentives. However, fee markets can disadvantage small users during congestion. Applications may use batching, fee sponsorship, account abstraction, or delayed settlement to reduce this burden.

Fees also influence decentralisation. If operating a validator becomes expensive, participation may concentrate among large operators. Conversely, excessively low fees can permit spam and increase storage costs without compensating node operators.

5. Main Scaling Strategies

Scaling strategies can be classified as Layer 1 scaling, which changes the base protocol, and Layer 2 or off-chain scaling, which moves some activity away from the base chain while retaining a defined settlement relationship.

5.1 Protocol and hardware optimisation

The simplest approach is to improve implementation efficiency: compact encoding, parallel signature verification, improved databases, transaction propagation protocols, caching, and pruning. These changes can provide substantial gains without changing the trust model. Their limitation is that optimisation cannot remove fundamental data-availability or verification requirements.

Increasing block capacity is also a Layer 1 strategy. It can raise throughput, but the decentralisation cost must be measured through propagation time, node hardware requirements, and synchronisation performance.

5.2 Sharding

Sharding partitions state and transaction processing among multiple subsets of validators or execution domains. Instead of every validator processing every transaction, a shard processes a portion of the workload. A coordination mechanism provides cross-shard communication and security.

If there are n equally capable shards, each with capacity r, an ideal upper bound is:

This assumes balanced workloads, low coordination overhead, and sufficient data availability. In practice, cross-shard transactions, uneven demand, validator assignment, and synchronisation reduce the gain.

Sharding improves parallelism but introduces complexity. Cross-shard transactions may require asynchronous messages, receipts, proofs, or delayed finality. A highly popular application can also create a hot shard, limiting effective system throughput.

5.3 Sidechains

A sidechain is a separate blockchain connected to a primary chain through a bridge or other interoperability mechanism. It may use a different consensus protocol, validator set, block interval, and fee model.

Sidechains can offer low fees and application-specific performance. Their principal limitation is that their security may not be inherited from the primary chain. Users must evaluate validator concentration, bridge custody, withdrawal rules, fraud handling, and governance.

A bridge is often the most vulnerable component. Even if both chains are secure individually, an incorrectly designed custody contract, validator federation, message verifier, or withdrawal process can cause catastrophic loss.

5.4 State channels

A state channel allows participants to transact off-chain after establishing an initial on-chain state. Parties exchange signed updates, and a final state is later submitted to the blockchain. The chain acts as an adjudicator if a participant behaves dishonestly.

Channels can provide very low latency and high transaction frequency between known participants. They are particularly suitable for repeated bilateral payments, gaming interactions, and machine-to-machine micropayments. Their limitations include capital or liquidity locking, participant coordination, channel routing, online availability requirements, and difficult multi-party workflows.

5.5 Rollups

A rollup executes transactions outside the base chain and posts compressed transaction data and/or a state commitment to the base chain. The base chain provides settlement and, depending on the design, data availability and dispute resolution.

#### Optimistic rollups

Optimistic rollups assume submitted batches are valid unless a challenger proves fraud during a challenge window. They require a fraud-proof mechanism and sufficient data for reconstruction. Withdrawals to the base layer may be delayed while the challenge period remains open.

#### Zero-knowledge or validity rollups

Validity rollups attach a cryptographic proof that the batch transition was correctly executed. The base chain verifies the proof rather than re-executing every transaction. They can provide strong finality after proof acceptance, but proof generation, circuit design, hardware requirements, and support for general computation may be complex.

Rollups reduce per-transaction cost through batching. If a batch has fixed overhead F, contains n transactions, and each transaction contributes average data cost d, the average data cost per transaction is:

The first term declines as the batch grows, although larger batches may increase proof, submission, or latency costs.

5.6 Validiums and data-availability alternatives

A validium uses validity proofs but stores transaction data outside the base chain, often with a specialised data-availability committee. This can reduce cost and increase throughput, but users must trust that data remains available. If operators withhold data, users may be unable to reconstruct or exit their state even when the validity proof is correct.

Data-availability committees, distributed storage, and erasure coding attempt to reduce this risk. Their security assumptions must be stated explicitly rather than treated as equivalent to base-layer data availability.

5.7 Plasma-like systems and application-specific chains

Plasma-like designs move state transitions off-chain while using the base chain for commitments and exits. They can be efficient but often require complex exit games and impose restrictions on supported applications.

Application-specific chains tailor execution, consensus, and data handling to one use case. This can produce strong performance, but the chain must establish its own validator security, liquidity, tooling, and bridge infrastructure.

6. Comparative Evaluation Framework

A selection decision should begin with application requirements rather than technology popularity. Important questions include:

• Must every transaction be independently recoverable from the base chain?
• Is delayed withdrawal acceptable?
• Are participants known or permissionless?
• Is the workload computational, data-heavy, payment-oriented, or interactive?
• What level of censorship resistance is required?
• Can users tolerate a bridge or committee trust assumption?
• What are peak demand, average demand, and acceptable 95th-percentile latency?

7. Applied Case: Scaling a Digital Ticketing Platform

Background

This illustrative case concerns a national event-ticketing platform issuing blockchain-based tickets. Each ticket transfer records ownership and must resist duplication. The platform expects 40 transactions per second normally and 400 transactions per second during popular event releases. Users require confirmation within 10 seconds, while final settlement may take several minutes.

Problem

A base chain processes only 25 ticket transactions per second under the required transaction complexity. During a release, the mempool grows rapidly, fees become unpredictable, and users submit repeated transactions. The platform also needs a reliable way to publish ticket ownership and prevent double spending.

Analysis

A single base chain cannot meet the peak workload. Increasing block size might provide additional capacity, but a tenfold increase could impose unacceptable requirements on public validators. A state channel is unsuitable because buyers are not known counterparties and ticket ownership must remain broadly verifiable. A sidechain could meet the throughput requirement, but its bridge and validator security would become critical.

A rollup is a stronger candidate because transfers can be batched, ownership commitments can be settled on the base chain, and the ticket application can use a specialised transaction format. The design must still address data availability, emergency withdrawals, proof generation, and congestion at the settlement layer.

Approach and solution

The platform adopts a rollup with compressed ticket-transfer transactions. The rollup posts state commitments and sufficient data for users to reconstruct ownership. A rate limit and queue are used during the busiest releases. The user interface displays separate statuses for accepted by the rollup, included in a batch, and final on the settlement chain.

To reduce spam, the platform uses sponsored fees with per-account limits and rejects duplicate submissions at the application layer. Independent monitoring measures batch size, submission delay, proof delay, state growth, and withdrawal performance.

Outcome

Normal and peak demand can be handled without requiring every base-layer validator to execute every ticket transfer. Fees become more predictable because many transfers share batch overhead. However, final settlement remains dependent on the base chain, and the platform must maintain a transparent emergency-exit process.

Learning points

1. Peak demand, not average demand, determines user-visible failure.
2. A scaling layer does not eliminate the need to analyse data availability and settlement congestion.
3. Application-level duplicate prevention complements, but does not replace, consensus security.
4. User interfaces must distinguish inclusion from finality.
5. Bridge, withdrawal, and governance procedures are part of performance engineering because failures in these components affect service availability.

8. Resource, Governance, and Security Trade-offs

Scaling can shift costs rather than remove them. A rollup reduces base-layer execution but adds proof generation, batch management, and data publication. Sharding reduces redundant execution but increases protocol coordination. Sidechains reduce cost for users but may concentrate validator power.

Governance must define who can upgrade contracts, pause bridges, change fee parameters, or alter sequencer behaviour. A centralised sequencer may provide excellent ordering performance but create censorship and availability risks. A decentralised sequencer may improve neutrality while adding coordination latency.

Ethically, system designers should disclose trust assumptions in accessible language. Users should not be told that a system is “secured by” a base chain if assets can be frozen by an external committee or if data is unavailable outside that committee. Regulatory requirements may also apply to custody, payments, consumer protection, financial market infrastructure, and data privacy.

Privacy introduces another trade-off. Publishing all transaction data improves auditability but may expose personal or commercial information. Zero-knowledge techniques can reduce disclosure, yet cryptographic privacy does not automatically solve metadata leakage, key loss, or legal access requirements.

9. Contemporary Performance Engineering Practices

Modern blockchain engineering increasingly uses:

• Batching: combining multiple operations to amortise fixed costs.
• Compression: reducing calldata, signatures, and repeated identifiers.
• Parallel execution: executing independent transactions concurrently, subject to conflict detection.
• Proposer–builder separation: separating block construction from proposal to improve market and execution efficiency, while introducing new trust and censorship considerations.
• Data-availability sampling: allowing nodes to test whether large data objects are available without downloading all data, subject to protocol assumptions.
• Modular architecture: separating execution, settlement, consensus, and data availability.
• Adaptive fee markets: adjusting prices to demand while preserving predictable inclusion rules.

These techniques should be evaluated experimentally. A claimed TPS improvement is not meaningful unless it states whether the result includes consensus, data publication, proof generation, failed transactions, and sustained operation.

10. Best-Practice Evaluation Procedure

A professional evaluation can follow this sequence:

1. Define workload classes, transaction sizes, execution complexity, and peak demand.
2. Identify the required inclusion and finality guarantees.
3. Measure current block, execution, bandwidth, storage, and state limits.
4. Locate the dominant bottleneck rather than increasing every limit indiscriminately.
5. Model queue growth when arrival rate exceeds service rate.
6. Compare scaling candidates by security inheritance, data availability, cost, latency, and operational complexity.
7. Test failure modes, including sequencer outage, bridge compromise, data withholding, validator churn, and reorganisation.
8. Report average and percentile metrics under sustained and burst workloads.
9. Document governance, upgrade authority, emergency procedures, and user exit paths.
10. Re-test after deployment because workload and fee-market behaviour change over time.

Chapter Summary

Scalability is a multidimensional engineering problem involving throughput, latency, finality, cost, decentralisation, security, and resource consumption. Ideal throughput can be estimated from block capacity and block interval, but actual performance is limited by computation, bandwidth, state access, storage, consensus, and demand variability. Larger blocks and shorter intervals may improve capacity while imposing propagation and node-operation costs.

Fees allocate scarce blockspace and usually depend on resource consumption and market demand. Sharding provides parallelism but introduces cross-shard coordination. Sidechains offer flexibility but may have independent security and bridge risks. State channels provide rapid repeated interaction for suitable participants. Rollups batch execution and settle commitments on a base chain; optimistic rollups rely on fraud challenges, while validity rollups rely on cryptographic correctness proofs. Validiums reduce cost by moving data availability outside the base chain but introduce additional trust assumptions.

A sound architecture begins with application requirements, measures peak as well as average demand, states its security and data-availability assumptions, and reports performance using reproducible workloads and percentile metrics. Performance improvements are valuable only when they preserve the guarantees required by users and the surrounding governance and regulatory environment.

Key Terms

Scalability: The ability of a system to handle increased workload while preserving required performance and security.

Throughput: Completed transaction or resource units processed per unit of time.

Latency: Time elapsed between an operation being submitted and a specified outcome.

Finality: The point at which a transaction is considered irreversible or economically impractical to reverse.

Block interval: Time between successive blocks.

Block capacity: Maximum data or execution work permitted in a block.

Mempool: A node’s collection of valid but not yet included transactions.

Queueing: Accumulation of pending work when demand approaches or exceeds service capacity.

State growth: Expansion of the persistent data required to represent current blockchain state.

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

Sharding: Partitioning processing or state across multiple coordinated domains.

Sidechain: An independent blockchain connected to another chain through interoperability mechanisms.

State channel: An off-chain interaction protocol whose state can be enforced or settled on-chain.

Rollup: A system that executes transactions away from the base layer and posts commitments and supporting data or proofs.

Optimistic rollup: A rollup that assumes batches are valid unless fraud is demonstrated.

Validity rollup: A rollup that submits a cryptographic proof of correct state transition.

Validium: A validity-proof system whose transaction data is stored outside the settlement chain.

Sequencer: A component that orders and batches transactions in many Layer 2 systems.

Bridge: Infrastructure that transfers assets or messages between blockchain domains.

Resource utilisation: The proportion of available computation, bandwidth, storage, or execution capacity being consumed.

Review Questions

Short Answer Questions

1. Distinguish throughput from latency and finality.
2. Why can increasing block size threaten decentralisation?
3. What is the purpose of a fee market?
4. State one major limitation of state channels.
5. How does a validity rollup demonstrate correct execution?

Long Answer Questions

1. Explain the main performance bottlenecks in a blockchain network and how they interact.
2. Compare sharding, sidechains, and rollups in terms of throughput, security, and complexity.
3. Explain why TPS figures must be accompanied by workload and measurement assumptions.
4. Discuss the relationship between block interval, propagation time, and confirmation latency.
5. Evaluate the governance and data-availability risks of Layer 2 systems.

Analytical / Application Questions

1. A network has a 1,500,000-unit execution limit per block, a 3-second block interval, and transactions averaging 15,000 units. Calculate ideal throughput and explain why actual throughput may be lower.
2. Select a scaling approach for a permissionless micropayment application involving millions of unrelated users. Justify the selection using latency, liquidity, data availability, and security criteria.
3. Design a performance benchmark for a blockchain ticketing system experiencing tenfold demand spikes. Specify workload, metrics, failure tests, and acceptance criteria.

Multiple Choice Questions with Answers

Question 1

A block has capacity for 2,000,000 execution units, blocks are produced every 5 seconds, and each transaction uses 20,000 units. What is the ideal throughput?

A. 10 transactions per second

B. 20 transactions per second

C. 40 transactions per second

D. 100 transactions per second

Correct Answer: B. 20 transactions per second

Question 2

Which metric measures the time until a transaction is considered irreversible or economically impractical to reverse?

A. Propagation bandwidth

B. Execution capacity

C. Finality latency

D. State growth

Correct Answer: C. Finality latency

Question 3

What is a major security limitation of many sidechains?

A. They cannot use smart contracts

B. They always require longer block intervals

C. They may have a separate validator and security model

D. They cannot connect to a base chain

Correct Answer: C. They may have a separate validator and security model

Question 4

What is the defining mechanism of an optimistic rollup?

A. Every transaction is mined directly on the base chain

B. Batches are assumed valid unless fraud is demonstrated

C. All transaction data is permanently kept off-chain with no proof

D. Validators are replaced by payment channels

Correct Answer: B. Batches are assumed valid unless fraud is demonstrated

Question 5

A transaction consumes 30,000 resource units priced at 0.00001 tokens per unit. What is its resource fee?

A. 0.03 tokens

B. 0.3 tokens

C. 3 tokens

D. 30 tokens

Correct Answer: B. 0.3 tokens

Question 6

Which scaling approach is most naturally suited to repeated interactions between known counterparties who can lock liquidity?

A. State channels

B. Global sharding only

C. A public block-size increase

D. A data-availability committee alone

Correct Answer: A. State channels

Question 7

If transaction arrival rate persistently exceeds sustainable service rate, what is the most likely immediate network effect?

A. Mempool growth and increased confirmation latency

B. Automatic elimination of all fees

C. Reduced state growth to zero

D. Guaranteed deterministic finality

Correct Answer: A. Mempool growth and increased confirmation latency

Question 8

What is the principal additional assumption introduced by a validium compared with a rollup that publishes data on the settlement chain?

A. Transactions cannot be batched

B. External data availability must remain reliable

C. Cryptographic proofs cannot be used

D. The base chain must execute every transaction

Correct Answer: B. External data availability must remain reliable

Question 9

Why can a shorter block interval fail to improve real-world performance?

A. It always prevents transaction batching

B. It gives nodes less time to propagate and validate each block

C. It eliminates the need for consensus

D. It necessarily increases transaction size

Correct Answer: B. It gives nodes less time to propagate and validate each block

Question 10

Which benchmark practice provides the most meaningful comparison between blockchain systems?

A. Reporting only the highest observed TPS

B. Using unspecified transactions on one powerful node

C. Reporting workload, resource assumptions, percentile latency, and finality conditions

D. Counting submitted transactions regardless of whether they execute

Correct Answer: C. Reporting workload, resource assumptions, percentile latency, and finality conditions