基于日志的Hyperledger Fabric排序节点propose与writeBlock模式差异问询

核心差异概述 #

• propose模式：属于交易处理的前置准备阶段，聚焦交易的接收、校验与排序前预处理
• writeBlock模式：属于区块生成的最终落地阶段，负责完成交易打包、区块签名与持久化

「propose」模式的具体操作 #

1. 交易接收：排序节点从Peer节点获取经过客户端签名、且已完成Peer背书验证的交易提案
2. 基础合法性校验：检查交易的格式规范性、签名有效性，排查重复提交的交易（防止重放攻击），同时验证交易是否符合所属通道的基础规则
3. 排序预处理：将通过校验的交易按通道分组，为后续的排序逻辑（如按时间戳、交易哈希等策略排序）做准备，此时交易仅暂存于内存交易池
4. 交易池暂存：把校验后的交易存入排序节点的内存交易池，等待触发区块生成的条件（比如交易数量达标、超时时间触发）

「writeBlock」模式的核心操作 #

1. 交易打包成区块：从交易池中取出已完成排序的交易，按照Fabric区块结构规则打包为候选区块
2. 区块签名：排序节点对候选区块进行签名，保证区块的完整性与不可篡改性
3. 区块持久化：将签名后的区块写入排序节点的账本存储（如文件系统或数据库）
4. 区块分发：把生成的区块同步给通道内所有Peer节点，供Peer完成最终的合法性验证与账本更新

内容的提问来源于stack exchange，提问作者Nurin Izzati Jafri