插件初始化
区块的生产是在producer_plugin里面实现的,和其他所有插件一样,插件初始化的时候从配置文件中读取相关参数如：私钥相关、区块产生相关、交易设置相关等参数并写到内存中去，接下来会使用到。和所有其他插件的初始化一样，大都是从配置文件中读取，然后根据关键字去匹配，匹配成功则写入内存，代码不再粘贴。
C++Tips
在插件启动的时候会调用on_block()函数，在这个函数中会将区块生产者集合和已激活区块生产者集合求交集，在这里使用了std::set_intersection,如下图所示:
下面通过一个简单的例子来介绍下std::set_intersection函数的功能及用法，我们知道射雕三部曲中主线人物之间的关系一直是串联起来的，如郭靖黄蓉夫妇不仅在《射雕英雄传》一书中侠肝义胆，在《神雕侠侣》一书中更是完美阐释了侠的本义：侠之大者，为国为民。
两本书中都有郭靖黄蓉夫妇，而神雕中没有杨康，射雕中没有张三丰，我们可以使用std::set_intersection来求两者的交集，如下图所示，打印结果为两本书中都存在郭靖和黄蓉，类似的std::set_union可以求两个集合的并集，std::set_different可以求两个集合的差集。
插件启动
言归正传,插件启动的时候会先从数据库中获取上一次最后一个不可逆区块的id并根据这个id从数据库中获取这个区块的相关信息。如图中所示，我上一次产生区块的id为142，代码断点调试可以看到这个lib_num为142且lib为142对应的区块相关信息。然后就开始了循环产生区块的过程，也就是我们最开始启动nodeos那一串串的打印。
在上图中调用了schedule_production_loop()之后会调用start_block()函数，由此开始产生区块。
在产生区块之前，首先调用获取上一个区块状态的指针，为了方便看到这个状态中都包含有什么，我们可以看到block_header_state结构体中包含有哪些内容，BM在注释中说到这个结构体定义了一些（尽可能少的）状态去验证区块产生或交易的参数。其中包含有DPoS共识机制下不可逆的区块个数，BFT-DPoS共识机制下不可逆的区块个数等参数，并实现了诸如设定新的区块生产者set_new_producer和set_confirmed等函数。
很遗憾的是本来上篇文章介绍完共识机制，本篇准备结合源码分析下BFT-DPoS的，然而源码中似乎并未涉及到BFT-DPoS，整个区块产生和验证过程中均未提到，且通过block_header_state的调试结果来看dpos_irreversible_blocknum是正常的也就是产生的区块均使用dpos区块做了不可逆的验证，但是bft_irreversible_blocknum的结果一直是0，不管产生多少区块，这个结果都是0。当然这是因为我部署了本地单节点的测试环境，无法说明问题，下一步在进行多节点部署的时候，继续去验证这个问题。
区块生产
现在让我们回到start_block上面来，看看区块产生的过程。在获取到上一个区块状态之后，有个延时的操作，如图中注释的，简单翻译过来就是：上次我们产生了一个区块，再产生下一个区块之前先等待50ms（也就是1/10个区块产生周期），如果区块生产者等不了50ms，那么就等500ms吧。那么这个等待是起什么作用呢？我们知道区块的产生、区块写入数据库、使用共识机制广播出去、区块经由其他节点的确认都需要耗时。如果在未完成以上操作之前就产生下一个区块，就可能产生分叉的现象。但是具体为什么设置50ms，我们还不得而知。此时设置产生区块的标志位为：producing，即开始产生区块。
在真正实现出块之前，还对该节点上有多少区块需要当前区块生产者确认进行了判断。如果区块生产者不属于当前节点，则直接舍弃。如果区块生产者属于当前节点但是从未产生区块，则也不需要确认。如果区块生产者属于当前节点且生产过区块且和上一个区块信息不同，则进行确认。这些都完成之后，开始调用chain.start_block()，并传入block_time（区块产生等待时间）及blcoks_to_confirm（等待确认的区块个数）。
在chain::controller类中开始start_block()如下图示：
这个pending直译过来是悬而未决的，在这里我们把它定义成一个待产生而未产生的区块，pending结构体中包含有以下内容，其中database::session是有关数据库操作的地方，这里我们不做过多分解，block_state_ptr其实就是取的上一个已产生区块的指针，action_receipt是当前区块接收到的action，在前面关于智能合约调试中，我们用到了相关的action。
而最后一个参数，block_status和block_state_ptr是不一样的，它指示当前待产生而未产生的区块的状态，这个状态量有四种：
1)不可逆状态：这个区块已经被应用过且认为是不可逆的。
2)合法状态：这个区块被一个合法的生产者认证且在该节点之前已经被应用过，但是是可逆的，也就是可能被认证的次数未达到应有的2/3以上节点的个数。
3)完成状态：区块已产生，未在该节点上使用过且可逆。
4)未完成状态：未完成的区块。
这里区块pending初始化状态为未完成状态，且通过maybe_promote_pending()函数可以做出判断，返回false。pending初始化完成之后，通过push_trasncation()将产生的区块信息打包进去。
关于push_transcation注释中已经说明：这个函数是在区块中创建一个新的交易的入口点，他将对交易的信息进行权限校验，同时决定是立刻执行还是延时执行这个交易。交易完成之后会将交易结束之后的回执信息打包到即将产生的区块中。至此，完成了一个区块的生产过程。在区块生成之后还进行了无效区块的删除、区块生产者权限更新等操作。
本文主要介绍了区块产生的流程及我们所谓的区块中到底包含有哪些内容。当然，还未涉及到区块产生之后的操作，如入库、上链、广播等过程。接下来的文章我们会一步步的去分析。
如果你对eos开发感兴趣,长按以下二维码,关注本公众号,一起学习eos开发.
微信公众号
有任何疑问或者指教请添加本人个人公众号,当然有对eos开发感兴趣或者金庸粉的也可以添加,备注eos开发或金庸,拉你进群一起交流
个人微信帐号