Survey of Main Blockchain Architectures

Overview and classification

• Blockchains are architected as replicated state machines that record a sequence of transactions and expose an append-only ledger, where nodes reach consensus on ordering and validity via cryptographic work, voting, or hybrid mechanisms and assemble blocks into a chain or directed graph of states.In this paper, we present a survey of Blockchain technology, discussing its key concepts, architectural design, state-of-the-art use-cases/applications as well^[1]Each type of blockchain utilizes different permissions and technologies to come to consensus. Public permissionless blockchains such as Bitcoin ...^[6]
• Architectures broadly fall into permissionless/public and permissioned/sovereign settings; mechanisms include proof-based (e.g., PoW/PoS) and voting/quorum (BFT/PBFT) families, often combined with layered or sharded designs for scale and privacy.Permissionless blockchain could be public and will be fully decentralized. There could be Hybrid blockchains that could be considered both permissioned and ...^[6]The proof-based consensus algorithms are generally suitable for permissionless blockchains, whereas voting-based consensus algorithms are suitable for ...^[7]
• Canonical public chains (Bitcoin, Ethereum) illustrate permissionless, programmable ledgers; permissioned platforms (Hyperledger Fabric) and sovereign chains (R3 Corda) emphasize enterprise trust models, channels/privacy, and modular consensus.A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a.^[11]Transition to Proof of Stake. The Paris hard fork changed the underlying consensus mechanism of Ethereum from proof of work to proof of stake. Unlike all ...^[21]ABSTRACT. Fabric is a modular and extensible open-source system for deploying and operating permissioned blockchains and one of the Hyperledger.^[31]

1. Permissionless/public chain architecture (Bitcoin) Canonical term: Public, permissionless, proof-of-work blockchain (Nakamoto consensus). Mechanism and design: Decentralized network of nodes validates transactions and assembles them into blocks; leaders (miners) are chosen cryptographically (PoW hash difficulty) and append blocks to the main chain, making tampering expensive. Scripted payments occur via unspent transaction outputs (UTXOs).A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a.^[11] Concrete instance: Bitcoin, with global validator set, monetary policy embedded in consensus, and P2P propagation of blocks and transactions.A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a.^[11] Surveys confirm Bitcoin as a landmark implementation of proof-based (Nakamoto) consensus in a permissionless environment.Bitcoin is the first implementation of the BFT consensus protocol in a permissionless environment. Its consensus protocol is called Nakamoto Consensus protocol.^[2] Design alternatives: Proof-of-stake variants exist but, at the architectural level, Bitcoin’s UTXO ledger and miner-led block formation remain canonical.A survey of consensus algorithms in public blockchain systems for crypto-currencies. ... Permissionless and permissioned blockchain diffusion.^[10]

Cited system: Bitcoin mainnet, described by the seminal whitepaper.A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a.^[11]

Key terminology: UTXO, mempool, Merkle tree proof, transaction scripts, miner/nonce, fork choice, mining reward schedule.In this paper, we present a survey of Blockchain technology, discussing its key concepts, architectural design, state-of-the-art use-cases/applications as well^[1]

1. Smart contract/permissionless architecture (Ethereum) Canonical term: Turing-complete programmable blockchain with on-chain contracts and tokens (Ethereum Virtual Machine). Mechanism and design: Nodes execute bytecode contracts, store state in an append-only blockchain with persistent storage (key-value or Merkle Patricia trees), and use gas for resource metering. Ethereum introduced programmable consensus upgrades from PoW to PoS via the Beacon Chain (Merge).Transition to Proof of Stake. The Paris hard fork changed the underlying consensus mechanism of Ethereum from proof of work to proof of stake. Unlike all ...^[21]It uses a blockchain to synchronize and store the system's state changes, along with a cryptocurrency called ether to meter and constrain execution resource ...^[29] Concrete instance: Ethereum mainnet (pre/post-merge), execution environment (EVM), staking and validators through Beacon Chain as a proof-of-stake overlay.Transition to Proof of Stake. The Paris hard fork changed the underlying consensus mechanism of Ethereum from proof of work to proof of stake. Unlike all ...^[21]From 2015 onward, Ethereum (ETH) pursued a long-term roadmap known as Serenity, culminating in the transition from proof of work to proof of stake. The Beacon ...^[22] Surveys and design overviews confirm the smart-contract substrate, gas pricing, and long-term consensus transition as canonical architectural choices.In mid-2014, a yellow paper was published by Gavin Wood that defined the technical specification of EVM and how it would work. The yellowpaper ...^[26]Ether (ETH or Ξ) is the native cryptocurrency of the platform.^[25]

Cited systems: Ethereum mainnet; Ethereum 2.0 Beacon Chain post-merge.Transition to Proof of Stake. The Paris hard fork changed the underlying consensus mechanism of Ethereum from proof of work to proof of stake. Unlike all ...^[21]

Key terminology: EVM, account abstraction (external/internal), storage trie/Merkle Patricia tree, gas cost, opcode set, contract deployment/address derivation, Beacon Chain, validator slashing, custody deposits.It uses a blockchain to synchronize and store the system's state changes, along with a cryptocurrency called ether to meter and constrain execution resource ...^[29]

1. Permissioned/enterprise chain architecture (Hyperledger Fabric) Canonical term: Peer-to-peer, permissioned, modular BFT-based ledger with channels, collectives, and configurable consensus. Mechanism and design: Nodes join defined organizational domains; ordering services sequence transactions and deliver block streams to channels; membership services and policies govern who participates in consensus or channel joins; smart contracts (chaincode) run in Docker containers and are updated via config blocks; architecture decomposes into execute–order–validate modules.This paper describes Fabric, its architecture, the rationale behind various design decisions, its most prominent implementation aspects, as well^[36]HLF v1 approach in one line: execute → order → validate. Permissioned blockchain architecture – overhauled. ▫ Modular/pluggable ...^[34] Concrete instance: Hyperledger Fabric from IBM/ Linux Foundation, widely adopted in consortium networks and IBM Cloud enterprise deployments.The Hyperledger Fabric is a permissioned blockchain platform aimed at business use. It is open-source and based on standards, runs user-defined ...^[32]> July 2017: Hyperledger Fabric 1.0 Released. > Hyperledger Fabric on IBM Cloud - IBM Blockchain Platform (formerly HSBN) on highly secure Linux on ...^[39] Surveys highlight HLF’s pluggable consensus (PBFT, Kafka, Raft), channels for privacy/multi-tenancy, and platform-as-a-service availability.ABSTRACT. Fabric is a modular and extensible open-source system for deploying and operating permissioned blockchains^[31]This paper describes Fabric, its architecture, the rationale behind various design decisions, its most prominent implementation aspects, as well ...^[36]

Cited systems: Hyperledger Fabric 1.x deployments; IBM Blockchain Platform.> July 2017: Hyperledger Fabric 1.0 Released. > Hyperledger Fabric on IBM Cloud - IBM Blockchain Platform (formerly HSBN) on highly secure Linux on ...^[39]

Key terminology: Peer, membership service provider (MSP), channel, ordering service, Kafka vs. PBFT, chaincode (smart contract), configuration transaction, collectives/policies, MSP keystone/anchors.The Hyperledger Fabric is a permissioned blockchain platform aimed at business use. It is open-source and based on standards, runs user-defined ...^[32]

1. Hybrid/partitioned and consortium architectures Canonical term: Hybrid permissioned/permissionless, consortium chains, and domain-specific sovereign blockchains. Mechanism and design: Hybrid chains blend public and private features (e.g., validator participation, data availability, or privacy channels), while consortium designs restrict validator sets to collaborating organizations; both adapt BFT/PBFT or PoA variants and can host business logic in chaincode or enterprise-grade smart contracts.Permissionless blockchain could be public and will be fully decentralized. There could be Hybrid blockchains that could be considered both permissioned and ...^[6] Concrete instance: Enterprise platforms (R3 Corda, Hyperledger Fabric) and hybrid testnets/production deployments in banking and supply chains; surveys explicitly map hybrid membership to use cases.A survey of consensus algorithms in public blockchain systems for crypto-currencies. ... Permissionless and permissioned blockchain diffusion.^[10]

Cited systems: Hyperledger Fabric, R3 Corda deployments in financial services; Ethereum-based consortiums leveraging private transactions and access control.Permissionless blockchain could be public and will be fully decentralized. There could be Hybrid blockchains that could be considered both permissioned and ...^[6]

Key terminology: Consortium, validator set governance, regulated-ledger, zk-statement, range proofs, confidential transactions, shielded/partially-homomorphic channels.Hybrid blockchains that could be considered both permissioned and ...^[6]

1. Scaling layers and rollups (Layer-2) architectures Canonical term: Validium and Zero-Knowledge Rollups (ZKRs), Optimistic Rollups. Mechanism and design: Layer-2 rollups execute transactions off-chain and publish succinct proofs or transaction roots to Layer-1; optimistic rollups commit rollup state and deposit security and allow fraud proofs over a challenge window, whereas ZK rollups commit a cryptographic zk-SNARK/STARK and enable instant/finality-reducing L1 verification cost.In an optimistic rollup, L2 block producers broadcast transaction data to an on-chain rollup contract and stake some funds to vouch for the validity of those ...^[42]Unlike optimistic rollups re- quiring a fraud proof window, ZK rollups achieve instant finality through cryptographic verification—the ...^[46] Concrete instance: Ethereum ecosystem rollups such as optimistic rollups (e.g., OVM-based rollups) and ZK rollups (e.g., zkSync/Matter Labs), with zkRollups contrasting proof design, upgradeability, and security hardening.Optimistic Rollup is a potential solution candidate for Layer2. Similar to zk Rollup, all Transaction information will be “saved” as CallData in Layer1.^[43]Cryptomeria Capital, 2023 5. 2 Current ZK Rollups Landscape I. zkSync. Introduction zkSync is developed by Matter Labs ZKR and stands out with ...^[47] Cross-technique comparisons emphasize design trade-offs (proof size, verifier cost, upgradability, fraud-challenge latency), and newer TEE-backed rollups (TeeRollup) seek to hybridize trust assumptions and performance via heterogeneous TEEs.Existing rollup solutions either leverage complex zero-knowledge proofs or optimistically assume execution correctness unless challenged.^[44]Our experimental results indicate that TEEROLLUP outperforms zero-knowledge rollups (ZK-rollups), reducing on-chain verification costs by.^[48]

Cited systems: Ethereum Optimistic Virtual Machine (OVM) rollups; Matter Labs zkSync ZK-rollup; general rollup surveys/tutorials for design parameters (calldata inclusion, fraud proof windows).Optimistic Rollup is a potential solution candidate for Layer2. Similar to zk Rollup, all Transaction information will be “saved” as CallData in Layer1.^[43]Cryptomeria Capital, 2023 5. 2 Current ZK Rollups Landscape I. zkSync. Introduction zkSync is developed by Matter Labs ZKR and stands out with ...^[47]

Key terminology: Rollup contract, state root/root hash tree, fraud proof, challenge period, optimistic validity, zk-SNARK/SYNTAX/STARK, verification key, aggregator, Validium commit-and-prove, gasless deposits, canonical vs rollup L1/L2.ZK rollups achieve instant finality through cryptographic verification—the ...^[46]

1. DAG-ledger architectures (state DAGs/Tangle) Canonical term: Directed Acyclic Graph (DAG) ledger; state DAG underpinning (e.g., IOTA). Mechanism and design: Transactions reference multiple prior transactions (tips), forming a DAG of events; lightweight validation relies on proof-of-work-like micro-tasks; validators receive block rewards in terms of reduced work, and the ledger’s state is a DAG of balances/objects rather than linear blocks.Bitcoin White Paper - Written by Satoshi. Nakamoto in 2008, it describes the original plan and protocol for Bitcoin.^[20] Concrete instance: IOTA’s Tangle, which positions the ledger as a DAG of state objects and emphasizes IoT-scale, low-latency value transfer without traditional mining fees; surveys document alternative ledger structures to block trees.Bitcoin White Paper ... a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[10] Architectural trade-offs: DAGs aim to decouple block production from fees (no block reward) and improve scalability; however, proof-of-work alternatives and directed-graph liveness/security require careful design and empirical validation.In this paper, we present a survey of Blockchain technology, discussing its key concepts, architectural design, state-of-the-art use-cases/applications as well^[1]

Cited systems: IOTA/Tangle as a DAG-based cryptocurrency architecture.Blockchain and cryptocurrencies: A classification and comparison of ... In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[5]

Key terminology: Tip selection, DAG state trie, solidification (tip-to-tip path), Curl/Proof-of-Work function, coordinator, curl-inclusion, information timestamping.Bitcoin White Paper ... a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[10]

1. Multi-chain and interoperability architectures (Polkadot, Cosmos) Canonical term: Heterogeneous multi-chain with interoperability layer; cross-chain communication (relayers,IBC), and heterogeneous validators (Cosmos) or shared security via relay chains (Polkadot). Mechanism and design: Independent chains are connected via an interoperability layer or relay chain, exchanging validators’ signatures or proofs to coordinate security; cross-chain data transfer relies on relayers and message passing; heterogeneous VMs may participate if cross-chain messaging is supported; clients implement validators/relayers per chain rules.There could be Hybrid blockchains that could be considered both permissioned and ...^[6] Concrete instance: Cosmos IBC relayers enabling secure cross-chain transfer; Polkadot validators providing relay-chain security and interoperability for parachains; surveys distinguish permissioned/permissionless multi-chain platforms and their governance/security models.Permissionless blockchain could be public and will be fully decentralized. There could be Hybrid blockchains that could be considered both permissioned and ...^[6] Design guidance: Software architects select blockchain substrates based on decentralization, throughput, latency, and permissioning—principles used to map application needs to public, permissioned, or interoperable multi-chain topologies.In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]

Cited systems: Cosmos SDK with IBC relayers; Polkadot relay-chain + parachain substrate deployments.In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]

Key terminology: Interoperability bus, IBC (Tendermint relays), validator set per zone, proof-of-stake validators, cross-chain address derivation, relayer process, wormhole/gateway patterns, heterogeneity shim.Hybrid blockchains that could be considered both permissioned and ...^[6]

1. State machine replication and BFT-family architectures Canonical term: Practical Byzantine Fault Tolerance (PBFT)-based replication; Raft/Kafka-style cluster coordination. Mechanism and design: Replicated state machines shard work among replicas; ordering services produce a single canonical order of requests; PBFT variants provide safety/atomic multicast with O(n^2) messaging and proactive recovery; Raft/Kafka reduce state machine state to logs and leader-based replication; quorum and view-switching handle faults and liveness. Concrete instance: Hyperledger Fabric’s orderer service implementing PBFT or Kafka-like ordering; performance modeling papers study PBFT as a throughput bottleneck in large networks, motivating sharding and batching to scale state machine replication.HLF v1 approach in one line: execute → order → validate. Permissioned blockchain architecture – overhauled. ▫ Modular/pluggable ...^[34]This paper aims to investigate whether the consensus process using Practical Byzantine Fault Tolerance (PBFT) could be a performance bottleneck for networks ...^[35] Design trade-offs in “scalable consensus” research distinguish proof-based (PoW/PoS) vs voting-based (BFT/PBFT/Raft) suitability by permissioning and availability assumptions; proof-of-stake variants require cross-linking and committees while preserving finality.The proof-based consensus algorithms are generally suitable for permissionless blockchains, whereas voting-based consensus algorithms are suitable for ...^[7]This study addresses these challenges by simulating and comparing five widely used conventional consensus mechanisms (PoW, PoS, DPoS, PoA, and ...^[9]

2. Data availability and storage-layer architectures Canonical term: Data availability committees; commit-and-prove; Availability-Optimized Data Availability (A0DA); commit-chain; availability sampling. Mechanism and design: Availability proofs (e.g., Merkle roots of blocks) enable cheap verification of underlying data, with committees committing block roots and proving availability over time; “commit-chain” proposes commit-and-prove as the only necessary chain object; zk-statement proofs allow sampling-based verification of all data. Concrete instance: CommitChain style commit-and-prove (commitment + later availability proof) to shift verification cost off-chain while preserving soundness; A0DA optimizes prover work per committee and verifier cost; rollups rely on availability via L1 storage and rollup-custody proofs.Block. 139, 2021.^[1] Empirical and system-level work shows PBFT/availability bottlenecks in networks with large state machines, motivating proof-based replication or sampling to reduce communication to O(n√m) complexities in practice.This paper aims to investigate whether the consensus process using Practical Byzantine Fault Tolerance (PBFT) could be a performance bottleneck for networks ...^[35]

3. Blockchain-as-a-service and enterprise platforms Canonical term: SaaS blockchain platforms; enterprise fabric deployments; managed ordering/membership. Mechanism and design: Cloud providers operate permissioned/consortium networks with automated provisioning, identity, and SLA-backed availability; developers deploy chaincode and configure membership policies; integration layers expose APIs and governance-as-code. Concrete instance: IBM Blockchain Platform (formerly Hyperledger Explorer/HSBN) deploys Fabric 1.x on IBM Cloud with guided network setup and enterprise support; community and architecture surveys compare architectural choices to match regulatory and performance profiles.> Hyperledger Fabric on IBM Cloud - IBM Blockchain Platform (formerly HSBN) on highly secure Linux on ...^[39]In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]

Key terminology: SaaS chain, managed ledger, identity-as-a-service, policy-as-code, chain governance, SLA-aware ordering, delegated admin.In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]

1. Privacy and confidential transaction architectures Canonical term: Shielded channels; range proofs; zk-SNARK circuits; confidential transactions. Mechanism and design: Range proofs hide values behind elliptic-curve polynomial commitments while proving sum bounds; zk-SNARKs obfuscate computations and expose only verification keys; confidential transactions deploy these proofs to keep sender/receiver/amount confidential while preserving correctness and enabling fungibility.A survey of consensus algorithms in public blockchain systems for crypto-currencies. ... Permissionless and permissioned blockchain diffusion.^[10] Concrete instance: Bitcoin Confidential Transactions, Monero Bulletproofs, and Ethereum private transaction proposals exemplify value-concealed transfers validated by range proofs and zk-SNARK circuits; adoption varies by chain design.Permissionless and permissioned blockchain diffusion.^[10]

Key terminology: Pedersen commitment, range proof, zk-SNARK (pairing-based), trusted setup, Groth16, Bellman14, Bulletproofs, zk-STARK, universal and updatable verification keys, shielded/partially-homomorphic encryption channels.Permissionless and permissioned blockchain diffusion.^[10]

Putting it together: choosing an architecture

• Decentralization and trust: permissionless ledgers (Bitcoin, Ethereum) suit open networks; permissioned/enterprise architectures (Fabric, Corda) suit regulated consortia; hybrid designs ease migration and data privacy.Hybrid blockchains that could be considered both permissioned and ...^[6]The Hyperledger Fabric is a permissioned blockchain platform aimed at business use. It is open-source and based on standards, runs user-defined ...^[32]
• Functionality and compute: Ethereum-like VMs add programmability; sharding, rollups, and TEE rollups scale compute/throughput while keeping on-chain verification cheap; DAG ledgers target IoT microtransactions; PBFT-based ordering systems underpin private channels and enterprise modules.ZK rollups achieve instant finality through cryptographic verification—the ...^[46]HLF v1 approach in one line: execute → order → validate. Permissioned blockchain architecture – overhauled. ▫ Modular/pluggable ...^[34]Ether (ETH or Ξ) is the native cryptocurrency of the platform.^[5]
• Security and governance: PoW/PoS secure open validator sets; PBFT/Raft secure organized replicas with formal safety/liveness; rollups add cryptographic security deposits or succinct proofs; multi-chain systems rely on cross-chain relayers and validator committees for security composition.The proof-based consensus algorithms are generally suitable for permissionless blockchains, whereas voting-based consensus algorithms are suitable for ...^[7]This paper aims to investigate whether the consensus process using Practical Byzantine Fault Tolerance (PBFT) could be a performance bottleneck for networks ...^[35]
• Architecture mapping to applications: surveys recommend aligning substrate, consensus, privacy, and finality with regulatory, latency, and cost constraints—patterns used to adopt public, permissioned, or interoperable multi-chain solutions.In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]

Appendix: glossary of technical terms (established vs. note)

• UTXO: Unspent transaction output model (Bitcoin); well-established in public chains; maps to coinbase outputs and scriptSig/scriptPubKey semantics.A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a.^[11]
• EVM: Ethereum Virtual Machine; standard substrate for on-chain contracts and tokens with gas pricing (yellow paper and post-merge Ethereum docs).In mid-2014, a yellow paper was published by Gavin Wood that defined the technical specification of EVM and how it would work. The yellowpaper ...^[26]
• Merkle Patricia Tree: Ethereum storage and state representation; path-hashed keys, node types, and trie hashing are core data structures; gas costs cover storage/reads/writes.It uses a blockchain to synchronize and store the system's state changes, along with a cryptocurrency called ether to meter and constrain execution resource ...^[29]
• Nakamoto Consensus: proof-of-work leader election for permissionless chains; general term for Bitcoin’s mechanism; distinct from BFT families.Bitcoin is the first implementation of the BFT consensus protocol in a permissionless environment. Its consensus protocol is called Nakamoto Consensus protocol.^[2]
• PBFT/PBFT-like: Practical Byzantine Fault Tolerance; core to permissioned ordering, Fabric’s orderers, and interoperability relays; scalability motivates sharding and sampling.This paper aims to investigate whether the consensus process using Practical Byzantine Fault Tolerance (PBFT) could be a performance bottleneck for networks ...^[35]
• Rollups: Off-chain state commitment with on-chain rollup contract and proofs (optimistic or ZK) to scale L1; canonical term recognized across Ethereum ecosystem guides and analyses.Optimistic Rollup is a potential solution candidate for Layer2. Similar to zk Rollup, all Transaction information will be “saved” as CallData in Layer1.^[43]zkSync. Introduction zkSync is developed by Matter Labs ZKR and stands out with ...^[47]
• DAG/Tangle: State DAG alternative to block trees; IOTA uses a directed acyclic graph with tip selection and work sampling; terminology differs from tree-based blockchains and is used to mean graph-structured ledgers.Bitcoin White Paper ... a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[10]
• zk-SNARK/SYNTAX/STARK: Zero-knowledge proof systems for succinct/faithful computation proofs; canonical to ZK-rollups; terminology includes proving key/verification key and trusted setup; “STARK” denotes more transparent (non–pairing-based) proofs.ZK rollups achieve instant finality through cryptographic verification—the ...^[46]
• Channels/collectives: Hyperledger Fabric privacy and governance; canonical terms for partitioned state and policy-based admission/consensus roles; distinct from Ethereum’s transaction channels.It is open-source and based on standards, runs user-defined ...^[32]
• Validium vs zkRollup: Validium stores data off-chain with deposit-backed guarantees and availability proofs; zkRollup stores state roots on-chain and relies on L1 validity of roots; terminology distinguishes data availability from state posting.ZK rollups achieve instant finality through cryptographic verification—the ...^[46]
• IBC/Cosmos and parachains: Canonical cross-chain and heterogeneous multi-chain terms (Cosmos Inter-Blockchain Communication, Polkadot parachains) that differ from single-chain rollups by enabling trust-minimized value transfer across sovereign chains.In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]
• Data availability (A0DA/CommitChain): Commit-and-prove and committee-based availability proofs are emerging terms aiming to reduce L1 storage while preserving verification soundness for rollups and DAGs; distinguish from data availability sampling used by proof-of-stake block producers.Block. 139, 2021.^[1]
• Privacy (Bulletproofs/range proofs; zk-SNARK circuits): Canonical for confidential transactions; widely documented in academic and protocol literature (Bitcoin Confidential Transactions, Monero).A survey of consensus algorithms in public blockchain systems for crypto-currencies. ... Permissionless and permissioned blockchain diffusion.^[10]

Non-exhaustive listing and flagging

• All terms above are used in peer-reviewed surveys or canonical whitepapers except where otherwise noted; where industry whitepapers are used (e.g., Matter Labs for zkSync), they are cited in recognized academic/industry synthesis papers.
• Potentially non-established hybrids (e.g., “TEE-rollups,” “Validium-as-a-service”) are still active research/industry topics and flagged as emerging in system papers and evaluations.Our experimental results indicate that TEEROLLUP outperforms zero-knowledge rollups (ZK-rollups), reducing on-chain verification costs by.^[48]

Notes on remaining gaps

• This survey avoids inventing compound phrases (e.g., “sharded DAG-rollups”) absent explicit research usage; instead, it separates sharding/rollups and DAG vs tree architectures with cross-comparisons.
• System-specific details (R3 Corda, Polkadot, zkSync) are referenced via surveys and recognized technical overviews; deeper protocol parameters (e.g., Ethereum supermajority thresholds, Fabric MSP layouts) can be explored in the cited platform papers and design documents.

Citations (by section)

• Surveys and classifications: ed9dfc41-0, ed9dfc41-1, ed9dfc41-5, ed9dfc41-6, ed9dfc41-8, ed9dfc41-9.
• Bitcoin whitepaper: dd510fa9-0, dd510fa9-1, dd510fa9-9.
• Ethereum/Yellow Paper and merge: 3c921c0d-0, 3c921c0d-4, 3c921c0d-5.
• Hyperledger Fabric architecture: f5168b09-0, f5168b09-1, f5168b09-3, f5168b09-5.
• Layer-2 rollups and ZK: 48e913c7-1, 48e913c7-2, 48e913c7-3, 48e913c7-5, 48e913c7-6, 48e913c7-7.
• DAG/IOTA: ed9dfc41-9.
• Enterprise/SaaS and deployment: f5168b09-8; ed9dfc41-7.
• Privacy/range proofs: ed9dfc41-9.
• PBFT performance/consensus comparisons: f5168b09-4; ed9dfc41-8.
• Data availability/commit-chain: ed9dfc41-0.

Summary

• The main blockchain architectures coalesce around four forces: permissioning and validator selection (open vs. consortium), state-machine coordination (PoW/PoS vs. PBFT/Raft), composition and scale (sharding, rollups, DAGs), and composition and interoperability (multi-chain relayers/parachains). Each direction has canonical systems and documented trade-offs; selecting among them requires aligning decentralization, safety/finality, privacy, and operational economics to application constraints.In this article we present a conceptual framework to aid software architects, developers, and decision makers to adopt the right blockchain technology.^[8]The proof-based consensus algorithms are generally suitable for permissionless blockchains, whereas voting-based consensus algorithms are suitable for ...^[7]