【区块链论文阅读】A Weak Consensus Algorithm and Its Applic

【区块链论文阅读】A Weak Consensus Algorithm and Its Application to High-Performance Blockchain

这是一篇网络顶会INFOCOM的文章，一作来自南方科技大学（第一次听说，南科大成立的晚，虽然不是985，211 但是实力非常强）

摘要：人们已经提出了大量的一致性算法。然而，严格一致性的要求限制了它们的广泛采用，尤其是在高性能系统中。在本文中，我们提出了一种弱一致性算法，只保持消息之间相对位置的一致性。我们应用这种一致性算法构建了一个高性能的区块链系统，称为Sphinx。我们使用32k+行代码实现该系统，包括consensus/P2P/ledger等所有组件。评估表明，Sphinx可以达到43k TPS的峰值吞吐量（8个完整节点），这比以太坊等现有区块链系统在相同实验环境下的速度要快得多。据我们所知，我们提出了第一个具有完全实现的区块链系统的弱共识算法。

1 介绍 INTRODUCITON

共识机制是分布式系统中的一个关键组成部分，为就网络的当前状态达成一致提供了强有力的手段。随着区块链的推广，共识机制因其在安全令牌传输中的重要作用而受到广泛关注。一般来说，共识算法有两种主流类型[1][2]，即经典的拜占庭容错（BFT）协议[3][4]和新提出的中本共识（NC）[5]，如PoW[6]、[7]、PoS[8]、PoA[9]等。然而，采用这些算法的区块链系统由于大规模通信或密集计算而存在低性能问题。例如，比特币需要竞争性计算来决定有效链，其速率限制为每秒7笔交易（TPS）[7]。这些限制极大地阻碍了在真实场景中的广泛采用。这让我们回到了它们的核心机制。

现在不管是做共识，还是做分片 一般都是为了解决吞吐量性能问题。

BFT协议被提出用于在存在恶意节点的情况下达成一致，其中容忍度最大为总节点的2/3。BFT协议需要协商过程才能做出最终决定。典型系统PBFT[4]如图1所示。a、 领导者向副本发送建议，副本分发回复。然后，在收到超过预定义阈值的有效回复后，复制副本将其状态（是否准备好进入新状态）广播给其他人。一旦收到的提交消息超过阈值，就会做出决定。由于网络延迟等因素，这样一个过程中的时间消耗是不可预测的不稳定。因此，交互通信会限制BFT共识的性能，并增加通信开销。

近几十年来，中本共识以其卓越的简单性在一个关键方面脱颖而出。NC打破了只有非公开委员会才能进行协商一致的假设，相反，它使所有参与者都能参与协商一致的过程。以比特币[7]为模式的NC协议无法达成最终共识。NC协议取消了交互模式，采用了竞争规则——最长链获胜。如图1.b所示。矿工们产生的block随机地附着在他们的祖先身上。只有拥有最多后代的链条才能存活，而其他竞争性的子链则被抛弃。最终的结果是通过让blcok埋得足够深来逐步实现的。因此，NC中的冲突解决显著降低了块的确认速度。

PS（Personal Statement）：Bitcoin共识遵从最长链原则，属于最终一致性 应该也算是弱一致性。

我们观察到，基于这两种共识的协议遵循相同的原则：在一轮中，只有一个区块被视为已确认（NC中的区块高度相等）。这极大地限制了它们的整体性能，因为解决冲突和为强一致性服务的总排序过程花费的时间远远超过预期。这种机制阻碍了它们的广泛采用[10][11]，尤其是在一些高性能要求的场景中[12]。为了缓解这种限制，我们提出以下问题： 是否有可能提出一种一致性算法，通过削弱一致性保证来提高性能？

直觉上，答案是“不”。状态一致性是协商一致机制的核心属性。严格的一致性确保分布式网络在存在故障维护者和对抗性网络延迟的情况下，就事务的总顺序达成一致。所有分布式节点在每个特定高度都具有相同的全局视图。这保证了状态以有组织和有管理的方式过渡， 支持智能合约等上层机构。相反，无序交易表示用户在调用区块链服务时可能感到困惑的模糊状态。例如，Alice向Bob发送一个事务。如果该事务存储在多个块中，Bob无法知道哪个位置提供了有效的事务。然而，在某些场景中，并不严格要求一致性，例如基于区块链的证书系统。证书验证程序的主要目标是确认证书确实存储在链中。本证书的具体位置无关紧要；甚至可以重复存储证书。应该注意的是，几个DAG结构项目[13][14]中的部分一致性仍然对事务的位置敏感，因为它们的上层应用程序[15]，例如令牌传输，仍然基于固定的事务序列。

针对于特定场景下 提出弱共识算法。

在这项工作中，我们提出了一种新的共识机制，称为弱共识，以适应上述情况。我们的设计削弱了严格一致性的保证，并放松了持久性[5]。弱一致性主要保证一条链中的区块相对序列与另一条链中的区块相对序列保持一致。如图1所示。c、 节点B创建一系列块1、2、3、4。我们的目标是确保序列（B1→ B2→ B3→ B4）可以跨链正确维护，无论在链之间插入多少块（由其他节点生成）。我们模型中的块需要接收来自对等方的回复消息，表示它们已成功存储了这些块。每当块收集的提交消息超过阈值时，它就被视为已确认。为了证明我们共识的稳健性，我们在[5]的启发下，正式定义了相对持久性和活性的属性。相对持久性关注前任和继任者之间的关系，确保相对位置的正确性。活跃度保证所有节点最终都会在块的关系上达成一致。此外，我们将该算法应用于区块链系统名为Sphinx，具有完整的实现。总之，我们做出以下贡献

• 我们找出了导致当前一致性协议性能瓶颈的原因，并提出了一种弱一致性机制，通过削弱严格一致性的保证来实现链的并行处理。

• 我们将我们设计的弱共识算法应用于一个高性能区块链系统，该系统具有正确定义的模型和严格证明的鲁棒性。

• 我们提供了Sphinx的完整实现，并对其性能进行了评估。结果表明，我们的系统在43k TPS（8个完整节点）的情况下实际上是高效的。

本文的其余部分结构如下：第二节介绍了高级算法设计。系统协议及其实现分别见第三节和第四节。第五节给出了安全性分析，第六节给出了对我们系统的评估，第七节给出了案例示例。第八节讨论了相关研究。最后，第九节讨论了结论和未来的工作。

我理解的是，每个节点存储的本地区块链都是不一样的，但是对于其他节点打包的区块的相对顺序是一样的。 但是 这样可能会存储相同的交易。不过本篇论文针对的是允许此类状况出现。

2 弱共识算法 WEAK CONSENSUS ALGORITHM

本节提供了安全性假设和共识算法的一般构造，以及相应的安全性属性。

A. Notations

我们将协议中的节点表示为N，并将每个节点标识为 {N0，N1，…，Nn} ，其中n是委员会成员的指数 n = 3f + 1。令 i 是一个增长的整数，满足条件 0≤i≤r ，其中 r是状态的index、 j 是一个整数，满足 0< j ≤ n。

• 假设M是消息空间，S是状态空间，R是参考空间。

• m，m∈M 是某个节点提出的消息。

• PF 是 成功插入M的证明

• s 表示满足S的已确认状态 s∈ S $S_{N_j}^i$ 是节点Nj 第i个确定状态 $S_{N_j}^i\in \left\{\mathbb{S}\mid S_{N_1}^0,\dots ,S_{N_1}^r;\dots ;S_{N_n}^1,\dots ,S_{N_n}^r\right\}$

这两个参数用于定位网络中的特定状态。

S { N 0 , … , N n } r S_{\left\{N_{0}, \ldots, N_{n}\right\}}^{r} S{N0​,…,Nn​}r​指当前r轮中从其他节点接收到的状态。

⇓ 是指示两个状态之间相对位置的参考。

Specifically，${\Downarrow }_A^B$是指从B指向A的参考。 它定义了关系 a发生在B之前。

更具体地说， ${\Downarrow }_{S_{N_j}^x}^{S_{N_j}^y}$ 以为是 x 是y 得祖先,当0 < x < y ≤ r

${\Downarrow }_{S_{\star }^{i-1}}^{S_{N_j}^i}$表示一组参照，包括来自状态的边 j 到 状态 $S_{N_0}^{i-1},\dots ,S_{N_n}^{i-1}$, $S_{N_j}^i$外向度

相对地，${\Downarrow }_{S_{N_j}^{i-1}}^{S_i^i}$包含所有的边从 状态 $S_{N_0}^i,\dots ,S_{N_n}^i$到状态 $S_{N_j}^{i-1}$。 $S_{N_j}^{i-1}$的 in-degree

B.Security Assumption

我们假设诚实的节点将始终执行诚实的行为，其中发送给对等方的消息是正确的。对于底层网络，我们遵循部分同步网络的隐式假设。特别是，我们系统中的诚实节点网络连接良好，诚实节点之间的通信通道畅通无阻。来自诚实的广播者的消息可能会被延迟，但它们最终会在已知的最大延迟δ内到达其他广播者[16]。我们的算法遵循经典BFT-style协议的基本设计，旨在容忍三分之一的拜占庭节点。具体来说，我们假设总共有3f+1个节点，并且参与的节点数量是固定的。这表明，同伴参与或搅动的动态不在我们的考虑范围之内。此外，我们假设其中至少有2f个节点正常工作，其中f是拜占庭节点的数量。

C. Protocol Overview

该协议被建模为跨分布式节点复制的状态机。网络中的每个节点都维护一个包含已接受消息和当前状态的消息日志。同时，在我们的算法中，一个节点必须保持从其他节点接收到的状态。我们按照PBFT[3][4][17]的描述来展示我们的协议：协议分两轮进行，每轮有三个阶段，即预准备、准备和提交。我们提供协议概述如下。

• Pre-prepare:主节点接收客户端请求，并将此类消息插入本地链。然后，节点创建一个Pre-prepare消息来声明两个客户端消息之间的相对位置。随后，它向对等方广播已签名的消息。

• Prepare:节点接收预准备消息并检查完整性、正确性和有效性。当接收到的Pre-prepare消息通过验证时，节点更新其本地存储状态，并广播回复的prepare消息以声明正确的相对位置。否则，节点将中止它。

• Commit.如果任何节点在指定的时间间隔内从对等方（可能包括他自己的对等方）接收到有效准备消息的仲裁2f+1，则该节点通过广播回复的提交消息来确认提议的决定。当一个节点收集了超过2f+1个提交消息时，该节点会转换状态并用更新的状态回复客户端。

Complementary mechanism.(互补机制): 我们的协议旨在最终确认两个状态之间的相对关系。由于缺少2f+1匹配的提交消息，可能无法提交相对关系。图2提供了一个例子来解释这些缺陷。我们假设有三个节点，并且节点N2已经确认了节点N1中的状态S1N3和S2N3的相对位置（感觉论文中说的可能是N2已经确认了N3中状态的相对位置）。通过之前协议的设计，Sphinx通过接收2f+1回复来达成协议。然而，节点N1可能存储冲突状态，即， 存储的相对位置是S2N3和S1N3。当超过计数器中设置的界限时，如果不从其他节点重新提取状态，冲突状态将永远无法反转。因此，互补机制将状态S2N1重新附加到N1的末尾，并且更新的S2N1替换旧版本。因此，状态s2n1和S1N1之间的相对位置从节点返回到正确的位置。上述程序对于N1是强制性的。如果N1不能接受来自诚实节点N2和N3的状态S2N1和S1N1之间的相对位置，那么N1之后的新消息将不会被N2和N3接受，因为他的预准备消息基于来自其他节点的最新状态。我们的安全分析中提供了更多细节。

Highlighted Differences. 突出差异。 我们的协议在四个方面不同于PBFT（见表一）：

（a）我们的协议是一个异步无领导的拜占庭协议。而不是依靠一个领导者， Sphinx取消了相关阶段的领先地位，使每个参与协商一致程序的参与者都能参与。因此，每个参与者不需要等待与其他参与者同步的最新状态。

（b） 网络中的每个共识节点都会执行类似的行为（预准备、准备、提交）。这些节点独立进行，但通过交叉引用相互交互。

（c） 我们删除了PBFT协议的辅助机制（如检查点、视图更改）。相反，我们提供了一个简短的补充机制来解决冲突，如保留两个状态的相对位置。

（d） 我们的协议削弱了强一致性的假设，获得了更高的性能和更短的确认时间。我们遵循PBFT的活性属性。此外，我们还引入了一个新的安全定义相对持久性，它的灵感来源于一致性[3]和持久性[5]的特性。

TODO 活性属性是什么，相对持久性是啥？

D. Security Properties

我们的算法通过达到部分一致性而不是线性一致性，削弱了对一致性的有力保证。在我们的共识中，不再需要完全排序的程序。每个节点分别创建新状态，同时存储远程（其他节点）状态。我们允许一个状态跨平行链存储在多个位置。关键的想法是保持两个状态之间相对位置的一致性。在此基础上，我们将算法形式化为两个属性：相对持久性和活性（relative persistence and liveness.）。相对持久性意味着，一旦足够多的诚实节点报告确认，两个状态的相对位置是不可逆的。活跃度是指一旦两个状态之间的相对位置被一个诚实节点确认，它最终应该被网络中的其他诚实节点确认。

定义1 相对持久性： Sphinx 实现了相对持久性的性质，如果对于所有R中的关系，存在一个可忽略的函数 negl（λ）例如 $ad{v}_N^R（\lambda ）<negl（\lambda ）$,$ad{v}_N^R（\lambda ）$是在同一关系${\Downarrow }_{S_{N_i}^x}^{S_{N_i}^y}$中做出决定的优势 ,任何两个诚实的节点所做的都是冲突的 0 < x < y ≤ r。？？

相对持久性属性确保一旦诚实节点确认了两个状态之间的相对位置，这种关系最终将以高概率在网络中的每个节点中得到确认。该性质保证了平行链上两个状态之间的相对位置保持一致。

定义2 活性： Sphinx 具有活性，如果对于所有PPT（BFT?）诚实节点，存在一个可忽略的函数 negl（λ），例如$ad{v}_N^R（\lambda ）<negl（\lambda ）$其中，advRN（λ）是诚实节点不接受正确关系的有利条件 ${\Downarrow }_{S_{N_i}^x}^{S_{N_i}^y}$ 0 < x < y ≤ r.

活跃性保证了所有节点最终都同意一种独特的关系。每一条链都有。这种独特的关系代表了一个状态与其祖先之间的相对位置。该术语最终表明可能需要足够的时间（在δ的上限内）才能达成一致。该属性可确保一个状态被放弃或接受，而不是永久挂起状态。

3 SPHINX SYSTEM

在本节中，我们首先介绍用于构建方案的密码构建块。然后，我们提出了一个采用弱共识算法的高性能区块链系统。

A. Cryptographic Building Blocks

Merkle Hash Tree. Merkle树[18]是基于单向加密哈希函数的树。数据以加密哈希的形式压缩。Merkle树中的每个节点都标记有一个由其子节点组成的哈希。这种技术能够对区块链系统中的交易进行高效、安全的验证。

Signature Scheme. 签名方案由三个概率多项式时间算法（kgen、sig、verify）组成，其中kgen生成一个私有签名密钥和一个公共验证密钥，sig在消息上输出签名，verify用于检查签名。

B. Entities.

Sphinx主要由两类节点组成，即区块链节点和客户端节点。客户端节点是消息的创建者，它允许向账本记录器发送请求，并在共识完成后等待回复。区块链节点负责两项功能：记录和验证。前一个功能用于记录本地链。另一个用于检查记录进度的正确性。

C. System Design

我们的具体构造Sphinx基于弱一致性算法。Sphinx中的状态被实例化为块，由对等节点验证和确认。该消息继承了经典的区块链结构，包括地址、时间戳、元数据等字段。在我们的系统中，每条链都有两种类型的引用：一种指向自己的父块，另一种指向对等方。明确地说，我们的系统采用交叉引用来提高区块链的安全性，多个节点同时并行生成自己的链，并验证其他节点的块。交叉引用确保每个链可以相互验证其他链的行为，例如它们是否通过检查之前的Merkle根来保持一致的块序列。这种机制保证了两个块之间相对位置的一致性。具体协议如下所示。

Pre-prepare： 每个节点维护一个单独的消息池和一个独立的分类账。当节点Np从客户端接收到请求（消息）M时，它首先检查消息的语法以确保正确执行。如果通过，它将对本地池中接收的客户端消息进行排序。这些消息按其时间戳（例如Lamport时间戳[3]）排序，其中最新消息的优先级高于早期消息。在算法中处理第一条接收到的消息，而丢弃冲突/重复的消息。基于有序序列，节点将有效序列号SN分配给M。我们强调序列号SN是一个局部变量，用于表示单链的索引r。它不同于BFT算法[3][4]中定义的全局变量SN。我们系统中的索引r有助于在局部链中定位块，而在全局视图中定位块需要链id Nj的附加参数来形成坐标（r，Nj）。

为什么最新消息的优先级高于早期消息？

之后，它将消息M插入到他的本地链中。插入主要是将M的散列和远程块 $\left(S_{N_0}^r,S_{N_1}^r,\dots ,S_{N_n}^r\right)$ 的状态合并到一个新的Merkle树中。接下来，它对Merkle根进行签名，并通过生成包含三种证明的证明pf将该块附加到公共日志中：（a）用于证明日志包含M的PM；（b） PB是old blocks的延伸；（3） PS证明S存在于树中。

消息M 和 状态$\left(S_{N_0}^r,S_{N_1}^r,\dots ,S_{N_n}^r\right)$ 按时间顺序从左到右存储在Merkle树的叶子中。因此，证明很容易计算。Merkle树包含M和状态$\left(S_{N_0}^r,S_{N_1}^r,\dots ,S_{N_n}^r\right)$ 。在我们的设计中，这些item单独存放在树叶上。之后，当前节点广播Pre-prepare消息 $⟨\text{ Pre-prepare, }M,SN,S_{N_p}^r,PF,{\Downarrow }_{S_{N_p}^{r-1}}^{S_r^r}⟩$ 给 对等节点，${\Downarrow }_{S_{N_p}^{r-1}}^{S^r}$表示第r状态和r-1状态的相对位置。

Prepare： 假设一个随机节点Nq从节点Np接收到预准备消息$⟨\text{ Prepare, }{S}_{N_p}^r,M,PF,{\Downarrow }_{S_{N_p}^{r-1}}^{S_r^r}⟩$。节点Nq验证预准备的正确性。

算法检查是否：

（a）S*的签名是正确；（b） 消息M已插入Np；（c） 前一个状态 S*q被差入到Np中（d） 声明的消息的状态没有冲突。当成功检查收到的预准备消息时，节点Nq更新其本地存储状态Sp，并将收到的消息插入其本地日志。然后，它生成并广播应答准备消息 $⟨\text{ Prepare, }SN,d(SN)⟩$其中d（SN）表示状态的哈希摘要。否则，节点将中止预准备消息。请注意，同一预准备消息只能接受一次，重复的预准备消息将被丢弃。

Commit： 如果一个节点从不同的节点（可能包括他自己的节点）收到有效准备消息的仲裁2f+1， 它确认提议的消息并广播提交消息$ \langle\text { Commit, } S N, d(S N)\rangle $然后，该节点从所有对等方收集提交消息。一旦超过阈值（2f+1），节点就会接受更新的状态。然后，该节点用新状态回复客户机。

Complementary Mechanism 互补机制：上述阶段是不够的因为恶意的 2f-1个节点也许存储错误的相对位置关系，使我们的系统无法满足相对持久性的安全属性。由于缺少2f+1匹配的提交消息，可能无法提交相对关系。因此，个状态永远不会终止。为了解决这个问题，我们介绍了我们的互补机制。一方面，每条消息都嵌入了一个计数器。如果由于没有足够的确认而导致消息失败，将启动重播过程，并且每次重试时，计数器都会增加。如果累积值大于计数器中设置的界限，则节点将从其他对等方提取最新状态，并接受反向关系并重新广播。 如果一个节点在相反的位置收集了超过2f+1个提交消息，则该节点会用更新的状态回复客户端。否则，消息将被中止，并向客户端发送失败消息。另一方面，当等待时间超过计数器中预定义的时间限制时，消息将被中止，并向客户端发送超时消息。互补机制对于实现相对持久性和活性的特性至关重要。

TODO: 目前还不是非常理解。

4 IMPLEMENTATION

为了评估我们的Sphinx，我们用Go语言实现了这个系统，代码超过32000行。我们开发了经典区块链系统的全部功能，包括账户配置、共识机制、对等网络、用户界面等。我们使用Go的内置哈希函数SHA-256和椭圆曲线数字签名算法secp256k1。这里，我们将重点介绍关键功能，以展示我们的实现框架。示例代码段和工作流程如图3所示。具体来说，

ValidateEstate会在状态转换后验证更改的状态，例如收据根和状态根。如果验证成功，该函数将返回一个数据库句柄。否则，将返回一个错误。

ValidateBody验证uncle块并验证其标题的收据。假设此时已经验证了标题。

NewBlockChain通过在数据库中加载信息来返回完全初始化的区块链。它初始化默认的验证器。

FastSyncCommitHead以散列的形式将提交的头块插入其他头块。

GetBlocksFromHash返回与哈希对应的块，最多n-1个。

InsertHeaderChain尝试将平行链的头插入本地链。

Insert将块的新标头插入或拒绝到当前链中。确认旨在确保块是否满足阈值条件。

5 SECURITY ANALYSIS 安全分析

在本节中，我们将证明我们的协议满足相对持久性和活性。我们首先假设诚实节点的提交是一致的，这意味着如果一个诚实节点接受一个相对状态，那么他在这个迭代和接下来的迭代中的所有提交都是一致的。形式上，我们在引理1中定义了上述直觉。

引理1：假设 节点Ni是第一个诚实结点，提交一个关系${\Downarrow }_{S_{N_i}^x}^{S_{N_i}^y}$对于在y和x的一个相对关系，在所有后续迭代中，来自对等方的所有提交都可以构建关于关系的有效决策 ${\Downarrow }_{S_{\ast }^x}^{S_{\ast }^y}$

定理1：（相对持久性）如果两个状态y和x的相对位置被节点Ni接受 在第 r轮 并且被 Nj 在r+1轮接受，他们对这段关系的决定是一样的 ，表示为 ${\Downarrow }_{S_i^x}^{S_i^y}={\Downarrow }_{S_j^x}^{S_j^y}$

证明1： 略

现在，我们继续讨论活动性属性，并解释我们的算法如何确保所有诚实节点在相同的相对关系上达成一致，并达到终止点。

定理2：（活性）如果一个正确的关系 ${\Downarrow }_{S_i^x}^{S_i^y}$ 被提交，每个诚实的节点最终都会接受它。

证明2：略

6 EVALUATION 评估

实验配置。我们的实验是在本地集群中的8台Dell R730机架式服务器上进行的，该服务器带有两个2.1 GHz Opteron CPU。带宽与1 Gbps交换式以太网连接。该操作系统基于Ubuntu 16.04.1 LTS版本运行。

性能评估。吞吐量表示在特定时间间隔确认的事务的速率。我们采用基于日志的方法[19]和每秒事务量（TPS）的概念来测量速率。在我们的实验中，我们将事务的生成设置为恒定速率，并计算固定时间段内事务的确认时间。通过挂钟运行时间以秒为单位测量时间。为了获得公平的测试结果，我们重复了300次测试。结果表明，Sphinx的平均吞吐量在8个完整节点时达到43k TPS，在64个完整节点时下降到约5000 TPS。然而，我们的系统比以太坊快得多。在相同的测试环境下，以太坊（版本1.9.25，于2020年12月11日发布）在8、16、32和64个节点的设置下仅达到355、311、268和91TPS。为了探索高吞吐量背后的原因，我们进一步评估了每个算法的性能。

首先，在预准备阶段，事务被添加到块中。评估结果（见图4）显示，完成块生成算法大约需要15毫秒，使我们的系统达到极高的吞吐量。高速生成率基于并行处理机制。每个节点生成并维护自己的分类账，即使它不包含最新的状态标题。相比之下，以太坊等经典区块链系统中的节点在获得最新的区块头之前无法挖掘，这会导致严重延迟。

然后，我们在准备阶段考虑验证时间和消息广播时间。验证时间表示验证特定状态字段的时间长度特别是，它涵盖了检查签名有效性的时间、证明的正确性、消息的非冲突性。结果表明，我们的验证算法只需要大约200毫秒，这是非常有效的。广播时间表示将消息从一个节点传播到另一个节点的时间长度。我们假设所有节点共享相同的时间戳，这样的配置可以通过NTP服务实现[20]。当消息由节点生成时，它将广播给网络中的对等方。我们采用覆盖率的概念来表示到达节点的百分比。我们的实验结果表明，实现100%的消息覆盖率大约需要500毫秒，这是我们系统的主要瓶颈。

此外，我们检查消息的响应时间。响应时间表示从任何链节点向客户端回复消息的时间长度。这个操作平均需要大约15毫秒，这在我们的实现中是快速高效的。

可扩展性： Sphinx中的可伸缩性用于描述处理越来越多事务的能力。为了研究其可扩展性，我们将块大小设置为4MB，块生成率设置为3s。然后，我们使用以下配置进行了实验：（i）在固定节点数的情况下，提高客户端的事务到达率；（ii）增加固定事务到达率的节点数量。为了获得准确的测试结果，我们重复了300次实验，并计算了它们的平均性能。

第一个实验试图评估不同事务到达率下的平均TPS。我们（随机）在系统中设置了8个节点，并以2000 tx/s的速率开始测试。然后，我们在固定的时间间隔内增加速率，如图5.a所示 。评估表明，当到达率小于50k时，吞吐量线性增加。当到达率接近或高于饱和点（50k）时，吞吐量稳定在43k TPS左右。原因是传播延迟成为主要瓶颈，使得到达率的影响可以忽略不计。同时，验证阶段等待的事务数也会影响最终结果。

第二个实验试图评估节点数量增加时的吞吐量。我们的算法基于PBFT实现，只适用于许可区块链。我们将委员会的规模限制在64个上限，这些节点的数量将保持稳定。我们以固定速率（2000 tx/s）发送事务，并将参与的节点从8个调整到64个。图5.b 显示了系统的吞吐量随着参与者的增加而下降。我们回到这样一个事实：系统的总吞吐量是通过参与节点的数量与每个单独节点的TPS的乘积来计算的。 仅仅增加参与者的数量就可以提高并发性，但会降低单个节点的性能。他们每个人都必须等待来自同龄人的足够多的回复，以超过阈值。因此，Sphinx的可扩展性无法无限制地提高。

磁盘空间： 为了检查可行性，我们还提供了磁盘空间的评估。在Sphinx中，每次将消息附加到本地链中时，节点的存储都会增加。同时，为了检查其他节点行为的正确性，每个审计员必须存储从其他节点接收到的状态。因此，我们从两个方面考虑空间评估：（i）本地链的大小，以及（ii）远程状态的大小。我们假设有八个节点的事务创建速率为每秒100条消息。然后，我们监控每个节点的空间使用情况，并分析它们的增长率。如图5所示。（c） 结果表明，随着交易量的增加，本地链的规模呈线性增长。平均而言，每个节点中本地链的大小以每条消息0.212 KB的速度增长。相比之下，远程状态的大小是静态的，与事务的规模无关。这很容易理解，因为远程状态的磁盘使用依赖于参与节点的规模，其中的数量在初始配置中是固定的。

远程状态 指的什么，忘记了。

7 USE CASES OF OUR CONSENSUS

Certificate System. 颁发和验证证书既缓慢又复杂，因为错误和欺诈威胁到证书的可用性。基于区块链的证书系统通常会将证书元数据上传到区块链，以实现可靠的管理。然而，比特币等当前系统的性能极低，导致证书的确认缓慢。这极大地限制了经典区块链系统的广泛采用。我们观察到，证书系统的关键思想是透明地存储证书，而不是对其顺序进行排序。因此，我们的系统可以完全满足以下要求：（i）链上的交易数据证明上传的证书存在；（ii）无线性有序序列的高性能系统适用于大规模证书场景。

Log System. 区块链技术为日志系统提供了一种新方法，因为它提供了一个可公开访问的公告板。将软件生成的日志记录到分布式存储系统中可以极大地提高安全性。区块链系统的不可逆性保证了上传的日志不容易被篡改。然而，当前区块链系统的低性能严重阻碍了日志的程序（上传/存储/下载/更改）。这阻碍了它们在业务场景中的应用。我们微弱的共识有利于当前的方法能够证明处理的存在和高性能，使基于区块链的日志系统实用。

目前只适用于 特定的系统。

8 RELATED WORD 相关工作

我们的方案采用平行链模型[21]，其中每个节点维护自己的链。在我们的模型中，通常采用两种协商一致机制：BFT协议的变体（称为无领导BFT协议）和改进的NC协议（称为extended Nakamoto consensus）。

无领导的BFT协议。 Hashgraph[22]是用无领导的BFT机制提出的。每个节点都维护一个单独的链，但它们需要通过gossip协议相互交互。接收同步信息的节点在本地创建一条消息来记录历史，然后将其广播给对等方。其他节点重复相同的过程。Hashgraph通过异步拜占庭共识实现共识。然而，包含所有以前历史的传播信息很重，这显著增加了通信开销。DEXON[23]中的平行链通过名为ack的参考字段相互确认，并通过这些参考达成共识。共识包括三个步骤。首先，通过比较每个块散列值的剩余值，将每个块确定地排列成一个单链。然后，DEXON采用源自Algorand[24]的变异BFT协议技术作为其单链共识。最后，提出了一种排序机制来确定并行链上所有块的总顺序。我们可以看到，如果发生网络延迟，这些步骤很容易阻塞，这将显著影响整个系统的性能。Aleph[25]是一个无领导的BFT分布式系统。每个节点同时发布单元（承载消息）。这些单元被分成不同的组。这些集合中的单元会经过投票算法。如果获得的票数超过阈值，则该单位视为有效。然而，该程序仍然依赖于线性化，如果存在任何冲突，会降低性能。

括展中本聪协议： OHIE[14]在组成多条平行链方面有相似之处。OHIE对每一条链都采用经典的中本共识。矿工需要计算一个拼图来生成区块，此外还需要对所有区块进行排序。区块在所有平行链上达到全局顺序，从而实现一致性。然而，由于强一致性假设，全序序列限制了性能的上限。Prism[13]用三种类型的块构造网络：提议块、事务块和投票块。这些模块取代了中本共识中一个公共模块的功能。一致性是通过对所有事务块进行排序来实现的。总排序由其提议块确保，提议块由投票块选择。然而，即使解耦功能达到其上限，总排序算法的过程仍然成为吞吐量的瓶颈。Chainweb[26]旨在通过维护多条平行链来扩大中本共识。它基于一个PoW共识，该共识结合了彼此的Merkle根，以提高散列率。网络中的每条链都挖掘相同的加密货币，可以通过简单的支付验证跨链传输。这种方法从一条链上减少了几枚硬币，并在另一条链上产生了等量的硬币。然而，Kiffer等人[27][21]认为，利用中本共识的Chainweb在相同的一致性保证下受相同吞吐量的限制。

9 CONCLUSION

本文通过放松强一致性承诺，提出了一种弱一致性算法。我们将我们的算法应用于高性能区块链系统Sphinx。该系统以并行链运行，在并行链中，所有事务和块都被并发处理。我们进一步定义了相对持久性和活性的安全性，并证明我们的系统实现了这些特性。此外，我们还提供了一个包含所有分层组件的完整实现，包括P2P/ consensus/ ledger/等。评估表明，斯芬克斯在总共约4.3万TPS的情况下实现了高性能。 我们进一步探索潜在的应用，以证明其可行性和适用性。

参考文献

Wang Q, Li R. A weak consensus algorithm and its application to high-performance blockchain[C]//IEEE INFOCOM 2021-IEEE Conference on Computer Communications. IEEE, 2021: 1-10.文章来源地址https://www.toymoban.com/news/detail-780631.html

到了这里，关于【区块链论文阅读】A Weak Consensus Algorithm and Its Applic的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！