区块链分片-CCFB-Jenga-优化分片

CCF B                                                                                                                                  2022年 

Jenga：在基于分片的区块链中构建智能合约以实现高效处理

问题：在处理日益重要的智能合约时，现有的区块链分片协议不能很好地扩展。它们通常需要复杂的多轮跨分片共识协议来执行合约，并在状态传输期间进行广泛的跨分片通信，主要是因为每个分片存储和执行一个孤立的、不相交的合约子集。

贡献点：1.减少多轮跨分片共识协议在智能合约执行过程中造成的性能损失。

2.减少状态获取和返回过程中跨分片通信带来的性能损失。

方法：

我们要求每个分片维护所有合约的执行逻辑。在这种设计下，多个合约可以在一个分片中一起执行，而不需要多轮跨分片执行。因此，一旦某个分片获得了合约交易的相关状态，所有相关合约都可以在同一个分片内执行一轮。为了减轻每个节点的存储开销，合约的状态只单独存储在一个分片中。（图a里通道1 2 3 分别进行了两次共识 因为不知道其他通道的逻辑，所以当本通道内合约执行完毕就进行共识，而图b中通道1 2 3相互知道逻辑所以在本通道合约执行完后会等待接下来的逻辑执行完再统一进行共识）

我们在存储隔离状态的分片（也称为状态分片）之间设置了多个“正交”的合约执行通道。在这种设计下，任何执行通道都可以覆盖所有状态分片。因此，不需要额外的跨分片通信来在任何状态分片和执行通道之间传输消息。具体来说，每个节点同时属于某个状态分片和“正交”执行通道。在多个状态分片中获得的状态可以通过某些重叠的节点子组直接广播到相应的执行通道。在执行合约后，通道中的节点通过对应的重叠子组直接将结果返回给相关的状态分片。这种设计消除了状态获取和返回期间的跨分片通信，提高了系统效率。（因为执行通道正交于状态通道，所以当执行通道想要获取状态通道内合约的状态时，可以通过正交节点进行获取，而正交节点在执行通道内传输状态属于通道内通信  但由于每个节点都要维护所有合约的逻辑 因此存储开销提高了n倍 相比于节点维护全局信息开销还是小）

系统模型：

系统有n个节点，s个执行通道，s个状态通道

确定节点所在的状态通道和相应“正交”的执行通道：

具体地，每个节点i将其公钥与所分配的随机性进行异或以获得新的随机数ri。然后对新的随机数ri取模N以得到随机数rN i。每个节点将rN i除以应该在每个分片内的节点的数量（即，N/S），并且所获得的结果的整数部分是节点所属的状态分片。将随机数rN i除以分片的数量（即，s）的执行通道，结果的其余部分是该节点所属的执行通道。这种分配方法实现了一种架构，其中状态分片与执行通道"正交"。它还确保状态分片的数量与执行通道的数量相同，并且每个状态分片内的节点数量与每个执行通道内的节点数量相同。

确定智能合约在哪个执行通道里执行：

我们的系统不再使用智能合约的哈希来确定智能合约的执行通道。相应地，我们使用智能合约交易的哈希值来确定其中包含的所有智能合约的执行地点，并且该交易内部的所有智能合约都由同一个执行通道执行。由于交易哈希的随机性，这种设计可以更好地平衡每个执行通道上的计算负载。

跨分片共识协议：

阶段一 预准备阶段

分片内共识：我们采用拜占庭容错（Byzantine Fault Tolerant，BFT）共识作为我们的分片内共识协议（在状态分片和执行通道中）。

状态确定：（a）状态可用。在这种情况下，状态分片达到分片内共识，将可用状态设置为不可用，并使用交易散列来确定将状态发送到哪个执行通道。然后，状态及其交易散列通过与执行通道重叠的状态分片的子组直接在执行通道中广播。(b)，状态不可用。在这种情况下，状态分片达成分片内共识，通过子组将AbortRequest消息和transaction hash广播到执行通道。

在此阶段，状态分片通过协商一致确定智能合约交易涉及的相关状态，并通过子组将其广播到执行通道。跨分片共识始于客户端启动智能合约交易(调用多个智能合约)。在发送交易之前，客户端在本地决定哪些合约、帐户和状态包含在智能合约交易中。这一决定可以通过动态程序分析(代码模拟)来实现，类似于[23]。然后，该信息被记录在交易中。

阶段二 准备阶段

在此阶段，执行通道执行与交易相关的所有合约，达成内部共识，并通过不同的子组将执行结果广播回状态分片。在执行通道接收到与交易相关联的第一状态确定的结果之后，它为该交易启动计数器c。c表示与交易相关联的状态数，可以通过解析智能合约交易来导出。对于成功获得的每个有效状态，计数器减1。最终，如果c=0，则执行通道开始执行交易内的所有智能合约，达成分片内共识，并通过不同的子组将执行结果（状态更新）和交易哈希直接返回到对应的状态分片。否则（例如，由于超时或无效状态），执行通道在达成共识后，通过子组直接向所有相关状态分片返回Abort信息和交易散列。

阶段三 提交阶段

在此阶段，状态分片通过子组从执行通道获取执行结果，通过共识更新状态，并提交智能合约交易。每个相关的状态分片在执行通道上从相应的子组获得反馈。这些信息通过子组直接广播到分片中。如果接收到有效的状态更新，则分片通过内部分片共识在内部将交易提交到区块，并将区块添加到区块链。同时，分片更新存储的状态并将状态恢复为可用。如果接收到有效的Abort消息，则交易被中止。

原文链接

Jenga: Orchestrating Smart Contracts in Sharding-Based Blockchain for Efficient Processing - AMiner