[SIGMOD 2021] SharPer: Sharding Permissioned Blockchains Over Network Clusters

Posted 2021-08-27 hbwoo!

1. 作者简介

论文发表在SIGMOD 2021，第一作者Mohammad Javad Amiri来自宾夕法尼亚大学，第二作者和第三作者都来自加州大学圣塔芭芭拉分校（Divyakant Agrawal和Amr El Abbadi都是ACM/IEEE Fellow，数据管理方面大佬）。

2. 背景介绍

可拓展性是区块链的一个重要性能指标，是指随着区块链网络中节点数目增加，系统对交易的处理性能也随之增长。分片技术是分布式数据库中常用来提升性能的技术方案，例如Google的Spanner。目前，分片技术也被运用在区块链来提升单链性能，Elastico，OmniLedger和Rapidchain用在公链的分片中，分片由节点随机组合产生，以通过概率来保障所有恶意节点均匀的分配到不同分片中。联盟链中的分片工作有Fabric，Cosmos，RSCoin，AHL，AHL是本文所对比的一个方法，其首先依靠可信硬件降低片内允许的节点数目下限，使恶意节点占比低于1/3。同时，片间共识需要依赖片以外的其他节点，共识的网络通信开销大，单片处理跨片交易不支持多片并行。

当前分片工作对于片内安全性假设有两种，预先定义错误节点数目或者概率性的错误假设。例如Spanner，基于真实世界中的物理情况约束，假设数据中心的大部分节点都是安全的（Paxos情况下恶意节点数目不会超过1/2，PBFT共识算法下恶意节点数据不超过1/3），即一种确定性的片内安全保证，其他例子还有ResilientDB和Blockplane。本文提出的Sharper也是基于这种确定性的安全保证假设，节点部署在数据中心，云服务或者本地服务器。Elastico，OmniLedger和Rapidchain都旨在更加广泛的对等网络中提供分片服务，通过随机分配节点形成分片，获得概率性的片内安全保障。

3. 贡献点

文章工作致力于提高当前联盟链在分片架构下的交易吞吐率，贡献点如下：

• 将区块链节点和数据进行分片，支持并行处理多个跨片交易。
• 支持片间共识（纯CFT或BFT节点错误），解决了片间并发时候共识出现的交易冲突、死锁、主节点故障问题。

4. Sharper 架构

假设前提：

1. 网络中的所有节点存在于异步环境网络环境。（根据FLP定理，异步网络下只能保证一致性协议的安全性，若要同时满足活性异步网络是不够的，需要弱同步网络）。

2. 网络中的所有节点分成P个分片P={p1, p2,…, pN}，每个分片维护区块链的部分视图数据D={d1, d2,…, dP}，片中所有节点存储一个视图中的所有数据，如图1所示。对于运行Paxos或者PBFT共识协议时，每个分片中节点数目都满足2f+1或者3f+1安全条件，f为故障阶段或拜占庭阶段数目。并且同一个片中的节点是由地理上距离比较相近的一批节点组成，互相通信延迟较低。

3. 网络中的消息经过签名认证，恶意节点无法锻造诚实节点的消息。
   
   Sharper架构示例如图1所示，整条链被分成4个分片，t10,t11是片1的第一个和第二个执行的交易，它们都是片内交易。t12,22是片1和片2需要共同执行的跨片交易，并且都是片内的第三个执行的交易。跨片交易需要确定在相关片中执行的序号确保结果的正确性。对于那些所涉及的分片不存在交集的跨片交易，Shaper支持并行处理这些交易。例如交易t12,22和交易t32,42。

4. 跨片共识
   区块链中的共识机制负责让所有节点对请求按照某个相同的处理顺序达成共识，需协议要满足以下四个性质：

   约同性（ Agreement ） , 所有诚实节点对相同的请求达成commit意见。
   有效性（ Validity ） ，好节点达成commit意见的值，必须是一个好节点的输入值。
   一致性（ Consistency ） ，所有好节点按照相同的顺序commit相同的值。
   可终止性（ Termination ） ，最终所有节点都会commit一个值。

   其中，前三个总结为协议安全性（safety），最后一个总结为活性（liveness）。

对单个分片而言，让片中所有节点对一笔交易保持一致的技术已经很成熟。然而对于跨片交易而言，它需要在多个排序实例的节点之间保持保持一致。本文分别研究了CFT和BFT网络节点错误环境下的跨片共识机制。值得一提的是，虽然现在区块链中大家都在研究BFT共识下的问题，对于研究CFT下的跨片共识的重要性作者给予了解释，认为在存在准入机制的联盟链场景中，CFT共识可能就已经足够了，例如有名的Hyperledger Fabric项目中也只支持CFT下的共识。

5. CFT 网络

5.1.1 片内 CFT 共识

对于只涉及到一个分片的交易只要走片内共识（Intra-shard consensus）就可以了，Sharper在CFT网络中的片内共识采用multi-paxos算法，该算法由Lamport 1998年提出，选择一个稳定的节点长期作为主节点，协议相比原始paxos具有更低的延时。

流程如下（因为网络中只有故障停节点，因此不需要对消息进行签名。只有主节点广播commit消息以及回复客户端的时候需要签名，用于其他节点和客户端作为交易提交的证明）：

1. 客户端向主节点发送一个交易请求，主节点分配一个消息序号返回给客户端
2. 主节点向所有从节点广播此消息并且带上accept信息
3. 从节点收到主节点发来的消息后返回主节点accept信息
4. 主节点收齐f个accept消息后（加上自己的一共f+1个），向所有从节点广播commit消息，返回客户端处理结果（交易哈希，commit信息，签名）。
5. 从节点收到主节点commit信息后，将交易打包区块，并带上主节点签名的commit请求提交给各自的节点验签、执行。（ 论文假设交易在所有节点上都是确定性执行 , 最后所有节点状态一定一致 ）

5.1.2 跨片 CFT 共识


跨片共识算法流程如下：

1. 客户端c向跨片交易所涉及的其中一个分片主节点π(pi)发送交易m=<REQUEST, OP, tc, c>δc，tc是交易时间戳，用于抵抗重放攻击，op是交易操作内容。δc表示客户端签名。
2. 主节点π(pi)给消息m分配编号hi，并向交易所涉及分片的所有节点广播propose消息<PROPOSE, hi,d, m>，m是客户端给主节点发送的交易，d是交易哈希。
3. 分片的从节点接受到主节点π(pi)的消息后，验证序号hi和消息内容。若当前节点在等待前一笔跨片交易m’的commit消息（m和m’涉及相同分片或者有重合）。为了保证片间commit顺序一致，节点将交易m存入缓存，等m’交易commit之后再处理m。否则，从节点直接向主节点π(pi)返回accept消息<ACCEPT, hi, hj, d, r>，其中hj表示片内一个从节点r给消息m分配的消息编号。
4. 当主节点π(pi)收齐来自每个分片的f+1个ACCEPT消息后，验证hj、hi和d，收集所有分片的从节点分配的消息编号(h1, h2, …, hk)，随后向所有涉及交易的分片广播COMMIT消息<COMMIT, [h1, h2, …, hk], d>δπ(pi)。δπ(pi)表示主节点签名，用于向区块链证明区块交易的正确性。主节点向客户端返回结果。如果客户端没收到回复，向所有相关分片节点广播。如果分片节点判断该请求已经被处理，则向客户端返回结果，否则，从节点将消息转发给主节点广播，如果主节点不广播消息，判断主已经故障。
5. 分片的从节点接受到COMMIT消息后确认编号hj之前的所有交易都已经COMMIT（即使之前没有ACCEPT，因为之前可能宕机了没收到），然后向区块链提交交易，执行，改变状态。

协议可能出现问题：

若某个时刻两个分片（p1和p3）的主节点同时向某个分片（p2）中的节点广播propose消息，如下图，由于网络延迟，p2中不同节点收到来自p1和p2的顺序可能不同，导致不同节点赋予相同消息的编号不同，造成p1或者p3收到的交易编号冲突，无法收齐f+1个编号一致的accept消息，造成此轮无法commit。另外，这也会进一步造成死锁情况，例如两个分片p1和p2同时收到p3的跨片共识请求，p1收到消息的顺序是m、m’; ，p2收到消息顺序是m’、m。p1只有收到m的commit消息后才会提交m’， p2只有收到m’的commit消息后才会提交m，系统陷入死锁。作者随后通过非常Naïve的方法解决这几个问题，最后还处理了主节点故障问题。

BFT场景中算法也非常类似，协议概要图如下：

同样，作者也针对这个场景下会发生的编号冲突、死锁、主节点故障进行了讨论，解法非常相似，这里不再赘述。

6. 实验

1测试CFT和BFT环境中不同workload下的吞吐，发现在跨片事务较小的时候性能最好。

2分片中节点数目增加，系统整体吞吐变化，意料之中，主要是共识开销。

转载请注明来自我的CSDN博客：https://blog.csdn.net/BOBOyspa/article/details/119119827