8.4 EOS共识代码实现

共识相关的对象

我们先来看看block_header_state的结构:

struct block_header_state {
•    block_id_type                     id;//块id
•    uint32_t                          block_num = 0;//块序号
•    signed_block_header               header;//签名块头
•    uint32_t                          dpos_proposed_irreversible_blocknum = 0;//第一轮共识的不可逆块序号
•    uint32_t                          dpos_irreversible_blocknum = 0;//最终的不可逆块序号
•    uint32_t                          bft_irreversible_blocknum = 0;
•    uint32_t                          pending_schedule_lib_num = 0;
•    digest_type                       pending_schedule_hash;
•    producer_schedule_type            pending_schedule;
•    producer_schedule_type            active_schedule;
•    incremental_merkle                blockroot_merkle;//merkle树根
•    flat_map<account_name,uint32_t>   producer_to_last_produced;//最后一轮的生产者map
•    flat_map<account_name,uint32_t>   producer_to_last_implied_irb;//备选的不可逆块map
•    public_key_type                   block_signing_key;//块签名键
•    vector<uint8_t>                   confirm_count;//当前生产的块所需的确认个数
•    vector<header_confirmation>       confirmations;
​
    block_header_state   next( const signed_block_header& h, bool trust = false )const;
    block_header_state   generate_next( block_timestamp_type when )const;
    
    void set_new_producers( producer_schedule_type next_pending );
    void set_confirmed( uint16_t num_prev_blocks );//共识函数
    void add_confirmation( const header_confirmation& c );
    bool maybe_promote_pending();
    
    bool                 has_pending_producers()const { return pending_schedule.producers.size(); }
    uint32_t             calc_dpos_last_irreversible()const;//从不可逆块备选列表,确定最终的不可逆块
    bool                 is_active_producer( account_name n )const;
    
    producer_key         get_scheduled_producer( block_timestamp_type t )const;
    const block_id_type& prev()const { return header.previous; }
    digest_type          sig_digest()const;
    void                 sign( const std::function<signature_type(const digest_type&)>& signer );
    public_key_type      signee()const;
};
​
struct block_state : public block_header_state {
   //两个参数的构造函数
   block_state::block_state( const block_header_state& prev, block_timestamp_type when )
   :block_header_state( prev.generate_next( when ) ), 
    block( std::make_shared<signed_block>()  )
   {
      static_cast<block_header&>(*block) = header;
   }
​
   //三个参数的构造函数
   block_state::block_state( const block_header_state& prev, signed_block_ptr b, bool skip_validate_signee )
   :block_header_state( prev.next( *b, skip_validate_signee )), block( move(b) )
   { }
};
​

看一下几个重要的变量和函数:

confirm_count:区块需要确认的次数列表,比如:1-12个块需要确认3次,则confirm_count:[3,3,3,3,3,3,3,3,3,3,3,3] dpos_proposed_irreversible_blocknum :第一轮本节点共识的不可逆块序号

roducer_to_last_implied_irb :由生产者确定的不可逆区块备选map列表

dpos_irreversible_blocknum:最终的不可逆区块序号

next():开始生产下一个块

generate_next():根据上一个区块构造新的区块

set_confirmed():共识实现函数

calc_dpos_last_irreversible():从不可逆块备选列表,确定最终的不可逆块

block_state继承自block_header_state,当构造block_state对象的时候,会调用next()或者generate_next()函数;

源码分析共识过程

共识分为两个部分:

- 对从其他节点接收到的块做确认;

- 对本节点生产的块本节点自己确认一次;

1.从其他节点接收到的块确认

当生产者切换时,需要确认已经接收到的块(即共识),共识从start_block()函数开始,代码如下:

从上面的代码可以看出pending->_pending_block_state = std::make_shared<block_state>( *head, when );在构造block_state时,会调用两个参数的构造函数,且构造函数中会调用pre.generate_next()函数,即构造新块的同时,取出最终的不可逆块,然后通过set_confirmed()对已收到的块做共识;

(1).先来看一下共识的函数,set_confirmed(uint16_t num_prev_blocks): confirm_block_count参数的含义:需要确认块的个数 = 全网生产的块序号 - 本节点作为生产节点时最后生产的块序号

需要确认块的个数,看下面的两段代码是如何实现的:

1.作为生产节点的时候,把每个生产者最后生产的块序号存在map变量_producer_watermarks中;

 

2.在start_block()中,获取生产节点上一轮最后生产的块,并根据全网的块序号计算出本节点共识需要确认的块个数;

以下图为例:B节点经过一轮生产后,作为第二轮的生产者时的变化:

 

B节点上一轮最后生产的块序号为24,A节点最后生产的块序号为60,切换生产者,轮到B开始生产时,B生产新块,并开始共识,那么B节点需要确认的块的个数为:60-24=36;

看下共识代码:

(2).看下generate_next(),在根据上一个区块构造新的区块时候,需要本节点从备选的不可逆块列表中确定最终的不可逆块序号:

下面看一下如何从备选的不可逆块列表中确定最终的不可逆块序号:

从上面的代码可以看出,最后的不可逆块,是从备选不可逆块列表中取1/3处获取,而加入到备选不可逆块列表中的块序号是第一轮的共识结果,按节点不可逆块号排序后,第二轮大于2/3的节点达成共识,那么1/3处位置一定是不可逆块;

2.本节点生产的块确认

本节点生产块从producer_plugin_impl::produce_block()函数开始: produce_block()->commit()->commit_block(true)->fork_database::add(),生产的块首先会添加到fork_db中,代码如下:

从上面的代码可以看出auto result = std::make_shared<block_state>( **prior, move(b), skip_validate_signee );在构造block_state时,会调用三个参数的构造函数,且构造函数中会调用pre.next()函数,即生产下一个块,这时在构造新快的同时,需要对上一个块进行确认; 代码如下:

看一下共识的函数,set_confirmed(uint16_t num_prev_blocks);参数num_prev_blocks的值是多少呢?

num_prev_blocks需要确认块的个数 = 全网生产的块序号 - 本节点作为生产节点时最后生产的块序号;

当生产者切换到本地节点,并且已生产了一个块后,比如:本节点生产了一个块61,那么最后生产的块序号更新为61,此时,本节点需要确认的块的个数为:61-61=0;

此时调用set_confirmed(uint16_t num_prev_blocks);num_prev_blocks需要确认块的个数为0; 最后调用generate_next(),根据上一个区块构造新区块时候,并从备选的不可逆块列表中确定最终的不可逆块序号;

总结

本章节我们详细分析了EOS的共识算法bft3.0-dpos的代码实现,需要知道EOS的共识算法大概分成两部分共识:

  1. 接收到的块做共识;

  2. 本节点生产的块做共识;

共识的过程又分为两步:

(1).区块达到(2/3+1)次确认后会被放到备选不可逆区块列表中;

(2).第二轮从备选不可逆区块列表中取1/3处,为最终的不可逆块;

EOS的共识算法bft3.0-dpos需要两轮共识是为了解决一轮共识可能产生的不可逆块冲突问题;

链接

http://www.3heu.com/

https://www.jianshu.com/p/60e54a43dc65

https://blog.51cto.com/14267585/2391529

<think>好的,我需要介绍LVGL 8.4的图片缓存代码实现。首先得回忆一下LVGL的图像处理机制,尤其是缓存部分。用户可能想了解如何配置和使用图片缓存,以及相关的API和注意事项。 首先,LVGL的图片缓存主要用于提升性能,避免重复解码图片文件。尤其是在频繁使用相同图片时,缓存能显著减少CPU负载。接下来需要确定用户的问题范围,是问缓存的基本使用还是更深入的实现细节? 可能需要分步骤说明:1. 缓存的作用,2. 如何启用和配置缓存,3. 相关API函数,4. 注意事项。需要确保涵盖主要函数如`lv_img_cache_set_size`和`lv_img_cache_invalidate_src`,并提到缓存的失效机制和管理策略。 还要注意不同图片源的缓存方式,比如文件系统中的图片和内存中的图片的区别。另外,内存管理方面,如果用户使用外部RAM或PSRAM,可能需要特别处理,这也是一个需要注意的点。 需要检查LVGL的文档或源码确认细节,确保信息准确。例如,图片缓存的默认大小是多少,如何调整,以及如何手动清除缓存。可能还需要提到缓存的LRU算法,当缓存满时如何替换旧的条目。 最后,是否需要代码示例?比如设置缓存大小的示例,或者如何监听缓存事件。但用户可能更关注实现原理和关键API,所以保持解释清晰,结构分明比较重要。避免过于深入源码细节,除非用户明确要求。 总结,回答结构大致分为:缓存的作用、配置方法、API介绍、使用注意事项。确保用中文,使用正确的格式,行内公式用$...$,独立公式单独成段。不过这部分可能不涉及数学公式,但需要遵守系统指令的格式要求。</think>以下是LVGL 8.4图片缓存代码实现的分步解析: ### 一、图片缓存的作用 1. **性能优化**:避免重复解码图片文件(如PNG/JPG) 2. **内存复用**:对高频访问的图片保持解码后的位图数据 3. **动态管理**:采用LRU算法自动清理低频使用的缓存项 ### 二、核心配置方法 ```c // 设置缓存条目数量(默认值:1) lv_img_cache_set_size(10); // 建议根据内存容量调整 // 设置单张图片最大缓存尺寸(单位:字节) lv_img_cache_set_max_size(1024*1024); // 限制为1MB ``` ### 三、关键API解析 1. **缓存初始化**: ```c lv_img_decoder_init(); // 内置解码器初始化时会自动创建缓存 ``` 2. **手动缓存控制**: ```c // 强制清除指定图片缓存 lv_img_cache_invalidate_src(&img_src); // 清空整个缓存 lv_img_cache_drop(); ``` 3. **高级回调(示例)**: ```c lv_img_decoder_set_open_cb(decoder, my_open_cb); // 自定义解码逻辑时控制缓存行为 ``` ### 四、实现原理 1. **数据结构**: ```c typedef struct { lv_img_src_t src_type; // 图片来源类型 void * src; // 源数据指针 lv_img_header_t header; // 图片头信息 uint8_t * decoded_data; // 解码后的像素数据 uint32_t last_use_time; // 最后访问时间戳 } lv_img_cache_entry_t; ``` 2. **缓存查找流程**: ``` [尝试打开图片] ↓ → 检查缓存是否存在匹配条目? ├─ 存在 → 更新LRU时间戳 → 返回缓存数据 └─ 不存在 → 解码图片 → 创建新缓存条目 → 淘汰旧条目(如有必要) ``` ### 五、注意事项 1. **内存消耗**: - 每个缓存条目占用空间计算公式: $$ \text{内存大小} = \text{宽} \times \text{高} \times \text{色彩深度(字节)} $$ 例如:$320\times240\times2\text{Bpp}=150\text{KB}$ 2. **特殊场景处理**: - 动态图片(GIF)需配合`lv_anim`自行管理帧缓存 - 使用文件系统时确保路径字符串唯一性 - 修改源图片后必须调用`lv_img_cache_invalidate_src()` 3. **性能调优**: ```c // 监控缓存命中率 lv_img_cache_get_info(&entry_cnt, &size, &miss_cnt); printf("命中率:%.1f%%\n", (1-(float)miss_cnt/entry_cnt)*100); ``` ### 六、扩展实现(自定义解码) 通过继承`lv_img_decoder_class_t`可实现: ```c static lv_res_t decoder_open(lv_img_decoder_t * decoder, lv_img_decoder_dsc_t * dsc) { if(/* 需要缓存 */) { dsc->cache = LV_IMG_CACHE_OPEN; // 标记需要缓存 } // 自定义解码逻辑 } ``` 建议结合具体硬件平台(如ESP32的PSRAM)优化缓存存储策略,当需要高频切换大尺寸图片时,适当增大缓存尺寸可显著提升渲染性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值