普通用户几乎不会用到 submitheader，但它是比特币核心 RPC 里少数能直接触碰”链头逻辑”的命令：给它一段十六进制的 80 字节区块头，它解码后作为候选链尖提交给区块头处理流程，合法就收下，非法就抛错。和 submitblock 收整块不同，这个命令只处理头——不含任何交易。它适合的场景都带同一个特征：你手里只有头，或者你只想让节点处理头。
一、命令做的那三件事
按 v31 版本源码里的实现顺序，第一步是解码：把参数按 80 字节区块头的序列化格式解析成版本、前一块哈希、默克尔根、时间戳、难度位、随机数六个字段，解不出来直接报反序列化错误。第二步是查父块：在区块索引里找 hashPrevBlock，找不到就抛”必须先提交前一个头”的错误，错误信息里会直接给出缺失的那个父头哈希——这是它最有用的提示，意味着头必须按链条顺序逐个提交，跳着喂会一直卡在缺环的位置。第三步才是提交验证：走的是和网络传播完全相同的区块头处理函数，检查工作量证明、时间戳规则、版本与难度目标。也就是说，通过 RPC 塞进来的头和从对端收到的头，过的关卡一模一样，不存在”内部通道免检”。
需要留意的是它对工作量检查的取巧参数：处理函数以”最低工作量已检查”的方式调用，因为调用方已经通过连接验证了基本门槛，但这不等于跳过难度——区块头仍必须满足自己声明的难度位对应的目标值。
二、什么人真的需要它
第一个场景是离线补链。隔离环境里的节点收不到新区块头时，运维可以从另一台联网机器导出头数据，用这个命令逐块补进索引；补完头之后，节点向对端请求对应区块体或者配合 loadblock 导入数据文件，账本才完整。第二个场景是重组演练与教学：在 regtest 测试网上手工构造两个分叉头，观察节点如何按累计工作量选链，getchaintips 里两种状态怎么切换，比读十篇文字直观。第三个场景是排障取证：怀疑某个对端喂了坏头时，可以把抓到的原始头单独提交，看验证器给出的具体拒绝理由，比翻模糊日志精确。
三、它改变不了什么
第一，提交头不等于承认那条链有用——节点比较的是累计工作量，一个费力不足的头不会动摇现有链；想让本地视图”偏爱”某条已验证的链，相关工具是 preciousblock，两者职责不同。第二，只有头没有体时，getblock 读这类区块会明确报缺数据，帮助文本就写着”需要先有该区块头，例如用 submitheader”——头与体的获取本来就是两条路。第三，头提交不进钱包扫描逻辑：钱包注意到新区块头依赖的是正常的区块/头通知路径，手工提交是否触发全部下游通知取决于版本实现，把它当同步手段前先验证 getbestblockhash 确实前进了。
安全边界也要交代：这个 RPC 属于特权操作，能操作它等于能影响节点的链头视图。默认它只在本机回环口可用；一旦把 RPC 暴露给网络，任何认证调用者都能喂头，虽然造不出违反共识的链，但足以制造大量无效索引项或干扰排障判断。权限收紧、端口收紧，比记住命令语法更重要。
四、一次最小实验的走法
在 regtest 上做一遍最直观：用生成工具造一个新区块头，先只提交它的父头确认成功，再提交子头，用 getchaintips 观察链尖是否移动；随后故意把子头的上一块哈希改掉一位重提，观察”必须先提交前一个头”的报错如何点出缺失哈希。这个小闭环能同时验证解码、查父、验证三步的行为，比在测试网上盲试快得多。要注意实验环境必须与主网数据目录严格隔离，命令本身没有”演练模式”，喂进生产节点的头会真实进入本地区块索引。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。