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

开发一条公链,对于任何技术团队都是一件极具挑战性的事情。假如糟糕的网络通信这种被动的恶意,还能让人接受,那么不择手段的双花、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

发表评论

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

星期日 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 —