getblock 的 verbosity 四档：从十六进制到 prevout 的代价阶梯

一、一个命令，四档深浅

getblock 是比特币节点最古老也最容易被低估的 RPC。表面看它只是”按区块哈希取区块”，但一个 verbosity 参数让它同时兼职四种工具：传 0，返回这个区块的原始序列化十六进制——和它在网络上传输的字节一致，是喂给解码器、写进存档的第一格式；传 1，返回一个 JSON 对象，哈希、高度、大小、权重、默克尔根、交易编号清单、时间戳、难度目标、累计工作量一次到齐，这是区块体检报告；传 2，交易不再只是编号清单，每笔交易的结构逐笔展开，适合逐笔翻查；传 3，再额外给每个输入标注上一手输出的金额与脚本——但仅限当前主链上未修剪的区块，修剪节点或重组掉的区块拿不到这一档的完整信息。

四档的区别不是信息量递增这么简单，背后是四次完全不同的磁盘与计算策略。理解这一点，才能理解它的坑。

二、代价随档位陡增

档位 0 最便宜：几乎只是定位区块文件、读回原始字节。档位 1 要多做一轮索引与字段展开，仍是轻活。从档位 2 开始，节点要逐笔解析这个区块里的全部交易——现代主网单块常有数千笔，JSON 载荷可以膨胀到几十兆字节；档位 3 还要为每个输入回查上一手输出的元数据，在大型区块上耗时明显。跑同步节点的运维都熟悉这个画面：某个监控面板定时抓最新块的完整结构，每隔十分钟节点就出现一次内存与 CPU 的尖峰，元凶往往就是高频的档位 2 或 3。

对高频轮询的自动化，合理架构是档位 0 或 1 打底，需要细节时只对命中的区块升级到高档位，像外科手术而不是地毯式扫描。需要长期高频解析全部交易的场景，正确工具是专门的索引器或 blockfilterindex 一类的预建索引，而不是把 RPC 当消息队列用。

三、档位 3 的三条边界

档位 3 的便利有明确边界，值得说细。其一，它依赖完整区块数据：修剪节点上对应区块文件已经删除，上一手信息无从回查。其二，它限定当前主链：区块被重组出局后，即便数据还在磁盘，这一档的语义也不再保证。其三，它给出的上一手信息是快照不是担保——上一手输出的脚本、金额取自主链当前状态，个别边角情形（比如 CoinBase 输出、特殊脚本）的展示与直觉不符，核对时以原始交易字节为准。

这三条边界的共同教训是：把高档位当默认值等于把节点的隐性依赖（未修剪、未重组、还在主链）变成自己系统的显性故障点。

四、体检报告怎么读

回到档位 1，这份报告本身值得逐字段练熟。confirmations 为负一，说明这个区块不在主链——你刚从 getchaintips 里看到的那些孤儿分支，就停在这里；strippedsize 与 size 的差值来自见证数据的打折记账，weight 则按四单位权重体系给出，三者对得上隔离见证的体积账；mediantime 是节点校验区块时间戳时用的前后中位时间，比 time 更接近网络的集体记忆；chainwork 是选链比较的标尺，重组之争最终比的就是它。

把这些字段连起来，getblock 就不再是查字典，而是一套体检流程：先档位 1 看整体指标是否健康，再对可疑区块升档位 2 逐笔翻，最后才动用档位 3 追资金来路。四档深浅，其实是四种耐心的形状。顺带一个实用技巧：区块哈希与区块高度各有所长，按高度取哈希要多走一步 getblockhash，但高度天然抗歧义、重组后重取即得正确链；直接抄来的哈希精准却可能是孤儿。脚本里存高度、用时再换哈希，是抗重组的便宜写法。

风险提示：本文仅为节点 RPC 机制科普，不构成任何投资建议。