区块链共识算法之DPOS（下）

吐槽

原以为EOS的“做事”这块比较简单，看了源码后，这块代码写的真是极其复杂。boost的signal把代码的关联性切割的支“离破碎”，加上VScode的跳转不怎么智能，外加上合约数据和nodeos主体之间的“传输”。。。。看的简直要吐了。

回顾

中篇介绍了eos的 dpos选举部分，通过投票选举出21个超级节点，这篇主要是说这些超级节点“如何做事”。

投票结果

中篇到最后提到投票结果放到producers_table中，供其他模块使用。那么怎么被使用的呢？在函数update_elected_producers中实现了对producers_table中所有节点按投票多少排序，选出前21个，然后在设置这21个所推荐的节点。具体看代码：

第93行 获取idx，这个idx关联的是根据节点获取投票数量排序的。第99行获得投票最多的前21个节点。

第113行，打包数据 ，也就是序列化了，然后调用115行的函数set_proposed_producers，这个函数的作用就把前21个节点数据“传递”出去了，这些数据到哪去了？wasm_interface.cpp中有这个函数的实现：

反序列化后传给了最后一行同名的函数set_proposed_producers，这个函数定义如下：

这个函数最后几行把节点数数据赋值给了gpo.proposed_schedule，gpo是一个全局属性对象。然后在函数start_block中调用函数set_new_producers又把 gpo.proposed_schedule设置到block_header的new_producers 和block_header_state的pending_schedule。设置完成后，把相关的proposed_schedule清空。

 

最初的update_elected_producers在系统合约onblock中被调用：

上面调用的地方可以看出，每1分钟更新一次 block producers。系统合约的action  onblock是在哪被调用的呢？同样是在函数start_block中，onblock的transaction在函数get_on_block_transaction中构造好，在函数start_block中push_transaction。

至此如何获取投票结果已经分析完成，最后看张流程图：

 出块

EOS出块的核心函数schedule_production_loop()，通过函数名字就可以看出 ，这个函数是循环调度产生区块的。函数源码：

这个函数先调用 start_block()，由于start_block函数内容较多，简要说下逻辑：

1、计算下一个区块是由哪个节点出块

2、判断是否需要继续同步区块

3、更新 最新的21个出块节点

4、对transactions的一些处理

根据start_block执行的结果，schedule_production_loop 往下的逻辑有4个不同的处理分支。

1、如果失败则重新进行调度。

2、如果等待则重新进行延时调度，或者等待下个块的到来。

3、如果轮到本节点出块，则进行出块操作，调用函数maybe_produce_block()，签名和提交。

4、speculating 模式则重新进行延时调度。

 

其中第3点 ，如果轮到本节点出块，则进行出块操作，调用函数maybe_produce_block()，签名和提交。在commit_block 时 会调用 利用boost singal---accepted_block 注册的函数on_block 。emit( self.accepted_block, pending->_pending_block_state )。

为什么要提这个on_block 函数呢 ，其中调用了函数generate_next，看下源码：

其中 源码后半段和其中调用的函数calc_dpos_last_irreversible 就是 EOS提到的 BFT了 ，2/3+1 确认不可逆。

结束语

至此 EOS的 DPOS算法 分析完毕 ，涉及到大量源码和逻辑 ，总的来就 就是选举+BFT出块。