签名有效，只证明掌握相应私钥的一方授权了签名所覆盖的那笔请求；它不证明钱包界面忠实展示了请求内容，也不证明签名者理解了这笔交易，更不证明请求没有被恶意前端构造。至于交易执行完之后链上状态会变成什么样，签名本身并不作担保。以太坊基金会 Access Cluster 在 2026 年 10 月 5 日发表过一篇关于交易断言的研究文章（原文），本站于 10 月 26 日整理这篇解读，讨论的正是请求与结果之间的这道缝隙。
签名约束的是请求，不是执行结果
一笔交易里，签名通常覆盖目标合约地址、转账 value、calldata 等字段，也就是“向谁、带多少价值、调用什么函数、传什么参数”。但交易真正执行时读到的合约代码和存储状态，可能在这笔交易被打包之前已经发生变化。同一段 calldata，在不同状态、不同区块、不同执行路径下，产生的净效果可以不同。
所以“我签的请求就是我想发起的请求”和“这个请求执行后满足我的经济目标”是两个问题。前者靠核对签名内容，后者需要结果层面的检查。日常遇到的滑点、授权额度变化，很多都落在后一层。
三种检查方式各自管到哪一步
研究文章讨论的 native transaction assertions，是在探索让交易本身携带对执行结果的检查。EIP-7906 是文中提到的可能方案之一，它基于 EIP-8141 的 frame 交易，在末尾一个只读的 POST_TX 阶段核查状态或事件变化。按该文发布时的叙述，这还处在设计讨论阶段，是否纳入升级尚未确定；本文不提供当前升级状态，也不给落地日期。这不代表主网已经普及，更不代表钱包已默认启用。
理解这类方案，可以对比三种检查思路。
| 检查方式 | 检查对象 | 主要局限 |
|---|---|---|
| 读签名请求 | 目标、value、calldata 等字段 | 管不住执行时的代码与状态变化 |
| 特定状态模拟 | 在选定状态上预演执行 | 模拟基于某一时刻状态，不保证未来执行结果 |
| 执行结束的结果约束 | 交易结束后的状态或事件净变化 | 依赖规则独立可信，且需被明确要求 |
第一种就是多数钱包签名页做的事：把请求展示给你确认。第二种是模拟，常见于交易预览，它能发现一部分问题，但模拟用的是选定状态，等到真正上链，状态可能已经不同。第三种是断言的核心思路：在交易执行末尾，按一套独立规则检查净变化，不符合就回滚执行体。
断言失败不等于“什么都没发生”
这里有个容易误解的点。断言失败会回滚执行体，但交易本身仍可能以失败状态保留在链上，并收取已经消耗的 gas。它不是免费撤销，不会让交易拒绝进入区块，更追不回此前已经发生的损失。把断言想成“不满意就全额退款”的保险，是错的。
另一个关键是规则来源。断言检查的规则必须独立可信。如果恶意前端把请求和规则一起篡改，那么即便交易带了断言，也挡不住你按被改过的规则去签。断言提高的是“结果可被校验”的能力，不能替代你对入口和规则的判断。
一个假设例子：把期望写成结束时的条件
设想一种教学场景（不是实际数据，也不代表现有钱包具备此功能）：你希望用某种资产换另一种资产，要求最低收到某个数量，并且交易结束后没有产生额外授权。若交易能携带结果断言，就可以把“净收到不少于某数量”和“授权状态未新增”表达成结束时的检查条件，执行完不满足就回滚执行体。这比只看签名页上的 calldata 更接近你的经济目标。
但这只是表达期望的一种方式。方案并不强制每笔交易都带断言，钱包和协议需要明确要求相应规则，普通用户才会实际用上；它也不会自动修好所有旧合约。文章明确把规则边界放在同网单笔交易内，不承诺跨链原子保障。
回到你自己的判断
先分清两件事：一是“我签的请求是否就是我想发起的请求”，二是“这个请求执行后是否满足我的经济目标”。前者靠核对签名内容，后者需要结果层面的检查。若你遇到的是签名与授权范围的问题，可参考钱包连接签名与代币授权；若想先弄清交易哈希、地址与网络的关系，可看钱包地址、网络与交易哈希。断言研究给出的方向，是让结果层面也有可校验的落点；至于你正在使用的钱包或协议是否已经支持某种具体实现，应以该钱包或协议的公开说明为准，本文不对其现状作断言。