比特股源码阅读笔记(四)

qixing (25) 在 cn • 22小时前

前面的笔记本提到,maybe_produce_block函数是witeness 插件尝试生成新块的函数。该函数会先执行一些必要的检查,如本地机器中是否保存有该轮见证人的私钥,时间是否正确。该函数依赖于前面提到的chain::database 类型的全局db对象提供的接口。主要接口有以下几个:

1、get_slot_time

2、get_slot_at_time

3、head_block_time

4、get_secheduled_witness

5、witness_participation_rate

6、generate_block

以上接口的功能,顾名思义就可以了,后期有机会在详细分析下,这里先专注于当前函数的逻辑。

按照bitshares的规则,每3秒就要产生一个块,见证人轮流产生新块,如果一个见证人由于意外而不能按时产生区块则需要跳过此见证人,并由排在他后面的一个见证人来产生区块。

schedule_production_loop 每秒都唤醒一次,并最后进入到maybe_produce_block中,而在maybe_produce_block中,只有当下个区块的正常产生时间与当前时间之间的差值在500ms以内,才会调用generate_block产生区块。

llabs((scheduled_time - now).count()) > fc::milliseconds( 500 ).count()

从这个函数中不能发现,如果一个见证人由于意外不能产生新的区块时,程序会如何处理。chain::database中的get_scheduled_witness 函数

witness_id_type database::get_scheduled_witness( uint32_t slot_num )const

{

const dynamic_global_property_object& dpo = get_dynamic_global_properties();

const witness_schedule_object& wso = witness_schedule_id_type()(*this);

uint64_t current_aslot = dpo.current_aslot + slot_num;

return wso.current_shuffled_witnesses[ current_aslot % wso.current_shuffled_witnesses.size() ];

}

只是简单地返回见证人数组中与slot_num对应的元素,而并没有考虑到元素所代表的见证人是否正常工作。

slot的含义是将要产生的第几个区块,比如 slot=1就代表下一个区块,slot==2就代表下下个区块。

程序到底如何应对见证人不能正常出块的情况呢?在

database::update_witness_schedule()

中我们看到似乎有相关的代码在打乱wso.current_shuffled_witnesses这人数组的顺序。那么我们的猜测到底正不正确呢?由于我们目前关注的控制流,还没有流到这个函数中,先暂时搁置这个问题。

https://steemit.com/cn/@qixing/74fjgj

你可能感兴趣的:(比特股源码阅读笔记(四))