Papers Link
BLOCKBENCH: A Framework for Analyzing Private Blockchains
Introduction
Category
- Problem Pattern: Well studied problems
- Idea Pattern: None
Background
What is the research problem?
In this paper, we first describe BLOCKBENCH, the first evaluation framework for analyzing private blockchains. It serves as a fair means of comparison for different platforms and enables deeper understanding of different system design choices.
Why it is an important problem?
Blockchain technologies are taking the world by storm.However, there is a clear lack of a systematic framework with which different systems can be analyzed and compared against each other. Such a framework can be used to assess blockchains’ viability as another distributed data processing platform, while helping developers to identify bottlenecks and accordingly improve their platforms.
Research Niche
There is a clear lack of a systematic framework with which different systems can be analyzed and compared against each other.
Challenge
- First, a blockchain system comprises many parts and we observe that a wide variety of design choices are made among different platforms at almost every single detail.
- Second, there are many different choices of platforms, but not all of them have reached a mature design, implementation and an established user base.
- Third, there is lack of a databaseoriented workloads for blockchain. Although the real Ethereum transactions and contracts can be found on the public blockchain, it is unclear if such workload is sufficiently representative to assess blockchain’s general data processing capabilities.
Research Summary
Bringing database designs into blockchain.
- Decouple storage, execution engine and consensus layer from each other, then optimize and scale them independently.
- Embrace new hardware primitives.
- Sharding.
- Support declarative language.
Contributions
- We present the first benchmarking framework for understanding and comparing the performance of permissioned blockchain systems. We have released the framework for public use.
- We conduct a comprehensive evaluation of Ethereum, Parity and Hyperledger. Our empirical results present concrete evidence of blockchain’s limitations in handling data processing workloads, and reveal bottlenecks in the three systems. The results serve as a baseline for further development of blockchain technologies.
Key Concepts
Blockchains
区块链是用分布式数据库识别、传播和记载信息的智能化对等网络, 也称为价值互联网。 中本聪在2008年，于《比特币白皮书》中提出“区块链”概念，并在2009年创立了比特币社会网络，开发出第一个区块，即“创世区块”。区块链通过由互联网上连接的节点运行的分布式协议来模拟可信计算服务。 区块链服务可以代表或创建一类资产，其中所有节点都是对等的，节点之间有限共享分布式账本上的数据，同时不需要依赖相互信任。
共有区块链：任何节点可以向任何人开放，每个人都可以参与到这个区块的计算，获得完整区块链的数据
私有区块链：只有被许可的节点才可以参与并且查看所有数据
Ethereum
以太坊是一个开源的有智能合约功能的公共区块链平台。通过其专用加密货币以太币（Ether，又称“以太币”）提供去中心化的虚拟机（称为“以太虚拟机”Ethereum Virtual Machine）来处理点对点合约。
Parity ErisDB Hyperledger Fabri
是一个分布式账本平台方案，主要用于运行智能合约，利用可靠的技术以及可插拔方式实现各种商业应用场景的模块化架构。
Byzantine fault tolerance
又叫拜占庭将军（Byzantine Generals Problem）问题，是 Leslie Lamport 1982 年提出用来解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于将军中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消息，试图会干扰一致性的达成。
拜占庭问题即为在此情况下，如何让忠诚的将军们能达成行动的一致。
对于拜占庭问题来说，假如节点总数为 N，叛变将军数为 F，则当 N>=3F+1 时，问题才有解，即 Byzantine Fault Tolerant (BFT) 算法。
PBFT
面向拜占庭问题的容错算法，解决的是网络通信可靠，但节点可能故障情况下的一致性达成。最早由 Castro 和 Liskov 在 1999 年提出的 Practical Byzantine Fault Tolerant（PBFT）是第一个得到广泛应用的 BFT 算法。只要系统中有 2/3 的节点是正常工作的，则可以保证一致性。 PBFT 算法包括三个阶段来达成共识：Pre-Prepare、Prepare 和 Commit。
POW
PoW 通过让每个节点，在准备提交下一个区块 B 之前，强制规定在区块 B 中插入一个数 nonce，使得：H(B)≤m 上述公式中，H 是某个哈希函数，m 是某个极小的实数，由哈希函数的性质决定，想要找到符合条件的 nonce ，就必须通过穷举 nonce 的方法来实现。通过调整 H ，m ，就能控制网络中节点，对于每个区块提交的时间窗口的期望。 在 PoW 机制下，由于找到符合要求的 nonce 期望时间是可以调整的，因而构建了去中心化的时间序列机制。同时，也解决了无中心多节点的结果决策问题，即，整个网络采用最早找到合法 nonce 的节点提交的数据。
POS
在 PoW 机制中，由于想要找到符合条件的 nonce 往往需要花费大量的电力和时间成本，因此，为了使每个 Block 更快被生成，PoS 机制去掉了穷举 nonce 这一过程，继而采用以下更快速的算法：
H(H(Bprev),A,t)≤balance(A)m * H 依然为某个哈希函数 * t 为 UTC 时间戳 * Bprev 指的是上一个区块 * balance(A)代表账户 A 的账户的余额 * m 依然代表某个认为定义的数
等式左边，唯一可以不断调整的参数是 t，等式右边 m 是某个固定的实数，因此，当 balance(A) 越大，找到合理 tt 的概率越大。网络中，普遍对于 t 的范围有所限制，如可以尝试的时间戳不能超过标准时间戳 1 小时，也就说，一个节点可以尝试 7200 次，来找到一个符合条件的 t，如果找不到即可放弃。因此，在 PoS 中，一个账户的余额越多，在同等算力下，就越容易发现下一个区块。
####账本分叉问题 ( Nothing at Stake Problem )
在 PoW 机制中，当账本出现分叉时，对 PoW 这种算力敏感的算法，矿工必须选择一个方向进行挖矿。而在 PoS 这种算力不敏感的时候，PoS 矿工往往会两个方向都挖，以争取实现利益最大化。当多数矿工都在两条链上一起挖矿的时候，就会很容易出现双重支付攻击。