Source-linked AI summary
Untangling Blockchain: A Data Processing View of Blockchain Systems
Tien Tuan Anh Dinh, Rui Liu, Meihui Zhang, Gang Chen, Beng Chin Ooi, Ji Wang
TL;DR
Blockchain systems need systematic comparison because their expanding design space makes their capabilities and data-processing performance difficult to assess. This paper surveys blockchain designs, presents BLOCKBENCH, and evaluates Ethereum, Parity, and Hyperledger. The study reports substantial performance gaps between blockchains and database systems and discusses database-inspired directions for improvement.
Problem
The paper addresses the need to understand blockchain properties, design differences, performance, and current challenges amid a rapidly expanding technology landscape.
Method
The paper surveys private blockchain systems across four dimensions, develops BLOCKBENCH, and evaluates Ethereum, Parity, and Hyperledger on data-processing workloads.
Results
The evaluation shows that current blockchain performance is far below what state-of-the-art database systems can offer.
Takeaways & Limitations
The survey and benchmark identify performance bottlenecks and database-inspired research directions for future blockchain systems.
Takeaways & Limitations
The surveyed list of blockchain systems is not exhaustive, particularly given continuing commercial and academic interest.
Abstract
from arXiv · showhide
Blockchain technologies are gaining massive momentum in the last few years. Blockchains are distributed ledgers that enable parties who do not fully trust each other to maintain a set of global states. The parties agree on the existence, values and histories of the states. As the technology landscape is expanding rapidly, it is both important and challenging to have a firm grasp of what the core technologies have to offer, especially with respect to their data processing capabilities. In this paper, we first survey the state of the art, focusing on private blockchains (in which parties are authenticated). We analyze both in-production and research systems in four dimensions: distributed ledger, cryptography, consensus protocol and smart contract. We then present BLOCKBENCH, a benchmarking framework for understanding performance of private blockchains against data processing workloads. We conduct a comprehensive evaluation of three major blockchain systems based on BLOCKBENCH, namely Ethereum, Parity and Hyperledger Fabric. The results demonstrate several trade-offs in the design space, as well as big performance gaps between blockchain and database systems. Drawing from design principles of database systems, we discuss several research directions for bringing blockchain performance closer to the realm of databases.
1 INTRODUCTION
The paper frames blockchain as a rapidly expanding technology whose properties and performance require systematic understanding. It surveys core designs, introduces BLOCKBENCH, evaluates major private blockchains, and identifies database-inspired improvement directions.
- Blockchain systems maintain ordered transaction records among nodes that do not fully trust each other.
- The paper distinguishes public and private blockchains and organizes their designs around distributed ledgers, cryptography, consensus protocols, and smart contracts.
- The paper introduces BLOCKBENCH to evaluate private blockchains against data-processing workloads.
- BLOCKBENCH evaluates Ethereum, Parity, and Hyperledger, showing that blockchain performance is far below state-of-the-art database performance.
- The evaluation identifies performance bottlenecks and provides a baseline for future blockchain research and development.
2 BLOCKCHAINS: PRIVATE VS. PUBLIC
Blockchain systems combine replicated historical state with agreement among mutually distrustful nodes. Public and private settings differ chiefly in membership, consensus assumptions, and resulting performance and application suitability.
- A blockchain stores historical states and transactions in linked blocks, with all nodes agreeing on transactions and their order.
- Blockchain transactions require ACID semantics, but Byzantine failures impose higher concurrency-control overhead than crash-only distributed databases.
- Public blockchains allow any node to join or leave, whereas private blockchains enforce authenticated membership through access control.
- 2.1 Public Blockchain: Bitcoin uses proof-of-work, whose probabilistic confirmation contributes to security and performance issues, including throughput of 7 transactions per second.
- 2.1 Public Blockchain: Proof-of-work is computationally expensive and nondeterministic, making it unsuitable for banking and finance applications requiring high-volume deterministic processing.
- 2.2 Private Blockchain: Private blockchains use authenticated-node consensus such as PBFT and support complex smart-contract logic suited to business and financial systems.
3 KEY CONCEPTS
The paper analyzes blockchains through distributed ledgers, consensus, cryptography, and smart contracts. These concepts explain how systems represent state, agree under failures, protect history, and execute user-defined logic.
- 3.1 Distributed Ledger: A distributed ledger is a replicated append-only transaction structure whose organization depends on applications, ledger count, and ownership.
- 3.2 Consensus: Consensus is required because replicated ledger updates must be agreed upon by parties that may behave in Byzantine ways.
- 3.2 Consensus: Consensus protocols range from computation-based PoW to communication-based PBFT, with hybrid approaches between them.
- 3.3 Cryptography: Cryptography protects both global states through Merkle trees and block history through hash pointers linking each block to its predecessor.
- 3.4 Smart Contracts: A smart contract is transaction-triggered computation whose inputs, outputs, and affected states are agreed upon by every node.
- 3.4 Smart Contracts: Smart-contract systems span constrained scripting and formally checkable semantics to Turing-complete computation, with different runtime environments including virtual machines and containers.
4 STATE OF THE ART
The state of the art spans diverse blockchain designs across ledgers, cryptography, consensus, and smart contracts, with important differences in application scope, trust assumptions, and execution safety. The survey highlights limitations involving key usability, consensus scalability and guarantees, transaction privacy, and smart-contract security.
- Taxonomy: The survey compares blockchain systems across distributed ledger, cryptography, consensus protocol, and smart contract dimensions.The listed systems are grouped by target applications and characterized by ledger properties, cryptographic mechanisms, consensus choices, and contract expressiveness.
- Distributed ledgers: Crypto-currency, digital assets, and general applications motivate open or private ledgers with transaction-based, account-based, or programmable state models.Ethereum supports account-based state and arbitrary business logic, while asset systems commonly record asset histories using transaction-centered models.
- Identity management: Private blockchains add authenticated access control, with Hyperledger separating membership and certificate services from the blockchain.Hyperledger checks signed requests against membership and certificate authorities before consensus processing; Multichain uses fixed global permissions.
- Cryptography: Public-blockchain key management remains difficult: an evaluation of six Bitcoin wallet approaches found none satisfactorily usable.The reported problems include misuse of traditional-currency metaphors and confusing abstractions.
- Consensus: PoW provides probabilistic confirmation, whereas PBFT provides deterministic finality but incurs O(N 2) messages per agreement round and scales poorly in practice.The paper connects PoW’s non-finality to double-spending attacks and reports the same scalability issues for Hyperledger’s PBFT evaluation.
- Smart contracts: Turing-complete smart contracts increase expressiveness but expose applications to software bugs, including the DAO attack and thousands of contracts with potential vulnerabilities.The paper attributes major bug causes to transaction-order dependencies, timestamp dependencies, and mishandled exceptions.
5 BLOCKBENCH
BLOCKBENCH is an open-source framework for quantitatively evaluating private blockchains as data processing platforms using database-inspired workloads and layered benchmarks. It integrates blockchain backends, workload drivers, and metrics spanning throughput, latency, scalability, fault tolerance, security, and application-to-execution layers.
- BLOCKBENCH targets private blockchains with Turing-complete smart contracts and includes data processing workloads commonly used in database benchmarks.
- The framework organizes evaluation into consensus, data model, execution, and application layers, with workloads designed to assess each layer individually.
- Its stack combines frontend and backend interfaces with a workload driver; Ethereum, Parity, and Hyperledger are supported backends.
- Benchmark metrics: BLOCKBENCH measures throughput, latency, scalability, fault tolerance, and security through transaction performance, node growth, failures, and block-branch divergence.
- Workloads: Macro workloads include YCSB, Smallbank, EtherId, Doubler, and WavesPresale, while micro workloads isolate consensus, analytics, storage, and execution behavior.
- Workloads: The CPUHeavy workload invokes quicksort on a large array to measure computational efficiency in the execution layer.
6 EVALUATION
The evaluation compares Ethereum, Parity, and Hyperledger across macro and micro data-processing benchmarks, fault scenarios, and security attacks. Hyperledger generally performs best but scales poorly beyond 16 nodes, while Ethereum and Parity show greater failure resilience yet remain vulnerable to blockchain forks; all three trail H-Store substantially.
- Macro benchmarks: Hyperledger performs consistently better than Ethereum and Parity across benchmarks but fails to scale beyond 16 nodes.
- Macro benchmarks: Hyperledger’s consensus bottleneck reflects PBFT communication overhead, while Parity’s bottleneck is transaction signing and Ethereum’s degradation is partly linked to network size.
- Comparison with databases: H-Store exceeds 140K tx/s with sub-millisecond latency, creating at least an order-of-magnitude throughput gap and a two-order-of-magnitude latency gap versus blockchains.
- Scalability: Hyperledger fails beyond 16 servers because dropped messages and repeated unsuccessful PBFT view changes leave the network stuck attempting to establish a stable view.
- Fault tolerance and security: Ethereum and Parity fork during a 150-second network partition, with up to 30% of blocks generated on the forked branch, whereas Hyperledger has no fork but recovers about 50 seconds more slowly.
- Execution layer: Ethereum uses 22GB of memory when sorting 10M elements and runs out of memory above that size, while Hyperledger uses 473MB for the same 10M-element task.
- Data model: Ethereum and Parity use an order of magnitude more storage than Hyperledger for IOHeavy workloads because they share a more space-intensive data model and index structure.
- Data model: Hyperledger’s customized historical-state contract reduces Q2 analytics latency by over 10x by replacing one RPC per block with one RPC overall.
7 DISCUSSION
The discussion uses comparative benchmarking to expose blockchain performance trade-offs and bottlenecks, then connects transaction processing to database designs as a basis for improvement directions.
- Lessons Learned From the Performance Study: BLOCKBENCH narrows private-blockchain design space into four abstraction layers for studying design trade-offs and performance bottlenecks.The layers derive from the paper’s taxonomy of distributed ledger, cryptography, consensus protocol, and smart contract.
- Lessons Learned From the Performance Study: Parity trades performance for scalability by keeping states in memory, while Hyperledger’s key-value model limits direct support for some analytical queries but enables targeted optimization.These observations come from the IOHeavy and Analytics workloads.
- Lessons Learned From the Performance Study: Blockchain systems perform poorly on data-processing tasks currently handled by database systems such as H-Store.The comparison highlights a performance gap between blockchains and databases designed under different failure models.
- Bringing Database Designs into Blockchains: A blockchain transaction is batched into a block, processed by consensus, executed by the engine, and then appended with newly created states.Each stage can become a performance bottleneck and target of optimization.
- Bringing Database Designs into Blockchains: Blockchain transaction flow resembles distributed-database processing, but blockchains use Byzantine-tolerant consensus instead of two-phase commit or Paxos.This similarity motivates adapting database design principles to blockchain performance.
- Bringing Database Designs into Blockchains: The proposed improvement directions include decoupling layers, using trusted hardware, sharding state, and supporting declarative smart-contract languages.The passages motivate these directions through independent optimization, fewer network messages, reduced computation, and low-level execution optimizations.
8 CONCLUSION
The paper surveys blockchain technologies, presents BLOCKBENCH for evaluating blockchains as data-processing platforms, and discusses database-inspired directions for improving performance.
- CONCLUSION: The paper surveys blockchain technologies and analyzes four underpinning concepts behind blockchain systems.It also presents BLOCKBENCH and discusses four potential research directions inspired by database design principles.
- CONCLUSION: BLOCKBENCH is designed to evaluate blockchain performance as data-processing platforms.The conclusion positions the framework alongside the survey and proposed improvement directions.
- CONCLUSION: The proposed research directions aim to guide future blockchain systems toward security, scalability, and real-world usability.This is the paper’s stated intended contribution of the survey and benchmarking framework.