先确认证据回答的是什么问题
区块链研究中的“证据”可能对应不同问题：系统是否采用分布式账本，交易如何被验证，历史记录在什么条件下难以修改，某项应用是否改善了业务流程，或者系统是否满足安全、性能和合规要求。核验前应先把问题写成可判断的命题，避免用一项技术原理替代对应用效果的证明。
例如，“区块包含前一区块的哈希”可以支持对链式数据结构的描述，但不能单独证明某个项目的数据真实、业务合规或成本更低。“交易写入后难以改变”也应说明共识机制、参与者权限、攻击假设和网络运行状态，而不能直接表述为绝对不可篡改。
第一步：检查来源与证据层级
来源核验至少包括发布机构、文档标题、版本或发布日期、作者身份、原始链接和引用范围。NIST IR 8202属于面向区块链技术的概览性技术文档，适合核对基本术语、组成机制和常见共识模型；比特币开发者文档则聚焦比特币区块链的具体规则，适合核对区块、交易、UTXO、梅克尔树和工作量证明等实现细节。两者用途不同，不能把特定系统规则直接推广为所有区块链的共同属性。
证据层级也要区分：标准或官方技术文档通常能支持“协议如何设计”的判断；源代码、测试记录和可复现实验能进一步支持“实现是否符合设计”；独立审计、对照实验、运行日志和长期观测，才更适合支持安全性、性能或应用效果结论。宣传页面、二手摘要和未给出方法的案例材料，只宜作为线索。
第二步：逐项核对技术断言
对“不可篡改”的核验，应拆成几个可观察条件：区块是否包含前一区块头哈希，交易是否通过节点验证，网络是否存在明确的共识规则，修改历史记录需要付出什么代价，以及节点在分叉时如何选择链。比特币开发者文档说明，改变已记录交易会影响所在区块及后续区块；在工作量证明机制下，重建这段历史的成本会随着后续区块增加而上升。这支持“篡改具有可检测性或成本较高”的较谨慎表述，不支持“任何情况下都不可能修改”。
对“交易已被确认”的核验，应确认所谓确认是本地节点接受、被区块收录，还是在若干后续区块出现后被业务视为稳定。比特币文档还区分了交易输入、输出和未花费交易输出，并规定同一输出不能被重复使用。由此可以核查双重支付相关的协议规则，但不能据此证明链外身份、商品交付或传感器数据本身真实。
对“数据可信”的核验必须区分数据完整性与数据真实性。哈希、数字签名和共识机制可以帮助发现记录被改动，并验证特定密钥对数据的签署关系；它们通常不能单独证明签名者身份没有被盗用，也不能证明写入链上的外部事实准确。涉及预言机、人工录入或跨系统同步时，应继续检查数据来源、授权流程、时间戳和审计记录。
第三步：检查适用条件与反例
每项结论都应附带适用条件，例如网络是许可制还是开放参与，节点是否相互独立，验证规则是否公开，攻击者能力如何定义，系统是否允许管理员回滚或修订，以及链外数据如何进入账本。若材料没有说明这些条件，结论的可信范围就应缩小为“在所描述的模型下成立”。
还要主动寻找反例。多个节点保存相同账本，并不等于所有节点都诚实；区块链具有时间戳和链式结构，也不等于时间来源绝对可靠；智能合约自动执行，也不等于合约逻辑正确。出现分叉时，暂时同时存在的区块可能并不会全部成为最终历史，因此应明确使用的是暂时状态还是被后续规则保留的链。
形成可复核的证据记录
建议为每条研究结论建立“主张—证据—条件—限制”记录。主张写成可检验句子；证据注明文档名称、章节或页面位置、数据版本和获取日期；条件记录共识机制、网络参与方式和测试环境；限制则写明尚未验证的部分。对于实验性结论，还应保留配置、样本、指标定义、原始日志和重复步骤。
核验结果可以分为三类：一是来源直接说明且范围清楚的事实；二是依据多个技术事实作出的有限推论；三是尚缺乏数据支持的应用效果或安全承诺。只有前两类在边界明确时适合写入研究结论，第三类应标为待验证，而不应通过“上链”“去中心化”等术语补足证据。
常见问题
问：区块链上的记录是否天然真实？答：不是。区块链主要解决共享记录、验证和历史修改检测等问题；记录在写入前是否准确，取决于身份认证、采集设备、人工流程和外部数据接口。
问：一份官方技术文档能否证明某个应用项目有效？答：通常不能。官方文档可以支持协议设计或实现规则的核对，项目效果还需要项目自身的架构、测试数据、运行记录和独立评估。
问：看到“不可篡改”时应如何改写？答：应改为更具体的表述，例如“在给定共识规则、参与者假设和网络正常运行条件下，已确认记录的修改可被检测，或需要承担较高的重写成本”，并注明仍可能存在权限管理、密钥泄露、软件缺陷和链外数据错误等风险。