Skip to content
Financial Context Wiki

Modular blockchain architecture

A dependency-based guide to separating execution, sequencing, data availability, consensus, settlement, proofs, bridges, governance and archival responsibilities.

Updated

For educational purposes only; not protocol, bridge or security advice. Modular labels do not define a system’s guarantees; verify every deployed component, data path, proof, clock, administrator, bridge and recovery route for the exact version and asset.

Direct answer

Modular blockchain architecture is a way to analyze how a system assigns responsibilities rather than a standardized product category. Execution, transaction ordering, state commitments, proofs or disputes, data publication and consensus, settlement, bridges, governance and long-term archival can be combined in one protocol, split across several systems, or duplicated across providers. One layer can perform several duties, and one duty can depend on several layers.

The useful question is therefore not whether a project is “modular,” but which component validates which object, who controls it, what happens when it stops, and how users independently recover state or assets. A sequencer receipt is not data availability or finality; a validity proof does not provide data; a settlement-chain commitment does not prove permanent retrieval; and shared settlement does not create synchronous cross-rollup composability.

How it works

  1. Pin the deployed system: execution and settlement chain IDs, protocol version, virtual machine, contracts, bridge and asset addresses, data-availability mode, operators, administrators and observation block or time. Marketing taxonomy cannot substitute for deployed configuration.
  2. Build a responsibility matrix. Separate transaction ingress and sequencing, deterministic execution, state commitment and proof or fault dispute, DA publication and its consensus, settlement acceptance and finality, bridge and cross-domain messaging, upgrades and pauses, and historical storage. Record overlaps instead of forcing one duty into one layer.
  3. Trace one transaction and batch end to end: signed input, sequencer or local receipt, ordered execution, encoded and compressed batch, calldata or blob or external-DA publication, state claim and proof or dispute, settlement finality, then message or withdrawal execution. Preserve hashes, versions, receipts and clocks at every boundary.
  4. Identify each verified object and trust assumption. Distinguish data commitment from bytes, availability during the protocol window from later retrieval, execution validity from consensus finality, and bridge accounting from asset liquidity. State who can replay, prove, challenge, censor, upgrade, pause or withhold each object.
  5. Reconstruct the capacity and fee ledger. Measure raw and compressed bytes, batch occupancy, DA price, proof and settlement overhead, execution and operator fees, bridge gas and liquidity fees. Average batch allocation is not the same as a user’s actual charge or the marginal cost of another transaction.
  6. Exercise failures rather than reading only normal-path throughput. Stop the sequencer, batch poster, prover, challenger, DA service, settlement RPC and bridge relayer; test forced inclusion, independent derivation, data reconstruction, proof or challenge, retry, exit and archival recovery under congestion and upgrade boundaries.
  7. Reconcile with canonical evidence. Match execution receipts and state roots to batch commitments, DA inclusion, proof or game status, settlement finality, bridge messages and final asset balances. Repeat the dependency review after reorganization, parameter change, contract upgrade or DA migration.

Worked examples

  • Batch cost and compression. A batch contains 5,000 transactions, 2,400 KB of raw inputs and 300 KB after compression. The compression ratio is 2,400 / 300 = 8.0x, and bytes fall by 87.5%. If DA costs 0.020 ETH and shared proof plus settlement overhead costs 0.005 ETH, shared average cost is (0.020 + 0.005) / 5,000 = 0.000005 ETH/tx. Adding 0.000020 ETH/tx of execution and operator cost yields 0.000025 ETH/tx. This is an allocation, not a guaranteed bill.
  • Sampling model boundary. In a teaching model, an adversary withholds 25% of shares and a client draws 20 independent uniform samples with replacement. The chance of missing every withheld share is 0.75^20 = 0.003171211939 = 0.3171211939%; detection probability is 99.6828788061%. Correlated peers, adaptive serving, erasure coding and the real protocol’s sampling rule can invalidate this simple model.
  • Committee safety and liveness. A 5-of-7 DA committee can form a new threshold attestation with at most 2 members unavailable; with 3 unavailable only 4 < 5 remain. Under a signature-only teaching rule, controlling 5 authorized signers can satisfy the threshold. A certificate still does not prove that five durable copies exist, that a user can retrieve bytes now, or that execution and settlement are valid.
  • Several clocks and a fast exit. A teaching soft confirmation arrives in 2 seconds, batch publication after 8 minutes, and settlement finality 13 minutes later: the precise elapsed time is 21 minutes 2 seconds. If an optimistic withdrawal adds a hypothetical 7 days, the total is 10,101 minutes 2 seconds. A fast bridge charging 0.15% on 10,000 USDC takes 15 USDC and delivers 9,985 USDC; speed adds bridge, liquidity-provider and reorganization assumptions rather than shortening the protocol clock.

Risks

  • Misidentifying the real responsibilities or layer boundaries.
  • Sequencer censorship, reordering or outage.
  • Forced inclusion being unavailable, permissioned or too slow.
  • Batch poster or state proposer outage.
  • Centralized prover failure or proof backlog.
  • No live, eligible or funded fault challenger.
  • Fault-game clock, bond, oracle or verifier failure.
  • Validity circuit, proving system or verification-key bug.
  • Data withholding during the required availability window.
  • Correlated sampling, eclipse or network-view failure.
  • DA committee threshold collusion or key compromise.
  • Available protocol data lacking durable independent archives.
  • Settlement reorganization or finality misclassification.
  • Bridge, messenger, replay or destination-execution failure.
  • Fast-bridge insolvency, inventory shortage or adverse pricing.
  • Administrator, multisignature or security-council compromise.
  • Immediate upgrade, incompatible version or inadequate escape delay.
  • DA fee spike, blob congestion, smaller batches or subsidy expiry.
  • State, data, proof, contract or client version mismatch.
  • Asynchronous cross-domain ordering, partial completion or composability failure.

Common misconceptions

  • Modular architecture is automatically more decentralized than a monolithic design.
  • A validity proof replaces data availability and historical retrieval.
  • Settling on Ethereum imports every Ethereum security property into every component.
  • A sequencer success message means final settlement and an executable withdrawal.
  • Higher TPS, shared DA or shared settlement guarantees lower costs and synchronous composability.

Sources

Navigation

Search the wiki...