PoP共识算法¶
区块链上采用不同的共识算法会对系统的共识效率、去中心化程度产生不同影响。ChainSQL采用的PoP(Proof of Peers)共识算法参考PBFT共识机制对原有共识算法(RPCA)做了优化, 在提高了交易共识效率的同时兼顾了安全性。主要优化有:
通过增加交易池,增加交易的吞吐率;
通过梳理交易验证流程,适当简化接收交易的验证过程来提高交易接收速度;
通过使用leader提案的方式进行交易集共识提高交易集共识效率;
交易执行次数由原来的 2-3次减少到只执行一次。
目前新版本已实现的目标如下:
性能提升(普通8核16G环境,固态硬盘)
发送tps 700 提升到 4000-7000
共识tps 700 提升到 4000-7000
出块时间可配置, 最小出块时间为1秒,交易能更快达成共识。
可配置是否生成空区块,默认不生成,解决空区块带来的储存空间浪费问题。
ChainSQL原有功能及调用方法基本保持不变。
PoP共识算法介绍¶
交互示意图:
总体说明¶
原始的RPCA共识也是一个两轮2/3的共识过程,与PBFT类似,不同在于,
PBFT是leader提案机制,RPCA是各节点平等,各自提案机制,从这个角度来说,
RPCA相对更加去中心化一点。
RPCA共识流程¶
各节点收集交易。
各节点判断达到了closeLedger条件,开始提案自己的交易集 TMProposeSet ,由 open 进入 establish 阶段。
各节点协商交易集分歧,交换交易交易集达成共识,进入 accepted 阶段。
各节点根据交易集生成区块,并广播区块 TMValidation ,同时进入到下一区块的 open 阶段。
各节点收集到quorum个Validation,区块达成共识。
'close' 'accept'
open ------- > establish ---------> accepted
^ | |
|---------------| |
^ 'startRound' |
|------------------------------------|
优化点¶
增加交易池,增加ChainSQL对交易数量上的处理能力。
交易提交时sequence的验证不使用OpenLedger,而是使用自定义类StateManager。
交易集的确认使用leader提案机制,替掉节点各自提案,然后沟通分歧的机制。
线程池中对于任务优先级的调整。
交易只验证一次(之前正常是2-3次)。
出块时间变短。
所有遍历区块中交易的地方,都使用同一个缓存。
同步入库一个区块使用一个事务,之前是一个交易一个事务。
|