先明确“不需要挖矿”的适用范围
“不需要挖矿”不足以确定一个网络的全部技术规则。核验前需要明确它采用什么共识机制，以及待核验参数属于哪个网络、哪个协议版本。本文围绕权益证明展开，不能将相关规则直接套用于所有不依赖挖矿的网络。
以太坊权益证明技术文档说明，验证者通过质押参与区块验证、提议和投票，违规行为可能受到罚没。由此可见，核验重点应放在验证者如何参与共识、区块如何被认可，而不能继续只用挖矿难度理解网络运行。
把参数定义与运行状态分开
整理待核验项时，可以分别记录参数名称、含义、单位、适用版本及依据。例如，协议规定的时间间隔属于规则，某次实际观察到的出块间隔属于运行现象。两者有关联，但一次观测不能单独证明规则设置正确或错误。
同样，参与验证的资格要求与某个验证者是否已经开始履职，也属于不同问题。核验结果应明确是在确认协议要求，还是在确认节点当前状态，避免把资格条件直接当成运行证明。
区分出块节奏与最终性
以太坊文档将时间组织为时隙和周期，并通过验证者对检查点的投票说明最终性。这意味着，核验时间参数和核验最终性需要关注不同证据：前者涉及时间安排，后者涉及投票及检查点状态。
常见问题是：看到新区块，是否就说明其中交易已经最终确定？不能仅凭新区块出现作出这一判断。核验记录应分别说明观察到的区块和最终性状态；缺少后者时，不宜把“已出块”写成“已最终确定”。
检查JSON格式，也检查字段含义
如果参数以JSON返回，RFC 8259可作为格式检查依据。它区分字符串、数字、布尔值、空值、对象和数组，并建议对象成员名称保持唯一；重复名称可能导致不同解析程序产生不同结果。
格式检查之后，还要核对字段的预期含义。例如，文本形式的数值与数字类型不能在未确认接口约定时随意互换；空值也不应直接理解为零。JSON能够正常解析，只能说明通过了相应格式检查，无法证明数据来源或参数内容真实。
让核验结论与证据范围一致
一份便于复核的记录，应将预期规则、观察结果和差异说明对应起来，并标明核验对象及适用版本。如果规则描述与返回结果不一致，先检查双方是否采用相同定义、单位和版本，再判断差异意味着什么。
仅有共识介绍和JSON规范，能够建立核验思路，但不足以确认某个具体网络的实际配置。缺少对应配置或运行证据的项目，应保留为未确认项，不能据此宣称整个网络已经通过核验。