Conflux团队注意到不论是中本聪共识还是GHOST共识,他们都是只维护一条主链,非主链的区块则被抛弃了,因此也就导致了这些被丢弃的块不能为整个区块链系统提供安全性,并且也降低了吞吐量(因为这些快被抛弃了,实际上也就是说系统的带宽被浪费了,因此他们就不能为系统贡献吞吐量)
上次我们讲到GHOST算法,它在中本聪共识的基础上提出的确定主链的算法,在保障了在高吞吐量的同时还保障了安全性(即不容易分叉,依然保证51%攻击)。但是GHOST算法的吞吐量是否还有进一步的提升空间呢?
答案是肯定的!Conflux团队注意到不论是中本聪共识还是GHOST共识,他们都是只维护一条主链,非主链的区块则被抛弃了,因此也就导致了这些被丢弃的块不能为整个区块链系统提供安全性,并且也降低了吞吐量(因为这些快被抛弃了,实际上也就是说系统的带宽被浪费了,因此他们就不能为系统贡献吞吐量)。
并且注意到,比特币的吞吐量很低的原因是它是串行执行交易的,也就是说交易必须先排好序才能够执行,这产生了很多不必要的依赖,也是导致分叉的根源。于是Conflux就采用延迟排序交易的方式,先乐观地并行执行交易(不论是否有依赖或者冲突)和出块(不论是否会产生分叉),然后经过一段时间再全局地对所有的交易排序,并删除哪些冲突的交易。
顺着这个思路,我们发现最核心的问题就是如何解决并行出块的时候,还能对区块的全局序达成一致,从而保证账本的不可篡改。那么Conflux是如何做到的呢?
为了并行出块,就需要把所有的块纳入到整个区块链之中。Conflux采用采用了两种关系来定义区块之间的关系:父边(parent edge)和引用边(reference edge),参考下图:
上述内容,可能涉及到一些专业术语 不好理解,举个排序例子(参考下图):
先根据最终子树GHOST原则确定枢轴链为G->A->C->E->H->NewBlock,然后由于C引用了B,所以拍B->C;那么D和F如何排序呢?D的父亲是A,F的父亲是B,A的epoch大于B,所以D在F前面。按照这样的顺序排完就是:
G->A->B->C->D->F->E->G->J->I->H->K->New Block
当然还有一些细节,比如两个区块在同一个epoch内,并且父边也在一个epoch里,那么就根据区块的hash值id的绝对大小排序,比如假设区块DD的id是011,FF的是111,011<111,所以DD在FF前面
具体的算法如下,图中相关名词对应的解释参考其论文《Scaling nakamoto consensus to thousands of transactions per second》:
区块排好序之后,在每个区块内,按照交易的出现顺序排序,如果有冲突交易,那么只保留最先出现的那个,丢弃所有冲突的交易。
看起来很厉害是吧,那么实际实验结果如何呢?
限制带宽20M,在4M/5s的出块速度下,每秒能处理比特币网络中3200笔交易!
这个还是非常恐怖的数字,要知道以太坊现在每秒才30~40Tps,Visa才6000多Tps。
因为交易的序受枢轴链影响很大,而枢轴链的序是按照GHOST规则来定的,可以证明,Conflux的安全性与GHOST一致。那么按照攻击者有20%全网算力,并且只有0.01%的概率(由GHOST安全性计算规则算出)篡改交易的假设,得到的数据是:4M的区块,5秒出一个块的话,在保证安全性的同时确认时间也只有10分钟。
带宽20M时3200Tps,近11分钟确认时间;
带宽提升到40M,交易处理速度几乎线性上升到6400Tps,确认时间也只有5.68分钟。
如下图,可以看出,随着节点数据增多,确认延迟几乎只是随之线性增长(不像BFT算法那样指数增长,受节点数据拓展影响很大)。
因此可见,Conflux提出的共识算法已经不在是PoW公链性能上的共识瓶颈!
如何处理带宽限制,高吞吐量带来的存储问题(20M带宽就消耗2.88G/h)和交易验证速度等问题,都是继续需要解决的问题。
如何应对存活性攻击等安全性问题,也就是说恶意网络阻塞,也是很值得研究的问题,可参考详解自适应权重 “GHAST”
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!