Scalability, Interoperability and Privacy

Introduction and Context

Blockchain systems were initially designed to provide replicated, tamper-evident records without depending on a single controlling institution. Their strongest properties—decentralisation, independent verification, and resistance to unilateral alteration—also create engineering constraints. Many nodes must receive, process, store, and verify transactions. Agreement must be reached over a distributed network in which communication is delayed and some participants may be unreliable or malicious.

The resulting design problem is often described as the blockchain trilemma: a system seeks decentralisation, security, and scalability, but improving one dimension can place pressure on the others. The trilemma is not a strict mathematical theorem. It is a design heuristic that highlights trade-offs. Modern architectures attempt to reduce these trade-offs through Layer 2 protocols, rollups, sharding, alternative data-availability designs, cross-chain communication, and privacy-enhancing cryptography.

This chapter examines how these approaches work, what assumptions they make, and where they can fail. It also distinguishes scalability from interoperability and privacy. A network may process many transactions but expose all transaction relationships publicly; another may offer strong privacy but be difficult to connect safely to other networks.

Learning Objectives

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

1. Explain the blockchain trilemma and the principal sources of scalability pressure.
2. Distinguish throughput, latency, finality, capacity, and storage growth.
3. Compare Layer 2 systems, optimistic rollups, zero-knowledge rollups, sidechains, and sharding.
4. Explain bridges, light-client verification, messaging protocols, and major interoperability risks.
5. Describe zero-knowledge proofs and other privacy-enhancing approaches.
6. Evaluate blockchain architectures using technical, economic, governance, and regulatory criteria.
7. Select an appropriate architecture for a practical application.

1. The Blockchain Trilemma and System Constraints

1.1 Decentralisation, security, and scalability

Decentralisation concerns the distribution of authority and the ability of independent participants to validate transactions and influence consensus. It is affected by hardware costs, bandwidth requirements, validator concentration, and governance arrangements.

Security includes resistance to double spending, censorship, invalid state transitions, denial-of-service attacks, consensus attacks, key compromise, and smart-contract exploitation. Security is broader than cryptographic correctness: operational and governance failures can also compromise a system.

Scalability is the ability to support increasing transaction demand while preserving acceptable cost, latency, reliability, and decentralisation. It is multidimensional rather than a single transactions-per-second number.

A highly replicated design requires every validator, or a substantial subset of validators, to process and store data. Increasing block size or reducing block intervals can increase nominal throughput, but may make it harder for ordinary participants to operate full nodes. This may increase validator centralisation and weaken independent verification.

1.2 Throughput, latency, and finality

Throughput is the number of transactions completed per unit of time. A simple average is:

where T is throughput in transactions per second, N is the number of completed transactions, and Δt is the elapsed time in seconds. This expression assumes that transactions are counted consistently and that the measurement interval is specified. It does not by itself describe peak capacity, confirmation quality, or transaction complexity.

For a block-producing chain, an approximate capacity model is:

where B is the usable block budget in bytes or execution units, s is the average transaction size or execution cost in the same unit, and τ is the block interval in seconds. The formula is an approximation. It assumes blocks are regularly produced and that transactions have approximately uniform resource requirements. If transaction sizes vary, a percentile or workload distribution is more informative than a simple average.

Latency is the time between submission and a useful confirmation. Finality is the point at which a transaction is considered irreversible under the protocol’s assumptions. A transaction can appear quickly in a block yet have probabilistic finality, while another system may take longer but provide deterministic finality after a known event.

For a transaction submitted just after a block is produced, the expected waiting time under a regular block interval is approximately τ ÷ 2, although actual waiting time depends on timing, congestion, propagation, and inclusion policy. This is a scheduling approximation, not a guarantee.

1.3 Storage and state growth

Blockchain storage includes historical blocks, transaction data, receipts, state, indexes, and sometimes witness or proof data. If a chain adds D bytes of retained data per day, the uncompressed annual growth is:

where G_year is annual growth in bytes and D is daily growth in bytes. The calculation assumes a 365-day year and excludes pruning, compression, database overhead, indexes, and duplicated storage.

State growth is especially important because current account balances, contract storage, and other application data must often remain available for validation. Archival requirements are different from full-node requirements: an archival node preserves historical states that a validating node may not need for routine operation.

1.4 The resource triangle

Blockchain performance is constrained by at least four resources:

• computation, including signature verification and virtual-machine execution;
• bandwidth, including block propagation and data dissemination;
• storage, including historical data and current state;
• coordination, including consensus communication and dispute resolution.

An architecture that improves one resource may shift pressure to another. For example, compressing transaction data reduces bandwidth but may increase computation; increasing off-chain execution reduces base-layer computation but creates new proof, availability, or operator-dependence requirements.

2. Scaling Architectures

2.1 Layer 1 scaling

Layer 1 refers to the base blockchain and its consensus and execution layer. Layer 1 improvements may include more efficient signature schemes, parallel transaction execution, compact data formats, better peer-to-peer propagation, proof aggregation, and changes to block limits.

Layer 1 scaling is attractive because it keeps activity within the base security and settlement environment. However, larger blocks and more complex validation can increase hardware and network requirements. Parallel execution also requires reliable identification of independent transactions. Conflicting transactions cannot safely execute in parallel unless the protocol resolves their ordering and state dependencies.

2.2 Layer 2 systems

A Layer 2 (L2) system processes transactions away from the base chain while using the base chain for settlement, dispute resolution, or data availability. Users generally deposit assets into an on-chain contract, transact in the L2 environment, and later withdraw or settle results on Layer 1.

L2 systems differ in their security model. Some inherit substantial security from the base chain through validity proofs or fraud challenges. Others depend on a committee, operator, or multisignature arrangement. Therefore, the label “Layer 2” does not automatically imply equivalent security.

Important evaluation questions include:

1. Who can order transactions?
2. Who can publish state commitments?
3. Is transaction data available to independent users?
4. Can an invalid state be rejected cryptographically or through a challenge?
5. Can users exit without cooperation from the operator?
6. What happens if the operator stops responding?

2.3 Payment channels and state channels

A payment channel allows parties to transact off-chain while periodically anchoring commitments to a blockchain. A state channel generalises this approach to broader state transitions, such as games or conditional agreements.

Channels can offer very low transaction latency and high repeated-use throughput because not every update is recorded on the base chain. Their limitations include capital lock-up, routing complexity, liquidity management, online availability requirements, and difficulty supporting arbitrary global state. They are most suitable when a known group of participants repeatedly interacts.

2.4 Sidechains

A sidechain is a separate blockchain connected to another chain through a transfer mechanism. It may use different validators, consensus rules, execution limits, and governance. A sidechain can provide greater throughput or lower fees, but it generally does not inherit the full security of the connected base chain.

The key distinction is between scaling by shared security and scaling by independent security. A rollup usually seeks to anchor its correctness to the base chain, while a sidechain typically relies on its own validator set or bridge committee. Sidechains can be useful for application-specific environments, experimentation, and controlled business networks, but users must assess the independent security assumptions.

2.5 Rollups

A rollup executes transactions off-chain and posts commitments and, depending on the design, transaction data or compressed data to a base chain. The base chain acts as a settlement and verification layer.

#### Optimistic rollups

An optimistic rollup assumes that a submitted state transition is valid unless challenged during a dispute window. A fraud-proof process allows a challenger to identify an invalid computation. The system must define a challenge period, evidence format, and final resolution procedure.

Advantages include compatibility with general-purpose smart contracts and comparatively mature execution models. Limitations include delayed withdrawals, dependence on active challengers, complex dispute games, and risks associated with upgrade keys or sequencers.

#### Zero-knowledge rollups

A zero-knowledge rollup submits a cryptographic validity proof that a batch of transactions correctly transforms one state commitment into another. The verifier can check the proof without re-executing every transaction.

The phrase “zero knowledge” refers to a proof property, but many systems use validity proofs primarily for scalability rather than transaction privacy. A rollup can publish all transaction data publicly while still using a zero-knowledge proof to establish correctness.

Advantages include fast cryptographic finality after proof verification and reduced verification work. Challenges include proving costs, specialised circuits, software complexity, proving latency, and the difficulty of supporting changing virtual-machine semantics.

2.6 Data availability

A state commitment is not sufficient if users cannot obtain the underlying transaction data needed to reconstruct or verify state. Data availability means that relevant data has been published and can be retrieved by participants.

Data availability sampling attempts to let light clients gain probabilistic assurance that large data blobs are available without downloading all of them. Such systems require carefully designed sampling, erasure coding, network assumptions, and honest participation thresholds. Availability is distinct from validity: data may be available but invalid, or valid data may be unavailable to users.

2.7 Sharding

Sharding divides transaction processing or state across multiple partitions, often called shards. If independent shards process transactions concurrently, aggregate capacity may increase. However, cross-shard transactions require communication and coordination.

A simple idealised model is:

where k is the number of equally capable independent shards and T_shard is the throughput of one shard. This is an upper-bound intuition, not a general law. Real systems lose capacity through cross-shard traffic, uneven workloads, consensus overhead, data availability requirements, and coordination delays.

Sharding also changes the security question. If an attacker can concentrate resources on a small shard, the protocol needs mechanisms such as validator randomisation, committee rotation, cross-shard security, and global settlement.

3. Comparing Scaling Approaches

No approach dominates in every dimension. A payment channel may be superior for recurring micropayments, while a rollup may be better for a general smart-contract ecosystem. A permissioned sidechain may be appropriate for regulated organisations with known governance, even though it is not equivalent to a public, permissionless rollup.

4. Interoperability and Cross-Chain Communication

4.1 What interoperability means

Interoperability is the ability of distinct blockchain networks, applications, wallets, and external systems to exchange information or value with predictable semantics. It has several layers:

• asset interoperability: representing or transferring value across networks;
• message interoperability: sending authenticated instructions or data;
• state interoperability: proving facts about another chain’s state;
• application interoperability: coordinating a complete workflow across systems.

A token representation on a destination chain is not automatically the same asset as the original. Its safety depends on the mechanism that locks, burns, mints, or otherwise accounts for the source value.

4.2 Bridges

A bridge connects two environments by monitoring events on one chain and authorising actions on another. Common models include:

1. Lock-and-mint: assets are locked on the source and a representation is minted on the destination.
2. Burn-and-mint: a representation is burned on one network and issued on another.
3. Liquidity-based transfer: a provider pays the user on the destination while later rebalancing liquidity.
4. Message-passing bridge: authenticated messages trigger calls without necessarily moving a token.

Bridges may use multisignatures, validator committees, threshold signatures, light-client proofs, optimistic verification, or zero-knowledge proofs. Their risk is often concentrated in the bridge contract, relayer set, key management, upgrade process, or message-verification logic.

4.3 Light clients and interoperability protocols

A light client verifies a compact representation of another chain’s consensus or state without storing the complete chain. If the destination chain can verify source-chain headers and inclusion proofs, the bridge can reduce reliance on a trusted committee. However, light-client verification may be computationally expensive, difficult to update, or incompatible with the source chain’s consensus changes.

Interoperability protocols may provide a standard message layer, but standardisation does not eliminate semantic risks. A message such as “transfer 100 units” requires agreement on denomination, finality, replay protection, ordering, failure handling, and authorisation.

4.4 Interoperability failure modes

Important threats include:

• forged or incorrectly verified messages;
• replay of a valid message;
• double minting or failure to burn;
• compromised relayers or validator keys;
• chain reorganisation and incorrect finality assumptions;
• smart-contract upgrades that change trust assumptions;
• denial of service or censorship;
• inconsistent handling of decimals, fees, and failed calls.

Bridge design should use domain separation, unique nonces, explicit chain identifiers, conservative finality thresholds, rate limits, emergency pauses, independent audits, and transparent governance. Rate limits reduce the maximum loss from a compromise but do not establish correctness.

5. Privacy and Zero-Knowledge Proofs

5.1 Transparency versus confidentiality

Public blockchains commonly expose transaction amounts, addresses, timestamps, and graph relationships. Pseudonymous addresses are not equivalent to anonymity. Identity can be inferred through exchange records, network metadata, address reuse, behavioural patterns, and application-level information.

Privacy has multiple dimensions:

• confidentiality: hiding transaction values or data;
• unlinkability: making it difficult to connect transactions to the same user;
• anonymity: protecting identity within an anonymity set;
• network privacy: concealing the origin or destination of a message;
• selective disclosure: revealing only information required for a particular purpose.

Privacy is therefore a system property, not merely a feature of a cryptographic primitive.

5.2 Zero-knowledge proofs

A zero-knowledge proof allows a prover to convince a verifier that a statement is true without revealing the secret information, called the witness, that makes it true. A useful proof system aims for:

• completeness: an honest prover can convince the verifier of a true statement;
• soundness: a dishonest prover cannot convince the verifier of a false statement except with negligible probability under the stated assumptions;
• zero knowledge: the verifier learns no information beyond the truth of the statement, within the defined security model.

For example, a user may prove that an account satisfies an eligibility rule without revealing the complete identity record. The proof statement must be carefully designed: proving that a balance is non-negative is different from proving that a balance exceeds a threshold, and neither necessarily proves legal ownership.

Some systems use trusted setup ceremonies, while others use transparent setup methods. Trusted setup systems require confidence that secret setup material was destroyed or not misused. Proof systems also differ in proof size, verification cost, prover cost, post-quantum considerations, and implementation maturity.

5.3 Privacy-enhancing techniques

Relevant approaches include:

• confidential transactions, which hide values using commitments and range proofs;
• mixing protocols, which obscure transaction relationships by pooling and redistributing funds;
• stealth addresses, which create one-time destination addresses;
• ring signatures, which hide the actual signer among a group;
• selective-disclosure credentials, which allow proof of attributes without revealing the full credential;
• secure multiparty computation, in which parties jointly compute a result without revealing private inputs;
• trusted execution environments, which protect computation through hardware isolation;
• differential privacy, which limits information leakage in aggregate data analysis.

Each approach has different assumptions and leakage patterns. Mixing can be weakened by timing analysis; hardware enclaves depend on vendor security and side-channel resistance; differential privacy deliberately adds statistical noise and is not a transaction-confidentiality mechanism.

5.4 Regulatory and ethical considerations

Privacy supports personal autonomy, commercial confidentiality, safety, and protection from unjustified surveillance. It can also complicate anti-money-laundering controls, sanctions compliance, taxation, audit, and lawful investigation. Responsible designs should distinguish privacy from concealment of unlawful activity and should consider proportionate controls such as selective disclosure, compliance credentials, transaction limits, and court-authorised access mechanisms where legally appropriate.

Developers must also avoid claiming that a system is anonymous when it is only pseudonymous. Privacy promises should be documented as threat models: who is protected, from which observer, for how long, and under what metadata assumptions.

6. Performance and Architecture Evaluation

A professional evaluation should combine quantitative metrics with security analysis. Useful metrics include:

• sustained and peak throughput;
• confirmation and finality latency;
• transaction-fee variability;
• execution cost per transaction;
• prover, sequencer, validator, or relayer concentration;
• data-availability guarantees;
• state and archival growth;
• withdrawal and recovery time;
• bridge value-at-risk and upgrade authority;
• privacy leakage under realistic observation.

A practical measurement must specify workload. A system may report high throughput using simple transfers while performing poorly on complex contracts. Benchmark reports should disclose transaction type, hardware, network conditions, batch size, failure rate, queueing, and whether values represent peak or sustained performance.

7. Applied Case: Illustrative Cross-Border Supply-Chain Network

Background

Consider an illustrative consortium of manufacturers, logistics firms, banks, and customs agencies. Participants need a shared record of shipment milestones, document hashes, and conditional payments. Some data is commercially sensitive, while regulators require auditable evidence.

Problem

A public Layer 1 cannot economically store every document and may expose supplier relationships. A private database controlled by one firm lacks sufficiently independent verification. The consortium also wants banks on a separate settlement network to receive authenticated payment instructions.

Analysis

The system has three different data classes. Large documents should remain off-chain, with cryptographic commitments recorded on a shared ledger. Routine workflow events may be handled by a consortium network or rollup. Settlement messages require strong authentication and replay protection. Privacy must hide commercially sensitive fields while permitting authorised audits.

Approach

The consortium adopts a permissioned execution environment anchored periodically to a public settlement chain. Each batch publishes a Merkle-root commitment and sufficient availability information for authorised participants. A zero-knowledge proof demonstrates that a payment instruction satisfies agreed rules—such as matching an approved shipment identifier and an authorised value range—without publishing the entire commercial contract.

A message bridge to the banking network uses domain-separated message identifiers, nonces, threshold authorisation, conservative finality confirmation, and a daily transfer limit. The bridge does not assume that a token representation is identical to the bank’s settlement asset; it transmits a verified instruction and records the resulting acknowledgement.

Outcome

The design reduces public-chain data volume, limits commercial disclosure, and provides an auditable anchor. It does not eliminate trust. Participants still depend on the consortium’s governance, document availability, identity systems, proof circuits, bridge operators, and legal agreements. A dispute process is required when an off-chain document is unavailable or a physical shipment does not match its digital record.

Learning points

1. Not every data item should be placed directly on a public chain.
2. A proof can establish that a rule was followed without proving that the underlying real-world event was truthful.
3. Interoperability requires semantic and governance agreements, not only cryptographic connectivity.
4. Privacy and auditability can be combined through selective disclosure, but the result depends on careful threat modelling.

8. Best Practices and Contemporary Directions

Best practice begins with explicit requirements rather than selecting a fashionable protocol. Teams should define acceptable throughput, latency, finality, privacy, availability, recovery, and governance before choosing an architecture.

Security reviews should cover smart contracts, cryptographic libraries, circuits, sequencers, key ceremonies, bridge logic, upgrade authorities, monitoring, and incident response. Economic incentives should be tested under congestion and adversarial behaviour. Operators should publish assumptions and make exit or recovery procedures practical.

Current development trends include modular blockchains that separate execution, consensus, settlement, and data availability; shared sequencing; recursive proof aggregation; application-specific rollups; interoperability protocols based on light clients or succinct proofs; and privacy-preserving identity credentials. These developments improve flexibility but can increase dependency chains and system complexity. A modular system may be scalable in aggregate while exposing users to failures at interfaces between modules.

Artificial intelligence is relevant mainly as an operational aid: anomaly detection, fee forecasting, testing, and monitoring can help identify unusual bridge activity or congestion. AI does not replace cryptographic verification or consensus. Models can produce false positives, be manipulated by adversaries, and introduce opaque decision processes; therefore, AI-based controls should be supplemental, explainable where possible, and subject to human governance.

Challenges and Limitations

Scalability solutions often move rather than remove costs. Rollups shift computation to provers and data to publication layers. Sharding creates cross-shard coordination. Channels create liquidity and availability requirements. Bridges introduce additional trust boundaries. Privacy systems may increase proving costs and complicate compliance. More complex architectures also create larger attack surfaces and make incident diagnosis harder.

The trilemma remains a useful warning because decentralisation and security are not free resources. A system that claims unlimited throughput should be examined for validator requirements, data availability, censorship resistance, finality assumptions, and the extent to which activity is actually secured by the base protocol. Similarly, a “trustless” bridge should be analysed as a set of explicit cryptographic and governance assumptions rather than accepted as a label.

Chapter Summary

Blockchain scalability is constrained by computation, bandwidth, storage, and coordination. Throughput, latency, and finality measure different aspects of performance, while storage growth affects the ability of independent participants to validate and preserve history. The blockchain trilemma expresses the recurring tension among decentralisation, security, and scalability.

Layer 2 systems, channels, sidechains, rollups, and sharding address these constraints in different ways. Optimistic rollups depend on fraud challenges, whereas zero-knowledge rollups use validity proofs. Sidechains usually rely on their own security assumptions. Sharding can increase aggregate capacity but introduces cross-shard coordination and workload-balancing challenges.

Interoperability involves assets, messages, state, and applications. Bridges are valuable but create concentrated risks involving message verification, keys, finality, replay, upgrades, and governance. Zero-knowledge proofs support both scalability and privacy, but zero knowledge does not automatically mean that transaction data is private. Privacy must be assessed across values, identities, relationships, network metadata, and selective disclosure.

Professional architecture selection requires workload-specific benchmarking, explicit threat models, transparent assumptions, governance analysis, and recovery planning. The most robust design is not necessarily the one with the highest nominal throughput; it is the one whose security, privacy, availability, and operational assumptions fit the application.

Key Terms

Blockchain trilemma: The design tension among decentralisation, security, and scalability.

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

Latency: The time between submission and a useful confirmation.

Finality: The point at which a transaction is considered irreversible under protocol assumptions.

State growth: The increase in current account, contract, and application state over time.

Layer 2: A system that processes activity away from the base chain while using it for settlement or security functions.

State channel: An off-chain protocol for repeated state updates with later on-chain settlement.

Sidechain: A separate blockchain connected to another chain through a transfer or messaging mechanism.

Rollup: An off-chain execution system that posts commitments and supporting data or proofs to a base chain.

Optimistic rollup: A rollup that assumes submitted results are valid unless challenged.

Zero-knowledge rollup: A rollup that proves state transitions using cryptographic validity proofs.

Data availability: The property that required transaction data has been published and can be retrieved.

Sharding: Partitioning execution, state, or data across coordinated subsets of a network.

Bridge: Infrastructure that transfers value or authenticated messages between blockchain environments.

Light client: A client that verifies another chain using compact headers, proofs, or consensus evidence.

Zero-knowledge proof: A proof of a statement that can reveal little or no information about its secret witness.

Selective disclosure: Revealing only the information necessary for a particular verification purpose.

Confidentiality: Protection of information from unauthorised disclosure.

Replay attack: Reuse of a previously valid message or transaction in an unintended context.

Review Questions

5 Short Answer Questions

1. What are the three dimensions commonly associated with the blockchain trilemma?
2. Distinguish throughput from finality.
3. Why does a sidechain generally not inherit the complete security of its connected base chain?
4. What is the role of a fraud proof in an optimistic rollup?
5. Why is pseudonymity different from anonymity?

5 Long Answer Questions

1. Explain the major computation, bandwidth, storage, and coordination constraints affecting blockchain scalability.
2. Compare payment channels, sidechains, optimistic rollups, and zero-knowledge rollups in terms of execution location, security, benefits, and limitations.
3. Explain how sharding can increase capacity and why cross-shard communication prevents simple linear scaling.
4. Describe the architecture of a bridge and analyse at least four bridge failure modes.
5. Explain the completeness, soundness, and zero-knowledge properties of a zero-knowledge proof and discuss their practical significance.

3 Analytical / Application Questions

1. A blockchain has a usable block budget of 1,000,000 bytes, an average transaction size of 500 bytes, and a 10-second block interval. Using the approximate capacity formula, calculate the theoretical transactions per second and identify two reasons real sustained throughput may be lower.
2. Design a privacy-preserving supply-chain application that must support regulatory audits. Specify which data is on-chain, which data is off-chain, how proofs are used, and what governance risks remain.
3. An organisation proposes moving assets through a bridge secured by a five-member multisignature committee. Critically assess the design and recommend technical and governance controls that would reduce, but not eliminate, the risk of loss.

Multiple Choice Questions with Answers

Question 1

Which statement best describes blockchain scalability?

A. It is only the number of transactions in a single block

B. It is the ability to support increasing demand while maintaining acceptable cost, latency, reliability, and decentralisation

C. It is the process of hiding all transaction identities

D. It is the number of validator signatures on each transaction

Correct Answer: B. It is the ability to support increasing demand while maintaining acceptable cost, latency, reliability, and decentralisation

Question 2

A chain has a usable block budget of 600,000 bytes, an average transaction size of 300 bytes, and a 6-second block interval. What is the approximate theoretical capacity?

A. 333 transactions per second

B. 1,000 transactions per second

C. 2,000 transactions per second

D. 3,600 transactions per second

Correct Answer: C. 2,000 transactions per second

Question 3

What is the principal security mechanism of an optimistic rollup?

A. A mandatory trusted hardware enclave for every user

B. A fraud-proof process during which invalid state transitions can be challenged

C. A requirement that every transaction be stored on a sidechain only

D. Random deletion of disputed transactions

Correct Answer: B. A fraud-proof process during which invalid state transitions can be challenged

Question 4

Which statement correctly distinguishes a zero-knowledge rollup from a privacy system?

A. Every zero-knowledge rollup necessarily hides all transaction data

B. A zero-knowledge rollup may use validity proofs while publishing transaction data publicly

C. Zero-knowledge proofs cannot be used for scalability

D. Zero-knowledge rollups do not require cryptographic verification

Correct Answer: B. A zero-knowledge rollup may use validity proofs while publishing transaction data publicly

Question 5

Why can sharding fail to provide perfectly linear scaling?

A. All shards must use identical user accounts

B. Cross-shard communication, uneven workloads, and coordination create overhead

C. Sharding eliminates all parallel processing

D. Shards cannot contain transaction data

Correct Answer: B. Cross-shard communication, uneven workloads, and coordination create overhead

Question 6

Which bridge threat involves using an already valid message again in an unintended context?

A. State growth

B. Replay attack

C. Data compression

D. Validator rotation

Correct Answer: B. Replay attack

Question 7

Which property means that an honest prover can convince a verifier when the statement is true?

A. Completeness

B. Censorship resistance

C. Finality

D. Unlinkability

Correct Answer: A. Completeness

Question 8

Which statement about sidechains is most accurate?

A. They always inherit the full validator security of the base chain

B. They are separate blockchains and commonly rely on their own validator or governance assumptions

C. They cannot execute smart contracts

D. They are identical to payment channels

Correct Answer: B. They are separate blockchains and commonly rely on their own validator or governance assumptions

Question 9

Which practice most directly helps prevent cross-chain message replay?

A. Removing chain identifiers

B. Using unique nonces and domain-separated message identifiers

C. Increasing transaction display decimals

D. Publishing private keys to auditors

Correct Answer: B. Using unique nonces and domain-separated message identifiers

Question 10

What does selective disclosure aim to achieve?

A. Revealing every attribute of a credential to every observer

B. Revealing only information necessary for a particular verification purpose

C. Deleting all evidence of a transaction

D. Replacing consensus with artificial intelligence

Correct Answer: B. Revealing only information necessary for a particular verification purpose