先把要证明的问题说清楚

查看一个区块时，常见问题包括某笔交易是否被包含、执行结果是什么、某个账户在特定区块的状态如何。它们是不同的问题，需要不同的数据与证明。区块头里的根哈希提供相应数据结构的承诺，但根哈希本身不是可直接阅读的账户清单，也不会解释交易为什么产生某个商业结果。

交易根对应交易集合

交易根与区块中按顺序组织的交易有关。验证某笔交易的包含关系时，要同时知道网络、区块头和相应证明结构。交易被包含不代表它执行成功，更不表示接收平台已经给客户入账。一个浏览器链接只提供查询入口；需要正式验证时，应明确自己信任的是节点、浏览器还是验证过的区块头。

回执根对应执行结果

回执通常包含执行状态、累计 Gas 使用和日志等信息。回执根承诺的是这些执行结果，而不是平台的客户余额。应用可能通过日志识别活动，但日志的发出合约、参数解码和交易状态都必须一起看。看到一条名为 Transfer 的事件，并不能跳过代币合约真实性和执行结果检查。

状态根描述特定区块状态

状态根对应某一状态快照，可涉及账户余额、nonce、代码及存储的关联结构。证明需要固定区块，不能把昨天的证明套用到今天。对某个存储槽的证明成立，也不代表代币经济、管理权限或外部预言机没有风险。技术承诺的范围应比营销文案中的“全部链上可查”更精确。

一个跨字段核对例子

设用户要确认一次合约调用。首先确定交易进入哪个区块，再看回执是否成功和事件参数，最后根据问题查询相关账户或合约状态。若浏览器与应用显示不同，检查是否引用不同区块高度或不同网络，而不是立刻认定某方造假。示例说明证据层次，不构成对任意合约的审计结论。

保存证明上下文

保留链标识、区块高度与哈希、根哈希类型、查询方法、证明数据和工具版本。若使用第三方解码服务，标注其角色及可能的缓存延迟。最终性与链重组仍会影响所选区块的地位；验证一份数据证明，只回答明确的技术问题，不证明服务实体、资产储备或未来可赎回能力。