9. Scalability, Interoperability and Infrastructure

Introduction and Context

A blockchain system is useful only when it can process transactions at a speed, cost, reliability, and level of assurance appropriate to its intended environment. Early blockchain networks demonstrated that decentralised consensus could support digital value transfer without a central operator, but they also exposed a fundamental tension: increasing throughput, reducing latency, preserving decentralisation, and maintaining strong security are difficult to achieve simultaneously. This tension is often described through the blockchain trilemma, although it is better understood as a set of engineering trade-offs rather than an absolute law.

Scalability concerns the ability of a network or application to handle increasing transaction volume without unacceptable deterioration in performance or cost. Interoperability concerns the exchange of assets, messages, proofs, and state across otherwise separate blockchain systems. Infrastructure includes the technical and organisational services that support blockchain deployment, including validators, nodes, data-availability systems, custody services, monitoring platforms, cloud environments, and blockchain-as-a-service platforms.

The central question is not simply whether a system is fast. A high-throughput network that depends on a small and vulnerable validator set may have poor resilience. A bridge that transfers assets rapidly but cannot verify the source chain securely may create catastrophic systemic risk. Similarly, a rollup that reduces execution costs but publishes insufficient transaction data may not provide meaningful recovery or user exit guarantees. Evaluation must therefore consider performance, resilience, cost, security, governance, and operational complexity together.

Learning Objectives

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

1. Explain the scalability problem and distinguish Layer 1, Layer 2, sidechain, channel, and off-chain approaches.

2. Compare payment channels, state channels, optimistic rollups, zero-knowledge rollups, validiums, and sharding.

3. Evaluate cross-chain protocols and bridges using trust, liveness, finality, and failure-domain criteria.

4. Explain data availability and its relationship to rollup security and user recoverability.

5. Assess blockchain infrastructure and blockchain-as-a-service using performance, resilience, cost, and governance metrics.

6. Analyse a blockchain architecture for a realistic organisational or industry use case.

7. Identify security, regulatory, ethical, and operational risks in scalable and interoperable systems.

9.1 The Scalability Problem as a Systems Problem

Blockchain scalability has at least three dimensions. Transaction throughput is the number of transactions processed per unit of time. Latency is the time required for a transaction to be accepted or considered final. Resource efficiency concerns the computation, storage, bandwidth, and energy required by nodes and users. A system may improve one dimension while weakening another. For example, increasing block size can increase throughput but may raise hardware requirements, reducing the number of parties able to operate full nodes.

A useful analytical model separates the transaction lifecycle into execution, ordering, consensus, data publication, settlement, and user confirmation. In a conventional monolithic chain, the same validator set performs most of these functions. This simplifies the security model but creates a bottleneck: every validator may need to receive, store, execute, and verify every transaction. Scaling the base layer by increasing block capacity can therefore impose substantial costs on node operators.

Performance should be measured under realistic conditions rather than by theoretical maximums. Important indicators include:

• sustained transactions per second rather than short-duration peaks;
• median and tail latency, especially the ninety-fifth or ninety-ninth percentile;
• confirmation and finality time;
• transaction-fee volatility and cost per successful transaction;
• node hardware, bandwidth, and storage requirements;
• recovery time after failure or network partition; and
• degradation under adversarial load.

The distinction between probabilistic finality and deterministic or economic finality is also important. In some systems, the probability of a reversal becomes smaller as additional blocks are added. In others, a consensus decision is final once a supermajority has committed it, subject to protocol assumptions. Cross-chain applications must account for the exact finality model of every connected chain.

9.2 Scaling Above the Base Layer

Layer 2 Systems

A Layer 2 system processes transactions away from the base blockchain while using the base layer for some combination of settlement, dispute resolution, data publication, or security. The principal design goal is to reduce the amount of computation and state growth that the base chain must perform directly.

Layer 2 systems do not all provide the same security. Some inherit substantial security from the base layer because transaction data and validity evidence are posted there. Others rely on separate validators, operators, or committees and are more accurately described as independent systems connected to the base chain. The term Layer 2 should therefore be evaluated functionally rather than accepted as a guarantee.

Payment and State Channels

A payment channel allows participants to transact off-chain after establishing an on-chain funding transaction. The parties exchange signed updates representing the current allocation of funds. Only the opening and closing, or a dispute, need to be recorded on the base chain. A network of payment channels can support repeated small payments with low marginal cost.

State channels generalise this idea beyond payments. They can represent game actions, contractual states, or other deterministic transitions. The main limitations are capital lock-up, the need for participants to monitor the chain, routing difficulties in multi-party networks, and challenges when participants are intermittently offline. Watchtowers or delegated monitoring services can submit protective transactions, but they introduce additional operational and trust considerations.

Channels are most appropriate where participants interact repeatedly, the state transition rules are well defined, and disputes can be resolved on-chain. They are less suitable for open-ended applications in which users interact with many unknown parties and require immediate global liquidity.

Rollups

Rollups execute transactions outside the base chain and periodically submit a compressed representation of transactions, state commitments, and supporting information to the base chain. The base chain acts as the settlement and security anchor. Two principal families are optimistic rollups and zero-knowledge rollups.

An optimistic rollup assumes that a submitted state transition is correct unless a challenger proves fraud during a defined challenge period. Fraud proofs require an interactive or otherwise verifiable dispute mechanism. The approach can be relatively compatible with existing smart-contract execution environments, but withdrawals to the base chain may be delayed while the challenge period remains open.

A zero-knowledge rollup, often called a validity rollup, submits a cryptographic proof that a batch of transactions was correctly executed according to the protocol rules. Once the proof is verified, the state transition can be accepted without every base-layer validator re-executing all transactions. Proof generation can be computationally demanding, and compatibility with complex smart contracts may require specialised virtual machines or compilation techniques.

Rollups reduce costs through batching and compression, but users still depend on data availability and the correctness of the bridge contracts that connect the rollup to the base layer. Sequencers may order transactions and provide a convenient user interface, yet a centralised sequencer can create censorship, liveness, or ordering risks. A mature design therefore needs credible escape routes, decentralised sequencing plans, or mechanisms that allow users to force transactions through the settlement layer.

Validiums and Volition Designs

A validium uses validity proofs but stores transaction data outside the base chain. This can reduce fees and increase capacity, but users may be unable to reconstruct the state or withdraw safely if the external data provider withholds data. A volition design allows users or applications to choose between on-chain data availability and an off-chain data mode. The choice becomes a direct trade-off between cost and recoverability.

9.3 Sharding and Modular Architecture

Sharding divides network state or transaction processing across multiple partitions called shards. Instead of every validator processing every transaction, different validator groups process different portions of the workload. Cross-shard communication protocols are required when a transaction affects more than one shard. These protocols must address ordering, message delivery, atomicity, and security when validator assignments change.

Sharding can be implemented at the execution layer, data-availability layer, or both. In execution sharding, transactions are distributed across state partitions. In data sharding, the network provides additional space for publishing transaction data while execution may occur elsewhere. Sharding improves capacity only if communication overhead and validator coordination remain manageable.

A modular blockchain separates execution, settlement, consensus, and data availability into distinct layers or services. This allows specialised optimisation: one system may offer data availability, another may execute application logic, and a settlement layer may verify proofs and resolve disputes. Modularity increases design flexibility but also expands the number of dependencies and trust assumptions. A failure in an apparently peripheral service can affect the entire application stack.

9.4 Sidechains and Independent Execution Environments

A sidechain is a separate blockchain connected to another chain through a bridge or transfer mechanism. It may use a different consensus protocol, validator set, block interval, virtual machine, or fee model. Unlike a rollup, a sidechain generally does not inherit the full security of the parent chain. Its security depends on its own validators and bridge design.

Sidechains can be valuable where an application needs a particular execution environment, predictable fees, privacy features, or governance arrangements. They are also useful for experimentation and application-specific networks. However, users must not treat an asset represented on a sidechain as equivalent to the native asset on the parent chain without examining the bridge’s collateral, validator assumptions, redemption process, and failure response.

9.5 Interoperability: From Token Transfer to General Messaging

Interoperability has several levels. The simplest is asset movement: a user locks an asset on one chain and receives a representation on another. More advanced protocols transfer arbitrary messages, enabling a contract on one chain to invoke logic on another. The most demanding form is shared state or composability, in which applications depend on timely and consistent cross-chain information.

A cross-chain protocol must answer five questions:

1. How does the destination chain know what occurred on the source chain?

2. How does it know that the source event is final?

3. Who verifies the message and how many parties must agree?

4. What happens if the message is delayed, duplicated, censored, or forged?

5. How are assets recovered if either chain or the communication mechanism fails?

Bridge Architectures

A custodial or multisignature bridge relies on a group of signers to attest that an event occurred. It may be efficient and inexpensive, but the signers become a concentrated target. A compromised threshold can authorise fraudulent withdrawals.

A light-client bridge verifies proofs of the source chain’s consensus or block headers on the destination chain. It can provide strong security if the proof system accurately represents the source chain’s consensus assumptions, although implementation complexity and verification costs may be significant.

A liquidity or canonical bridge may use pools on both chains rather than minting a direct representation. It can provide fast transfers but introduces liquidity, pricing, and solvency risks. An optimistic bridge accepts messages unless challenged, creating a challenge window and requiring watchers with sufficient incentives to detect fraud.

Bridge security depends on more than cryptography. Key management, upgrade authority, oracle design, validator diversity, rate limits, monitoring, incident response, and governance all matter. A technically valid proof cannot protect a bridge whose administrator can unilaterally replace its verification logic.

9.6 Data Availability and Recoverability

Data availability means that the information needed to verify state transitions and reconstruct the current state is accessible to the parties that need it. It is distinct from data validity. A system may provide a valid state commitment while withholding the underlying transaction data. In that case, users may be unable to verify the commitment or generate a valid exit transaction.

Rollups commonly publish transaction data or compressed data commitments to a settlement layer. Data-availability committees, distributed storage, erasure coding, and sampling protocols are alternative techniques. Data availability sampling allows nodes to test whether sufficient portions of a large data object are available without downloading the entire object. Its security depends on sampling assumptions, coding schemes, network participation, and the number of honest nodes.

For evaluation, ask whether an ordinary user can independently reconstruct state, whether data is retained for an adequate period, whether archival copies are geographically distributed, and whether a forced exit remains possible during operator failure. Availability is both a technical and governance issue because retention policies and access rights influence practical recoverability.

9.7 Infrastructure for Production Blockchain Systems

A production blockchain application requires more than smart contracts. It needs reliable nodes, remote procedure call endpoints, indexers, archival storage, key-management systems, observability, deployment pipelines, and operational procedures.

Node infrastructure may be self-hosted, rented from specialist providers, or deployed through public cloud platforms. Self-hosting offers control and can reduce dependence on a single provider, but it demands specialist operations and redundant connectivity. Cloud deployment offers rapid scaling and managed infrastructure, yet creates concentration and jurisdictional risks. A sound architecture uses multiple providers, regions, and independent data sources where the application’s risk warrants it.

Indexers transform blockchain events and state into queryable databases. They improve application performance but can introduce stale, incomplete, or manipulated views. Critical decisions should be validated against authoritative chain data rather than relying solely on an indexer.

Key management is central to resilience. Validator keys, bridge keys, treasury keys, and administrative upgrade keys should have separate roles, least-privilege permissions, threshold controls, hardware-backed protection, rotation procedures, and emergency revocation processes. Operational security often matters more than the nominal consensus algorithm.

Blockchain-as-a-Service

Blockchain-as-a-service (BaaS) provides managed nodes, development environments, deployment tools, analytics, identity integration, and sometimes hosted networks. It can lower initial costs and shorten development time. Organisations can focus on application logic rather than maintaining every infrastructure component.

However, BaaS may create provider lock-in, opaque operational dependencies, inconsistent service-level guarantees, and uncertainty about data location. A provider outage may affect many customers simultaneously. Procurement should therefore examine exit procedures, data portability, audit rights, incident notification, service-level objectives, key ownership, subcontractors, and regulatory responsibilities. BaaS is not a substitute for governance; it redistributes operational responsibility.

9.8 A Decision Framework for Architecture Selection

Architecture selection should begin with requirements rather than fashionable technology. A useful decision sequence is:

First, define the workload. Estimate transaction volume, burst behaviour, transaction size, state growth, user geography, privacy requirements, and interaction patterns.

Second, classify the security requirement. Determine whether the application requires inherited base-layer security, an independent validator set, trusted operators, confidential execution, or formal proof guarantees.

Third, specify finality and availability needs. Financial settlement may require strong finality and robust recovery, whereas a gaming application may prioritise low latency and inexpensive microtransactions.

Fourth, map trust and failure assumptions. Identify operators, sequencers, bridge signers, cloud providers, data committees, upgrade administrators, and oracle providers. Treat every additional dependency as part of the threat model.

Fifth, model cost. Include execution fees, data publication, proof generation, storage, infrastructure, monitoring, compliance, liquidity, and incident-response costs. Low user fees may conceal high operator or security costs.

Finally, test failure scenarios. Simulate chain reorganisation, sequencer censorship, unavailable data, bridge compromise, cloud outage, key loss, governance capture, and abnormal transaction demand.

A decision matrix can score candidate architectures from one to five against throughput, latency, security inheritance, decentralisation, cost, interoperability, operational maturity, recoverability, and regulatory fit. The scores should be justified by measurements and documented assumptions rather than treated as objective facts.

9.9 Applied Case: A Cross-Border Trade Settlement Network

Background

The following is an illustrative case. Meridian Trade Network is a consortium of banks, logistics companies, and insurers seeking to automate settlement for documentary trade transactions. Participants operate in several jurisdictions and require auditability, controlled access, and integration with existing payment systems.

Situation and Problem

The consortium’s initial design placed every document hash, status update, and payment instruction on a single permissioned blockchain. During a pilot, the system experienced increased latency during document-processing peaks. Participants also disagreed about whether customers should be able to use public-chain liquidity and whether a bridge should connect the consortium network to a public settlement chain.

Analysis

The workload contained two different classes of activity. Document status changes required permissioned access and moderate throughput. Final payment settlement required stronger external assurance and interoperability. Keeping both functions on one chain created unnecessary coupling. The consortium also discovered that a bridge controlled by five jointly appointed signers would become a high-value target, while a fully trust-minimised light-client bridge would require greater engineering effort.

The risk analysis identified four principal concerns: confidentiality of commercial documents, availability during a participant outage, fraudulent cross-chain messages, and legal uncertainty about the finality of tokenised settlement assets.

Approach and Solution

Meridian adopted a modular design. Document metadata and workflow execution remained on a permissioned network. Large documents were stored in encrypted off-chain repositories, with hashes and access-control events recorded on-chain. A separate settlement service prepared batched payment instructions for an external chain. Rather than allowing unrestricted two-way bridging, the consortium introduced capped daily transfer limits, segregated operational and reserve keys, multi-party approval, continuous reconciliation, and an emergency pause function.

For higher-value transfers, the system required stronger confirmation of the external chain and delayed release until finality conditions were met. Independent monitoring nodes operated by different consortium members compared source-chain events, bridge records, and bank settlement records. A disaster-recovery procedure allowed participants to reconstruct document states from replicated archives and continue settlement manually if the workflow chain became unavailable.

Outcome

The architecture reduced the pressure on the permissioned chain and separated confidential workflow data from public settlement activity. It did not eliminate trust: consortium governance, bridge administrators, banks, and cloud providers remained important. However, the trust assumptions became explicit, limits reduced the maximum loss from a bridge compromise, and recovery procedures improved resilience.

Learning Points

The case illustrates that interoperability should be introduced selectively rather than assumed to be an unconditional benefit. A bridge is not merely a software connector; it is a financial and governance boundary. It also demonstrates the importance of workload separation, independent monitoring, capped exposure, and recovery testing.

9.10 Risks, Governance and Professional Responsibility

Scalable and interoperable systems amplify both benefits and failures. A vulnerability in a widely used bridge, sequencer, proof system, or data provider can affect many applications simultaneously. Common mistakes include comparing advertised throughput with sustained production performance, ignoring tail latency, treating a wrapped asset as native, assuming that a rollup automatically inherits all base-chain security, and failing to test withdrawal during operator failure.

Governance must specify who can upgrade contracts, change validator membership, alter fee rules, pause transfers, or modify data-retention policies. Emergency powers may protect users during an attack, but unrestricted emergency authority can itself become a centralisation and abuse risk. Changes should be subject to transparent procedures, timelocks where appropriate, independent review, and clearly defined recovery objectives.

Regulatory analysis should consider custody, money transmission, securities or payment-asset classification, privacy, sanctions compliance, operational resilience, and data-protection requirements. Immutability does not remove legal obligations to correct inaccurate data or restrict access to protected information. Storing personal data directly on a permanent ledger may create avoidable compliance problems; references, encrypted records, and controlled deletion strategies may be preferable.

Ethically, system designers should disclose material dependencies and risks to users. Marketing a system as decentralised while retaining unilateral administrative control is misleading. Professionals should distinguish verified properties from assumptions, publish security boundaries, and avoid presenting benchmark results obtained under unrealistic conditions as production guarantees.

9.11 Current Developments and Emerging Directions

Several developments are shaping the field. Proving systems are becoming more efficient and are being integrated into general-purpose execution environments. Shared sequencing and decentralised sequencing research seeks to reduce dependence on a single rollup operator. Data-availability layers and sampling techniques aim to support larger volumes of published data without requiring every node to store everything permanently.

Interoperability is moving from simple token bridges toward standardised message-passing, intent-based execution, and proof-based verification. These approaches may improve user experience, but they also create new solver, relayer, and execution dependencies. Confidential computing and zero-knowledge techniques are being combined with scalable infrastructure to support privacy-preserving compliance and selective disclosure.

Artificial intelligence is increasingly used for anomaly detection, fee estimation, infrastructure forecasting, smart-contract monitoring, and incident triage. AI outputs should remain advisory where false positives or false negatives could cause financial loss. Models must be trained and evaluated against adversarial conditions, and automated responses should be bounded by explicit policies and human oversight.

Best Practices

1. Measure sustained performance, tail latency, finality, and total cost rather than relying on headline throughput.

2. Document the security inheritance and independent trust assumptions of every layer.

3. Treat data availability and user exit as first-class design requirements.

4. Use rate limits, exposure caps, threshold keys, monitoring, and tested emergency procedures for bridges.

5. Separate execution, settlement, storage, identity, and analytics where separation reduces risk.

6. Maintain redundant infrastructure across providers, regions, and independent operators.

7. Test adversarial conditions, including censorship, reorganisation, data withholding, key compromise, and cloud failure.

8. Design governance and upgrade processes before deployment, not after an incident.

9. Protect personal and commercially sensitive information through off-chain storage and selective disclosure.

10. Reassess architecture as transaction volume, regulation, dependencies, and threat conditions change.

Chapter Summary

Scalability is a multidimensional systems problem involving throughput, latency, resource requirements, cost, and finality. Layer 2 systems, channels, rollups, sharding, sidechains, and modular architectures distribute work in different ways and therefore make different security and operational assumptions. Rollups can obtain substantial security from a settlement chain, but their guarantees depend on proof mechanisms, sequencer behaviour, and data availability. Sidechains generally rely on their own validators and should not be assumed to inherit parent-chain security.

Interoperability introduces communication and trust boundaries. Bridges may use multisignatures, liquidity pools, optimistic verification, or light-client proofs, but all require careful analysis of finality, key management, governance, solvency, and recovery. Data availability determines whether users can verify state and exit during operator failure. Infrastructure and BaaS improve deployment efficiency but create dependencies involving cloud providers, indexers, managed keys, and service operators.

A sound architecture is selected through workload analysis, security modelling, cost evaluation, failure testing, and governance design. The most important professional principle is to make trust assumptions visible and to evaluate systems by resilience and recoverability as well as speed.

Key Terms

Scalability: The ability of a system to handle increasing workload while maintaining acceptable performance and security.

Layer 2: A system that processes transactions above a base blockchain while using it for settlement, security, or dispute resolution.

Payment channel: An off-chain mechanism that allows repeated payments after an on-chain funding transaction.

State channel: A channel that supports general state transitions, not only payments.

Rollup: An execution system that batches transactions and submits commitments, data, or proofs to a settlement chain.

Optimistic rollup: A rollup that assumes submitted state transitions are valid unless successfully challenged.

Zero-knowledge rollup: A rollup that submits a cryptographic validity proof for a batch of state transitions.

Sidechain: An independent blockchain connected to another chain through a transfer or messaging mechanism.

Sharding: Partitioning state or processing across multiple blockchain segments.

Modular blockchain: An architecture that separates execution, consensus, settlement, or data availability into specialised layers.

Interoperability: The ability of distinct blockchain systems to exchange assets, messages, proofs, or state.

Bridge: A protocol that transfers assets or messages between blockchain environments.

Data availability: The accessibility of information required to verify and reconstruct blockchain state.

Finality: The condition under which a transaction is considered irreversible under specified protocol assumptions.

Sequencer: An operator or mechanism that orders transactions for a Layer 2 system.

Light-client bridge: A bridge that verifies source-chain consensus or block proofs on the destination chain.

Blockchain-as-a-service: Managed infrastructure and development services supplied by a provider for blockchain applications.

Tail latency: High-percentile transaction delay, such as the ninety-fifth or ninety-ninth percentile.

Trust assumption: A condition or party whose honesty, availability, or correct operation a system requires.

Review Questions

Short Answer Questions

1. What is the difference between throughput and finality?

2. Why can a payment-channel network reduce on-chain transaction demand?

3. How does an optimistic rollup respond to an allegedly invalid state transition?

4. Why is data availability necessary for user recovery from a rollup?

5. Name two operational risks associated with blockchain-as-a-service.

Long Answer Questions

1. Compare optimistic rollups and zero-knowledge rollups in terms of security mechanism, latency, compatibility, and cost.

2. Explain how sharding and modular architecture address scalability and identify their principal coordination risks.

3. Analyse the security differences between a multisignature bridge and a light-client bridge.

4. Develop a decision framework for selecting between a sidechain, rollup, and permissioned blockchain for an enterprise application.

5. Discuss why infrastructure, key management, governance, and disaster recovery are essential parts of blockchain security.

Analytical / Application Questions

1. A gaming platform requires very low transaction fees, rapid confirmation, frequent small interactions, and recovery if its operator disappears. Which scaling design would you recommend, and what additional safeguards are necessary?

2. A financial institution proposes a bridge controlled by seven signers, of whom four must approve withdrawals. Evaluate its trust assumptions, attack surface, and risk-reduction measures.

3. An application claims a major increase in throughput but requires every user to rely on one cloud provider, one sequencer, and an unavailable off-chain data store. Assess the claim using performance, resilience, cost, and security criteria.

22. Multiple Choice Questions with Answers

Question 1

Which measurement best distinguishes sustained production capacity from a short-lived benchmark result?

A. Peak transactions per second during a brief test

B. Sustained throughput under realistic workload and adversarial conditions

C. Number of tokens supported by the application

D. Number of smart contracts deployed

Correct Answer: B. Sustained throughput under realistic workload and adversarial conditions

Question 2

What is the principal security mechanism of an optimistic rollup?

A. Every transaction is executed independently by all users

B. A committee permanently controls all withdrawals

C. Submitted state transitions can be challenged through fraud proofs

D. Transaction data is never published

Correct Answer: C. Submitted state transitions can be challenged through fraud proofs

Question 3

Why can a validium be cheaper than a rollup while creating an additional risk?

A. It uses no cryptography

B. It stores transaction data off-chain, creating data-withholding risk

C. It requires every validator to execute every transaction twice

D. It eliminates the need for a settlement layer

Correct Answer: B. It stores transaction data off-chain, creating data-withholding risk

Question 4

Which statement most accurately describes a sidechain?

A. It always inherits the complete security of its parent chain

B. It is an independent blockchain connected through a transfer or messaging mechanism

C. It is only an encrypted database operated by a cloud provider

D. It cannot have a different consensus protocol from its parent chain

Correct Answer: B. It is an independent blockchain connected through a transfer or messaging mechanism

Question 5

A bridge controlled by a small signer group is most directly exposed to which risk?

A. Compromise or collusion sufficient to authorise fraudulent transfers

B. Inability to produce any block headers

C. Automatic elimination of transaction fees

D. Guaranteed deterministic finality on both chains

Correct Answer: A. Compromise or collusion sufficient to authorise fraudulent transfers

Question 6

What is the main purpose of data availability in a rollup system?

A. To prevent all transaction batching

B. To allow users to verify state and recover or exit when necessary

C. To make the sequencer the sole holder of transaction history

D. To replace consensus with a password

Correct Answer: B. To allow users to verify state and recover or exit when necessary

Question 7

Which infrastructure practice most improves resilience against provider failure?

A. Using one cloud region with a larger server

B. Relying exclusively on an indexer for authoritative state

C. Distributing infrastructure across providers, regions, and independent operators

D. Giving one administrator all keys for rapid decisions

Correct Answer: C. Distributing infrastructure across providers, regions, and independent operators

Question 8

Why may a centralised sequencer be a concern even when a rollup uses a secure settlement chain?

A. It may censor or delay transactions and create a liveness dependency

B. It makes cryptographic proofs impossible by definition

C. It automatically converts the rollup into a sidechain

D. It prevents all users from observing the base chain

Correct Answer: A. It may censor or delay transactions and create a liveness dependency

Question 9

Which factor should be included when calculating the total cost of a scalable blockchain architecture?

A. Only the user’s transaction fee

B. Only the cost of validator electricity

C. Execution, data publication, storage, proof generation, monitoring, and recovery costs

D. Only the initial software development cost

Correct Answer: C. Execution, data publication, storage, proof generation, monitoring, and recovery costs

Question 10

In the illustrative trade-settlement case, why were transfer limits and segregated keys introduced?

A. To increase dependence on a single bridge administrator

B. To reduce maximum exposure and separate operational authority from reserves

C. To eliminate the need for reconciliation

D. To ensure all documents were stored publicly

Correct Answer: B. To reduce maximum exposure and separate operational authority from reserves