Scalability, Performance and Operational Analytics

Introduction

A decentralized application (dApp) can be functionally correct yet commercially unusable. Users may face delayed confirmations, unpredictable transaction fees, congested networks, failed transactions, or slow data retrieval. These problems are not merely programming defects. They arise from the interaction of consensus protocols, block capacity, execution costs, data availability, network propagation, smart-contract design, wallet behaviour, and operational monitoring.

Scalability is the ability of a blockchain system to accommodate greater transaction volume, application complexity, and user demand without unacceptable deterioration in cost, latency, security, or decentralization. Performance concerns how efficiently a system responds under a specified workload. Operational analytics converts blockchain activity and infrastructure telemetry into evidence for decisions such as whether to batch transactions, move computation to a Layer 2 network, alter contract design, increase indexing capacity, or revise fee policies.

This chapter examines Layer 2 systems, optimistic and zero-knowledge rollups, sidechains, batching, caching, and the metrics required to operate dApps professionally. It also considers trade-offs: a solution that increases throughput may introduce new trust assumptions, bridge risks, liquidity fragmentation, or data-availability concerns.

Learning Objectives

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

1. Explain the scalability constraints of base-layer blockchains.
2. Distinguish state channels, sidechains, validiums, optimistic rollups, and zero-knowledge rollups.
3. Evaluate batching, caching, indexing, and RPC strategies.
4. Calculate and interpret throughput, latency, utilization, fee, and error metrics.
5. Design an operational dashboard using on-chain and off-chain evidence.
6. Make reasoned architecture and cost decisions under security and governance constraints.
7. Identify risks associated with bridges, sequencers, data availability, and misleading metrics.

1. The Scalability Problem

A blockchain must process transactions, verify state transitions, propagate blocks, retain historical data, and achieve agreement among distributed participants. These activities compete for limited resources. Increasing the block size may increase throughput, but it can also increase bandwidth, storage, and validation requirements. Higher resource requirements may reduce the number of independent participants able to operate full nodes, weakening decentralization.

The main performance dimensions are:

• Throughput: completed transactions or application operations per unit of time.
• Latency: elapsed time between submission and a defined confirmation condition.
• Finality: the point at which reversal becomes impossible or sufficiently improbable under the protocol model.
• Capacity: the maximum sustainable workload under specified resource and policy constraints.
• Cost: fees paid by users or the application operator.
• Reliability: the proportion of requests completed correctly and within an agreed service level.
• Data availability: the ability of relevant participants to obtain the data needed to reconstruct or verify state.

Throughput should be stated carefully. A chain may report transactions per second (TPS), but one transaction can represent a simple transfer or a complex contract call. Application-level operations per second may therefore be more informative than raw transaction count.

A basic throughput measure is:

where λ is average throughput in transactions per second, N is the number of completed transactions, and T is the observation interval in seconds. The measure assumes that the interval and completion rule are clearly defined. It does not describe peak throughput or transaction complexity.

For a block-producing system, an approximate capacity relationship is:

where C is capacity in transactions per second, B is usable block capacity measured in bytes or execution units, s is average resource consumption per transaction, and τ is block interval in seconds. This is an approximation: execution limits, transaction size, state-access patterns, validator policies, and demand can make the relationship nonlinear.

If a system processes 1,200 transactions during a 60-second observation period, its average throughput is 1,200 ÷ 60 = 20 transactions per second. This does not imply that every second contained exactly 20 transactions.

1.1 The scalability trilemma

A frequently used analytical model describes tension among decentralization, security, and scalability. It is not a mathematical theorem stating that only two can ever be achieved. Rather, it highlights resource and coordination trade-offs. Greater throughput may require larger blocks or more specialized infrastructure; these can increase the cost of validation and reduce the number of independent validators. Faster finality may require stronger assumptions about communication or validator participation.

Good engineering therefore asks: scalable for whom, under which workload, with what security model, and at what operational cost?

2. A Layered View of Blockchain Scaling

Scaling approaches can be classified into three broad groups.

1. Base-layer scaling: improving consensus, execution, storage, networking, or block capacity on the underlying chain.
2. Layer 2 scaling: processing transactions away from the base layer while using it for settlement, dispute resolution, or data publication.
3. Application and infrastructure scaling: reducing unnecessary work through batching, caching, indexing, request routing, and efficient contract design.

These approaches are complementary. A rollup may reduce settlement costs, while an indexer and cache reduce read latency. Neither replaces the other.

Figure: Scaling is distributed across settlement, execution, and application-operational layers.

3. Layer 2 Systems and Their Trust Models

A Layer 2 (L2) system is an execution environment associated with a base blockchain (Layer 1, or L1). The L2 usually processes many user operations, compresses or aggregates information, and periodically interacts with the L1. “L2” is a functional description, not a guarantee of decentralization or security. Evaluation must examine who orders transactions, where data is stored, how invalid activity is challenged, and how users exit.

3.1 State channels

A state channel allows a defined group of participants to transact off-chain after establishing an on-chain contract. Participants exchange signed state updates and later settle a final state on-chain. Channels can provide very low per-payment latency and cost when activity is frequent and participants are known in advance.

Limitations include the need for participants to remain online or use monitoring services, channel-liquidity constraints, complex routing for multi-party networks, and limited suitability for arbitrary composable applications.

3.2 Sidechains

A sidechain is a separate blockchain connected to an L1 through a bridge or other interoperability mechanism. It may use different validators, consensus rules, block intervals, and fee markets. Sidechains can offer high throughput and low fees, but their security is generally not inherited automatically from the L1. A compromised validator set, bridge, or governance process can threaten assets even when the L1 remains secure.

A sidechain is therefore not equivalent to a rollup. The relevant question is not simply whether transactions occur away from the L1, but how the L1 can verify or recover from an invalid sidechain state.

3.3 Rollups

Rollups execute transactions outside the L1 and publish sufficient information or cryptographic evidence to the L1. They usually inherit more security from the L1 than ordinary sidechains, but the exact guarantee depends on data availability, proof verification, upgrade keys, sequencing, withdrawal rules, and implementation maturity.

Rollup economics often involve a fixed L1 publication cost distributed across many transactions. If a batch has total publication cost F and contains n transactions, the average publication component is:

where fₚ is the average publication cost per transaction. This is only one component of total cost; execution fees, priority fees, bridge charges, and operator margins may also apply.

#### Optimistic rollups

Optimistic rollups generally assume that a proposed state transition is valid unless challenged during a dispute window. A fraud-proof mechanism allows a challenger to demonstrate an invalid transition. Their strengths include broad compatibility with existing smart-contract execution environments and relatively mature development tooling.

The principal operational concern is withdrawal delay. A user leaving to the L1 may need to wait for the challenge period unless a liquidity provider advances funds for a fee. Security depends on the existence of an effective challenge mechanism, accessible data, honest or watchful parties, and correctly implemented dispute logic.

#### Zero-knowledge rollups

Zero-knowledge (ZK) rollups attach a validity proof showing that a batch satisfies the specified state-transition rules. The L1 verifies the proof rather than replaying every transaction. In principle, a valid proof can reduce the need for a long fraud-challenge period.

Trade-offs include proving cost, hardware requirements, circuit complexity, proving latency, and compatibility with general-purpose virtual machines. “Zero knowledge” does not automatically mean private: many systems publish transaction data, and validity proofs primarily establish correctness rather than confidentiality.

#### Validiums and data-availability variants

Some systems publish validity proofs on the L1 but store transaction data off-chain. This can reduce cost, but users may be unable to reconstruct or exit from the latest state if the data provider withholds information. The distinction between a rollup and a validium is therefore principally a data-availability and security distinction, not merely a branding difference.

3.4 Sequencers and decentralization

Many L2 systems use a sequencer to order transactions. A sequencer can improve user experience, reduce latency, and simplify fee management. However, a centralized or permissioned sequencer can censor transactions, suffer outages, or create ordering and governance risks. An evaluation should record:

• whether users can force transactions through the L1;
• whether the sequencer can reorder or censor activity;
• how sequencer downtime is detected;
• whether there is a fallback proposer or escape hatch;
• who controls upgrades and emergency pauses.

4. Batching, Compression and Smart-Contract Efficiency

Batching combines multiple logical operations into one submission. For example, a payroll application can aggregate payments into a single contract call rather than issuing separate calls from the operator account. Batching reduces repeated transaction overhead, but it may increase calldata size, execution complexity, failure scope, and gas consumption within the batch.

Suppose each independent transaction has fixed overhead h and variable work v. A batch of n operations has approximate resource use:

Separate submissions have:

The model assumes that variable work is approximately additive and ignores nonlinear storage, memory, and event costs. Batching is beneficial when h_b + n×v < n×(h+v), but a very large batch may approach block or execution limits.

Batch design must address atomicity. In an all-or-nothing batch, one invalid item may revert the entire transaction. In a partial-success design, each item needs a clear result, replay protection, and event indicating success or failure. The contract should also protect against duplicate execution, malformed input, and denial-of-service through deliberately expensive items.

Other efficiency techniques include:

• packing data where safe and readable;
• reducing unnecessary storage writes;
• avoiding repeated external calls;
• using events for data intended primarily for off-chain indexing;
• separating settlement from high-frequency user-interface activity;
• choosing data structures with known access costs;
• estimating gas against realistic, not merely average, workloads.

Optimization should not compromise auditability. A small gas reduction is not worth introducing an untestable or opaque financial calculation.

5. Caching, Indexing and Read Performance

Blockchain state is often expensive to query directly. A dApp should distinguish authoritative state from derived read models.

• Direct node queries provide canonical data but may be slow, rate-limited, or difficult for complex historical queries.
• Indexers consume blocks and events, then build queryable databases. They improve read performance but introduce synchronization delay and data-reconstruction risk.
• Caches store recent or frequently requested results. They reduce latency and RPC load but may return stale information.

A cache policy should specify the freshness requirement. Immutable historical data can be cached for long periods. A token balance, liquidation status, or auction price may require short time-to-live (TTL) or block-aware invalidation.

If a cached value is served at time t and was generated at t₀, its age is:

where A is cache age in seconds if both times use the same clock. For blockchain data, block height is often safer than wall-clock time. A read may be labelled with the block number from which it was derived, allowing the client to detect whether it is behind the application’s minimum acceptable confirmation point.

Caching cannot be used to claim that a transaction has finalized. User interfaces should distinguish at least: submitted, included, confirmed, finalized, and indexed. A cache may improve display speed but cannot change the underlying settlement state.

6. Operational Metrics and Measurement Design

A metric is useful only when its definition, source, sampling interval, and failure conditions are known. Dashboards should avoid a single “TPS” number and instead present a set of related indicators.

6.1 Throughput and utilization

Average throughput is λ = N/T. For time-varying demand, let λ(t) represent throughput over a defined window. Report percentiles or distributions where appropriate rather than only averages.

Utilization compares actual demand with available capacity:

where U is utilization, D is demand or consumed resource per unit time, and C is sustainable capacity in the same units. Units must match. If demand is 700,000 gas units per second and sustainable capacity is 1,000,000 gas units per second, utilization is 0.70, or 70%. Sustained utilization close to 100% leaves little room for bursts and increases fee pressure.

6.2 Latency and service levels

For a transaction, submission-to-inclusion latency and inclusion-to-finality latency should be measured separately. If t_s, t_i, and t_f are submission, inclusion, and finality timestamps:

These formulas assume timestamps are comparable and the events are unambiguously observed. Report median, p95, and p99 latency where possible. Averages can hide congestion affecting a minority of users.

6.3 Reliability and errors

A basic success rate is:

where S is the number of successful operations and F is the number of failed operations within the defined period. The denominator must specify whether it includes dropped, replaced, reverted, timed-out, or user-cancelled requests.

Smart-contract reverts, RPC timeouts, nonce conflicts, underpriced transactions, sequencer errors, and indexer lag should be classified separately. Combining them into one error count prevents effective diagnosis.

6.4 Cost analytics

For a transaction using g gas units at a gas price p denominated in the native token, the fee is:

If the native token price is q currency units per token, then:

The units must be reconciled: if p is quoted in gwei, it must be converted to the native-token unit before multiplication. Cost reports should separate user-paid fees, subsidized fees, bridge fees, relayer costs, data-publication costs, and infrastructure costs.

6.5 On-chain and off-chain evidence

On-chain sources include blocks, transaction receipts, event logs, state changes, fee data, contract calls, and bridge messages. Off-chain sources include RPC response times, queue depth, sequencer health, indexer lag, cache hit rate, database load, memory consumption, and user-facing traces.

A log is not automatically a complete business record. Events can be emitted by contracts, but an indexer may be delayed or misconfigured. Reconciliation should compare event-derived records with authoritative state and, for critical systems, retain transaction hashes and block references.

7. Dashboard and Observability Design

A professional dashboard should answer four questions:

1. Is the system available?
2. Is it meeting performance targets?
3. Is it operating safely?
4. What action should the team take?

A practical dashboard may contain the following panels:

Metrics need labels such as network, contract version, method, wallet type, region, and transaction outcome. Excessive labels create high-cardinality monitoring costs and may expose personal information. Logs should avoid unnecessary addresses, private data, or sensitive business information.

Alert thresholds should reflect service objectives. For example, an alert may trigger when p95 inclusion latency exceeds a target for ten consecutive minutes, rather than when one transaction is slow. Alerts should include a runbook: owner, diagnostic queries, rollback or failover procedure, and communication plan.

8. Worked Application: Choosing a Settlement Architecture

Consider an illustrative digital-ticketing platform. It expects 90,000 ticket transfers during a three-hour event window. The existing L1 design submits one transaction per transfer. The average transaction uses 80,000 gas units, and the gas price is 30 gwei. Assume 1 gwei = 10⁻⁹ native tokens.

The average demand is:

At 80,000 gas per transaction, the average gas demand is:

This average may be feasible, but bursts near event opening can be much higher. The platform also pays repeated transaction overhead and exposes users to fee volatility.

The team evaluates three approaches:

• retain direct L1 settlement;
• batch transfers in a contract call;
• use an L2 rollup and periodically settle to the L1.

Batching can reduce repeated signature and submission overhead, but a single batch may become too large and an error could affect many ticket holders. The team therefore proposes batches of 500 transfers with per-item result recording and replay protection.

The L2 option lowers the L1 publication component per transfer, but the team must investigate withdrawal procedures, sequencer availability, bridge security, data availability, wallet support, and whether tickets must be transferable on the L1 during an outage.

The decision should not be based only on advertised TPS. The team creates acceptance tests:

• p95 submission-to-inclusion latency below the user-experience target;
• failed transfer rate below the agreed threshold;
• indexer lag below the ticket-display tolerance;
• demonstrated recovery from sequencer or RPC failure;
• verified reconciliation between ticket ownership and emitted events;
• transparent fee and subsidy accounting;
• an emergency method for proving ownership from canonical data.

A pilot is run under normal and burst workloads. The final choice is a hybrid: high-volume transfers use an L2, while critical administrative actions retain an L1 route. The application labels ticket status as pending, included, and finalized, rather than presenting an optimistic cache result as final ownership.

Learning points from the case

First, average demand is insufficient for capacity planning; burst demand and tail latency matter. Second, batching changes failure scope and must be designed with replay and partial-success rules. Third, L2 selection is a security and governance decision, not only a fee decision. Fourth, operational analytics must connect technical measurements with business outcomes such as successful ticket access and accurate ownership.

9. Challenges, Risks and Governance

9.1 Bridge risk

Bridges may hold large asset balances and implement message verification, minting, locking, and withdrawal logic. Common risks include compromised keys, incorrect validator assumptions, replay attacks, message-ordering defects, and upgrade abuse. A cheaper or faster bridge is not necessarily safer.

9.2 Data availability and censorship

If users cannot obtain the data needed to reconstruct state, proof verification alone may not protect them. Operators should document data providers, publication commitments, forced-inclusion mechanisms, and recovery procedures. Censorship resistance should be tested rather than inferred from marketing terminology.

9.3 Upgrade and administration risk

Admin keys, proxy contracts, emergency pauses, and sequencer controls can materially alter the trust model. Governance documentation should identify who can upgrade code, how delays are imposed, how users are notified, and whether independent review is required.

9.4 Privacy and regulatory considerations

Operational analytics may combine public wallet addresses with IP addresses, account identifiers, or behavioural profiles. Such data may become personal data under applicable law. Teams should minimize collection, control access, establish retention periods, and avoid exposing sensitive information in logs and dashboards. Financial, gaming, identity, and tokenized-asset applications may also face licensing, consumer-protection, tax, and transaction-monitoring requirements.

9.5 Metric gaming and incomplete measurement

A system can improve reported TPS by counting trivial operations, excluding failed requests, or measuring only internal sequencer acceptance. Teams should define denominators, publish methodology, and use independent measurements. Cost per successful business operation is often more meaningful than cost per submitted transaction.

10. Best Practices for Performance Engineering

1. Define the unit of work: transaction, contract call, transfer, or completed business operation.
2. Measure p50, p95, and p99 latency, not only averages.
3. Separate submission, inclusion, finality, indexing, and user-interface latency.
4. Load-test normal, burst, degraded, and recovery conditions.
5. Treat L2, sidechain, bridge, and sequencer assumptions as part of the threat model.
6. Use batching only with explicit limits, replay protection, and failure semantics.
7. Make cache freshness visible and never equate cached data with finality.
8. Reconcile indexer records with canonical chain data.
9. Attribute all costs, including L1 publication, relayers, infrastructure, and subsidies.
10. Use dashboards linked to runbooks and named operational owners.
11. Protect logs and analytics against unnecessary disclosure of personal information.
12. Reassess architecture as workload, protocol maturity, and governance arrangements change.

Contemporary Developments

Current scaling research increasingly combines execution sharding, modular data availability, validity proofs, shared sequencing, proof aggregation, and application-specific chains. These developments may reduce costs or improve interoperability, but they also increase architectural complexity. A modular system can optimize each layer independently while making incident diagnosis, governance, and user guarantees more difficult.

Artificial intelligence can assist with anomaly detection, log clustering, capacity forecasting, and incident summarization. It should not be treated as an authority for settlement truth. Models may hallucinate causes, miss rare attacks, or learn from biased operational history. Any AI-generated alert or recommendation should be tied to observable evidence, retain an audit trail, and remain subject to human review for security-critical actions.

Chapter Summary

Blockchain scalability is a multidimensional engineering and governance problem involving throughput, latency, finality, cost, reliability, decentralization, and data availability. Base-layer improvements, Layer 2 systems, batching, caching, indexing, and infrastructure optimization address different bottlenecks.

State channels support rapid interaction among defined participants. Sidechains can provide independent high-throughput environments but introduce separate validator and bridge risks. Rollups execute away from the base layer while using settlement and verification mechanisms on it. Optimistic rollups rely on challenge processes; ZK rollups rely on validity proofs. Neither category should be evaluated without examining data availability, sequencing, upgrades, withdrawal paths, and operational maturity.

Batching can lower repeated overhead but changes transaction size, failure scope, and replay requirements. Caches and indexers improve read performance but may be stale or inconsistent with canonical state. Operational analytics should measure throughput, resource utilization, latency percentiles, reliability, fees, queue depth, indexer lag, and security events using clearly defined denominators and units.

The professional objective is not to maximize a single TPS figure. It is to choose an architecture that meets business service levels while preserving appropriate security, transparency, recoverability, regulatory compliance, and user trust.

Key Terms

Scalability: The ability to accommodate increased workload while maintaining acceptable cost, performance, security, and decentralization.

Throughput: The number of completed transactions or operations per unit of time.

Latency: The time elapsed between two defined events, such as submission and inclusion.

Finality: The condition under which a transaction is considered irreversible or sufficiently irreversible.

Layer 2: An execution system associated with a base blockchain that processes activity away from the base layer.

State channel: An off-chain protocol in which participants exchange signed state updates and settle on-chain later.

Sidechain: A separate blockchain connected to another chain through interoperability mechanisms.

Rollup: A system that executes transactions off-chain and publishes data or proofs for base-layer settlement or verification.

Optimistic rollup: A rollup that treats proposed state transitions as valid unless successfully challenged.

ZK rollup: A rollup that uses a validity proof to demonstrate correct state transition execution.

Data availability: The ability of relevant parties to obtain data required to verify or reconstruct state.

Sequencer: A component that orders and often submits Layer 2 transactions.

Batching: Combining multiple logical operations into one transaction or submission.

Indexer: Software that transforms blockchain activity into queryable derived data.

Cache: Temporarily stored data used to reduce repeated computation or network requests.

Utilization: Actual resource demand divided by sustainable capacity.

Tail latency: High-percentile latency, commonly p95 or p99, experienced by slower requests.

Observability: The ability to understand system behaviour from metrics, logs, traces, and state evidence.

Bridge: Infrastructure that transfers assets or messages between distinct blockchain environments.

Service-level objective: A measurable target for availability, latency, reliability, or another service property.

Review Questions

Short Answer Questions

1. Define throughput and explain why raw TPS may be an incomplete performance measure.
2. What is the principal difference between a sidechain and a rollup?
3. Why can a cache improve user experience without proving transaction finality?
4. State the purpose of a sequencer in many Layer 2 systems.
5. Identify two risks introduced by batching transactions.

Long Answer Questions

1. Compare state channels, sidechains, optimistic rollups, and ZK rollups in terms of execution, settlement, security assumptions, and user-exit mechanisms.
2. Explain how throughput, latency, utilization, reliability, and cost should be combined in an operational dashboard.
3. Discuss the data-availability problem and its implications for rollups and validiums.
4. Develop a performance-engineering strategy for a dApp experiencing RPC failures, high indexer lag, and rising transaction fees.
5. Critically evaluate the claim that Layer 2 systems solve the blockchain scalability problem.

Analytical / Application Questions

1. A dApp completes 48,000 operations in 40 minutes. Calculate average throughput and explain what additional data is needed before declaring the system scalable.
2. An application has a p95 inclusion latency of 18 seconds but a p99 latency of 140 seconds during demand bursts. Recommend two operational and two architectural responses, justifying each.
3. Design a measurement and governance plan for selecting between direct L1 settlement, a sidechain, and a rollup for a high-value asset-transfer application.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an optimistic rollup?

A. It assumes proposed state transitions are valid unless successfully challenged.

B. It stores all state permanently on users’ devices without settlement.

C. It uses a separate validator set and cannot interact with a base layer.

D. It guarantees privacy because all transaction data is hidden.

Correct Answer: A. It assumes proposed state transitions are valid unless successfully challenged.

Question 2

A system completes 1,200 transactions in 60 seconds. What is its average throughput?

A. 12 transactions per second

B. 20 transactions per second

C. 60 transactions per second

D. 72,000 transactions per second

Correct Answer: B. 20 transactions per second

Question 3

What is a primary operational risk of a centralized Layer 2 sequencer?

A. It makes all cryptographic proofs mathematically impossible.

B. It prevents any transaction from being represented as an event.

C. It may censor transactions or suffer an outage.

D. It automatically eliminates data-availability requirements.

Correct Answer: C. It may censor transactions or suffer an outage.

Question 4

Which formula represents utilization when demand and capacity use the same units?

A. U = C / D

B. U = D + C

C. U = D − C

D. U = D / C

Correct Answer: D. U = D / C

Question 5

What is the main purpose of an indexer in a dApp architecture?

A. To replace the consensus protocol

B. To transform blockchain activity into queryable derived data

C. To guarantee that every transaction is final

D. To encrypt all public blockchain state

Correct Answer: B. To transform blockchain activity into queryable derived data

Question 6

If a transaction uses 50,000 gas units at 20 gwei, what is the fee in native tokens, assuming 1 gwei = 10⁻⁹ native tokens?

A. 0.001 native tokens

B. 0.0001 native tokens

C. 0.00001 native tokens

D. 1 native token

Correct Answer: C. 0.00001 native tokens

Question 7

Which statement about caching is correct?

A. A cache can reduce latency but may return stale data.

B. A cache changes the canonical blockchain state.

C. A cache guarantees finality immediately after submission.

D. A cache eliminates the need for reconciliation.

Correct Answer: A. A cache can reduce latency but may return stale data.

Question 8

Why can batching reduce transaction cost?

A. It removes the need for any validation.

B. It distributes repeated fixed overhead across multiple operations.

C. It guarantees that every item succeeds independently.

D. It makes block capacity unlimited.

Correct Answer: B. It distributes repeated fixed overhead across multiple operations.

Question 9

Which metric most directly measures the proportion of operations that completed successfully?

A. Cache age

B. Block interval

C. Success rate

D. Average gas price

Correct Answer: C. Success rate

Question 10

Which issue is especially associated with publishing validity proofs while storing transaction data off-chain?

A. Loss of all cryptographic verification

B. Inability to reconstruct or exit if required data is withheld

C. Guaranteed sequencer decentralization

D. Automatic elimination of bridge risk

Correct Answer: B. Inability to reconstruct or exit if required data is withheld