区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载本篇技术指南以 Grin 仓库中的《Blocks and Block headers》文档为骨架系统讲解 Mimblewimble 节点如何通过 gossip 协议接收区块、如何首次同步、如何在落后时追赶最重链most worked chain、如何应对未知最长分叉以及批量获取头部的限流机制。读完本文你将掌握 Grin 双头head与header_head状态机、locator 定位器、头同步/体同步/状态同步三阶段流水线以及孤儿块池与临时分叉的处理原理并能对照仓库源码定位每个关键环节的实现。一、核心概念区块头与区块两个头的分离在进入各场景之前需要先理解 Grin 链数据模型中的一个关键设计区块头BlockHeader与完整区块Block是分开存储、分开推进的。从 chain/src/chain.rs 中Chain结构体的字段可以看到节点同时维护两条链状态header_pmmr以 PMMR 形式存储的区块头链对应的链头称为header_head用于快速验证工作量证明与累计难度total_difficultytxhashset维护输出/范围证明/内核 MMR 的完整交易哈希集对应的链头称为head即完整区块链头代表节点已完整验证到的区块状态。在 Chain::init 中节点会以创世块genesis初始化存储、打开header/header_head目录下的头部 PMMR 与 TxHashSet并建立output_pos与kernel_pos索引。Chain同时保存了archive_mode归档模式标志、pow_verifierPoW 验证函数与denylist被拒绝头部的哈希黑名单。为什么要把头与体分离因为区块头体积小、验证快节点可以先用头部链快速判断哪条链工作量最大再决定是否下载完整的区块体。这也是后续同步流程header-first的基础。二、正常操作节点从对等节点接收区块2.1 处理流程文档描述的正常场景是正常运行时Grin 节点通过 gossip八卦协议从已连接的对等节点peer收到区块。如果区块与区块头均通过验证则两者都被写入存储store随后header_head更新为指向最新区块头headblock head更新为指向最新区块。这套流程在源码中对应 Chain::process_block 与 Chain::process_block_single其内部按顺序执行先处理头部调用 Chain::process_block_header将头部交给pipe::process_block_header验证PoW、累计难度等。头部无效则提前失败避免浪费后续处理去重检查调用 Chain::is_known若头部与当前head相同或头部累计难度不大于当前头且区块已存在则判定为重复块Unfit(duplicate block)孤儿检查调用 Chain::check_orphan如果该块的prev_hash既不是当前head的最后一个区块哈希本地也没有父块则将其放入孤儿池OrphanBlockPool等待后续处理核心管道处理通过pipe::process_block应用区块更新 TxHashSet 与头部 PMMR并提交数据库批次batch状态归类调用 Chain::determine_status根据处理结果把区块归类为BlockStatus::Next当前头部的直接后继主链正常延伸BlockStatus::Reorg发生了重组reorg切换到了新的更重链BlockStatus::Fork挂到主链之外的分叉上通知外部通过adapter.block_accepted(b, status, opts)通知系统的其他部分如交易池、P2P 层区块已被接受。2.2 孤儿块池乱序到达的缓冲区块可能乱序到达例如先收到子块后收到父块。源码中的 OrphanBlockPool 正是为此设计孤儿池以区块哈希为键、以高度为辅助索引便于在父块处理完成后立即找到子块池容量上限为MAX_ORPHAN_SIZE 200超过时优先淘汰太旧MAX_ORPHAN_AGE_SECS 300秒与高度超前的孤儿每成功处理一个区块后Chain::check_orphans 会按高度递归尝试处理被缓冲的孤儿块形成接受一个、连带处理一串的级联效果。三、节点首次同步First Time Sync文档中该小节标注为[tbd]待补但仓库中已有完整的实现可以说明其真实行为。从 servers/src/grin/sync/syncer.rs 的sync_loop与 servers/src/grin/sync.rs 的模块划分来看一个新节点只有创世块加入网络后的同步过程是三阶段流水线Header Sync头部同步通过 HeaderSync 向对等节点请求区块头列表先建起完整的头部链明确最重链在哪里State Sync状态同步通过 StateSync 下载并验证某个历史高度处的完整 TxHashSet快同步或通过 PIBD 分段下载从而免去从头验证全部历史交易Body Sync体同步通过 BodySync 下载从状态点到头部链顶端之间缺失的完整区块体把head推进到header_head。同步循环启动前还会调用wait_for_min_peers要求至少 3 个难度不低于本节点的出站对等节点或超时后继续。关于状态同步的详细安全模型可参见仓库内另一份文档 doc/chain/chain_sync.md全量历史同步、部分历史同步与地平线Z的概念。四、节点落后追赶对等节点Sync to Catch Up4.1 触发条件比较 total_difficulty文档指出节点会定期将自己的total_difficulty与所有已连接对等节点的total_difficulty比较若发现存在更高累计难度的对等节点就尝试向这个most_work_peer最大工作量对等节点同步如果存在多个最重对等节点则随机选择其中一个。源码实现位于 SyncRunner::needs_syncing遍历所有已连接对等节点取max_difficulty再从中随机挑选一个优先出站连接为防频繁抖动同步阈值不是对方难度严格大于本地而是本地累计难度 最近 5 个区块难度之和作为阈值超过才开启同步若已在同步中只要没有任何对等节点的难度高于本地就判定已同步输出synchronized at ...并触发链压缩chain.compact()。在 HeaderSync::choose_sync_peer 中同样体现了选最重、随机挑一个的策略先按HEADER_HIST能力过滤再取最大难度最后在出站连接里choose_random()出站不足时回退到入站连接。4.2 构建 locator 并请求头部文档说同步过程始于基于当前已知链状态构建一个locator并向对等节点请求头部列表把 locator 一并传给对等节点帮助对方挑选合适的头部。源码对应 HeaderSync::get_locator 与 get_locator_heightslocator 是一组从当前header_head高度向创世块方向、以 2 的幂递减的哈希列表如高度 1000 对应[1000, 998, 994, 986, 970, 938, 874, 746, 490, 0]最大定位符数量受 p2p/src/types.rs 中MAX_LOCATORS 20约束Locator在反序列化时也会校验长度不超过该上限该函数附带的单元测试test_get_locator_heights验证了各种高度下的 locator 形态可对照阅读。4.3 收到头部后的处理验证并推进 header_head文档说收到头部列表后节点验证它们并存入 store对每个头部header_head更新为反映最新的头部。对应 Chain::sync_block_headers该方法只在同步期间使用基于sync_head把一批头部交给pipe::process_block_headers处理只有当累计工作量total work增加时才更新header_head。返回值是新的sync_head——注释明确指出在同步一个长分叉时sync_head可能会暂时与header_head不一致。4.4 请求缺失区块体同步文档说节点通过从header_head向回比较头部链、从head向回比较区块链找出每个缺失的区块区块向累计难度大于本节点的对等节点请求该过程反复执行直到没有对等节点难度更高、且两个头状态一致指向同一个头/区块。对应实现BodySync::block_hashes_to_sync从fork_point.height count与header_head.height的较小者开始沿头部链向回走到fork_point收集尚未拥有的区块哈希跳过已在孤儿池中的BodySync::body_sync筛选累计难度严格大于本地head的对等节点归档模式下额外要求BLOCK_HIST能力随机挑选对等节点发送send_block_request单轮请求量block_count min(100, peers.len() * 10)并受孤儿池剩余容量MAX_ORPHAN_SIZE约束发送请求前会检查check_txhashset_needed如果所需区块低于地平线horizon导致无法同步完整历史则返回 true转入状态同步TxHashSet 下载BodySync::body_sync_due 负责节奏控制有超时未收到区块时重新请求收到则顺延 1 秒待请求数降到 2 以下再发起新一批。4.5 同步完成条件综合 SyncRunner::sync_loop 与 HeaderSync::check_run 可以看到重复执行直到一致的落地方式主循环每轮调用needs_syncing()判断是否还需要同步只有头部链高度追上最高高度后体同步才会启动当没有任何对等节点难度高于本地、head与header_head都稳定后同步状态切换到NoSync并触发链压缩以修剪冗余数据。五、新对等节点连接带来此前未知的最长分叉文档以一张流程图sync_on_fork描述该场景一个此前未知的、更长的分叉通过新连接的对等节点被发现节点需要离开当前主链、切换到新的更重链。源码中支撑这一能力的核心是 Chain::reset_chain_head 与 Chain::rewind_and_apply_fork先按目标头部把输出/范围证明/内核 MMR回退rewind再沿目标头部重新应用分叉上的区块期间每个头部都要通过 denylist 校验reset_chain_head的rewind_headers参数允许选择是否同时回退头部 PMMR在 PIBD 场景下可保留已下载的头部链另有 reset_chain_head_to_genesis 用于 PIBD 失败时把链头直接重置回创世块、保留头部链以及 reset_prune_lists 清理剪枝列表。在头部同步侧SyncRunner 中的sync_head状态就是为了针对头部链上的一个大分叉进行长时间同步而引入的同步期间sync_head暂时领先于header_head待分叉的累计工作量最终胜出后header_head才会被更新随后体同步沿着新分叉把head追平。六、节点严重落后500 个区块分批获取头部文档明确指出当前头部获取被限制为每批约 500 个原文档标注512?并提出了一个待思考的问题——收到第一批 500 个头后如果新头部链的累计难度不足以超过现有链会发生什么源码给出了确切答案p2p/src/types.rs 定义MAX_BLOCK_HEADERS 512即对等节点单次最多发送 512 个区块头消息层 p2p/src/msg.rs 也按2 365 * MAX_BLOCK_HEADERS计算Headers消息的最大字节数HeaderSync::header_sync_due 中的节奏控制正是围绕该批量上限设计当header_head.height prev_height (MAX_BLOCK_HEADERS as u64) - 4时认为本批头部已全部收到可以请求下一批若头部处理停滞stalling超过 120 秒仍无进展且对方声称的难度更高则将该对等节点以ReasonForBan::FraudHeight封禁对应新链难度不足以胜出的问题sync_block_headers只在累计工作量增加时才更新header_head因此一批头部即使被完整验证并入库若其累计难度仍低于当前头部链header_head不会移动节点会继续请求后续批次sync_head可暂时领先直到累计工作量反超。这正是头部链先行、主链头延后的设计目的可以安全地沿着一条当前较弱的候选分叉继续收集头部而不影响已验证的主链状态。七、节点成功挖出一个区块Mining a Block文档该小节标注为[tbd]但仓库中的挖矿相关代码可补充说明其行为。挖矿位于 servers/src/mining 模块mine_block.rs、stratumserver.rs、test_miner.rs链侧的关键支持在 Chain 中Chain::set_prev_root_only为新区块头设置prev_root将前一头部应用到头部 MMR 后的根Chain::set_txhashset_roots把待出块应用到当前 TxHashSet 的只读扩展上从而计算并设置新区块头的prev_root、output_root、range_proof_root、kernel_root以及输出/内核 MMR 大小——这些根是 PoW 挖矿输入的一部分挖出的区块随后通过正常的process_block路径进入本节点链上并向全网广播此时本节点作为出块者经历与第二节相同的验证与入库流程。八、两个竞争区块同时被挖出临时分叉文档同样以[tbd]标注仓库实现可从以下机制还原真实行为临时分叉的本质两个矿工几乎同时基于同一父块产出两个合法区块网络中不同节点可能先收到不同的一方。此时本地节点会把先到的一方接为主链延续BlockStatus::Next把另一块挂到分叉上BlockStatus::Fork见determine_status累计难度裁决由于每个头部都携带total_difficulty见 doc/chain/chain_sync.md 中每个区块头都包含截至该块的链累计难度当某条分叉后续积累了更高工作量时节点通过第五节所述的rewind_and_apply_fork/reset_chain_head重组到更重链孤儿块的兜底若竞争区块的父块尚未收到区块先进孤儿池OrphanBlockPool待父块到位后级联处理check_orphans与对等节点的持续比较needs_syncing的阈值设计本地难度 最近 5 块难度避免了在难度接近的临时分叉间反复横跳只有对方明显更重时才触发同步。九、源码与文档索引继续深入阅读主题文档 / 源码位置本文档英文原版doc/chain/blocks_and_headers.md韩文译本doc/chain/blocks_and_headers_KR.md链同步安全模型全量/部分历史同步doc/chain/chain_sync.md链门面与块处理入口chain/src/chain.rs块处理管道pipechain/src/pipe.rs头部同步servers/src/grin/sync/header_sync.rs体同步servers/src/grin/sync/body_sync.rs状态同步TxHashSet / PIBDservers/src/grin/sync/state_sync.rs同步主循环servers/src/grin/sync/syncer.rs协议常量512 / 20 等p2p/src/types.rs头部同步单元测试locatorservers/src/grin/sync/header_sync.rstest_get_locator_heights十、小结围绕区块与区块头这一主题Grin 的实现呈现出一条清晰的主线头部先行、体随后、状态兜底。正常运行时靠 gossip 接收、process_block校验并双头推进落后时靠total_difficulty比较发现最重对等节点用 2 的幂递减的 locator 请求头部以 512 为批量上限分批同步面对未知最长分叉与临时竞争区块靠sync_head、孤儿池与rewind_and_apply_fork完成重组的平稳过渡。理解这两条链head与header_head的分工与协作是掌握 Grin 乃至 Mimblewimble 类链节点同步行为的钥匙。赞分享区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载相关推荐从源码看 Grin 区块与区块头传播双 Head 机制与 P2P 追赶同步全解析从源码看 Grin 区块与区块头传播双 Head 机制与 P2P 追赶同步全解析 本文以 Grin 仓库中《Blocks and Block headers》区块链Web3区块链重组处理Chia应对分叉的终极技术实践指南区块链重组处理Chia应对分叉的终极技术实践指南 区块链重组Blockchain Reorg是分布式账本系统中常见的现象当网络中出现更长或更优的竞争链时区块链后端Grin 区块链节点同步机制详解全量历史同步与基于 Horizon 的部分历史同步Grin 区块链节点同步机制详解全量历史同步与基于 Horizon 的部分历史同步 本文以 GrinMimblewimble 协议的极简实现官方文档 do区块链Web3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考