English version · 区块链学习导航 · 上一篇：密钥与数字签名
区块链学习 · 文章 BC014
区块链包含证明回答一个精确问题：这些项目字节，是否属于某个特定根值所承诺的集合？一个真正有用的验证结果，还应说明网络、区块、承诺类型，以及让这个根值具有意义的链视图。如果这些信息缺失，一个绿色的“证明有效”提示仍然不完整。
本篇是一堂证明使用者的核验实验课。你会检查一份虚构证据包，辨别证据支持哪些结论，并判断证明格式错误、区块头未经确认、区块退出被接受分支时应该怎样处理。目标是写出经得起复核的验证报告，而不只是算出相同的哈希。
关于树结构、证明大小的对数增长和数学练习，可以先读为什么学数学：默克尔树、哈希路径、包含证明与高效同步（英文）。本篇把该基础用于另一项任务：使用区块链记录的证据，同时不混淆成员关系、有效性、状态与最终性。
选择适合你的阅读路线
本篇目录
- 一、先写清声明，再检查证明
- 二、盘点证据包里有什么
- 三、第一关：把字节绑定到请求对象
- 四、第二关：重新计算承诺
- 五、第三关：确认应该依据哪个区块头与根值
- 六、区块可以真实存在，却不再被选中
- 七、区分成员关系、执行、状态与最终性
- 八、使用证明前，先认清承诺类型
- 九、六份证据包：接受、拒绝，还是仍待确认？
- 十、报告不应只有一个绿勾
- 十一、服务商意见不同，怎样避免猜测？
- 十二、常见问题
- 来源与下一步阅读
如果你正在看服务商提供的证明，可以从明确声明和三道验证关卡开始。如果独立学习，请按顺序完成虚构证据包和失败案例。如果你在设计报告或界面，请重点看结果标签、链视图变化和证据保留。
练习无需钱包、真实密钥、付款或生产网络连接。下文的实验网络、区块名称和接受规则均为虚构。默克尔运算可以复算，但练习并没有实现比特币、以太坊或任何生产共识协议。
一、先写清声明，再检查证明
设想一家博物馆的虚构区块链阅读器收到服务响应：“gamma 已验证。”这句话究竟是什么意思？gamma 可能是已提交消息、被承诺的项目、交易标识，也可能只是显示在另一串字节旁的标签。如果没有先定义声明，“已验证”反而遮住了真正的问题。
本实验的声明特意限定为：在阅读器记录的链视图下，虚构 Museum-Lab 网络的 Cedar 区块中，gamma 的 UTF-8 字节位于四项记录承诺的索引 2。索引从零开始。Cedar 是方便阅读的练习名称，不是真实区块哈希。
这句话固定了对象、位置、集合、区块、网络和观察背景。它没有说 gamma 是一次成功的应用操作，也没有说博物馆因此拥有某项资产，更没有说这条记录会永远保持同样的意义。
真实请求应把所有虚构标签替换为协议的实际标识。如果同一高度可能出现不同区块，只有区块高度还不够。只有交易哈希，也没有指定阅读器关心哪条链或哪一次包含事件。
二、盘点证据包里有什么
虚构服务商发送以下证据包：
- 网络：Museum-Lab；构造：Lab-Merkle-v1。
- 请求项目：gamma，采用 UTF-8，不带引号或换行。
- 区块：Cedar；承诺字段：recordsRoot。
- 树大小：4；叶子索引：2。
- 两个兄弟摘要，以及足以确定路径的位置资料。
- 一份声称含有 recordsRoot 的区块头，以及“Cedar 属于阅读器接受的链视图”的声明。
包内有两种性质很不同的信息：可以通过运算检查的证据，以及关于这些运算为何有意义的背景声明。不能悄悄把后一类升级成已确认事实。
阅读器另有一张实验核对表。第一个练习中，教师已经在快照 S1 标记 Cedar 被接受，并给出预期 recordsRoot。这张被信任的表，是明确写出的教学假设。服务商不能仅在响应中加入一个名为“可信”的字段，就替自己的声明完成认证。
生产环境中的对应依据，必须来自明确的验证程序，或使用者有意识选择的信任安排。这里要学的是识别这种依赖，而不是拿教师核对表代替真实客户端。
三、第一关：把字节绑定到请求对象
先检查收到的对象是否就是请求的对象。用户看到的标签，与证明验证器实际处理的字节可能不一致。带末尾换行的 gamma，与不带换行的 gamma 是不同输入。JSON 响应可能展示一个解码后的字段，但真正被承诺的是还包含其他字段的序列化记录。
本实验输入恰好为五个字节，即 gamma 的 UTF-8 编码。叶子数据不含时间戳、标识、签名、包装层或隐藏分隔符。这种简化是有意的。生产协议必须规定真实序列化方式，以及承诺究竟覆盖哪些内容。
再检查构造标识、摘要长度、叶子位置、集合大小和证明形状。应按协议拒绝格式错误或不可能的位置。针对第四项的证明，不能仅因为第三项也在同一区块中，就被重新贴成第三项的证明。
请把解析失败与密码学不匹配分开。“无法按该格式解释输入”与“所给证据算出了另一个根值”是不同发现。两者都不自动证明有人不诚实；版本不一致、响应损坏或实现缺陷也可能导致失败。
四、第二关：重新计算承诺
Lab-Merkle-v1 使用 SHA-256。叶子计算先放一个零字节，再放项目字节；父节点计算先放一个数值为 1 的字节，再依次放左右两个各 32 字节的原始摘要。四个有序标签为 alpha、beta、gamma、delta。这借用了实验性证书透明度规范 RFC 9162 第 2.1 节的叶子与节点区分方法，不是比特币的树格式。
对 gamma 而言，第一个兄弟是右侧的 delta 叶子；第二个是左侧的 alpha/beta 子树摘要。下面给出完整十六进制值，分组仅为方便阅读：
右侧兄弟：5c7117fb 9edb0cec 38725789 1105da6a 6616722a f247083e 2d6eda67 1529cdc5
上一层的左侧兄弟：983cb57c 04cddd52 634edab3 8a7bef85 708a974f 114bbd9a a9ec5d4c e6656b4b
预期 recordsRoot：42fc54ee b6352f90 cc81fdd5 791292cc a3974a16 8208b395 b06a7624 0b24884d
先从 gamma 计算叶子，不能直接接受服务商给出的叶子摘要。结果为 4c79d0d6 2f7cf5ca 8874155f 2d3b875f 2625da2b b3abc86b bd6833f2 5ba90e51。将第一个兄弟放右边，按规则计算父节点，得到 839a554f 6df0e53b 2c704fb4 2b7a3fb5 eacc1fe5 68612f06 921b19f5 229f115c。再将第二个兄弟放左边，与这个父节点组合，算出根并比较。
两次父节点运算的输入均为 65 字节：一个前置字节和两个各 32 字节的摘要。打印出的十六进制字符只是显示形式，不是摘要原始字节。匹配只代表通过运算关卡。NIST FIPS 180-4规定了这里使用的哈希原语。
五、第三关：确认应该依据哪个区块头与根值
现在把算出的根，与目标区块背景中正确的承诺字段比较。复制到响应里的根值，并不会自动成为被接受区块头中的根值。同样，一份文件即使名叫“区块头”，也不会自动变成已经验证的区块头。
快照 S1 的核对表确认了 Cedar 及其预期 recordsRoot。因此，实验结果可以把 gamma 连接到明确被接受的 Cedar 背景。如果核对表没有确认 Cedar，正确结果应该是：“包含关系与所给根值匹配；区块头背景尚未确立。”
真实阅读器必须说明，其区块头视图如何取得、经过哪些检查。它可能使用自己的验证节点、特定协议的轻客户端，或明确选择信任的服务商。这些方法依赖不同假设。把三者一概称为“独立验证”，会向用户隐藏重要信息。
比特币开发者指南说明交易默克尔根位于区块头中。比特币白皮书第八节描述使用区块头和默克尔分支的简化验证，同时将它与全节点独立检查交易区分开来。本实验借此强调检查分层，并不是说只要拿到任意区块头，就建立了有效历史。
六、区块可以真实存在，却不再被选中
现在教师给出快照 S2。在这个虚构网络练习中，Cedar 已退出被接受分支，对应位置改为选择 Birch。本篇不模拟共识如何作出选择；更新后的链视图作为另一项独立输入提供。
重新检查旧的 gamma 证明，运算仍然与 Cedar 的 recordsRoot 匹配。分支选择没有改变旧证明的字节。但“gamma 通过 Cedar 位于当前被接受分支”这个结论，已经不能由它推出。
因此，正确报告应分两部分：针对 Cedar 的历史包含检查通过；Cedar 在 S2 中不再被选中。如果任务要求当前分支中的包含关系，那么在取得适当的新证据前，这项任务仍未满足。Gamma 以后可能出现在 Birch 或另一个被接受区块里，但旧证明没有建立这件事。
旧分支的证明与运算错误的证明，是不同情况。如果删掉这种区别，排错和用户沟通都会变差。服务可能因此指责对方的哈希运算无效，而真正的问题只是链视图改变。
应使用目标协议支持的精确状态。过时分支、孤块、尚未最终确定、被拒绝等术语，在不同系统中不能随意互换。请记录区块标识和观察背景，不要仅依赖模糊标签。
七、区分成员关系、执行、状态与最终性
下面四个问题经常被压缩成同一个“已验证”：
- 成员关系：这些字节是否被承诺在这个集合中？
- 执行或有效性：相关操作是否满足协议和应用规则，产生了什么结果？
- 状态：在某个特定状态承诺或历史位置，某个值或条件是什么？
- 最终性或结算信心：在协议假设下，有什么依据支持把该区块或结果视为稳定？
Gamma 的路径回答第一个问题。它没有执行应用，也没有检查后续记录。即使真实交易确实被纳入，也不足以单凭这一点断定预期应用效果已经成功。不同系统对执行失败和无效交易的表示方式不同，应使用相应的回执、执行和验证规则。
历史更新也不一定代表当前状态。设想一条有效博物馆记录在星期一修改展品标签，星期二又有另一条有效修改。星期一的包含证明不能建立星期二的标签。关于当前状态的请求，需要与相应状态及链视图绑定的证据。
默克尔路径本身也不计算最终性。无论外围协议把区块视为暂定、已最终确定，还是位于接受历史之外，根值匹配这一步都不会因此变化。最终性证据属于另一层，有自己的假设和验证程序。不能编造一个适用于所有区块链及所有后果的通用确认次数。
八、使用证明前，先认清承诺类型
一个系统可能提供不同对象的承诺：交易、执行回执、账户状态、应用记录，或其他结构。外观相似的摘要字符串，不是可以互换的证据。针对交易承诺的证明，不能直接称为账户余额证明。
本实验中的 recordsRoot 只承诺四个标签，没有金融含义，也没有账户模型。这个证据包不能支持余额、所有权或付款结论，因为被承诺对象和规则根本没有表达这些事情。
生产验证请求应在处理响应前，明确预期的根字段和证明方案。如果服务商返回另一类证明，就应停下来说明不匹配。不能悄悄把用户的问题改写成收到的数据碰巧能够回答的问题。
以太坊轻客户端文档提供了一个真实例子：使用同步委员会认证区块头。它与比特币工作量证明的区块头背景不同。“轻客户端”是一类方法的名称，并不是可以原封不动搬到不同网络的通用验证算法。
九、六份证据包：接受、拒绝，还是仍待确认？
除非题目另有说明，均使用快照 S1。每一题都判断范围明确的实验声明，不要事后添加更大的结论。
证据包 A：完整且匹配。Gamma 的精确字节、规定的两个兄弟摘要、索引 2、大小 4、Lab-Merkle-v1 构造和 Cedar 根值，都与被接受的 S1 核对表相符。
结论：接受实验中的包含声明。报告快照和范围，不要附加执行成功、事实真实或永久最终性的结论。
证据包 B：载荷改变。其他资料不变，但载荷变成 gamma 加一个末尾换行，仍使用原来的兄弟摘要。
结论：在本声明下，拒绝针对所收字节的这份证明。除非协议明确规定在承诺前进行该转换，否则不能为了得到匹配而擅自删除换行。
证据包 C：哈希成功，区块头未知。路径与服务商所给 Willow 区块头中的根值匹配，但核对表没有建立任何被接受的 Willow 背景。
结论：运算可以通过，区块头来源依据仍待确认。不能标记为“被接受链中的包含关系”。需要更多背景证据，计算本身不能补上。
证据包 D：旧分支。在 Cedar 已不再被选中的 S2 中，检查原来的 Cedar 证明。
结论：保留它与 Cedar 之间有效的历史关系，但拒绝“通过 Cedar 属于当前分支”的声明。需要与选定链视图绑定的证据。
证据包 E：回答错了问题。用户问“展品目前的标签是什么？”，服务商却返回证据包 A。
结论：回答不充分。它证明 gamma 的包含关系，却没有建立所有相关更新之后的当前应用状态。
证据包 F：没有响应。请求 gamma 的证明时，服务商超时。
结论：记录为证据不可取得。超时既不证明包含，也不证明不存在，更不证明 gamma 已被删除。
十、报告不应只有一个绿勾
好的验证报告能够说明不确定性，又不让读者淹没在细节里。实验成功案例可以简洁写成：“Gamma 的精确字节与 Cedar 四项记录承诺的索引 2 匹配。Cedar 在实验快照 S1 中被接受。本次未评估应用执行与未来稳定性。”
请分别保留解析、根值重算、区块头背景、链分支选择，以及任务要求的应用或最终性检查状态。界面可以汇总它们，但不能把尚未确认的背景检查变成笼统成功标志。
保存足够证据，使结果可以重现：网络和区块标识、承诺类型、构造版本、项目字节或妥善保留的引用、证明、预期根值、链视图引用，以及实际执行的检查。如果涉及真实敏感数据，还应采用适当保留期限和访问控制；本篇只使用公开的虚构标签。
观察时间也有帮助，但不能代替区块或快照引用。“十点已验证”没有说明使用哪个链视图，也没有说明这个视图如何建立。
十一、服务商意见不同，怎样避免猜测？
假设两个服务商返回不同的选定区块。若它们可能依赖同一后台，就不能靠数网页来解决分歧。先核对网络、区块标识、观察时间、同步状态和精确查询。一份响应可能过时，另一份可能来自不同环境。
然后遵循所选客户端的验证和同步程序。如果阅读器依赖外部服务商，应把这个事实写明，而不是暗示比较两个仪表板就重现了共识验证。证据不足时，“仍待确认”比凭空选出胜者准确。
同样，成功包含并不说明所有底层记录都能取得。以太坊数据可用性指南解释了为什么取得底层数据是独立问题。本实验中，所给路径能够验证 gamma，却没有提供 alpha 和 beta。范围较小的任务可以成功，而更全面的审计仍然缺少必要信息。
十二、常见问题
根值匹配能证明区块已最终确定吗？
不能。它建立的是与该根值的关系。区块在具体协议中的状态，需要另行提供证据。
区块浏览器能提供有用证据吗？
能，但应区分从它那里取得的数据，与自己的验证器独立检查过的声明。页面显示成功，并不是完整证明规范。
证明失败是否应该立即指责对方？
不应该。保留失败类别与输入。错误版本、编码差异、过时背景或传输损坏都可能解释失败。不匹配证明的是某项检查失败，并不自动证明行为意图。
这是一份生产验证操作指南吗？
不是。它是使用者视角的推理实验，并提供可复算运算。生产软件需要精确目标协议、持续维护的实现、完整输入验证，以及真实信任与共识假设。
来源与下一步阅读
来源核对日期为新加坡时间 2026 年 10 月 12 日。Museum-Lab 网络、Cedar/Birch/Willow 名称、快照与判断均为原创教学情境。SHA-256 数值来自明确规定的四标签构造。RFC 9162 是 2021 年 12 月的 Experimental（实验性）规范；FIPS 180-4 发布于 2015 年 8 月，其页面注明了计划修订信息。
- 已有数学基础：默克尔树与包含证明（英文）。
- RFC 9162 第 2.1 节：示例中的叶子与内部节点区分。
- NIST FIPS 180-4：SHA-256。
- 比特币开发者指南：Block Chain和比特币白皮书：区块头与简化验证背景。
- 以太坊：Light clients与Data availability：区块头认证及底层数据这两类独立问题。
检查根值公告或检查点的认证方式时，可以复习数字签名文章。下一篇转向地址、密钥派生与身份，继续区分简洁标识符与“由谁控制”这一完整声明。