[论文解读] FireLedger: A High Throughput Blockchain Consensus Protocol
FireLedger 是一种高吞吐量的区块链共识协议,通过乐观假设提议者正确来减少通信开销,实现在每轮通信中仅需最少消息即可达成一个区块的决策:提议者仅发送其提议,其他节点每轮仅发送一位比特。在一个包含10个节点的单数据中心环境中,对于512字节的事务,其吞吐量高达160 K tps,相较于HotStuff和BFT-SMaRt在不同配置下提升20%至600%。
Blockchains are distributed secure ledgers to which transactions are issued continuously and each block of transactions is tightly coupled to its predecessors. Permissioned blockchains place special emphasis on transactions throughput. In this paper we present FireLedger, which leverages the iterative nature of blockchains in order to improve their throughput in optimistic execution scenarios. FireLedger trades latency for throughput in the sense that in FireLedger the last f + 1 blocks of each node's blockchain are considered tentative, i.e., they may be rescinded in case one of the last f + 1 blocks proposers was Byzantine. Yet, when optimistic assumptions are met, a new block is decided in each communication step, which consists of a proposer that sends only its proposal and all other participants are sending a single bit each. Our performance study demonstrates that in a single Amazon data-center, FireLedger running on 10 mid-range Amazon nodes obtains a throughput of up to 160K transactions per second for (typical Bitcoin size) 512 bytes transactions. In a 10 nodes Amazon geo-distributed setting with 512 bytes transactions, FireLedger obtains a throughput of 30K tps. Moreover, on higher end Amazon machines, FireLedger obtains $20%-600%$ better throughput than state of the art protocols like HotStuff and BFT-SMaRt, depending on the exact configuration.
研究动机与目标
- 在拜占庭故障罕见的许可制环境中提升区块链吞吐量,通过利用区块链的迭代特性。
- 通过假设乐观执行条件来减少共识协议的通信开销,从而在正常运行期间最小化消息量。
- 设计一种协议,在标准非专用硬件上实现高性能的同时保持强最终性。
- 在真实部署条件下,超越现有最先进共识协议(如HotStuff和BFT-SMaRt)在吞吐量和效率方面的表现。
提出的方法
- FireLedger 保留最后 f+1 个区块作为暂定状态,若该窗口内的任意提议者为拜占庭故障,仍可实现恢复,同时在 f+1 轮后确保最终性。
- 采用基于轮次的共识模型,每轮决定一个新区块,提议者仅发送其提议,其他节点仅发送一位比特以表示同意。
- 协议利用密码学认证和两阶段通信模式:第一阶段传播区块头;第二阶段仅在需要恢复时才传输交易数据。
- 通过每区块事务批处理,并将区块头与交易数据分离,以提升可扩展性并减轻带宽压力。
- 仅在检测到故障提议者时触发恢复机制,从而在正常运行期间最小化开销。
- 通过CPU高效设计及配置参数(如批处理大小 β、工作节点数 ω 和区块大小 σ)优化性能。
实验结果
研究问题
- RQ1区块链共识协议是否可通过假设乐观条件(即提议者正确)实现显著更高的吞吐量?
- RQ2在不牺牲最终性或安全性的情况下,拜占庭容错共识中的通信开销可被减少到何种程度?
- RQ3乐观共识协议的性能在不同网络拓扑(包括单数据中心和广域网分布部署)下的可扩展性如何?
- RQ4在相同硬件和容错约束条件下,FireLedger 与 HotStuff 和 BFT-SMaRt 等领先协议相比,在吞吐量和延迟方面表现如何?
主要发现
- 在包含10个中等配置节点的单个亚马逊数据中心中,FireLedger 对于512字节的事务,峰值吞吐量达到160,000笔事务/秒(tps)。
- 在10个节点的广域网分布环境中,FireLedger 实现了30,000 tps的性能,即使在广域网环境下也表现出色。
- 在各种配置和集群规模下,FireLedger 的吞吐量相比HotStuff提升20%至300%,相比BFT-SMaRt提升40%至600%。
- 由于 f+1 最终性机制,FireLedger 的延迟随集群规模增加而上升,但依然具有竞争力——在 n ≤ 30 个节点时,可实现Libra设定的10秒最终性目标。
- 吞吐量随批处理大小(β)和节点数(n)提升,得益于更好的CPU利用率和批处理效应,尤其在大规模集群中更为显著。
- 对于大尺寸事务,FireLedger 与 HotStuff 的性能差距缩小,因为数据传播成为通信开销的主要部分,从而削弱了协议层面的性能优势。
更好的研究,从现在开始
从阅读论文到最终审阅,大幅缩短您的研究时间。
无需绑定信用卡
本解读由 AI 生成,并经人工编辑审核。