先明确讨论范围
这里将“对手交易”理解为与交易对手方发生的链上转账或合约交互，讨论技术验证与履约之间的关系。比特币的交易脚本与以太坊的智能合约机制不同，下面涉及各自机制的解释仅适用于相应场景。
误区一：签名有效就代表对方身份可信
比特币开发者指南以常见的P2PKH交易为例，说明网络通过公钥、签名和脚本条件验证支出授权。此类验证能够检查一笔支出是否符合协议条件，但不会自动核实签名者的现实身份。
因此，“能够授权支出”和“确实是某家机构或某个人”属于不同判断。即使签名有效，也不能仅凭它认定对方的商业承诺真实可靠。
误区二：链上付款等于整个交易已经履约
比特币交易通过输入引用既有输出，并创建新的输出。开发者指南描述的是链上资产支出与验证机制，其验证范围并不包含商品质量、物流交付等现实事项。
例如，一笔付款被记录与一件商品是否按约交付，需要不同证据。区块链能够呈现付款这一环节，但一项业务是否完成，仍取决于约定中包含哪些义务。
误区三：智能合约自动执行就不会出问题
以太坊智能合约介绍将合约解释为位于链上地址的代码和状态，用户通过交易调用其功能。自动执行意味着按照程序规则运行，规则本身是否符合业务意图仍需另外判断。
假如程序只检查付款条件，它不会因此同时检查未写入程序的交付要求。“执行符合代码”与“结果符合双方预期”可能存在差距，不能把自动化直接视为履约保证。
误区四：合约天然知道现实世界发生了什么
以太坊文档说明，智能合约无法独立获取链外事件信息；预言机可以把外部数据提供给合约。因此，涉及线下结果的自动执行，还依赖数据输入。
例如，交付状态被输入合约后，程序才能按相应条件处理。合约执行逻辑是否正确、输入状态是否真实，是两个需要分别理解的问题。
常见问题：如何理解技术保障的边界
没有人工中介，是否就没有对手方风险？自动执行可以减少部分人工执行环节，但未被程序覆盖的义务仍然存在。
这些结论能否直接用于评价某个平台？不能。基础机制只能解释验证对象和能力边界，无法单独证明具体平台的身份声明、合约实现或履约能力。