带条件的广播：eth_sendRawTransactionConditional 把前提写进提交请求

发交易的人大多只有一个通道：把签好名的交易丢进公共内存池，然后听天由命——能不能上块、排在第几位、执行时世界状态还是不是签名的那一刻，全由不了自己。ERC-7796（Conditional send transaction RPC）提出的改法是在提交环节就附上条件：只有满足条件时，出块者才接纳这笔交易。按 ercs 仓库记录，该提案状态为 Review，创建于 2024 年 4 月 16 日，定义的是 JSON-RPC 方法 eth_sendRawTransactionConditional，面向区块构建者与排序器。

options 字段能声明哪些前提

方法参数一仍是原始签名交易，参数二 options 是一组可选条件。blockNumberMin 与 blockNumberMax 圈定允许入块的区块号区间，timestampMin 与 timestampMax 圈定时间戳区间，两者从时间轴上给交易设了有效期。knownAccounts 是更有分量的部分：它是一张地址映射，每个地址可以给出预期的存储根哈希，或者直接给出一组”槽位到值”的映射，声明这些存储槽此刻必须恰好等于这些值；三个特殊键 balance、nonce、code 分别声明余额、Nonce 和账户代码——代码值给空字符串表示预期该地址没有代码，带 0xef0100 前缀则表示预期一段 EIP-7702 委托。换句话说，你可以在提交时声明”某合约的某几个槽位是这个值我才发”，出块者验证不满足就直接拒绝。

拒绝时返回标准错误码：条件验证失败用 -32003 transaction rejected 并附原因，条件清单太大超出处理能力用 -32005 limit exceeded。提案同时提醒：即便受理成功返回了交易哈希，也只代表进了构建器的内部队列，调用方仍然必须盯链上结果，不能假设必然入块。

对普通用户与 NFT 场景的现实意义

直接收益是省掉一类昂贵的自救动作：在条件不满足就必亏的场景里，用户传统的做法是先在模拟器里跑一遍、再抢在状态变化前提交，这本质是在用模拟交易赌时序。把条件写进提交请求后，验证挪到出块者一侧，赌局变成”不满足就不收”，失败不再烧 gas。对 NFT 玩家，典型对应场景是高价藏品抢铸与限价收单：你声明的槽位条件可以是铸价参数、剩余配额，或某个挂单合约的当前状态。

和相邻方案的对照：从模拟交易到私有内存池

理解这个 RPC 方法最快的办法是看它替代了什么。最原始的做法是公开内存池广播加抢跑赌运气；进阶一步是向构建器提交模拟交易表达”状态不对就丢单”，但模拟本身消耗构建资源，失败照样占额度；再进阶是各类私有交易池与意图市场，把排序权整体外包给出价者。条件广播处在中间：交易仍是普通签名交易，用户保留完整的 gas 定价自主，只额外获得一个”提交时核验状态”的权利，不用改变交易结构，也不用把意图交给求解器。对照之后适用边界自然浮现：适合它的场景是失败成本高、状态前提明确且可写成槽位断言的交易——白名单配额核验、铸价参数核验、挂单合约状态核验都属于此类；不适合的是前提涉及对手方未来行为或链外事实的交易，存储槽断言写不出”如果以太坊之外的世界如何”这样的条件。顺带一提，knownAccounts 对代码槽支持 EIP-7702 委托前缀这个细节，说明标准在跟进账户模型的演进，委托型账户正成为条件核验的一等公民。

也要把限制说全。第一，这不是共识层功能，而是 RPC 层约定：不是每个出块者、每个 RPC 服务商都实现这个方法，不支持的连接方要么忽略要么报错。第二，条件验证的是”提交时”的世界状态，防的是时序错配，不保证成交结果本身有利。第三，它给出的是一种表达权，而表达的前提是你清楚自己要锚定哪些槽位——这本身就需要读合约状态的能力。本文为机制说明，不构成任何投资建议。