挑战“不可能三角”公链设计、选型与开发实战

浪花财经浪花财经 专栏 2018年12月30日
1.24W 0
开发一条公链，对于任何技术团队都是一件极具挑战性的事情。假如糟糕的网络通信这种被动的恶意，还能让人接受，那么不择手段的双花、DDoS、智能合约攻击等等，让我们必须谨慎的设计每一个逻辑环节。

挑战“不可能三角”公链设计、选型与开发实战

开发一条公链，对于任何技术团队都是一件极具挑战性的事情。假如糟糕的网络通信这种被动的恶意，还能让人接受，那么不择手段的双花、DDoS、智能合约攻击等等，让我们必须谨慎的设计每一个逻辑环节。

公链面临的问题

我们先来看看公链设计中的“不可能三角”问题：Scalability、Decentralization、Security。

  1. Scalability，可以理解为可扩展性，例如分片技术；也可以理解为网络能耗低，保证网络的性能最优，总的来讲就是优异的TPS。

  2. Decentralization，去中心化是如何保障网络的去中心性，这就要求该网络需要是一个对等网络，该网络中的机器的地位都是平等的，不存在任何特殊化的中心节点，同时为了保证该网络的去中心性，该网络需要是一个开放的无准入的网络，从而可以让人人都能够加入该网络，且该网络不会被一个或多个中心控制。

  3. Security，安全性是保障该网络足够安全，不能被坏人破坏。在一个开放并与经济利益挂钩的网络中，不仅会有好人购买机器加入这个网络，也会有更多的坏人企图希望通过破坏该网络获利。那么，如何在网络内部存在坏人的情况下，保证网络的安全性，这已经突破了传统意义上的安全架构，是安全设计的挑战。

挑战“不可能三角”公链设计、选型与开发实战

PoW的算力浪费以及单节点产块让它的性能低下，PoS面对众多安全问题，例如无厉害攻击、远程攻击等，DPoS的产块节点有限，虽然有选举制度，但是它的去中心化就是让人耿耿于怀，而PBFT的同步通信让它的节点数注定会受到制约。

以上是现有共识的优缺点，而我所在的alabs ADAG公链团队，选择了Hashgraph作为基本共识算法来设计我们的公链，因为我们通过严谨的分析该共识算法，并在此基础上做了重要的改进，在不破坏算法严谨性的同时，让它面对公网环境时，也能具有很强的说服力。我们在它身上，看到了画出一个尽可能最大三角的可能，以下就谈谈它的性能，去中心化和安全三个维度的情况。

挑战“不可能三角”公链设计、选型与开发实战

ADAG为什么选择Hashgraph共识 

Hashgraph的性能与去中心化

Hashgraph算法是swirlds团队基于DAG（有向无环图）设计的一种完全异步的类BFT共识算法。该算法有两大特点：

  1. Gossip about gossip （八卦协议）

  2. Virtual Voting（虚拟投票技术）

事实上，在选型之初，我们很快意识到Hashgraph是一个类BFT算法，而且不像PoW，DPoS那样，完美的避开了拜占庭将军问题。这让它显得没有那么有魅力，而就是这两个特性，让我们看到了它的独特之处。

概括的说，它们指的就是，节点间随机的发生通信，通信的载体叫event，图中的圆圈。A，B，C，D为不同的节点。例如A与B通信，通信的内容就是A节点知道的，而B节点不知道的交易列表。

假如B节点创建一个event来记录这次通信内容，该event除了要包含交易，还要有两个非常重要的字段，即Selfparent（B） 和 Otherparent（A），由此随着交易的发生，每个节点本地都会存在一个这样由通信历史组成的哈希图（Hashgraph），而每个节点根据本地的Hashgraph都能够独立的计算出一个块，而且块中包含的交易序列以及顺序都是一致的。

挑战“不可能三角”公链设计、选型与开发实战

节点间的通信我们叫gossip，而gossip的内容简单来说就是我知道的，而你不知道的，所以很形象的称为八卦协议。而self parent 和 otherparent 又记录下所有的历史通信记录，这是算法再进行witness 和 famouswitness 选举时最重要的信息（具体算法可以参照swirlds白皮书），有了这些信息，节点就可以独立的计算并获得块（产块），并保证块的一致性（这叫做虚拟投票）。

所以你会发现，通过这种看似随意的通信，Hashgraph避免掉了传统BFT类共识中常见的消息传递风暴（N²），很大程度的降低了网络能耗，而且能够很好的支持并发。用Hashgraph发明者的话来说就是：“Hashgraph具备投票算法的一切优点，然而避开了它的最大缺陷。”

从算法中我们也可以看到，这是一个异步的类BFT算法，所有的节点是对等的，不存在其他身份的节点，所以它是一个去中心化的系统。当然作为BFT类共识，它依然要面对拜占庭问题，即1/3恶意节点问题，我们需要额外的奖惩机制来约束网络环境。

挑战“不可能三角”公链设计、选型与开发实战

Hashgraph的安全性

首先Hashgraph作为一个完全异步的拜占庭容错，这意味着它并不对消息在互联网上传递有多快做任何假设。该功能使得它能够抵御DDoS攻击、僵尸网络。另一个经常被讨论的问题就是Hashgraph能否经受Sybil攻击，即攻击者通过创建大量假身份来破坏对等网络的信誉系统，并利用它们获得不成比例的巨大影响力。

我们设计了一种让所有共识参与者共同维护“共识白名单”的机制，让所有参与者能够验证彼此对同一个块的签名，再配合奖惩机制，让它能够应对假身份攻击的危险。

该算法能够通过定义网络中的大多数为2/3*N~3/4*N,从而能够抵抗1/3~1/2的恶意攻击，当然大多数越接近N，对性能会有负面的影响。

Hashgraph存在的问题

当然Hashgraph并不是完美的，作为一个完全异步的BFT类共识，它在公网环境下，能够支持多少个节点？完全的异步让它对网络环境的要求没有那么苛刻，我们知道它最终能够达成一致，但是，如果这个时间窗口过长，那么它将无法面对很多业务场景，而且，作为BFT类共识，它必须知道全网节点数N，而这些都是公网环境下无法保证的。于是我们设计了基于Hashgraph的快速同步功能以及共识节点的动态验证集策略。

在传统链式结构中，大家对这两个功能并不陌生。像以太坊的快速同步功能，以及casper中的动态验证集。基于链式的数据结构让我们很容易能够想象，这两个功能如何去实现，所以我们需要把Hashgraph链式化。  

如何解决

链式账本结构，它更适应于表示不可变的事务的有序列表。在我们的系统里，交易顺序由Hashgraph一致性算法控制，但是最终的“块状”交易被映射到由块组成的线性数据结构。每个块包含交易的有序列表，前一个块的哈希，对应的应用程序状态（statehash），以及来自动态验证集的签名集合。

在区块链世界里，任何一个共识系统的输出都是一个有序的交易列表。我们最终决定使用链式结构来建模最终数据，是因为它是高效的，具有良好区块链兼容性（分片，跨年，layer2等）。由批量，有序的交易序列，hash，签名，组成的线性数据结构让它很容易验证很多事务。

Hashgraph是一种基于同义数据结构的，优秀的一致性算法。然而swirlds团队也仅仅是给出对交易进行排序的一致性算法，然而哈希图数据结构在表示线性交易序列时并不容易使用。它是一个有向无环图（DAG），其顺序必须通过一些复杂的一致性函数来提取，为了验证给定交易的一致性索引，必须重新计算hash图的子集上的一致性方法。而链式结构不需要进一步的处理来提取交易的有序序列，并且通过简单的加密原语足以验证块。

挑战“不可能三角”公链设计、选型与开发实战

如上图所示，我们根据swirlds算法中的round以及roundreceived概念，将Hashgraph映射为链式结构。在链式结构上，我们通过设计新的数据结构来截断Hashgraph，以便支持快速同步，并在不同的round中支持不同的动态验证集，这让我们的公链在面对恶劣的公网环境，能够有很好的适应能力。

同步功能，我们设计了两种同步方式，一种是基于全图谱的全数据同步模式，另一种是基于某一个特定的“frame”，以及对应的block，对应的账本snapshot的快速同步模式。

快速同步功能虽然并不陌生，但是它对与一个完全异步的BTF类共识就显得格外重要了，因为由于网络原因，某些节点会落后于当前大多数节点，在一些特定得应用场景中，我们鼓励节点积极的使用快速同步，这样可以有效得控制并防止异步过程中，全网数据状态不一致的时间窗口越来越长。当然需要全数据的节点可以通过不断的gossip，来同步自己的全数据，然后不断产块，来追赶最新的数据，方式是灵活的。

挑战“不可能三角”公链设计、选型与开发实战

动态验证集功能，公网环境下，我们很难控制节点的行为，当然有效的奖惩机制是个不错的选择，这是另外一个很大的话题，这里暂且不说。节点的添加与删除，我们通过设计一种特殊的交易类型来实现。

这样的交易会像普通交易一样被封装在event里，并gossip到全网中，这样根据一致性的共识算法，这个交易会被大多数节点放到同一个块里，那么它们就可以在逻辑上一致性的去维护一个共识白名单。我们的策略是一个节点可以随时的在线或者断线，但是我们将它在逻辑上与对应的round周期相对应，这样在投票算法中，就不会破坏共识算法的严谨性。

回到文章开始的地方，我们之所以选择Hashgraph+链式账本结构的方式来开发我们的公链，就是因为，通过严谨的研究与分析，以及核心创新功能的开发，我们在ADAG身上看到了很多可能。

挑战“不可能三角”公链设计、选型与开发实战

关于layer2的一些思考

在区块链的技术栈中，跨链和layer2的方向正被越来越多人重视，相关技术的发展也越来越成熟。我们团队也一直很重视ADAG对相关技术的支持，如果不是很严谨的说，Inter-Blockchain Communication (IBC)是关于一个链充当另一个链的轻客户端，而为一个链式结构构建一个清客户端明显要比在一个hash图上构建要简单的多。为了在块链之间实现相互操作，几个倡议已经被提出，如Cosmos、Polkadot 和 EOS。而ADAG的链式账本可以与这些网络体系结构很好的集成。

Layer2的很多技术都可以通过智能合约来实现，ADAG采用通用的链式账本结构，能够轻松的支持智能合约，当前支持EVM，支持WASM的分支也在开发中。

挑战“不可能三角”公链设计、选型与开发实战

分享与建议

公链并不是万能的，它需要适配自己的业务场景。这对技术选型，未来的成长至关重要。

假如你使用的共识算法并不成熟，而你又希望开发一条公链，那么建议团队在全力投入之前，先确定你的共识算法的安全，容错边界，以免搭建空中楼阁。

无论中本聪类共识，还是BFT类共识的容错边界都是有限的，所以也不要对公链初期的准入与控制行为耿耿于怀。

篇幅原因，文章中没有对经济模型和奖惩机制做更多的介绍，而它们与共识一样对公链的成败至关重要。

作者：冯英飞，Alabs ADAG主链项目技术负责人。区块链领域开发专家，致力于区块链主链技术的研发及应用落地，毕业于江南大学，曾工作于futurmaster中国，长期从事分布式计算，网络通信等领域的研发工作。

— END —

生成图片
♥赞4
区块链(9086)区块链技术(1061)

相关文章

发表评论

挑战“不可能三角”公链设计、选型与开发实战

星期日 2018-12-30 0:06:35

挑战“不可能三角”公链设计、选型与开发实战

开发一条公链，对于任何技术团队都是一件极具挑战性的事情。假如糟糕的网络通信这种被动的恶意，还能让人接受，那么不择手段的双花、DDoS、智能合约攻击等等，让我们必须谨慎的设计每一个逻辑环节。

公链面临的问题

我们先来看看公链设计中的“不可能三角”问题：Scalability、Decentralization、Security。

  1. Scalability，可以理解为可扩展性，例如分片技术；也可以理解为网络能耗低，保证网络的性能最优，总的来讲就是优异的TPS。

  2. Decentralization，去中心化是如何保障网络的去中心性，这就要求该网络需要是一个对等网络，该网络中的机器的地位都是平等的，不存在任何特殊化的中心节点，同时为了保证该网络的去中心性，该网络需要是一个开放的无准入的网络，从而可以让人人都能够加入该网络，且该网络不会被一个或多个中心控制。

  3. Security，安全性是保障该网络足够安全，不能被坏人破坏。在一个开放并与经济利益挂钩的网络中，不仅会有好人购买机器加入这个网络，也会有更多的坏人企图希望通过破坏该网络获利。那么，如何在网络内部存在坏人的情况下，保证网络的安全性，这已经突破了传统意义上的安全架构，是安全设计的挑战。

挑战“不可能三角”公链设计、选型与开发实战

PoW的算力浪费以及单节点产块让它的性能低下，PoS面对众多安全问题，例如无厉害攻击、远程攻击等，DPoS的产块节点有限，虽然有选举制度，但是它的去中心化就是让人耿耿于怀，而PBFT的同步通信让它的节点数注定会受到制约。

以上是现有共识的优缺点，而我所在的alabs ADAG公链团队，选择了Hashgraph作为基本共识算法来设计我们的公链，因为我们通过严谨的分析该共识算法，并在此基础上做了重要的改进，在不破坏算法严谨性的同时，让它面对公网环境时，也能具有很强的说服力。我们在它身上，看到了画出一个尽可能最大三角的可能，以下就谈谈它的性能，去中心化和安全三个维度的情况。

挑战“不可能三角”公链设计、选型与开发实战

ADAG为什么选择Hashgraph共识 

Hashgraph的性能与去中心化

Hashgraph算法是swirlds团队基于DAG（有向无环图）设计的一种完全异步的类BFT共识算法。该算法有两大特点：

  1. Gossip about gossip （八卦协议）

  2. Virtual Voting（虚拟投票技术）

事实上，在选型之初，我们很快意识到Hashgraph是一个类BFT算法，而且不像PoW，DPoS那样，完美的避开了拜占庭将军问题。这让它显得没有那么有魅力，而就是这两个特性，让我们看到了它的独特之处。

概括的说，它们指的就是，节点间随机的发生通信，通信的载体叫event，图中的圆圈。A，B，C，D为不同的节点。例如A与B通信，通信的内容就是A节点知道的，而B节点不知道的交易列表。

假如B节点创建一个event来记录这次通信内容，该event除了要包含交易，还要有两个非常重要的字段，即Selfparent（B） 和 Otherparent（A），由此随着交易的发生，每个节点本地都会存在一个这样由通信历史组成的哈希图（Hashgraph），而每个节点根据本地的Hashgraph都能够独立的计算出一个块，而且块中包含的交易序列以及顺序都是一致的。

挑战“不可能三角”公链设计、选型与开发实战

节点间的通信我们叫gossip，而gossip的内容简单来说就是我知道的，而你不知道的，所以很形象的称为八卦协议。而self parent 和 otherparent 又记录下所有的历史通信记录，这是算法再进行witness 和 famouswitness 选举时最重要的信息（具体算法可以参照swirlds白皮书），有了这些信息，节点就可以独立的计算并获得块（产块），并保证块的一致性（这叫做虚拟投票）。

所以你会发现，通过这种看似随意的通信，Hashgraph避免掉了传统BFT类共识中常见的消息传递风暴（N²），很大程度的降低了网络能耗，而且能够很好的支持并发。用Hashgraph发明者的话来说就是：“Hashgraph具备投票算法的一切优点，然而避开了它的最大缺陷。”

从算法中我们也可以看到，这是一个异步的类BFT算法，所有的节点是对等的，不存在其他身份的节点，所以它是一个去中心化的系统。当然作为BFT类共识，它依然要面对拜占庭问题，即1/3恶意节点问题，我们需要额外的奖惩机制来约束网络环境。

挑战“不可能三角”公链设计、选型与开发实战

Hashgraph的安全性

首先Hashgraph作为一个完全异步的拜占庭容错，这意味着它并不对消息在互联网上传递有多快做任何假设。该功能使得它能够抵御DDoS攻击、僵尸网络。另一个经常被讨论的问题就是Hashgraph能否经受Sybil攻击，即攻击者通过创建大量假身份来破坏对等网络的信誉系统，并利用它们获得不成比例的巨大影响力。

我们设计了一种让所有共识参与者共同维护“共识白名单”的机制，让所有参与者能够验证彼此对同一个块的签名，再配合奖惩机制，让它能够应对假身份攻击的危险。

该算法能够通过定义网络中的大多数为2/3*N~3/4*N,从而能够抵抗1/3~1/2的恶意攻击，当然大多数越接近N，对性能会有负面的影响。

Hashgraph存在的问题

当然Hashgraph并不是完美的，作为一个完全异步的BFT类共识，它在公网环境下，能够支持多少个节点？完全的异步让它对网络环境的要求没有那么苛刻，我们知道它最终能够达成一致，但是，如果这个时间窗口过长，那么它将无法面对很多业务场景，而且，作为BFT类共识，它必须知道全网节点数N，而这些都是公网环境下无法保证的。于是我们设计了基于Hashgraph的快速同步功能以及共识节点的动态验证集策略。

在传统链式结构中，大家对这两个功能并不陌生。像以太坊的快速同步功能，以及casper中的动态验证集。基于链式的数据结构让我们很容易能够想象，这两个功能如何去实现，所以我们需要把Hashgraph链式化。  

如何解决

链式账本结构，它更适应于表示不可变的事务的有序列表。在我们的系统里，交易顺序由Hashgraph一致性算法控制，但是最终的“块状”交易被映射到由块组成的线性数据结构。每个块包含交易的有序列表，前一个块的哈希，对应的应用程序状态（statehash），以及来自动态验证集的签名集合。

在区块链世界里，任何一个共识系统的输出都是一个有序的交易列表。我们最终决定使用链式结构来建模最终数据，是因为它是高效的，具有良好区块链兼容性（分片，跨年，layer2等）。由批量，有序的交易序列，hash，签名，组成的线性数据结构让它很容易验证很多事务。

Hashgraph是一种基于同义数据结构的，优秀的一致性算法。然而swirlds团队也仅仅是给出对交易进行排序的一致性算法，然而哈希图数据结构在表示线性交易序列时并不容易使用。它是一个有向无环图（DAG），其顺序必须通过一些复杂的一致性函数来提取，为了验证给定交易的一致性索引，必须重新计算hash图的子集上的一致性方法。而链式结构不需要进一步的处理来提取交易的有序序列，并且通过简单的加密原语足以验证块。

挑战“不可能三角”公链设计、选型与开发实战

如上图所示，我们根据swirlds算法中的round以及roundreceived概念，将Hashgraph映射为链式结构。在链式结构上，我们通过设计新的数据结构来截断Hashgraph，以便支持快速同步，并在不同的round中支持不同的动态验证集，这让我们的公链在面对恶劣的公网环境，能够有很好的适应能力。

同步功能，我们设计了两种同步方式，一种是基于全图谱的全数据同步模式，另一种是基于某一个特定的“frame”，以及对应的block，对应的账本snapshot的快速同步模式。

快速同步功能虽然并不陌生，但是它对与一个完全异步的BTF类共识就显得格外重要了，因为由于网络原因，某些节点会落后于当前大多数节点，在一些特定得应用场景中，我们鼓励节点积极的使用快速同步，这样可以有效得控制并防止异步过程中，全网数据状态不一致的时间窗口越来越长。当然需要全数据的节点可以通过不断的gossip，来同步自己的全数据，然后不断产块，来追赶最新的数据，方式是灵活的。

挑战“不可能三角”公链设计、选型与开发实战

动态验证集功能，公网环境下，我们很难控制节点的行为，当然有效的奖惩机制是个不错的选择，这是另外一个很大的话题，这里暂且不说。节点的添加与删除，我们通过设计一种特殊的交易类型来实现。

这样的交易会像普通交易一样被封装在event里，并gossip到全网中，这样根据一致性的共识算法，这个交易会被大多数节点放到同一个块里，那么它们就可以在逻辑上一致性的去维护一个共识白名单。我们的策略是一个节点可以随时的在线或者断线，但是我们将它在逻辑上与对应的round周期相对应，这样在投票算法中，就不会破坏共识算法的严谨性。

回到文章开始的地方，我们之所以选择Hashgraph+链式账本结构的方式来开发我们的公链，就是因为，通过严谨的研究与分析，以及核心创新功能的开发，我们在ADAG身上看到了很多可能。

挑战“不可能三角”公链设计、选型与开发实战

关于layer2的一些思考

在区块链的技术栈中，跨链和layer2的方向正被越来越多人重视，相关技术的发展也越来越成熟。我们团队也一直很重视ADAG对相关技术的支持，如果不是很严谨的说，Inter-Blockchain Communication (IBC)是关于一个链充当另一个链的轻客户端，而为一个链式结构构建一个清客户端明显要比在一个hash图上构建要简单的多。为了在块链之间实现相互操作，几个倡议已经被提出，如Cosmos、Polkadot 和 EOS。而ADAG的链式账本可以与这些网络体系结构很好的集成。

Layer2的很多技术都可以通过智能合约来实现，ADAG采用通用的链式账本结构，能够轻松的支持智能合约，当前支持EVM，支持WASM的分支也在开发中。

挑战“不可能三角”公链设计、选型与开发实战

分享与建议

公链并不是万能的，它需要适配自己的业务场景。这对技术选型，未来的成长至关重要。

假如你使用的共识算法并不成熟，而你又希望开发一条公链，那么建议团队在全力投入之前，先确定你的共识算法的安全，容错边界，以免搭建空中楼阁。

无论中本聪类共识，还是BFT类共识的容错边界都是有限的，所以也不要对公链初期的准入与控制行为耿耿于怀。

篇幅原因，文章中没有对经济模型和奖惩机制做更多的介绍，而它们与共识一样对公链的成败至关重要。

作者：冯英飞，Alabs ADAG主链项目技术负责人。区块链领域开发专家，致力于区块链主链技术的研发及应用落地，毕业于江南大学，曾工作于futurmaster中国，长期从事分布式计算，网络通信等领域的研发工作。

— END —