一、先把研究结论拆成可核验的问题
“支付技术可靠”并不是边界清晰的结论。核验时应分别判断：交易如何获得授权、支付状态如何识别、金额与费用如何表达、订单如何关联，以及具体实现是否符合这些要求。不同问题需要不同证据，不能用一段协议介绍同时证明全部结论。
本文讨论以太坊交易与比特币支付处理相关的通用证据核验方法，不评价具体项目，也不将某条链的规则直接推广到所有区块链。
二、明确两个来源分别支持什么
ethereum.org 的 Transactions 文档介绍交易签名、交易字段、费用和交易生命周期，可用于解释以太坊交易的基本机制。它不能单独证明某个支付系统已经正确实现这些机制，也不能证明其实际处理速度。
Bitcoin Developer Guides 的 Payment Processing 指南讨论支付请求、金额单位、订单与地址关联等环节，并包含 BIP70 弃用警告。它支持支付流程层面的说明，不等于对任何具体服务的认证。
这两个来源属于不同技术体系。来源数量增加，并不意味着同一结论已经得到交叉验证；只有当证据针对同一个问题且适用条件一致时，才具有相互印证的意义。
三、检查版本、上下文与适用条件
核验记录应保留文档名称、网址、相关章节，以及能够确认的版本信息；无法确认的更新日期不能自行补写。遇到“当前支持”“新协议”等表述，应检查是否依赖特定客户端版本或历史背景。
历史功能介绍与弃用警告可能同时出现在一个页面中。因此，不能只摘取功能优点而忽略限制。示例参数也不能直接当作通用配置，更不能把示例费用当作实时成本。
四、把机制证据与实现证据分开
协议文档回答“机制如何规定”，实现材料回答“系统如何落实”，运行记录才有助于判断“实际发生了什么”。核验具体项目时，应查看其结论是否具有对应的实现说明和真实记录；缺少这一层证据，只能说明方案符合某种设计思路。
例如，声称能够准确识别支付，需要说明交易状态与业务订单状态之间的对应关系。仅展示交易标识，不能充分证明订单已完成；将交易广播、区块收录和业务完成混为一谈，也会扩大证据的证明范围。
五、常见问题与结论表达
官方文档是否足够？解释基础机制时有参考价值，但评估具体项目仍需项目层面的证据。两份文档是否可以互证？只有针对相同命题时才可以，不能用比特币支付流程证明以太坊字段的含义。
资料出现矛盾怎么办？先标注分歧，再检查版本和上下文；无法消除时保留不确定性。最终表述应明确“文档支持什么”“项目还缺什么证据”，避免从机制存在直接跳到系统可靠、全面兼容或已经验证的结论。