阿希的DPOS+PBFT共识机制是如何运作的?



  • 提一个小问题,问答测试



  • 最好出一些高质量的讲解视频,这些英语单词不会读,很尴尬



  • 技术帖啊,一号围观群众准备着



  • @半阶 said in 阿希的DPOS+PBFT共识机制是如何运作的?:

    @liangpeili 哈哈,这种题目难不倒我这种作弊界的学霸。http://docs.asch.mobi/help/

    转载有价值的信息,没什么不好,学习了。



  • @liangpeili 哈哈,这种题目难不倒我这种作弊界的学霸。http://docs.asch.mobi/help/



  • @半阶 已标记为答案



  • 白皮书里有介绍。昨天又看了白皮书,主要的改进在于每个选举周期(101×10秒)内生产101个区块的过程中,每个节点记账(打包区块数据)加入了一个共识算法,限制了记账的权力。增加这一操作后,会使系统更安全些但会导致打包数据区块的效率有所降低,并牺牲了一点网络宽带。如果要达到秒级,或者毫秒级别的确认,不知道未来这样的设置基础上能否做到?





  • 开卷考试吗?答案对吗?



  • 0 前言

    我曾在这个项目里(大概在5月份)分析了DPOS算法的漏洞并且模拟了一个简单的攻击的方法,然后实现了一个简化的PBFT算法模型试图去修复该漏洞,并且对比了效果。
    6月底,我们在正式的产品中实现了完整版的算法,并且部署了10台机器进行了测试。测试的结果在安全性方面完全符合预期,即经过频繁的重启、不按常规的广播区块、少数受托人联合作弊的情况下,整个系统依然不会分叉;但是在性能方面,不太理想,在没有任何交易的情况下,网路流量的峰值(广播区块的瞬间)达到了1.5Mbps。
    其实这个流量也不算离谱,为了安全性,付出一些带宽的代价也算合理,但我们认为还有很大的优化空间,而且asch作为一个开发平台,平台底层的效率和稳定性是很重要的,带宽方面的优化是很有必要的,我们立刻着手去做了。截止到8月9号,系统已升级到0.9.5版本,在49个节点组成的testnet中,带宽的峰值在600kbps左右。
    0_1509682107702_11.jpg
    带宽统计
    下面我们会对比下这几个版本共识算法的差异和基本原理。为了方便起见,我们把最初实现的dpos with pbft算法称为AC0.5(AC即asch consensus),优化后的版本称为AC1.0。

    1 AC0.5与DPOS

    我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的区块共存于网络中的不同节点,也就是所谓的分叉,进而造成双重支付。
    PBFT算法的本质则是让每一个节点都尽可能知道其他节点的决策,并以此来确定自己的决策。
    因此,PBFT带来额外的流量消耗就可以理解了,其根源也找到了。在AC0.5算法中,这个额外的流量或者说“其他节点的决策”指的就是每个节点对下一个区块的投票信息,投票信息主要内容有4个部分,即区块高度、区块ID、签名、公钥,其中区块高度和区块ID的长度可以忽略不计,签名的长度为64字节,公钥的长度为32字节,一个区块达成共识需要全部受托人总数的2/3的投票,在asch系统中受托人总数为101人,也就是说需要至少67个投票。一个区块的大小大约是200字节,相当于2个投票的大小,因此AC0.5中流量消耗是原始DPOS的30多倍。

    2 AC1.0做了哪些改进

    2.1 序列化方法

    AC0.5中服务器之间的消息传递使用json格式,二进制字段则是转化为hex编码后再进行传输,投票中的二进制字段包括公钥和签名,之前我们算的是100字节,转化为hex编码后则翻1倍,变成200字节了。
    另外json的字段信息和冗余的分隔符所占的字节数也不少。
    AC1.0对这一点做了改进,使用了protobuf作为序列化方法,效果很不错,带宽降为原来的60%左右。
    0_1509682150184_22.jpg
    consensus proto

    2.2 算法流程

    AC0.5的流程为

    广播一个待确认区块
    收集选票(以广播的形式)
    收集确认信息(以广播的形式)
    确认区块
    AC1.0的流程为

    propose (广播一个区块的元信息及当前generator的ip信息)
    collect votes (其他节点采用一对一的方式直接将选票发送给当前generator)
    commit and broadcast(广播一个已经确认的区块并携带投票信息)
    通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。

    2.3 广播协议

    AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一个条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行N^2次通讯。
    AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。
    这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)
    除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性也可靠性也不如更简单的随机算法,需要更多的测试。
    算法的demo版本在这里,有兴趣的可以研究下。
    gossip topology
    0_1509682201783_33.png
    3 容错性

    关于容错性,我认为可以从内因和外因两个方面来说。

    从内因的角度来说,系统应该能容忍正常节点出错,这些错误主要是指服务器宕机、硬件错误、网络拥塞等。Asch系统能够容忍最多1/3的受托人节点同时出错,假如个受托人的节点出错了,那轮到该受托人生产区块的时候,就会缺失一个,并顺延到下一个10秒。假如超过1/3节点同时出错,那么系统将暂停工作,等到足够的节点恢复正常后,系统就可以立即恢复正常。
    假如1/3以上的节点永远无法恢复(这种情况是存在的,比如他们的密钥丢了),那么系统必须要通过一次软件更新来恢复,并且这个软件更新不强制所有节点必须更新,只要少数节点更新,区块生产恢复正常后,通过受托人投票把那些不正常的节点撤销掉,系统就恢复如常了。

    从外因的角度来说,系统应该能够容忍黑客攻击、受托人作弊的情况。这里的黑客攻击不是说DDOS,DDOS造成的后果最多是系统宕机,我们已经归到内因里去了,这里的黑客攻击主要是指通过入侵拿到部分受托人密钥并获取权限,然后利用这些权限获利。获利的手段无非是广播多个版本的区块,在短时间内造成分叉,然后进行双重支付。在asch系统中,黑客必须要同时获得1/3以上节点的密钥,才能够发动连续攻击,使网络的分叉持续下去,否则系统将通过最长链同步算法迅速消除分叉。

    从现有的使用DPOS算法的系统来看,包括bitshares、crypti、lisk在内,这些系统出现的分叉都是内因造成的,甚至大多数是算法实现上的bug所导致的。黑客攻击DPOS的案例还没有听说过,虽然存在理论上的漏洞,但要想真正的攻击,需要高超的技术和昂贵的资源,成本和收益不对等,因此也不会有人去攻击,当一个DPOS系统的市值慢慢增大,我们可以继续提高受托人节点的数量,进一步提高攻击的成本,因此外因的风险基本可以不用忽略。

    最后,我想解释一下分叉这个词,分叉来源于英文的fork,fork根据上下文的不同,我认为可以翻译成两种意思,一个是分叉,另一个是分裂。
    分叉指的是在社区成员团结一致的情况下系统因为bug或被攻击造成的不一致性,而分裂是指社区成员因观念分化造成软件走向不同的方向。
    分叉强调的是系统的bug和不一致性,强调了物的因素,分叉后系统可能还是一个系统;而分裂则是强调了人为的因素,一旦社区分裂,则系统一分为二,变成两个系统。
    从这个角度来说,asch可以做到事前的预防和事后的修复,但无法应对社区的分裂,任何一个区块链系统也无法解决分裂的问题,包括比特币和任何一个声称可以避免分叉的PBFT系统。



  • This post is deleted!

Log in to reply
 

Looks like your connection to Asch was lost, please wait while we try to reconnect.