Title: Survey of Blockchain Architectures

Executive summary This report surveys core blockchain architecture patterns—how participants join, how consensus orders work, how scalability is achieved, and how execution is organized—and explains their trade-offs with concrete mechanisms and representative systems. It organizes architectures along four interacting axes: who participates (public/permissioned/consortium), how the network agrees (PoW/PoS/BFT/hybrids), how scalability is handled (monolithic vs layered vs modular), and where and how execution happens (on-chain full validation vs off-chain with on-chain proofs/settlement) Scalability spans layers and inter-chain/technology dimensions^[7] Consensus mechanisms fall into groups capturing throughput/security/energy/flexibility trade-offs^[9]. We conclude with a practical recipe for aligning architecture to requirements such as censorship resistance, throughput, latency, and regulatory control.

1. Public (permissionless) blockchains What they are and how they work Public blockchains are open to anyone for read/write/validate participation. Transactions are bundled into blocks, cryptographically linked into a chain, and added via a consensus mechanism that secures the ledger. Bitcoin exemplifies a proof-of-work (PoW) design: miners repeatedly hash the block header (including a nonce) to find a value below the current target, committing computational effort to produce a valid chain of proofs-of-work; validators accept the lowest-work chain as the canonical ledger The block header provides a nonce field enabling repeated hashing for proof-of-work mining^[21] Mining hashes the block header repeatedly, changing the nonce to achieve a target hash^[22] Block headers are serialized and hashed as part of Bitcoin’s proof-of-work algorithm^[25]. Execution and settlement are native to the base chain; smart contracts are integral to many public systems (e.g., Ethereum). The account- or script-based state allows complex interactions and is the natural substrate for AI agents that maintain on-chain state and interact with contracts Proof-of-Work is the native security primitive enabling settlement^[22].

Examples and traits Bitcoin’s base ledger stores UTXO commitments in the block header’s Merkle root; clients verify inclusion via Merkle proofs and reject conflicting chains lacking work, achieving strong censorship resistance with native token economics (Bitcoin) and no trusted setup Including the Merkle root lets the block header fingerprint the full set of transactions^[26] Request and verify a Merkle proof for a specific transaction against the header’s Merkle Root^[28]. Ethereum evolved from an UTXO ledger to an account-based, Turing-complete EVM environment with on-chain programmatic settlement and a move toward PoS; rollups then provide a way to outsource execution to off-chain virtual machines while settling on Bitcoin/Ethereum with proofs or fraud monitoring Layer-1 approaches like committee consensus and sharding, and Layer-2 methods, improve scalability^[1].

Core traits and trade-offs

• Open participation: permissionless membership and native token incentivize honest behavior and tolerate Byzantine faults with security proportional to stake or hashpower. Public cryptocurrencies followed Nakamoto in using PoW, reflecting hashpower-based security^[6].
• Strong censorship resistance and trust minimization come with lower throughput, higher fees under peak demand, and slower finality; governance is organic and often token-weighted. We categorize consensus into performance groups—high throughput vs strong security vs low energy—refl ecting trade-offs^[9].
• Maximum transparency and auditability are baked in; AI agents and oracles can read/produce events, but off-chain reliance introduces new attack surfaces that must be mediated by on-chain attestation and monitoring. Best-for use cases Censorship-resistant financial systems, public settlement layers, global programmable money, and open financial compositing benefit from decentralization and native token security. Consensus choices map to security and energy profiles^[9].

1. Private (permissioned) blockchains What they are and how they work Private chains restrict participation to known entities, using identity-based access control and BFT-style consensus rather than economic staking/mining. The network flow typically consists of client endorsements, ordering (sequencing) by a trusted or consortium-run ordering service, and peer validation via digital signatures; light clients and fraud checks add security without full PoW cost Orderers coordinate producers and peers to create the canonical transaction order; the ordering service mediates between orderers and peers^[11] Fabric uses an endorsing-and-ordering mechanism: endorsers produce digitally signed endorsements and orderers sequence them into blocks^[18] A BFT ordering service for Fabric employs a new BFT consensus library to sequence blocks^[13]. Ordering services can be Kafka-based clusters for throughput and fault tolerance, or BFT variants for Byzantine resilience under known validators Configure an orderer cluster to use a Kafka cluster to run the Fabric ordering service^[12] A SmartBFT library is proposed to be integrated into Fabric’s ordering service^[19].

Examples and traits Hyperledger Fabric is a canonical example; R3 Corda focuses on “ledger by contract” with peer-to-peer note finality and notarization rather than global chain growth. Both target enterprise workflows where identity governance supersedes monetary incentives Fabric 3 emphasizes robust, industrial-grade BFT consensus as a data integrity and trust layer for enterprise and AI initiatives^[20].

Core traits and trade-offs

• Controlled validator set and identity-based ACLs improve performance, regulatory alignment, and operational costs.
• Faster, cheaper transactions with lower energy and more flexible governance; however, trust is delegated to the consortium or operator.
• Reduced censorship resistance: adversarial operators or notaries can censor or reorder transactions; clients rely on proofs or notarization to detect fraud. Best-for use cases Enterprise coordination (supply chains, inter-bank settlement, confidential transactions), compliance-sensitive data sharing, and line-of-business applications where throughput/latency and governance predominate over censorship resistance. Fabric avoids high energy consumption of PoW blockchains while providing permissioned order and endorsement^[15].

1. Consortium / federated blockchains What they are and how they work Consortium chains occupy middle ground: participation and validation are restricted to a pre-approved set of organizations with shared governance. Sequencing and validation leverage BFT-style protocols among known validators and identity-based access, akin to permissioned chains but with multi-party oversight and possibly cross-organization smart contracts. They can be viewed as “multi-company permissioned” networks where a group consortium controls policy, validator sets, and upgrades. Public/permissionless surveys note scalability/governance patterns; permissioned/consortium blockchains are treated as semi-decentralized with pre-approved validators^[3]. Examples and use cases Industries deploy consortiums to coordinate cross-stakeholder ledgers; these systems trade some decentralization for resilience and compliance across partners, often deploying BFT or permissioned consensus.

Traits and trade-offs

• Semi-decentralized, auditable coordination with identity and regulatory alignment.
• Faster and more flexible than public chains, with lower transparency to outsiders.
• Security hinges on the integrity of the consortium rather than token economics. Best-for use cases Multi-stakeholder coordination without full public exposure—trade financing, inter-bank payment rails, supply chain provenance.

1. Layered architectures (Layer 1 vs Layer 2) Layer 1 (Base chain) The base chain defines the settlement ledger with final consistency, core consensus/security, and on-chain execution. Changes in this layer scale the entire network and alter security assumptions. Common techniques historically include committees, sharding, and committee-assembled blocks (committee-based consensus), and more recently modular separations. Scalability enhancement is mainly done by layer-1 solutions such as committee-based consensus protocols and sharding^[1] Scalability spans inner-chain (e.g., sharding) and inter-chain/technology dimensions^[7].

Layer 2 (Scaling layers) Rollups (optimistic and zk), state channels, and sidechains offload computation, state, and sequencing from the base chain while anchoring to it for final settlement. They can increase TPS, reduce fees, and shorten latency, trading off architectural complexity and trust assumptions. Layer-2 scaling techniques, including ZK-Rollups and Optimistic Rollups, offload computations from Layer-1, thereby reducing energy and emissions^[10]. Mechanics and trade-offs

• Optimistic rollups batch state changes on-chain and rely on “postage” tokens and off-chain challenge periods (fraud proofs) to ensure honesty. If no fraud is posted, outputs are considered final; otherwise, disputes resolve with base-chain enforcement and partial rollbacks. Optimistic rollups offload work to L2 with energy benefits; complexity and trust assumptions vary^[10].
• Zero-knowledge rollups produce ZK-SNARKs/STARKs or KZG-based commitments to prove validity off-chain and post compact proofs; they offer stronger guarantees but require careful trusted setups in some schemes and careful code to avoid invalid proof races. ZK-Rollups offload work and can reduce energy^[10].
• State channels allow parties to state-interact off-chain and only commit winning states to the base chain after a long “timeout” or challenge period, reducing congestion. Layer-2 approaches are primary pathways to scale^[1].
• Data availability and finalization risk: naive light clients may accept invalid chains if data is withheld; DA sampling, proofs, and DA improvements (Proto-Danksharding, KZG retention, fraud proofs) mitigate these risks. Kroma-style systems separate execution and consensus on the shared base chain and rely on data availability via fraud proofs and ZK proofs^[40] A naïve light client can be tricked into believing a chain is valid by a malicious consensus without accessible data^[32] EIP-4844 (Proto-Danksharding) adds KZG commitments retained for ~18 days, making blob data verifiable and critical for fraud proofs^[35]. Overall Layer designs are the most mature scalability knob today, with clear operational trade-offs: lower fees and faster speed at the cost of added complexity, and varying trust minima (on-chain proof vs ZK vs optimistic challenge windows). Layer-2 and sharding improve efficiency but add complexity and raise regulatory considerations^[2] ZK and optimistic rollups reduce energy by offloading; complexity varies^[10].

1. Modular vs monolithic blockchains What the terms mean Monolithic chains keep execution, consensus, and data availability tightly coupled in a single runtime; performance often depends on changing the core, which can complicate scaling and experimentation. Modular or “modularized” chains split responsibilities—e.g., a validator or consensus layer, an execution/sharding layer, and a data availability or sampling layer—enabling specialized optimizations and pluggable trust boundaries. Consensus designs group along throughput/security/energy/flexibility; modularization reframes these trade-offs across layers^[9]. Mechanics in practice

• Cosmos SDK systems can run distinct validators per application, share a proof-of-stake security substrate (or custom consensus), and exchange data via interoperability and relayers. Separation of concerns allows upgrades without changing core security in many modules. Scalability across inner-chain and inter-chain dimensions reflects modular designs used in practice^[7].
• Execution-and-consensus separation (post-Merge Ethereum) decouples a Proof-of-Stake Beacon Chain (consensus) from rollups’ execution environments; L2s rely on proofs (fraud or ZK) and base-chain DA properties to be safe and fast. Ethereum’s Merge created a separate consensus layer (Beacon Chain) and rollups rely on data availability via fraud proofs and ZK proofs^[40].
• Data availability layers/DA sampling: clients need assurances that committed data exists and can be checked; DAS enables sampling proofs to catch withholding without downloading everything; fraud proofs let the network contest invalid states. Data availability issues threaten naive light clients, motivating proofs and sampling^[32] The “minimal viable merged consensus” literature discusses designs where transaction data posted on-chain, combined with fraud proofs, secures rollups^[34]. Rationale and trade-offs Modular systems offer more flexible scaling and specialization—e.g., one fast execution/availability engine secured by a robust consensus core—but introduce cross-layer coordination and correctness risks (proof verification, DA expiry, trust in the rollup code). A simple L2 security and finalization roadmap shows acceptable tradeoffs even for ZK-OP systems, with risks that the single ZK-EVM or proof system could be incorrect^[36]. Examples and best-for-fit
• Cosmos and IOV-style ecosystems: share security across chains with pluggable execution and governance; good for multi-organization L1s and L2s seeking interoperability and upgrade flexibility. Inter-chain and technology dimensions capture modular ecosystems^[7].
• EVM/OP Stack or OP equivalents: use a shared execution environment with optimistic or ZK rollups; good for application developers wanting fast, cheap transactions with base-chain finality as backup. EIP-4844’s Proto-Danksharding and KZG retention improve rollup finality and fraud proof viability^[40].
• Celestia/IOV-style minimal layers: focus on proof-of-stake security for a data availability substrate, with execution VMs or rollups tailored to state-machine needs. Celestia-style networks use fraud proofs for correctness in a modular layer design^[40].
• Monoliths like Solana bundle execution, consensus, and DA in one stack for high performance and simple upgrade coordination but face steeper scaling limits and more contentious upgrades. Monolithic performance hinges on a single consensus/execution layer; flexibility demands changing core elements^[9].

1. Smart contract platforms vs UTXO-based chains Design distinction and mechanics

• UTXO-based (Bitcoin): Each transaction consumes previous outputs and creates new ones; the block header’s Merkle root commits to the full set of transaction outputs on chain, enabling point-in-time proofs via Merkle inclusion. UTXO immutability and spendability form a “coin”-like abstraction; programmatic logic is expressed as scripts at output level. This stateless design enables cheap pruning and fast SPV, and its separation from complex account states makes it easier to use as an integrity substrate for AI agents and oracles; agents request Merkle proofs for specific transactions and aggregate them to verify history without executing smart contracts. Including the Merkle root in the header commits to the set of transactions^[26] Light clients prove specific TXID inclusion by verifying the Merkle path against the Merkle Root^[28].
• Account-based (Ethereum/EVM): Ledgers track accounts with balances and code; transactions mutate account state and are validated by EVM semantics. Smart contracts execute in place, maintain complex state, and can create new contracts and tokens. This model supports AI agents that persist state, call contracts, and participate in DeFi oracles more directly than UTXO. Scalability and rollups Monolithic UTXO systems can add L2 rollups that run stateful EVMs or application-specific machines; in practice, UTXO-based L2s rely on zk-proofs or optimistic disputes over execution traces, while account-based L2s share an execution engine and data availability guarantees. ZK and optimistic rollups offload work from the Layer-1, reducing energy and increasing throughput^[10] L2s post proofs and data to the Layer-1 for finality, enabling fast and cheap execution^[40]. AI agent implications UTXO chains suit agents needing a simple, verifiable ledger of coinflows and verifiable snapshots without executing complex environments; account-based chains suit agents that hold accounts, deploy helper contracts, and manage continuous state machines.

1. DAG-based and alternative structures (IOTA) What they are and how they work Directed Acyclic Graph (DAG) ledgers replace linear chains with directed graphs where transactions directly point to prior transactions and can be validated in parallel. IOTA (the “tangle”) targets IoT and M2M transactions: parallel validation increases throughput, but security relies on honest majority, social graph topology, and validation effort rather than a single chain-of-proof or staked collateral; this trades latency/throughput gains for weaker first-mover and sybil resilience assumptions. Consensus mechanisms group along throughput/security/energy/flexibility; DAG-based designs reflect different security and performance assumptions^[9]. Architectural trade-offs

• Potentially higher throughput and lower fees due to parallelizable validation and no single block proof.
• Security depends on honest participation, graph governance, and resistance to selfish mining/topology attacks, requiring careful protocol and network design. Best-for use cases Low-cost, high-frequency machine-to-machine or edge transactions where latency and energy efficiency dominate and token economics rely on reputation or delegated trust rather than mined security.

1. Hybrid architectures What they mean and how they compose Hybrid architectures combine elements for resilience, privacy, and performance:

• Private chain with public anchoring: on-chain notarization or publication of proofs and merkle roots guarantees external auditability, while core data remains off-chain.
• Off-chain compute with on-chain settlement: AI agents compute and validate proofs (Merkle, ZK) off-chain and only write results or vouchers to-chain; L2s exemplify this pattern. ZK-rollups publish succinct proofs to Layer-1 for finality^[10].
• Cross-chain bridges and interoperability: proof-based or staked assets move across modular chains; correctness depends on accurate cross-chain proof systems and deposit/withdrawal mechanics. Inter-chain dimensions capture cross-chain data movement and interoperability^[7].
• Zero-knowledge bridging: commit-to-verify patterns, blob-to-proof designs, and KZG-based commitments provide verifiable summaries at base chain speed; optimistic dispute channels mitigate residual trust. KZG commitments retained for an 18-day window make data verifiable for fraud proofs^[35] Merkle proofs verify specific transaction inclusion efficiently^[28]. Rationale Hybrids aim to achieve best-in-class latency/throughput/cost while preserving base-chain security or audibility. They also allow enterprise-grade privacy (off-chain data) with regulatory comfort (on-chain proofs and vouchers).

Beyond-the-survey: governance and operations Governance differs by architecture:

• Public token-weighted blockchains centralize political power in token holders and disincentivize hard forks without consensus, creating resilient settlement with political friction. Bitcoin’s PoW ties security to hash work, evolving into a governance mechanism over upgrades^[6].
• Permissioned consortia outsource political power to operators/consortiums, accelerating upgrades but shifting trust vertically to administrators and notaries. BFT-based Fabric deployments centralize sequencing authority among known validators^[13]. Operations trade-offs mirror architecture: PoW is energy-intensive and slow to finalize; permissioned BFT systems prioritize throughput and availability but need membership governance and careful failure handling. Consensus underpins a single consistent and honest ledger; mechanism choice governs performance and cost^[5] High-throughput vs strong-security vs low-energy vs flexible designs reflect operational realities^[9].

Putting it together: a practical design playbook

• Choose participation: open/public for censorship resistance and fungibility (Bitcoin/Ethereum base) vs private/permissioned for regulated enterprise (Fabric/Corda-like) vs consortium for multi-party coordination.
• Pick a security model and throughput target: PoW for maximal censorship resistance (and slow/fast second-layer), PoS for sustainable throughput and finality (Ethereum Merge), or BFT for high-throughput private domains (Fabric 3+), with DA sampling and proof systems where data is large (Proto-Danksharding, rollups).
• Scale wisely: upgrade L1 only when necessary; add L2s for bandwidth/cost, anchored by proofs and DA guarantees. Layer-1 committee consensus and sharding improve scalability^[1] EIP-4844 improves DA for rollups^[40].
• Use modularization where possible: separate execution from consensus and add DA sampling or light-client hardenings.
• Decide agent integration: UTXO chains suit lightweight agents using Merkle-settlements; account-based chains suit full-state AI agents with contract APIs and identity.
• If your domain tolerates DAG assumptions, consider DAG-based designs for ultra-low-latency/microtransactions.

Open questions and research directions

• Rollup finality and DA: Improving DAS, shortening dispute periods, and making optimistic and ZK finality robust under network congestion and adversary pacing remain active areas. A survey overviews data-availability sampling and proposes improvements^[37].
• Cross-rollup composability: Aligning L2s via standardized proofs and canonical interfaces is a practical open problem.
• Hybrid security: Formalizing minimal trust assumptions in zk/optimistic stacks and reducing the blast radius of a single proof system or bridge failure are key for enterprise-grade AI systems.

Notes on evidence gaps and uncertainty Some vendor-grade details (e.g., exact throughput metrics, specific governance token-weightings) vary by release and are evolving; we conservatively avoid unverifiable specifics and stick to documented mechanisms where possible. Additional on-chain evaluations and peer-reviewed measurements would further calibrate throughput/latency trade-offs and proof-system performance in production. Architectural enhancement adds complexity and regulatory considerations that vary by deployment^[2].