翻译 - Proof of Previous Transactions (PoPT): An Efficient Approach to Consensus for JCLedger

Proof of Previous Transactions (PoPT): An Efficient Approach to Consensus for JCLedger

Abstract

JCLedger 是基于区块链的分布式账本，用于 JointCloud，可以提高不同云之间交换资源的可靠性和便利性。其实现最大的挑战是共识机制。现存的共识机制，如：PoW 和 Pos，需要大量的计算资源，且低吞吐量并伴有垄断的风险。

本文提出基于 PBFT 的共识算法 proof of previous transactions(POPT)，记账人由特殊的 hash 算法从确定数量的候选人中获得。获选人来自参与 JointCloud POPT 共识过程的用户。同时，本文针对并行计算提出了新的区块链结构，用于提高 JCLedger 的吞吐规模。提出一致性共识算法为不同记账人分配交易。模拟实验表明 PoPT 为不同算力的用户提供了同等的记账机会，并行记账可以使 JointCloud 中大规模和高频交易处理更有效。

1. INTRODUCTION

JointCloud 是新一代云计算模型，允许多云服务提供商(CSPs)跨云进行合作，促进小中型企业成为云服务顾客（CSCs）。

为了让 JointCloud 中云资源和价值交换更可信和便利，前人提出了 JCLedger，一个基于区块链的分布式账本。

共识算法从所有用户/节点中为每个区块选择记账人。账本/区块链由记账人打包的区块组成。

记账人选择的两条基本原则（为 JCLedger 设计共识算法的核心要素）：

1. 选择过程不能由少数人控制（不超过一半）

2. 选择结果是不可预测的

JointCloud 中参与者包括 cloud services brokers（CSBs），CSCs，和 CSPs。

在满足共识算法的基础需求外，我们需要以下完成以下约束：

1. 避免浪费算力

2. 为不同算力的用户提供同等记账的机会

3. 记账激励更合理

4. 处理大规模和高频交易

之前，我们为 JCLedger 提出过基于 POW 的共识算法 PoPF。本文我们提出另一个共识算法 proof of previous transaction（PoPT），满足以上约束，且更适合 JointCloud。PoPT 基于 PBFT，比 PoPf 更高效。PoPF 使用哈希函数从获选人中选择记账人，用新链结构进行并行记账。

2. BACKGROUND AND RELATED WORK

除了满足区块链中共识算法的基本需求外，我们希望共识算法可以使系统更有效。让系统更有效的主要因素是记账人。记账人的工作是打包区块，包括在广播区块前收集和验证交易。交易的验证包括发送人签名的验证，以及是否同其它交易冲突。区块链系统的效率主要取决于记账交易的处理速度。

3. DESIGN OF POPT

每个区块记账人根据用户的排名选取，排名取决于用户参与前一个交易的情况。

本章节包括：链结构，为每个区块确定区块数量，记账人选取，交易分配，区块打包与验证，基于 PBFT 的共识过程

3.1 Chain Structure

区块链由区块高度组成。不同区块高度可能有不同区块数。同一区块高度的区块有同样的区块头，区块头是上一个区块高度的哈希值。记账人为同一区块高度并行打包区块。同一区块高度中的区块排序取决于记账人 id 的哈希值。同一区块高度的区块组成一个大区快。

3.2 Number of Blocks for Each Block Height

一个区块对应一个记账人，每个区块高度的区块数量等于记账人的数量。由于交易数量会动态变化，所以不同区块高度有不同区块数量。尽管无法准确估计交易数量，但是我们可以可以通过前一个区块高度分析趋势，确定即将到来的区块高度需要多少记账人。

针对交易数量设置两个值：$m_l$ 表示下限，$m_u$ 即上限。假设 n 是区块中交易的数量，那么规则为：

1. n < $m_l$: 下一个区块高度减少一个记账人

2. n > $m_u$ ： 下一个区块高度增加一个记账人

3.3 记账人选择

1. $R(x)$: 用户/结点 $x$ 排名

2. $F(x)$: 从上次成为记账人以来，用户/结点 $x$ 支付的费用

3. $M(x)$: 用户/结点 $x$ 成为记账人的次数

4. $hash(x)$: 字符串 $x$ 的哈希值

5. $cur\_header$: 当前 big-block’s header 的哈希值

6. $str\_id_i$: 候选 $i$ 的 id（public key）

哈希函数 $hash(x + y)$ 中 “$+$” 表示字符串 $x$ 和 $y$ 的连接。这里存在两种类型的结点：普通结点和记账结点。记账结点需要存储整个账本。对于记账结点，$F(x)$ 和 $M(x)$ 可以根据历史数据简单计算出。每个用户的排名由下面公式计算：

$R(x)=\frac{F(x)}{M(x)+1}$

从该排名中将分数最高的 $n$ 个用户设为记账候选人。假设当前区块高度需要 $k$ 个记账人，下面公式描述如何通过一个哈希函数从候选人中选择 $k$ 个记账人：

$h_{standard}=hash(cur\_header+str\_id_1+str\_id_2+...+str\_id_n)$

$h_{id}(i)=|hash(str\_id_i+R(i))-h\_{standard}|.$

最小的 $k$ $h_{id}(i)s$ 一旦被发现，对应的候选人将成为记账人。一旦候选 $x$ 成为记账人，我们设置 $F(x)=0$ 和 $M(x)=M(x)+1，这将致使 $R(x)=0$。因此 $x$ 将无法成为候选人，直到他支付足够的费用。该规则有效保证候选人轮询，避免持续记账。

3.4 Assignment of Transactions

交易通过一致性哈希算法分配给不同记账人/区块。分配分为三步：

1. Hash Circle: 记账人和交易被映射到一个值空间，在该值空间中可以行程一个首尾圆。SHA256 是映射用的哈希算法，保证值空间范围从 $0$ - $2^{256}-1$

2. Map Accountants and Transactions to the Hash Circle: 函数值表示位于哈希圈中的位置。对记账人，记账人 id 和当前区块高度是函数的参数。此外，函数参数是交易交易发送人的 id。映射函数保证，在同一高度，来自同一发送人的交易将被分配给同一记账人。因此，双花问题得以避免。

3. Map Transactions to Accountants: 根据哈希圈的位置，交易分配给据它顺时针最近的记账人。记账人只能处理映射给它的交易。

图四是交易分配的例子。虚拟结点用于避免不平衡分配问题。

3.5 区块打包和验证

在交易打包进区块之前需要验证，发送账户余额以及签名。一个区块中交易数量是有限的。记账人必须及时打包和广播区鲁哀，否者无法通过验证，将被丢弃。

当用户收到一个区块，在添加区块当账本之前，需要先验证区块的合法性。验证分 7 步。

1. 发送者是否是记账人身份

2. 记账人签名是否正确

3. 根据分配规则判断区块中的交易是否属于记账人

4. block-header 是否是上一个区块高度的 big-block 哈希值

5. 区块中的所有交易是否合法

6. 交易的数量是否超出限制

7. 区块广播到达时间是否超出限制

如果区块通过验证，添加区块至分布式账本中，否者丢弃，并广播消息，取消打包区块记账人身份。我们将在之后讨论如何处理无效记账人。

3.6 PBFT_Based Consensus Process

BPFT 是容忍拜占庭错误的 replication 算法，可以处理 $1/3$ 恶意拜占庭 replicas。view 中选择的 primary 负责将请求多播到其他 replicas。对 JCLedger 来说，候选人代表 replica， 区块高度代表 view，记账人代表 primary(关于 primary、view、和replica 的介绍可以参考：PBFT实用拜占庭容错算法深入详解)。图 5 表示 JCLedger 中 PBFT 的用法：

假设候选人（包括记账人）数量是 $n$，最大恶意拜占庭副本数是 $f$，那么$f=(n-1)/3$。所有诚实结点将广播合法区块。如果一个诚实结点确定记账人无效，那么所有其它诚实结点都会认为该记账结点无效。所有诚实结点所做的决定都是相同的。当结点从其它 $f+1$ 个不同结点接受到同一消息，它可以确定该消息来自诚实结点，因为恶意拜占庭结点数不超过 $f$。这里的消息代表一个区块或者是无效记账人的判断结果。

基于 PBFT 共识过程如图 6. 记账人向全网广播打包好的区块，然后获选人验证区块并向其它候选人广播验证结果：如果候选人在约定的时间内收到 $f+1$ 个结论宣称区块有效，它可以向全网发送 commit。；否者，它发送消息宣称记账人无效。在接收到 $f+1$ 个 commit 之后，所有用户将添加区块至它们的 JCLedger 中，并宣称区块有效。记账人无效存在两种情况：

1. 广播的区块被证实非法

2. 存在来自同一记账人的两个不同合法区块（不同区块可能来自双花问题）。

如果有结点确定记账人无效，它们可以丢弃来自无效记账人的区块并全网广播。无效记账人将被惩罚（剥夺记账权力和清空财产），已分配给它的交易将再下一个区块高度被处理。恶意拜占庭候选人可以只广播虚假 commit，但是它起不了任何作用，因为数量不超过 $f$。PoPT 是由 PBFT、记账人选取、交易分配组成的混合协议。根据算法，记账人选取和交易分配是本地处理的两步。结点计算谁将成为记账人，并且根据它们持有的区块链分配交易，而不需要任何网络通信。如果两个结点拥有同样的数据，他们将计算获得同样的结果，包括记账人和交易分配方案。因此不需要考虑这两个步骤上的网络攻击（DDos 或者 poor network latency）。PoPT 中的网络攻击可以被防御，因为在假设下 PBFT 是安全的，这一点将在 Section V 讨论。尽管 PBFT 模型容易收到 Sybil 攻击（单节点可以创建或者操纵网络中大量身份，威胁网络），但是 PoPT 中 Sybil 攻击无法成功。这是因为结点在成为记账候选人之前需要支付足够的 fees。

根据我们的设计，每一个区块高度至少存在 4 个候选人。尽管每个区块都需要 PBFT 共识过程，但是产生一个区块高度的时间与并行执行的的区块数量不成正比。与传统链结构相比，吞吐量将增加。

4. SIMULATION EXPERIMENTS

JCLedger 中模拟了 250 个区块高度的生成。实验中，记账结点数 250，随机彼此发送交易。记账候选人 50，区块中最大交易数 200， $m_l=50$，$m_u=150$ 。每个区块高度，我们为每个结点生成三个随机数来决定它们的行为。详细见表 1

模拟实验开始之前，没有历史数据。我们为每个结点随机设置 $F(x)$ 和 $M(x)$，第一个区块高度的记账人数设为 6。

4.1 记账人分布

根据设计，PoPT 可以为不同算力的参与者提供同等记账的权利，确保记账分配更加合理。用户支付费用和成为记账人的次数决定用户是否成为记账候选人。对候选人来说，成为记账人是完成随机的。图 7 表示每个用户/结点支付的费用总和和初始 $R(x)$ 值。图 8 表示每个用户在 250 个区块高度分别成为记账人和候选人的次数。

大多数用户成为记账人的次数为 3 - 10。两个用户 3 次成为记账人。9 个用户 10 次成为记账人。一旦用户成为候选人，存在两种情况：成为记账人，或者被其它 50 个用户超越排名。

图 9 表示 250 个区块高度中记账人分布情况。所有用户都有平等记账的机会，意味着 PoPT 解决了不平等算力问题，提供合理的物质激励。此外，选取过程由所有参与者操纵，结果不可预测。

4.2 Omnet++ for Network Simulation

Objective Modular Network Testbed in C++ (Omnet++) 是由 C++ 模拟库和框架组成的模块，最初用于构建网络模拟。当前场景中，Omnet++ 用于模拟 PBFT 三阶段并行处理。根据实验设定，公式过程中存在 50 个候选人。我们分别为区块高度设置区块/记账人数量（1 - 50）。假设模拟中拜占庭容错参与者不超过 $f(f=(50-1)/3)，因为我们的目的是当系统运行正常时分析并行记账的不同之处。最后一个参与者达成共识的时间即系统达成共识的时间。

第一个网络模拟中，发送消息的网络延迟范围随机在 50 - 100 ms，拜占庭容错参与者数量设为 16，意味结着点在做出决定之前需要收到超过 33 个 commits。如图10，当区块高度中去快数小于 10，区块数越多，区块高度所需时间越多，区块达成共识的时间越少。区块数超过 10 ，效果相反。

第二个网络模拟中，随机发送消息的网络延迟在 100 - 200. 拜占庭容错参与者数量也设为 16。图 11 表明，转折点从最初的 10 变为 12. 虽然 PBFT 需要考虑网络资源确认区块或者改变记账人，但是，如果并行规模根据网络延迟合理设置，并行记账可以降低区块达成共识的平均时间。

上面实验说明，当拜占庭容错参与者数量为 $f$ 时，区块高度达成共识所需时间的最糟情况。然后，如果 JointCloud 中不存在拜占庭容错参与者，结点在做决定前只需要收到 17 个 commit，这缩短了达成共识的时间。图 12 表示在网络延迟为 100 - 200 时，最好和最坏情形的对比。如果拜占庭容错参与者数量不超过 $f$，区块和区块高度达成共识的时间没有大的区别。

总结：

1. 模拟实验 A 证明 PoPT 可以为不平等算力之间提供平等的记账权力，同时提供合理的激励分配。

2. 模拟实验 B 证明，如果并行规模可以根据真实系统合理设置，并行计算可以提高系统性能。

5. DISCUSSION AND FUTURE WORK

5.1 Security Assumptions

正如 PBFT，假设存在 n 个结点，2/3 以上是诚实结点，少于 1/3 非诚实（长时间存在下线结点或者产生分叉）。假设非对称算法对数字签名是安全的，签名无法被伪造。此外，hash 函数是安全的，hash 冲突不会发生。假设网络是“部分同步的”，这意味着消息延迟 $d(t) 不会无限比 $t$ 增长的更快。

5.2 Tamper Block

PoPT 中，选择第一批记账人，记账人开始打包区块，意味着攻击者无法篡改一个不是由他打包的区块，除非该攻击者拥有记账人的私钥。此外，篡改一个区块意味着需要篡改该链的所有其它已有的区块，所以攻击者需要有所有用户的私钥。如果攻击者有所有私钥，那么他可以肆意花费这些用户中的所有钱，而不是篡改区块。最糟的情况是攻击者成功篡改了一个区块，但是也没有用，因为网络中出现来自同一用户的两个区块，该区块将被认定为非法，被丢弃。

5.3 Where the Crypto-Currency Comes From?

crypto-currency provider (CCP) 提供和回收 在 JointCloud 中流通的 crypto-currency/coins，并且承担 coins 价值证明。CPSs 和 CSCs 可以用流通货币（Chinese Yuan 或者 U.S. Dollars）从 CCP 购买 coins，或者使用 coins 兑换法币。购买和兑换是 JCLedger 中两种特殊交易类型。此外，CCP 提供超过一种类型的 ctypto-currency，JCLedger 支持 multictypto-currency 流通。图 13 表示 JointCloud 中三种主要参与者。

5.4 Computing Power

PoPT 基于 PBFT，这意味着我们不需要大量算力挖矿达成共识。PoPT 中，计算资源主要用于计算 $R(x)$，验证区块和交易。任何 PC 或者手机都可用，因此消除了不同算力的问题。

5.5 Future Directions

未来工作主要关注 PoPT 应用、 JCLedger 实现、智能合约。结合并行记账、off-chain micropayment channels和分片技术解决大规模问题。区块大小和间隔是区块链设计中两个重要的参数，需要结合系统实际状态动态调整。可以引入深度学习调整这两个参数。引入侧链技术完成跨链交换。

6. CONCLUSION

本文，提出基于 PBFT 共识算法 PoPT，用于 JointCloud 中分布式账本进行并行记账。PoPT 中，记账人选取来自确定数量的候选人，候选人根据用户排名选取。排名由用户参与前一个交易计算获取（包括用户支付的费用和成为记账人的次数）。随着系统交易的增加，排名持续发生变化，导致记账候选人动态变化，中心化危险得以避免。使用 hash 函数从候选人中选取记账人可以节约算力。为了解决大规模问题，提出并行记账，不同于 micropayment channels 和分片。机型计算意味着并行选取超过一个记账人处理交易。设计新 区块链结构用于并行记账。新结构中，多个区块在每个区块高度同时添加到区块链中。交易通过一致性哈希算法分配给不同记账人/区块，使用虚拟结点避免不平衡分配。因为 JointCloud 中交易数量不稳定，每个区块高度的区块数量需要动态调整。我们根据历史数据预测交易数量，判断下一个区块高度需要多少区块。需要注意的是，并行记账和 micropayment channels 以及分片技术并不冲突，这三种技术均可以同时解决大规模问题。