先明确研究究竟要证明什么
区块链交易场景的研究，可能讨论协议是否支持某种操作、某笔操作是否发生，或某种应用是否改善了业务。三类问题需要不同证据。技术文档可以解释机制，具体记录用于核对事件，业务效果还需要与研究目标对应的观察和比较。
核验前应把结论改写成可检查的问题，明确网络、交易类型和观察范围。例如，“支持价值转移”与“完成了某笔订单的支付”需要的材料不同，不能用前者的技术说明直接证明后者。
两个来源分别支持什么
ethereum.org 的 Transactions 页面说明，以太坊交易是经过密码学签名、用于更新网络状态的指令，涉及发送方、接收方、金额、输入数据及费用参数。它为检查转账和合约调用的技术含义提供基础，不能单独证明某个应用的实际效果。
developer.bitcoin.org 的 Transactions 指南从输入、输出与未花费交易输出解释比特币交易：输入引用先前输出，支出需要满足相应脚本条件。其 P2PKH 示例适用于理解这种支出授权机制，不宜直接推广到所有交易形式。
两份来源来自不同网站，但讲解的是不同协议模型。它们能帮助识别核验方法的差异，并不构成对某个具体场景结论的相互印证。
把证据连接到可复查的记录
研究应保留网络名称、交易标识、对应记录和判断依据，使读者能够定位同一对象。交易标识用于定位交易，单独展示一串标识，尚不足以说明发生了什么业务行为。
以太坊场景需区分普通转账与合约调用，结合目标地址和输入数据理解操作。比特币场景则需对应输入引用的先前输出、输出金额及支出条件，不能机械套用以太坊的字段含义。
对于合约调用，函数选择器只能提供识别线索；解释参数还需要对应的接口定义和代码依据。研究应明确哪些内容来自原始记录，哪些属于解码或分析所得。
常见问题：签名和记录能证明多少
签名验证能够支持协议层面的授权判断，但不能仅凭签名确定现实中的主体身份，也不能证明商品交付或合同履行。把地址与企业、个人对应起来，需要额外且可审查的依据。
广播、纳入区块与执行结果应分别核对。以太坊交易被纳入区块，也可能执行失败；研究不能把“已提交”直接写成“业务已完成”。确认状态还应注明观察时点，避免把不同阶段混为一谈。
适用范围与结论表达
这些核验原则适用于支付记录、资产转移和合约交互的技术研究。涉及效率、成本或可靠性比较时，还应交代样本范围、统计口径和比较条件。单笔交易可以说明一个案例，无法独自代表整体表现。
可信的结论应与证据强度对应：机制文档支持可行性解释，交易记录支持具体事件判断，业务材料支持场景效果分析。无法连接起来的环节，应明确标为尚未证实。