0 前言

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

2 AC1.0做了哪些改进

2.1 序列化方法

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

consensus proto

2.2 算法流程

AC0.5的流程为

  1. 广播一个待确认区块
  2. 收集选票(以广播的形式)
  3. 收集确认信息(以广播的形式)
  4. 确认区块

AC1.0的流程为

  1. propose (广播一个区块的元信息及当前generator的ip信息)
  2. collect votes (其他节点采用一对一的方式直接将选票发送给当前generator)
  3. commit and broadcast(广播一个已经确认的区块并携带投票信息)

通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。

2.3 广播协议

AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行100 * N次通讯,在N小于100的情况下,相当于复杂度为O(N^2), 在这里N为整个网络的节点个数。

AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。
这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)。

除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性和可靠性也不如更简单的随机算法。
算法的demo版本在这里,有兴趣的可以研究下。
gossip topology

3 容错性

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

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

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

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

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