[VLDB'21] SlimChain：On/Off-Chain协同的私有链

《Scaling Blockchain Transactions through Off-Chain Storage and Parallel Processing》论文笔记

Introduction

现有的区块链系统存在的问题：

1. 区块链节点存储和计算耦合：
   1. 每个节点都需要保存完整的账本，都需要执行所有的交易导致节点的存储压力和计算压力增加；
   2. 扩展性有限；
   3. 由于能够处理如此大量数据的节点越来越少，网络变得更加中心化，从而破坏了系统的安全性和稳健性；
2. 区块链网络分片：
   1. 治标不治本，每片内的节点仍然执行重复的计算和存储；
   2. 会引入跨分片交易处理问题以及额外的安全问题；

本文提出了无状态区块链SlimChain，其主要特点包括：

1. 最小化区块节点的负担：区块节点设为无状态，区块相关数据存放在单独的存储节点；
2. 最大化系统吞吐量：支持交易在不同节点并行执行；
3. 支持高效分片：利用分片提高区块链交易处理的扩展性；
4. 安全保证：充分的区块链安全保证机制。

Design

整体架构

SlimChain组件主要包括三个部分：

1. 客户端（client）：发起交易（智能合约）请求；
2. 共识节点（consensus node）：SlimChain的链上（on-chain）部分，通过共识协议维护一致的账本视图（ledger view），具体可分为两种类型：
   1. 区块提议节点（block proposers，后文简称提议节点）：生成新区块（类似于矿工节点）；
   2. 区块观察节点（block observers，后文简称参与节点）：验证新区块；
3. 存储节点（storage node）：SlimChain的链下（off-chain）部分，持久化存储账本和其他区块相关的数据，执行交易。

区块数据结构

链上部分：

• $H_{prev\_blk}$：前一个区块的哈希；
• $\pi_{cons}$：共识相关的参数；
• $H_{tx\_root}$：区块中所有交易的汇总哈希值；
• $H_{tx}$：单个交易tx的哈希值；
• $H_{state\_root}$：当前区块交易Merkle树的根节点；

链下部分：

• Transactions：实际的交易执行内容；
• Merkle Trie：持久化保存的账本。

交易处理

流程概述

SlimChain中交易完整的流程如下：

1. 客户端向其中之一的存储节点发送交易请求$<tx_{input},\sigma_{tx}>$，包含交易的输入以及客户端的数字签名；
2. 存储节点收到后在本地执行（simulate）交易获取读集${r}_{tx}$和写集$w_{tx}$，再执行完成后将执行结果以及证明$\pi_{tx}$广播给所有共识节点；
3. 共识节点验证执行结果后，生成区块并更新区块链的状态（修改区块高度等）；
4. 存储节点发现区块已经生成后，将事务的执行结果提交到底层账本中去。

存储节点交易执行流程

存储节点的执行过程在TEE（trusted exection environment）中完成。

在TEE中会执行流程包括：

1. 验证客户端发送的交易签名（L1）；
2. 基于前一个链下状态$H_{old}$执行交易并获取读写集（L2）；
3. 验证从$H_{old}$中读取结果的正确性（L3-4）；
4. 对读写集进行签名（L5）。

离开了TEE之后，还会交易的写集$\{w\}_{tx}$创建一个额外的Merkle证明$*\pi_{write}*$留在后面使用。所以交易执行得到的结果就是下面这样，左边是当前新创建的链下状态（$H_{old}$指的是$H_{99}$），在TEE中的执行结果不会立刻写回链下的状态。

最后存储节点会将交易$txn_{submit}=<tx_{input}, \{r\}{tx}, \{w\}{tx}, H_{old}, \pi_{TEE}, \pi_{write}>$打包并广播给所有的共识节点。

共识节点交易提交流程

算法中一些符号的含义：

• $M_{i\mapsto r/w}[k]$：区块$k$中的读集/写集；
• $M_{r/w\mapsto i}[k]$：读/写过记录$k$的区块集合；
• $T_{w}$：根据窗口内区块写集构建的不完全状态（完全状态的子集，完全状态保存在存储节点中，二者的根节点一致）。

存储节点和共识节点均维护有一个相同结构的状态树，其高度为i的区块的根节点分别记为$HS_i$和$HC_i$，相同高度的哈希值是一致的并且$HC_i$只是$HS_i$中的一个子树。但是由于网络异步问题，同一交易发送到共识节点时其区块的高度要大于其在存储节点执行时区块的高度，举个例子交易$txn$在存储节点上执行时$HS$的高度为99，但是在执行节点生成区块时$HC$的高度为101。为了保证交易的及时处理（避免长时间无响应），同时考虑到二者高度差值越大可能出现冲突的概率就越大，所以需要加上时间窗口限制，这里的窗口大小设置为k。

提议节点通过共识协议保证交易接受顺序的一致性。提议节点收到来自存储节点的交易后会按照顺序依次对事务做以下验证：

1. 检查是否在窗口内，签名验证是否通过，事务读写集是否满足序列化（L4-7）；

2. 使用写集$\{w\}_{tx}$*对应的写验证$\pi_{write}$*树插入到$T_{w}$中（还没有计算新的根节点的值）（L8）；

3. 更新相应的映射集合$M_{i\mapsto r/w}$和$M_{r/w\mapsto i}[k]$（L9-12）；

4. 重新计算$T_w$的根节点值$H_{state\_root}$，并生成新的区块（L13）；

5. 滑动窗口（L14-23）。

   

将写集中每一项对应的$\pi_{write}$合并至$T_w$以及根据映射集合删除失效路径（窗口外区块）的算法分别如上所示，这里不过多介绍。

对交易的可序列化检查算法如上所示，支持OCC和SSI两种经典并发控制算法，并未做优化所以这里也略过。

这里提供了提议节点完成的执行流程的例子，如上图所示。交易$tx_1-tx_4$都可以正常提交，而交易$tx_5$因不满足SSI而退出。

提议节点会将生成的区块同步给观察节点和存储节点。存储节点收到区块后会按照交易的顺序将其写集提交至底层账本，并且会保存交易的相关信息（例如交易的输入参数，读写集等）和上一个区块的快照$H_{old}$而不是摘要。而观察节点在收到提议节点发送的区块之后会根据Algo2对区块的交易进行验证，然后加入到本地的区块链中。