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多倍。

2 AC1.0做了哪些改进

2.1 序列化方法

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

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，如果发现没有收到过，就会继续广播给它的相邻节点。也就是说一轮广播需要进行N^2次通讯。
AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点，每个节点只需要广播给10个相邻节点。
这个改动很小，但是参数的设置却是非常需要经验的，我们做过了大量的测试后，认为sqrt(N)可以达到比较理想的效果，一次广播需要的通讯次数略高于N * sqrt(N)
除此之外，我们还实现了一个基于一致性哈希的广播算法，性能达到了极致，算法复杂度降低到了O(N), 但是这个算法需要更多的测试，其稳定性也可靠性也不如更简单的随机算法，需要更多的测试。
算法的demo版本在这里，有兴趣的可以研究下。

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系统。