Source-linked AI summary
Distributed Ledger Technology: Blockchain Compared to Directed Acyclic Graph
Federico Matteo Benčić, Ivana Podnar Žarko
TL;DR
Distributed ledger research often treats blockchain as synonymous with DLT, while DAG-based ledgers provide a less-covered alternative. The paper compares these paradigms using Bitcoin, Ethereum, and Nano across distributed-systems features. It finds that the approaches differ in ledger structure, consensus, confirmation, ledger-size management, and scalability strategies.
Problem
Blockchain is only one DLT specialization, while DAG-based ledgers have received less coverage beyond the established cryptographic treatment of blockchain.
Method
The paper qualitatively compares Bitcoin, Ethereum, and Nano by analyzing ledger structures, consensus, confirmation confidence, ledger size, and scalability.
Results
Blockchain bundles transactions into blocks and generally uses leader election, whereas Nano’s DAG uses transaction graphs and delegates ordering to users and representatives.
Takeaways & Limitations
Blockchain and DAG implementations use different approaches to consensus, transaction confirmation, ledger pruning, and scalability, and neither paradigm guarantees scalability per se.
Abstract
from arXiv · showhide
Nowadays, blockchain is becoming a synonym for distributed ledger technology. However, blockchain is only one of the specializations in the field and is currently well-covered in existing literature, but mostly from a cryptographic point of view. Besides blockchain technology, a new paradigm is gaining momentum: directed acyclic graphs. The contribution presented in this paper is twofold. Firstly, the paper analyzes distributed ledger technology with an emphasis on the features relevant to distributed systems. Secondly, the paper analyses the usage of directed acyclic graph paradigm in the context of distributed ledgers, and compares it with the blockchain-based solutions. The two paradigms are compared using representative implementations: Bitcoin, Ethereum and Nano. We examine representative solutions in terms of the applied data structures for maintaining the ledger, consensus mechanisms, transaction confirmation confidence, ledger size, and scalability.
I. INTRODUCTION
The paper distinguishes blockchain from DAG-based distributed ledgers and compares them through distributed-systems features and representative implementations. It examines ledger structures, consensus, confirmation confidence, ledger size, and scalability.
- DLT maintains a global, append-only data structure among mutually untrusted participants in a distributed environment.
- Blockchain bundles transactions into cryptographically linked blocks, whereas DAG-based ledgers use a different transaction-organizing paradigm.
- The paper compares blockchain and DAG paradigms using data structures, consensus mechanisms, confirmation confidence, ledger size, and scalability.
- Bitcoin and Ethereum represent blockchain implementations, while Nano represents DAG-based ledgers because of their relatively mature implementations and developer communities.
- The paper separately analyzes ledger-maintenance structures before examining consensus, confirmation, ledger growth, and scalability.
A. Blockchain
Blockchain stores transactions in ordered, cryptographically linked blocks, while Nano’s DAG stores transactions in account-specific structures. Nano transfers use separate send and receive transactions.
- Blockchain: Blockchain consists of ordered blocks whose headers reference predecessor hashes, beginning with a genesis block.
- Blockchain: Bitcoin stores transactions in one Merkle tree, whereas Ethereum uses separate structures for transactions, receipts, and state.
- Directed Acyclic Graph: DAG ledgers store individual transactions in nodes rather than bundling them into blocks.
- Directed Acyclic Graph: Nano organizes each account’s transaction and balance history in a dedicated account-chain within the block-lattice.
- Directed Acyclic Graph: Nano executes value transfers through matching send and receive transactions generated by the sender and receiver.
III. CONSENSUS
Consensus is required before entries are appended in public, permissionless ledgers, where participants cannot be implicitly trusted. The supplied passages frame this environment but do not detail a complete consensus algorithm.
- Public, permissionless ledgers allow nodes to read from and append to the ledger, so blocks or nodes cannot be implicitly trusted.
- Consensus requires network agreement on the validity of each new ledger entry before it is appended.
- Bitcoin, Ethereum, and Nano are discussed as public and permissionless distributed-ledger solutions.
A. Blockchain
Blockchain consensus uses agreement among nodes under an honesty assumption, with Nakamoto-style leader election used to propose and order entries. Proof of Work selects leaders through cryptographic puzzles and mining incentives.
- Ledger consensus assumes that a supermajority of nodes are honest and reliable.
- Nakamoto consensus elects a leader by lottery to propose entries, which other nodes validate and consistently order.
- Proof of Work awards leadership to the first participant solving a cryptographic puzzle involving a block, nonce, and target hash pattern.
- Mining provides token incentives, and without miners, Proof-of-Work systems cannot mine blocks or achieve transaction throughput.
2) Proof of Stake:
Proof of Stake replaces computational leader election with token-weighted validator selection, while Nano avoids leader election and resolves conflicts through weighted representative voting.
- 2) Proof of Stake:: In Ethereum’s Proof of Stake, validators stake tokens, and higher stakes increase the chance of creating the next block.Ethereum implements PoS through the Casper smart contract.
- 2) Proof of Stake:: PoS consumes less electricity than PoW and allows attacks to be penalized by burning the attacker’s stake.The paper contrasts burning stake with the hardware costs retained by attackers in PoW.
- 2) Proof of Stake:: Nano uses Proof of Work only for spam protection, while representatives resolve conflicts through votes weighted by delegated account balances.Transactions without conflicts require no voting overhead.
A. Blockchain
Blockchain forks temporarily create competing histories when blocks are produced close together, after which the longer chain is adopted and the shorter chain is orphaned. Confirmation confidence therefore increases with additional blocks, but inclusion is initially reversible.
- A. Blockchain: A soft fork occurs when network delays cause nodes to receive different blocks with the same predecessor, creating temporarily competing chains.Nodes continue building on their received blocks until one chain becomes longer.
- A. Blockchain: The longer chain is adopted, while the shorter chain is discarded or orphaned; transactions from the orphaned chain must enter a new block.This resolves the temporary fork but does not preserve every original transaction placement.
- A. Blockchain: Bitcoin requires six appended blocks for high-confidence inclusion, while Ethereum requires five to eleven.Ethereum is also described as introducing Casper FFG checkpoints intended to make inclusion non-reversible.
- A. Blockchain: A newly appended block is not guaranteed to remain valid because a later fork can orphan it.The probability of discard decreases as more blocks are added above it.
V. LEDGER SIZE
Distributed ledgers continually grow because they retain information from genesis, so Bitcoin and Ethereum provide pruning or synchronization mechanisms that reduce stored historical data.
- V. LEDGER SIZE: On 02.01.2018, Bitcoin was estimated at 145,95 GB and Ethereum at 39.62 GB.These figures illustrate the storage burden of an ever-growing append-only ledger.
- V. LEDGER SIZE: Bitcoin pruning deletes raw block data after validation while retaining a small subset for relaying recent blocks and handling soft forks.Pruning saves disk space but prevents other nodes from downloading the pruned node’s complete history.
- V. LEDGER SIZE: Ethereum can discard old state deltas and uses fast sync to download recent transaction receipts and state instead of replaying the entire blockchain.State synchronization begins from a recent pivot point, 1024 blocks behind the chain head.
B. Directed Acyclic Graph
Nano’s ledger design supports different node-storage roles and planned pruning, but its scalability remains a broader DLT challenge illustrated by pending transactions in Bitcoin and Ethereum.
- B. Directed Acyclic Graph: Nano distinguishes historical nodes, current nodes retaining account-chain heads, and light nodes that hold no ledger data.The passage notes that the current implementation consisted of historical nodes.
- B. Directed Acyclic Graph: Nano plans to reduce ledger size by discarding historical data while retaining account balances, but pruning was not implemented in 2018.The planned approach relies on balances rather than unspent transaction inputs.
- B. Directed Acyclic Graph: On 05.01.2018, Bitcoin had around 186,951 pending transactions and Ethereum around 22,473, illustrating a scalability issue for global DLT adoption.The paper presents scalability as one of the main barriers to wider adoption.
A. Blockchain
Blockchain-based ledgers regulate transaction inclusion through block production, making throughput depend on block timing and capacity. Scaling approaches can increase capacity or move activity off-chain, but larger blocks may increase centralization pressure.
- Bitcoin’s roughly 10-minute block interval and 1 MB maximum block size limit throughput to 3–7 transactions per second.
- Ethereum mines blocks roughly every 15 seconds and achieves approximately 7–15 transactions per second through a dynamic gas-based block limit.A planned transition to Proof of Stake is described as potentially reducing block generation time to 4 seconds or lower.
- Increasing block size can raise transaction capacity, but may centralize the network if consumer hardware cannot process larger blocks.Segwit2x is cited as a Bitcoin effort that included increasing block size to 2 MB.
- Off-chain channels such as Raiden and Lightning let parties conduct high-volume microtransactions before recording final balances on-chain.Channels lock a prepaid amount, allow transactions outside the network’s transaction cap, and close by recording final account balances on-chain.
- Plasma scales Ethereum through nested blockchains, while sharding partitions transaction processing across K network shards.Plasma periodically broadcasts sidechain Merkle roots, whereas sharding reduces the requirement that every node process every transaction.
B. Directed Acyclic Graph
Nano’s DAG design assigns transaction ordering to account owners rather than dedicated block validators, removing an inherent protocol throughput cap. Its observed throughput remains constrained by consumer hardware and network conditions.
- Nano users order their own transactions asynchronously instead of relying on dedicated validators to generate and order blocks.
- Nano’s protocol has no inherent transaction-throughput cap, but a main-network test reached 306 TPS peak and 105.75 TPS average.The stated practical limit is the quality of consumer-grade hardware and network conditions.
VII. CONCLUSION
The comparison finds distinct approaches to ledger structure, transaction ordering, confirmation, ledger growth, and scalability. DAGs avoid leader election and can couple transaction verification with network usage, while both paradigms face practical constraints and ledger-size tradeoffs.
- Ledger structure and ordering: Blockchain bundles transactions into blocks and selects one global history through stochastic leader election, whereas DAGs store transactions as edges and delegate ordering to users and representatives.Nano’s DAG uses representatives to resolve conflicts instead of electing leaders.
- Transaction confirmation: Blockchain transactions may require multiple appended blocks for confirmation because an included block can later be orphaned; Nano confirms transactions through majority representative votes.Block inclusion alone does not guarantee persistence in the blockchain’s global-truth ledger.
- Ledger size: Ledger pruning addresses significant ledger-size growth by keeping full history on historical nodes while other nodes retain only a subset, trading disk usage against historical accessibility.The tradeoff determines how much historical data remains directly available to ordinary nodes.
- Scalability: A scalable DLT need not require every node to process every transaction, but existing DAG and blockchain implementations do not guarantee this property by themselves.The paper describes blockchain approaches including larger blocks, off-chain channels, hierarchical chains, and sharding, while DAGs can couple network usage with transaction verification.