Web3 applications require more than a smart contract deployed on a blockchain. They depend on a complete infrastructure stack that includes execution networks, consensus mechanisms, transaction-data systems, bridges, messaging protocols, storage networks, indexing services, wallets, RPC providers and monitoring tools. The quality of this infrastructure determines whether an application is secure, affordable, fast, discoverable and usable at scale.
The central engineering challenge is the blockchain trilemma: a system seeks decentralization, security and scalability, but improvements in one dimension may create pressure in another. A Layer 1 (L1) blockchain may provide strong settlement and censorship resistance but have limited throughput. A Layer 2 (L2) may increase throughput and reduce transaction costs but introduce additional assumptions concerning operators, sequencers, fraud proofs or validity proofs. A bridge may connect ecosystems but create a concentrated point of failure. Decentralized storage may improve availability but does not automatically guarantee data permanence or confidentiality.
This chapter compares these infrastructure choices and develops a framework for evaluating them. It also examines rollups, sidechains, bridges, cross-chain messaging, decentralized storage and indexing, with attention to security, governance, performance and professional implementation.
Learning Objectives
By the end of this chapter, you should be able to:
Distinguish Layer 1 networks from Layer 2 systems, sidechains and application-specific chains.
Explain how optimistic and zero-knowledge rollups scale blockchain execution.
Evaluate bridges and cross-chain messaging according to their trust and security assumptions.
Compare decentralized storage and indexing systems with conventional databases.
Analyse trade-offs among throughput, latency, cost, security and decentralization.
Design a practical infrastructure architecture for a Web3 application.
Identify operational, regulatory, governance and ethical risks in multichain systems.
1. The Web3 Infrastructure Stack
A blockchain application can be understood as a set of layers:
Layer
Main function
Typical examples
Settlement and consensus
Orders transactions and establishes final state
Ethereum, Bitcoin, Solana
Execution
Runs smart contracts and updates state
EVM, SVM, WASM-based environments
Scaling
Processes activity away from or alongside an L1
Rollups, validiums, sidechains
Interoperability
Transfers messages, assets or proofs between networks
Light-client bridges, optimistic bridges
Storage
Stores files, metadata and large objects
IPFS, Arweave, Filecoin
Indexing and access
Makes blockchain data searchable and usable
The Graph, Subgraphs, custom indexers
Application
Provides user-facing services
Exchanges, games, DAOs and marketplaces
These layers are related but not interchangeable. A blockchain may provide secure settlement without offering convenient historical queries. A decentralized storage network may store an image but cannot, by itself, enforce ownership rights represented by a token. An indexer may provide fast search but is generally an off-chain interpretation of on-chain data and must be validated against canonical chain state.
Figure: A simplified Web3 infrastructure stack. The layers interact, but each has distinct security and availability assumptions.
2. Layer 1 Networks
A Layer 1 is a base blockchain that independently provides consensus, transaction ordering, state transition and usually data availability. Its validators or miners verify transactions according to a protocol. Examples include Ethereum, Bitcoin and Solana, although their architectures differ substantially.
An L1 offers a strong settlement anchor. Once a transaction reaches the network's accepted finality conditions, applications can treat its state as authoritative. However, all users compete for the same block space. When demand exceeds capacity, fees rise and confirmation may become slower or less predictable.
A useful throughput relationship is:
Throughput ≈ B ÷ τ
Here, throughput is measured in transactions per second, B is the number of transactions that can fit in a block, and τ is the average block interval in seconds. This simplified relationship assumes approximately stable transaction size and block capacity. Real networks have heterogeneous transactions, execution limits, propagation delays and confirmation requirements, so actual throughput may differ.
L1 evaluation should include:
Security: economic cost of attacking consensus, validator diversity and client robustness.
Decentralization: distribution of validators, stake, hardware requirements and governance power.
Finality: the time and conditions under which a transaction is considered irreversible.
Execution capacity: limits on computation, storage growth and block size.
Data availability: whether participants can obtain the data needed to reconstruct state.
Operational maturity: tooling, audits, wallets, explorers and developer support.
3. Layer 2 Networks and Scaling Models
A Layer 2 is a system that processes transactions outside the primary execution path of an L1 while using the L1 for some combination of settlement, dispute resolution, data availability or security. The term covers several architectures, and not every system marketed as an L2 has identical security properties.
3.1 Rollups
A rollup executes transactions off-chain, groups them into a batch and posts data or commitments to an L1. The L1 then acts as the settlement and dispute environment. Rollups can reduce per-transaction cost because many transactions share the cost of publishing batch information.
A simplified cost model is:
Ctransaction ≈ (Cbatch + Cexecution) ÷ N + Cproof
C_transaction is the average user cost, C_batch is the cost of publishing batch data, C_execution is any shared execution or verification cost, N is the number of transactions in the batch, and C_proof is the per-transaction allocation of proof-related costs. The model assumes that costs are allocated across a batch and excludes application-specific fees and exchange-rate effects. As N increases, the shared batch component generally declines per transaction, although congestion and proof-generation costs may change.
#### Optimistic rollups
Optimistic rollups assume that submitted state transitions are valid unless someone challenges them during a dispute window. A fraud-proof procedure allows an honest participant to demonstrate that a proposed transition is incorrect. Their principal advantages are broad compatibility with existing smart contracts and relatively mature development tools.
Their limitations include withdrawal delays when users exit directly to the L1, reliance on active monitoring, and the complexity of dispute-game design. Fast exit services can provide liquidity before the challenge period ends, but users then rely on the service provider and pay a fee.
#### Zero-knowledge rollups
Zero-knowledge, or validity-proof, rollups submit a cryptographic proof that a state transition was executed correctly. The L1 verifies the proof rather than re-executing every transaction. The term “zero-knowledge” refers to the proof technique; many systems primarily use validity proofs for integrity rather than for hiding transaction data.
Validity proofs can provide rapid finality after verification and avoid long fraud windows. However, proving complex programs can require specialized hardware, sophisticated circuits and careful compiler design. Compatibility with general-purpose smart contracts may therefore be more difficult, although this is improving.
3.2 Validiums and Volitions
A validium uses validity proofs but keeps transaction data off the principal L1, often with a separate data-availability committee or storage system. This can reduce cost and increase capacity, but users may be unable to reconstruct or exit their state if data is withheld. A volition system allows an application or user to choose between on-chain and off-chain data availability, creating a configurable security-cost trade-off.
3.3 State channels and plasma-like designs
State channels allow participants to execute many transactions off-chain and settle a net result on an L1. They are efficient for repeated interactions among known participants but less convenient for arbitrary, open-ended activity. Plasma-like systems keep much of the transaction data off-chain and rely on exit mechanisms and fraud detection. Their usability and application scope are more constrained than those of general-purpose rollups.
4. Sidechains and Application-Specific Chains
A sidechain is an independent blockchain connected to another network but not necessarily secured by the parent L1's validator set. It may use a separate proof-of-stake system, committee or federated model. Sidechains can offer lower fees, faster blocks and customized execution, but their security must be assessed independently.
An application-specific chain can optimize block space, fee policy, governance and execution for a particular application or sector. This may improve performance and predictability. The cost is ecosystem fragmentation, additional validator or sequencer operations and a smaller economic base securing the chain.
The distinction between an L2 and a sidechain is therefore primarily about the security and settlement relationship, not simply whether transactions are processed separately. A system that posts data and proves state transitions to an L1 may inherit significant L1 security. An independent sidechain generally does not inherit that security automatically.
Property
Layer 1
Rollup
Sidechain
Validium
Main execution
On base chain
Off-chain, settled on L1
Independent chain
Off-chain, proved and data kept elsewhere
Typical cost
Higher during congestion
Lower per transaction
Often low
Often very low
Security anchor
Native consensus
L1 plus proof and implementation
Independent consensus
L1 proof plus data-availability assumptions
Withdrawal complexity
Native
May involve proof or challenge period
Bridge-dependent
Data availability and bridge-dependent
Main risk
Congestion and state growth
Software, sequencer and proof risks
Smaller or centralized validator set
Data withholding
5. Interoperability: Bridges and Cross-Chain Messaging
Interoperability allows users and applications to move value or communicate across networks. Two different functions must be distinguished:
Asset transfer: representing an asset from one network on another, commonly through locking, minting, burning or liquidity exchange.
Message passing: transmitting instructions or data, such as “release collateral,” “update governance,” or “execute a cross-chain call.”
A bridge does not literally transport a token through physical space. It changes the state of contracts or custodians on two networks. Common models include:
Custodial or multisignature bridges: a group controls locked funds and authorizes representations elsewhere.
Liquidity networks: liquidity providers facilitate swaps between assets on different chains.
Light-client bridges: one chain verifies consensus evidence from another.
Optimistic bridges: messages are accepted provisionally and can be challenged.
Canonical rollup bridges: assets move between an L1 and its rollup through protocol-defined contracts.
Bridge security depends on the weakest critical assumption. A technically sound token contract can still be exposed if a bridge administrator, validator committee, oracle or relayer is compromised. Relevant questions include:
Who can mint or release assets?
How many independent parties must collude to forge a message?
Is the source-chain finality correctly understood?
Can messages be replayed or reordered?
What happens during a chain reorganisation?
Is there a pause mechanism, and who controls it?
Can users recover funds if the bridge stops operating?
Cross-chain messaging introduces an expanded attack surface. A message should contain a unique identifier, source domain, destination domain, nonce, sender, recipient and authenticated payload. Destination contracts should reject duplicate nonces and validate the intended source. Messages should not be accepted merely because an external relayer claims that they occurred.
A practical risk principle is:
System security ≤ minimum security of its critical dependencies
This is not a physical law or exact quantitative equation. It is an engineering design heuristic: if a system requires several components to be secure, the weakest essential component can dominate the overall risk.
6. Decentralized Storage
Blockchains are inefficient for large files. Storing a video, high-resolution image or extensive dataset directly on-chain can impose substantial cost and increase state growth. Web3 applications therefore separate ownership or integrity records from bulk data storage.
6.1 Content addressing
In content-addressed systems, a file is identified by a cryptographic digest of its content. If the content changes, its identifier changes. IPFS uses content identifiers and a distributed retrieval model. Pinning services improve availability by maintaining copies, but pinning is an operational service and should not be confused with guaranteed permanence.
6.2 Permanent or incentivized storage
Arweave is designed around long-term data storage economics. Filecoin uses markets and cryptographic proofs to coordinate storage providers. These systems have different pricing, retrieval, replication and governance models. A professional deployment should examine service continuity, geographic redundancy, encryption, legal jurisdiction and recovery procedures.
Storage integrity and confidentiality are separate properties. A content hash can show that retrieved data matches a known file, but it does not make the file private. Sensitive information should be encrypted before decentralized publication, with keys managed under an explicit access-control policy.
Metadata is a frequent failure point. If a token points to a mutable web URL, the associated image or document may be replaced. Content-addressed metadata reduces this risk, but the application must also ensure that the referenced content remains retrievable.
7. Indexing and Data Access
Blockchains are optimized for verifiable state transitions, not complex queries. Reading every block and reconstructing application state at request time is expensive and slow. Indexers consume blocks, decode events, transform data and expose query interfaces.
An indexer typically contains:
A chain listener or node connection.
A decoder for transactions, logs and state changes.
A database with application-specific entities.
A reorganisation handler.
An API or query layer.
Monitoring, backfilling and data-integrity controls.
The most important operational principle is that indexed data is derived data. The canonical chain remains the source of truth. Indexers must handle chain reorganisations, failed transactions, event omissions, contract upgrades and changes in token standards. A robust indexer records block numbers and block hashes, supports rollback, and periodically reconciles derived records with canonical state.
Managed indexing services improve development speed but introduce provider dependence, pricing risk and possible availability or censorship concerns. A critical application may use multiple providers or operate its own indexing pipeline.
8. Evaluating Scalability and Trade-offs
Scalability is multidimensional. Throughput alone is insufficient. A network may process many transactions but provide poor user experience if finality is uncertain, data is unavailable or fees are volatile.
Important metrics include:
Throughput: transactions or computation units per second.
Latency: time until a transaction is included.
Finality time: time until reversal becomes highly improbable or cryptographically impossible under stated assumptions.
Cost: user fee plus bridging, storage, indexing and operational costs.
Availability: probability that users can submit transactions and retrieve required data.
Decentralization: distribution of validation, sequencing, governance and infrastructure.
Security margin: economic and technical cost of violating protocol assumptions.
A useful capacity measure is utilization:
u = λ ÷ μ
Here, u is utilization, λ is the incoming transaction rate, and μ is the service capacity, both measured in transactions per second. The formula assumes comparable transaction units and a stable measurement interval. As u approaches 1, queues and confirmation delays generally become more sensitive to demand variation. It is therefore poor practice to design a system permanently at nominal maximum capacity.
The blockchain trilemma should not be treated as a rigid theorem. Protocol engineering can improve all three dimensions relative to an earlier design, but resources and trust assumptions remain limited. For example, increasing block size may increase throughput while raising hardware and bandwidth requirements, potentially reducing validator diversity.
9. Applied Case: A Multichain Supply-Chain Finance Platform
The following is an illustrative case, not a report of a specific company.
Background
A financial-technology firm wants to tokenize invoices issued by small manufacturers. Investors purchase fractional claims, while suppliers receive early payment. The platform must support identity checks, document storage, investor reporting and settlement in a stable-value asset.
Problem
The firm initially proposes putting all invoice documents and transactions on a single high-value L1. Testing shows that document storage is expensive, investor searches are slow, and peak issuance periods produce unpredictable fees. Management considers a low-cost sidechain and a rollup but is concerned about bridge security and regulatory auditability.
Analysis
The legal ownership record and settlement obligations require a strong, auditable anchor. Invoice PDFs and confidential purchase orders should not be public. Investors require fast portfolio queries, but those queries do not need to be executed by the settlement chain itself. Cross-chain movement of stable-value assets creates additional custody and compliance risks.
Approach
The architecture adopts the following design:
A regulated L1 contract records issuance, redemption rules, compliance status and final settlement events.
A rollup handles frequent investor transfers and portfolio interactions.
Encrypted documents are stored in a controlled repository, while content hashes and document versions are anchored on-chain.
A permissioned indexer exposes investor dashboards and preserves block references for audit.
The bridge is restricted to approved assets, uses rate limits and has an emergency pause governed by a documented committee.
Withdrawal and recovery procedures are tested before production deployment.
Outcome
The design lowers routine transaction cost and improves search performance while retaining an auditable settlement anchor. It does not eliminate risk: the rollup sequencer, bridge, document-key management and compliance committee remain critical dependencies. The firm therefore publishes a risk register and discloses which components are decentralized, permissioned or externally operated.
Learning points
First, not every datum belongs on-chain. Second, a low-cost network is not automatically a secure scaling solution. Third, interoperability should be minimized where a single-chain design is adequate. Finally, architectural claims must specify exactly which component provides security and who can intervene during failure.
10. Governance, Regulation and Professional Practice
Infrastructure decisions have legal and ethical implications. A bridge operator or sequencer may possess powers comparable to a financial intermediary. Tokenized assets may trigger securities, payments, custody, consumer-protection or data-protection obligations depending on jurisdiction and use.
Public blockchains create tension with privacy regulation because personal data may be difficult or impossible to delete. Applications should avoid placing unnecessary personal information on-chain. Data minimization, encryption, pseudonymization and carefully designed retention policies are essential.
Governance must be explicit. The following controls are recommended:
publish trust assumptions and administrator powers;
use independent audits and formal verification where appropriate;
apply multisignature controls with geographically and organizationally diverse signers;
enforce transaction limits and anomaly monitoring;
maintain incident-response and disclosure procedures;
test upgrades, pauses and recovery paths;
separate development, staging and production keys;
monitor sequencer uptime, bridge balances, proof status and indexer lag;
disclose service-provider dependence to users.
AI can assist with anomaly detection, contract review and operational monitoring, but it should not be treated as a substitute for deterministic verification or expert security review. Models may generate false positives, miss novel attacks or expose confidential transaction data. Human accountability remains necessary.
11. Contemporary Developments
Several developments are reshaping infrastructure design. Modular blockchain architectures separate execution, settlement, consensus and data availability. Data-availability sampling seeks to let validators verify that large datasets are available without downloading every byte. Shared sequencing attempts to reduce fragmentation among rollups, although it introduces governance and coordination questions. Interoperability protocols increasingly use standardized message formats and proof systems rather than simple multisignature custody.
Account abstraction is improving wallet flexibility by enabling sponsored fees, programmable recovery and alternative authentication. However, these features increase dependence on paymasters, relayers and wallet infrastructure. Restaking-based security markets may provide additional economic guarantees, but they can also create correlated failure and governance risks.
The strategic direction is therefore not simply “more chains.” It is a more modular infrastructure in which each component has a defined role. Professional architects must evaluate whether modularity reduces cost and improves specialization or instead creates hidden dependencies that users cannot understand.
Best-Practice Design Framework
Before selecting a network or service, document:
Application requirements: transaction types, data volume, latency and geographic users.
Security objective: what must never happen, and what losses are tolerable?
Trust model: which operators, committees, sequencers or providers are trusted?
Data model: what belongs on-chain, in decentralized storage, or in confidential databases?
Interoperability need: whether cross-chain communication is essential or merely convenient.
Failure mode: how users exit, recover funds and obtain records during downtime.
Governance: who can upgrade, pause or change fees, and how those actions are constrained.
Compliance: identity, custody, privacy, financial regulation and audit requirements.
Operational plan: monitoring, key management, incident response and provider redundancy.
User disclosure: clear communication of finality, fees, risks and decentralization limits.
Chapter Summary
Web3 infrastructure is a layered system comprising settlement networks, scaling systems, interoperability protocols, storage and indexing services. Layer 1 networks provide native consensus and settlement but face limits in capacity and cost. Rollups increase execution capacity by processing transactions away from the L1 and publishing data or proofs for settlement. Optimistic rollups depend on challenge mechanisms, while validity-proof rollups depend on proof generation and verification. Sidechains may be efficient but generally have independent security assumptions.
Bridges and cross-chain messaging expand application reach but introduce risks involving custodians, validators, relayers, replay, reorganisation and message authentication. Decentralized storage improves content integrity and availability but does not automatically provide privacy or permanence. Indexers make blockchain data usable while remaining derived systems that must handle reorganisations and preserve links to canonical state.
Sound infrastructure decisions assess throughput, latency, finality, cost, availability, decentralization and security together. The most appropriate architecture is determined by application requirements, trust assumptions, regulatory obligations and failure-recovery plans rather than by marketing labels alone.
Key Terms
Layer 1: A base blockchain that provides consensus, execution and settlement.
Layer 2: A scaling system that processes activity separately while relying on an L1 for defined security or settlement functions.
Rollup: An off-chain execution system that submits transaction data, commitments or proofs to an L1.
Optimistic rollup: A rollup that assumes proposed transactions are valid unless successfully challenged.
Validity-proof rollup: A rollup that submits cryptographic proof that a state transition is valid.
Sidechain: An independent blockchain connected to another network but not necessarily secured by it.
Data availability: The ability of participants to obtain data required to verify or reconstruct blockchain state.
Sequencer: A component that orders transactions for a rollup or scaling system.
Bridge: A protocol or service that transfers assets or authenticated messages between networks.
Cross-chain message: Data or an instruction transmitted from one blockchain domain to another.
Light-client bridge: A bridge that verifies evidence of another chain’s consensus rather than relying solely on a committee.
Content addressing: Identifying data through a digest derived from its contents.
IPFS: A distributed content-addressed protocol for storing and retrieving data.
Indexing: Transforming raw blockchain activity into searchable, application-oriented data.
Finality: The condition under which a transaction is considered irreversible under stated assumptions.
State: The current data maintained by a blockchain, including balances and contract storage.
Multisignature: A control requiring signatures from multiple authorized parties.
Modular blockchain: An architecture that separates functions such as execution, settlement and data availability.
Blockchain trilemma: The design tension among decentralization, security and scalability.
Review Questions
5 Short Answer Questions
What is the principal difference between a Layer 1 and a Layer 2 network?
How does an optimistic rollup respond to an invalid state transition?
Why is content addressing useful for decentralized storage?
What is the role of an indexer in a Web3 application?
Name two security questions that should be asked when evaluating a bridge.
5 Long Answer Questions
Compare Layer 1 networks, rollups and sidechains in terms of settlement, security, cost and decentralization.
Explain the operational and security differences between optimistic and validity-proof rollups.
Discuss why cross-chain messaging creates risks beyond those of a single-chain application.
Evaluate the claim that decentralized storage automatically provides permanent and private data storage.
Explain how a Web3 architect should apply the blockchain trilemma when selecting infrastructure.
3 Analytical / Application Questions
A gaming application requires low fees and rapid interactions but must preserve valuable player assets. Propose an infrastructure architecture and justify the location of execution, settlement, metadata and indexing.
A bridge relies on five signers, of whom three must approve a transfer. Analyse its trust assumptions and recommend operational controls for reducing compromise risk.
An indexer reports ownership of an asset that is not visible after a chain reorganisation. Explain how the incident should be investigated and how the indexer should be redesigned to prevent recurrence.
Multiple Choice Questions with Answers
Question 1
Which function is most characteristic of a Layer 1 blockchain?
A. Providing native consensus and settlement
B. Only storing images for applications
C. Serving as an off-chain search database
D. Relaying unauthenticated messages between chains
Correct Answer: A. Providing native consensus and settlement
Question 2
What is the defining security mechanism of an optimistic rollup?
A. Every transaction is permanently stored as a full L1 transaction
B. Invalid state transitions can be challenged during a dispute period
C. A custodial committee signs every user transaction
D. No data or proof is submitted to the settlement chain
Correct Answer: B. Invalid state transitions can be challenged during a dispute period
Question 3
Why can a validium usually offer lower costs than a rollup?
A. It eliminates all cryptographic verification
B. It does not use smart contracts
C. It keeps transaction data off the principal L1
D. It prevents users from submitting transactions
Correct Answer: C. It keeps transaction data off the principal L1
Question 4
Which statement best describes a sidechain?
A. It is always secured by the validator set of its parent chain
B. It is an independent blockchain connected to another network
C. It is only a database index of an L1
D. It cannot execute smart contracts
Correct Answer: B. It is an independent blockchain connected to another network
Question 5
What is the primary purpose of a cross-chain message nonce?
A. To increase block size
B. To identify and help prevent replay of a message
C. To encrypt all files in decentralized storage
D. To determine the price of gas
Correct Answer: B. To identify and help prevent replay of a message
Question 6
Which statement about content addressing is correct?
A. Changing the content normally changes its content-derived identifier
B. It guarantees that data is confidential
C. It requires all data to be stored directly on an L1
D. It eliminates the need for storage providers
Correct Answer: A. Changing the content normally changes its content-derived identifier
Question 7
An indexer should treat which source as the canonical source of blockchain truth?
A. Its cached API response
B. A social-media announcement
C. The canonical chain state
D. An unverified user interface
Correct Answer: C. The canonical chain state
Question 8
If a system receives λ = 60 transactions per second and has capacity μ = 100 transactions per second, its utilization u = λ ÷ μ is:
A. 0.06
B. 0.40
C. 0.60
D. 1.67
Correct Answer: C. 0.60
Question 9
Which factor most directly distinguishes a bridge from simple asset storage?
A. A bridge authenticates or coordinates state between different blockchain domains
B. A bridge only compresses files
C. A bridge removes the need for consensus
D. A bridge guarantees that every transaction is private
Correct Answer: A. A bridge authenticates or coordinates state between different blockchain domains
Question 10
Why should a professional architecture document trust assumptions explicitly?
A. To ensure marketing claims replace security analysis
B. To identify who or what must remain reliable for the system to operate safely
C. To make all components equally decentralized automatically
D. To prevent users from understanding system limitations
Correct Answer: B. To identify who or what must remain reliable for the system to operate safely
Web3, DeFi & Blockchain Applications
Chapter 6
of 15