3大热门公链项目Algorand、Dfinity和Thunder共识体系的技术分析

Algorand.jpg

在当前的区块链公链体系中,有三大当红项目Algorand、Dfinity和Thunder,因其创始成员来自美国著名大学教授,均以独特的学术见解和创新的科学方法来提升区块链的去中心化程度、安全性和交易性能,试图破解区块链领域中著名的“不可能三角”难题。这些项目为新一代的区块链创新技术研发提供了崭新的思路和解决途径,虽然此三个项目还没有实际公开上线运行,但已经引起了各方的密切关注和大量讨论。

随着对这三个项目的深入调查和研究,我们有了进一步的理解,特此撰文分享我们的一些思考和见解。根据具体的技术分析,我们认为:

(1)Algorand可能无法达到所宣称的高性能,且其去中心化特性存在潜在问题;

(2)Dfinity和Thunder在安全性和性能上都存在较多疑点;

(3)因三者均没有实际公开上线和工程落地,是否真正解决区块链的“三元悖论”存疑。

此外,值得关注的是,这三个项目都没有公开相应的Token激励机制,我们认为会制约参与者的积极性,进而影响其公链的生态发展和实用价值。同时,其容量的限制和网络通讯的低效,都会制约其规模应用和实际使用的落地。


1. Algorand共识体系分析


Algorand是一个基于随机算法的公有链项目, 由MIT著名的密码学专家、图灵奖获得者Micali教授及其团队提出,其动机是为了解决区块链中由去中心化、安全性以及交易性能三个方面所组成的“不可能三角”难题。该问题也被称为“三元悖论” ,一般认为在现有区块链技术中这三个方面无法同时满足,最多只能满足其中两个要素。Algorand其本质是通过密码学的方法,来做一个随机数发生器来随机决定下一个区块的生成者是谁。如果这个随机数发生器是完全随机的,也就是说,任何人(包括上个区块的发布者)都无法预测下一个的发布者是谁,那么其实这就是一个可用的共识算法了。

在Algorand算法里提出并解决了三个问题,第一个是随机数发生器,第二个是随机出来的提案者如何在不泄露自己身份的情况下证明自己,第三个是如何应对不在线的节点。Algorand采用了PoS(Proof of Stake)共识机制的分组方式——包括提案组和验证组,以解决PoW共识机制所带来的高能耗问题,并希望同时提升交易性能。

在Algorand方案中,首先每个新区块是由一个独立的随机生成的提案组产生多个提案块,其成员随机选择,期望值为26人。然后再由多个随机组成的验证组逐步经多次验证达成共识。这里验证组的个数一般为12组甚至更多,而每组包含2000~4000成员。每个提案组和验证组都是从所有用户的集合中随机选出,以强化去中心化程度。而用户的账户余额将会影响被选中的概率,并且给予每一个被选中用户一个优先级别(priority)以及拥有此优先级的证明。被提议的多个区块随后将在全网内通过八卦协议(gossip)传播,到达下一组进行验证和共识,直到最终唯一确认,最后唯一获选的区块加上各验证组共识组员签名信息上链。

Algorand的独特创新是VRF(可验证随机函数)和加密抽签,整体方案具有后验性。具体而言,用户是唯一知道自己是否成为某组(某轮的提案组或某步的验证组)成员的人,他人无法事先获知,只能等其广播后验证,恶意攻击者甚至无法事先知道组成员是谁,因此不能对他们进行贿赂或发起拒绝服务攻击,组员间也无法共谋,提高了系统的安全性。

但分析其具体工作机制后,我们发现有以下问题:

1) 签名数据庞大,造成存储浪费并影响性能。Algorand使用VRF来确定提案组与验证组,这个方式充分发挥了VRF的可验证性优势,且后验优势使得Algorand的共识体系更安全。但是,Algorand进入验证阶段,采用的是一种可扩展的拜占庭容错算法,即BA*算法,参与节点通过VRF秘密抽签选出。这一设计使Algorand在验证前必须等待凭证(VRF prove)到来,才能知晓参与节点。而且,由于使用了可扩展的拜占庭容错算法,使得Algorand的验证组规模必须比较大(2000~4000人),这将导致签名数据异常庞大。根据我们的估算,在平均每组3000个验证节点的规模下,每组的签名数据长达126KB,加上其它信息,通知信息约300K,每块的签名数据可达2000*64*12=1M(共12组,每组3000人,至少2/3达成共识。ed25519签名数据长度是64。),远超一般门限签名几十个字节,严重浪费存储和容量(因每块存储的交易量将被占用,不存储签名又会影响安全),不仅造成存储浪费,而且更影响性能。

2) 算法对于网络带宽要求极大,个人用户很难参与,严重影响去中心化特性。如下图所示,对照来自于Algorand论文中的公开测试数据,在实验环境中,Algorand需要让区块达到10M大小,才能达到125倍比特币的性能(约10M-1M=9M,每M存储的交易数为1万,则基于Algorand的测试数据,有90000/50=1800TPS,约为比特币的100多倍)。10M区块大小意味着要求节点的网络带宽峰值至少需要80M才能承载,这对目前一般用户非常困难,影响了系统的效率和去中心化特性。

3) 节点网络规模受限,网络通讯不经济并影响性能。当网络规模太小时,将无法组成所需的提案组和验证组,影响系统正常工作。而网络规模太大时,提案块(假设大小2M,去除签名的1M,有效交易存储空间为1M)和验证信息(大小约300K)无法快速传播到后继验证节点,也会影响系统性能。

Algorand即使在验证环境也需要等待5*10=50s以上(包括等待潜在提案者的时间延迟及其特殊的拜占庭算法),加上其提案传播时间10秒,至少需要60秒才能完成一次出块上链。假设一个有效存储1M(去除签名后)的块包含1万笔交易,则其TPS为10000/60=167。我们预估在全网真实环境下,这个结果会更糟。假设每个验证组成员为3000个,每次验证组成员不重复(一般12组甚至更多),则至少需要12*3000=36000个节点。根据下图所示,一个2M的块,要传播到3000个节点,需要36秒,如传播到36000个节点,可能需要45秒左右甚至更长才能到达第一验证组。验证信息(大小300K)需要9秒左右才能传播3000个节点,如传播到36000个节点,可能需要12秒或更久,到达下一验证组。而其一般要11步或更多才能完成验证,再加上最后一步,这样就验证就需要12*(11+1)=144秒。整个过程需要189秒,其性能仅约53TPS,离项目方宣称的1000TPS差之甚远。

4) 账本数据存储相对较大。如前所述,因其采用多步BA共识算法,其签名占据巨大存储空间,虽然提高了安全性,但影响了性能,也浪费了账本存储空间,制约了账本系统的存储容量和系统规模。

5) 不具有强的输出公平性保证。保证公平性(Bias-resistance)能够确保协议的输出不被敌手操纵。然而Algorand为了选择提案者使用了一个有些偏向的随机性,使得那些需要真正随机均匀分布的应用不适合采用该协议。
总的来说,我们认为Algorand的VRF和加密抽签后验性给出了一个解决“三角悖论”的很好设计思想,但其在验证环节的设计更偏单纯的学术化理想化,导致其对网络流量、有效通讯数据等实际工程落地思考不够,严重影响了公链运行性能、节点网络规模、账本存储容量和去中心化程度。

 
2. Dfinity共识体系分析


最近一段时间,Dfinity共识体系是被认为较有希望提供高性能交易的区块链公链方案之一。为了解决PoW性能低下和高能耗的问题,Dfinity也采用了PoS分组模式。与Algorand不同,Dfinity在Github提供了一个GO语言的概念验证POC实现。Dfinity用随机数把矿工分为若干个组,每组400人,组中的一个节点将按顺序被选作提案节点,其它节点为验证节点。每次由随机数决定下一出块组,组内随机轮询决定下一个出块提案节点。提案块全网广播到同组成员,进行验证,使用BLS门限签名来达成组内共识。BLS门限签名要比Algorand的可扩展的拜占庭容错算法更有效率,无需像拜占庭容错算法那样多轮的验证步骤,不但提高了TPS而且还省下了长签名数据入链造成的存储容量问题。其理论上整个铸块时限timeout是10秒,每隔2秒一个提案,且在其testnet上的TPS是2500。我们认为Dfinity在性能方面比Algorand更具优势。但是因采用了先验模式,它的安全性不如Algorand。同时其网络通讯效率不高,像比特币和Algorand一样,完全靠P2P的传播,没有针对分组模式进行设计。容量虽不像Algorand那样浪费,但最大容量仍受限于全帐节点存储空间。

1) 不具有后验性,安全性较差。虽然有多个组,但各组的成员事先固定,容易被攻击,也容易组内窜谋,影响安全性。每次出块组某轮出块期间只有一个节点被选作提案节点,形成单点故障,又容易受到攻击,而且无法保证被选提案节点是否在线。同时,组内各成员按顺序轮流作提案节点,容易被外界所知,造成安全隐患。因其没有采用加密抽签方式,不具有后验性,因此会受到DDOS攻击和女巫攻击。Dfinity也没有考虑同组的提案人和验证者联手共谋的可能,存在被人为控制的隐患。

2) 性能解决方案缺乏鲁棒性,而且系统规模受限。每次随机抽取的一个提案节点如不在线,需要等待到下一轮,影响出块速度。提案块需要广播到全网,到达同组的其它成员,它们构成了验证组(400个节点),验证节点需要等待提案块的到达,浪费时间而影响性能。验证组内需要多轮通讯才能达成共识,而400个成员的组内通信也是依靠P2P的八卦协议,通讯量巨大,效率低下,影响出块速度和系统性能。假设有10个组,每组400个节点,则系统有4000个节点,按TradeBlock上图所示,1M的块需要约18秒传播到3000个节点,远超其铸块timeout时间,系统无法正常工作,影响系统的稳定性、性能和规模。

3) 网络通讯效率低下。Dfinity组内的通讯量是O(n^2),400人的组内通讯量大。不论提案块还是验证组内共识,亦或是共识块的上链,都依靠P2P的广播,增加网络传输负担,影响系统效率。

4) 存储容量受限于单节点的存储能力。与比特币、以太坊和Algorand一样,其系统容量,受限于单节点的存储空间,没有涉及分布式存储技术的应用和优化。

5) 依赖新的密码学基(cryptography primitive)。依赖新的密码学基(椭圆曲线pairing)和密钥生成协议,其安全性和效率都有待时间的考验。

和Algorand对比,Dfinity在性能方面因其分组共识和BLS组签名有所提高,但其安全性有所下降。其400人分组规模的通讯效率也存在一定问题,我们认为其技术架构和宣称的去中心化云服务仍有较大的差距。


3. Thunder共识体系分析


与前两个项目不同,Thunder是一种Layer2的公链解决方案,可用于提升已有的公链特性。但与Algorand和Dfinity一样,Thunder也用分组的方式(其快速通道fast path模式),有1个leader和多个验证组员,希望提高系统性能,但其选择leader和组员的方法还在研究中,没有公开。其快速通道是由系统选出一个leader和多个组员,由leader给出提案块,然后由组员经BFT验证达成共识,再由leader传播全网上链。为了弥补安全的不足,它在上面的快速通道模式的基础上,增加了定期检查,每次检查如没有发现问题,就移动检查点。一旦发生问题,就在上次的检查点,启动慢速通道(慢速通道slow path,比如采用比特币的POW方式),让系统仍能工作,虽然性能低下。

1) 中心化明显。Thunder的leader和组员不论如何选取,在被轮换之前,都是固定的,特别是提案、通讯、出块等都依靠leader,具有浓厚的中心化特征。

2) 不具后验性、随机性不足,且安全性较差。因为固定的leader和组员,其leader就有作恶的可能,而且成为单点故障。不论组的leader还是组员,都不如Dfinity和Algorand的选取更具随机性,去中心化不足,因而很容易受到DDOS攻击和女巫攻击,同时也没有考虑提案人leader和验证者组员联手共谋的可能。因其组内通信依靠leader,进一步影响安全性。其安全性要比Algorand和Dfinity稍差。

3) 网络通信还需要改善。为了改善组内通信效率,Thunder所有组内通讯都要经由leader,导致leader的中心化、单点故障(如不在线或作恶),影响通讯效率、性能和安全性。与Algorand和Dfinity一样,共识块需要经由P2P全网广播后上链,效率低下。

4) 性能不够好,存储容量受限。因没有采用组签名,其存储效率比Dfinity要差。但因只需一步共识,而且组的规模较小,所以其签名数据比Algorand要小,存储效率高于Algorand。其存储容量也同样受限于单节点的存储空间。为保证系统可靠性,一旦检查出问题,就回退到慢速通道。其慢速通道虽然可以让系统正常工作,但会影响系统出块速度,性能较差。

可以看出,Thunder设计了快慢两种数据同步模式,增加了可靠性,但其去中心化程度、系统安全和交易性能都有所欠缺。


4. 小结和展望


至笔者成文为止,Algorand、Dfinity和Thunder的很多数据还停留在实验室阶段,相关实现代码大多没有公诸于世(除了Dfinity中有的少量PoC部分代码开源)。虽然三者都基于各自的学术论文,但其理想化的数学模型,离工程实现和落地相距甚远。在区块链领域的技术讨论中,所谓的“三元悖论”——去中心化、安全和交易性能,这三者只能取其二的说法,并没有理论逻辑上的支撑,而只是对现有解决方案的观察。其实,去中心化仅是手段,不是目的。而安全与系统的吞吐能力和容量并不相互矛盾。本文希望就目前当红明星项目的分析,提出问题,从而可以找出一个融合它们各自优点(如Algorand中后验的安全性,Dfinity中BLS签名带来的性能提高,Thunder的慢速通道的可靠性),形成一个真正可以落地的、更好的解决目前区块链“三元悖论”的共识方法。不仅提高其去中心化、安全性和性能,同时,可以达到规模化应用,突破单节点容量的限制,打造一个“高可用、强安全、高效率”的区块链,真正做到“区块链的高可信与中心化的高效率”融合并存。此外,我们是否也应该接受不具有同时解决“三元悖论”的理论和技术方法,从而根据具体应用的需求而选择相应具有特色的共识算法呢?


作者:Tim,致远博士,Larry
201810290239109063.jpg 201810290237168970.jpg

0 个评论

要回复文章请先登录注册