By 彭肖文, 2022年2月16日
论文题目：Bidl: A High-throughput, Low-latency Permissioned Blockchain Framework for Datacenter Networks
这篇论文发表在CCF-A类会议-ACM Symposium on Operating Systems Principles 2021(SOSP 2021)。
1、论文作者简介
Ji Qi (The University of Hong Kong), Xusheng Chen (The University of Hong Kong), Yunpeng Jiang (The University of Hong Kong), Jianyu Jiang (The University of Hong Kong), Tianxiang Shen (The University of Hong Kong), Shixiong Zhao (The University of Hong Kong), Sen Wang (Huawei Technologies Co., Ltd.), Gong Zhang (Huawei Technologies Co., Ltd.), Li Chen (Huawei Technologies Co., Ltd.), Man Ho Au (The University of Hong Kong), Heming Cui (The University of Hong Kong)
本文来自香港的崔鹤鸣团队，崔鹤鸣的导师是哥伦比亚大学的 Junfeng Yang。
2、论文背景
时下热门的通用许可链框架——Hyperledger Fabric (HLF)，使用了 Execute-then-Order的工作流程。如图1所示，每笔交易首先并发执行，然后利用排序保证上链数据的一致性，从而容忍非确定性（non-deterministic）交易[1]。EO流程存在2点不足：当交易存在大量竞争时，这些冲突的交易会被标记为abort，从而导致HLF的吞吐率受到极大影响，此外排序阶段会导致最终确认的时延增加。
注1：定义 Non-determinism (e.g., caused by data races): given the same state and input, correct nodes may produce different execution results on the same transaction.
另一类工作如Quorum，使用了Order-then-Execute的工作流程：首先用BFT协商次序，然后依次执行事务。OE流程在竞争条件下的吞吐量表现极佳，而且不会出现交易冲突的情况。但是OE流程无法容忍非确定性交易，且交易顺序执行的效率低下。
本文希望能兼得二者的优势：既能高效处理交易，又能允许非确定性交易的存在。本文的观察是：数据中心网络可以为许可链提供高效排序，方法是将部分逻辑下放到路由层中，借助sequencer节点排序。因此，本文基于数据中心网络提出高吞吐，低延时的BIDL(Blockchain-powered In-Datacenter Ledger) 许可链框架。
3、系统模型
BIDL的工作流程如下图2所示。
- Phase 1：客户端通过TLS-enabled链接将签名交易提交给共识节点的Leader。
- Phase 2：Leader通过运行一个测序线程来充当sequencer。Leader将接收到的交易分配连续的序列号，并将其多播到所有一致和正常节点。为了提高性能，Leader不在多播消息上签名。
- Phase 3：共识节点运行BFT类协议对“交易哈希序列的顺序”进行共识。
- Phase 4：和Phase 3 并行执行。Normal节点根据序列号顺序，推测性地顺序执行（speculative execution）客户端事务。为了确保存在非确定性交易时系统的状态一致性，系统采用了multi-write协议[2]，以使Normal节点遵循相同的执行结果。如果节点产生了不一致的执行结果，则中止交易。
- Phase 5：
- 情况①：如果Normal节点接收到来自Phase 3的匹配的约定交易，则提交交易。
- 情况②：如果存在攻击者作恶，则Phase 4中推测执行的交易顺序与Phase 3 共识的交易顺序会不同。此时Normal节点会根据共识的交易顺序重新执行，相当于BIDL回退到顺序工作流（sequential workflow）。
4、性能分析
（1）系统的吞吐量：BIDL的Normal节点是顺序执行竞争交易（定义为并发访问同一密钥的交易），可以消除交易依赖性导致的事务中止，并提高系统在竞争工作负载上的吞吐量性能。
（2）系统的交易延迟：论文的共识节点（Phase 3）和Normal节点（Phase 4）的工作是并行执行，与HyperLedger Fabric等框架的顺序工作流程相比，可以极大降低交易延迟。论文指出该协议的延迟通常被BFT共识掩盖（Phase 3）。
5、安全性分析
（1）防止DoS攻击：
- Leader不在多播消息上签名，一方面可以减少共识节点和Normal节点的验证签名时间，提高性能。另一方面，还可以防止攻击者伪装成 Leader node, 发送签名无效的资源耗尽型DoS攻击。
- 如果客户端发送格式错误的交易（例如，带有无效签名），则Leader会断开连接，以避免客户端对Leader发起DoS攻击。
（2） Leader作恶： 如果Leader作恶（例如给不同的 Consensus 节点 和 Normal 节点发送不一样的交易顺序），则系统可以使用视图切换 (view changes) 来更换leader。本文采用的视图切换不是round-robin轮询方式，而是unpredictable的。系统以the hash of the last committed block 作为随机种子，从共识节点中随机选取一个来替换作恶的Leader。
（3）攻击者 𝓐 伪装leader作恶：攻击者会企图伪装成leader，使用客户端 c 签名的交易来向共识节点和 Normal 节点发送不一致的交易顺序。
本文指出，攻击者必然是自己制造一个恶意客户端 c （或者和恶意的客户端 c 合谋），生成并发送malformed交易，从而制造出交易顺序不一致的冲突情况。因为基于triangle inequality定理可知，共识节点和 Normal 节点会率先接受到来自Leader广播的正确交易，因此攻击者无法利用正确交易发动“交易不一致”攻击。
考虑到在许可链的环境下，攻击者 A 无法制造大量的恶意客户端，所以可以设置一个 denylist 将攻击者拉入黑名单。
6、论文实验
作者基于 HyperLedger Fabric 开发 BIDL 框架，并开源了 BIDL 框架的代码：github.com/hku-systems/bidl。交易大小设置为 1KB，默认区块大小设置为500条交易。如果图3所示，实验对比了 BIDL 和 HLF (HyperLedger Fabric), FastFabric (FF) 和 StreamChain 的性能。实验设置 4 个共识节点（为了配合 FF 的 VFT 环境，没有设置恶意节点）和 50 个 Normal 节点。
- 与HLF和FF相比，BIDL的延迟降低了60.2%，吞吐量平均提高了3.3倍。
- BIDL在有竞争交易环境下的性能最好：当交易竞争率从0%增加到50%时，BIDL的吞吐量（40.1k TXN/s）比FF高出2.2倍，中止率为零，而FF的中止率为37.7%。
7、创新点总结
本文提出了BIDL许可链框架，既能高效的处理交易，又能允许非确定性交易的存在。
- BIDL利用数据中心网络，可以引入sequencer节点在路由层中进行高效排序。
- 现有数据中心网络模型仅针对crash fault tolerance (CFT)，而非BFT。为此，BIDL通过节点共识和视图切换来处理作恶的Leader节点。
- BIDL引入Normal节点，通过预测执行（speculative execution）来提高并行性能。
- 为了避免恶意节点通过广播错误事件发动性能攻击，BIDL引入denylist protocol，将恶意节点添加到黑名单中。
8、个人启发
作者能够从 Execute-then-Order 和 Order-then-Execute 两种工作流程总结出各自的优点和不足，并能结合两种工作流程的优势，提出高吞吐，低延迟的 BIDL 许可链架构。这种思路值得我们学习。
另一方面，即使取消了 Leader 对交易序列号的签名，系统通过引入很简单的 denylist 机制来防止攻击者 𝓐 伪装成 leader 作恶。这里的逻辑有理有据，是一个很大的创新。
9、参考资料
[1]. Yamashita K , Nomura Y , Zhou E , et al. Potential Risks of Hyperledger Fabric Smart Contracts[C]// 2019 IEEE International Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, 2019.
[2]. Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, et.al. Dynamo: Amazon’s highly available key-value store. ACM SIGOPS operating systems review, 41(6):205–220, 2007.