写数据也要指路：ERC-7700 存储路由器如何用 revert 传参数

从别处读数据，社区早有 EIP-3668（俗称 CCIP-Read）：合约 revert 时甩出一个 URL，客户端去那儿取回带签名的数据。但反方向——把一个本该存在主网的字段写到二层或数据库去省 Gas——一直没有标准动作。2024 年 4 月 30 日创建的 ERC-7700 补上这半张拼图，昵称 CCIP-Store，按 ercs 仓库记录状态为 Draft。它延续了熟悉的套路：用 revert 传路由指令。

三种路由器

标准先定义三种最简路由。StorageRoutedToL1() 只带一个参数：真正该调的 L1 合约地址，客户端拿原始 calldata 原样重放到那个合约——调用数据在路由中必须保持不变是硬性前提。StorageRoutedToL2() 带二层合约地址和 chainId 列表，客户端确认自己接了那条链后在二层发起同样的调用。StorageRoutedToDatabase() 只带一个 gatewayUrl 字符串，把写入交给一个 REST 端点。新路由类型怎么办？标准把入口设计成提案制：新 StorageRoutedTo__() 错误想被承认，得另开 EIP 把接口和设计讲清楚——文中顺手列了通向 Solana、Filecoin、IPFS、Arweave、Swarm 的候选名单，都还只是设想。

数据库路由多一道签名

三类路由器里数据库最特殊。L2 自带验证者给数据背书，数据库没有，所以标准给它加了密码学课：revert 之后客户端先向用户索取一个秘密签名派生出确定性的 dataSigner 密钥对，用该私钥对 calldata 签出 dataSig，连同被签的数据一起交给网关。网关事后被查询时，要把数据和签名原样吐回来，让任何想核验的人能在 L1 上对照 dataSigner 验真。读写于是闭环：EIP-3668 读回的数据带着签名，CCIP-Store 写入的数据也带着签名，L1 合约的安全边界都锚在密钥上而非服务商的口头承诺上。

calldata 不变式与信任转移

对普通用户的实际含义有两条。其一，路由的前提是调用内容不变：改参数、换函数就不许路由，否则“省 Gas 的中转”就变成“换地方的执行”，客户端必须校验。其二，把存储写到二层或数据库，等于把数据的可用性和可回溯性部分让渡给路由方——主网节点的历史不再是这份字段的唯一底账；网关宕机，读路径可能受阻，写进去的字段也可能暂时查不到。标准用签名把“内容不可抵赖”做实，但“永远在线”仍是服务商的问题。

读侧先行的历史：CCIP-Read 已经跑通的那一半

这份标准不是从零发明模式，而是把已跑通的路照抄到写侧。EIP-3668 的套路是：合约读不到本地数据时 revert 并附带一段 URL，客户端循着 URL 去网关取回带签名的数据再重放调用——价格预言机和 ENS 的记录解析都靠它跨链供数。多年下来读侧生态成熟，写侧却始终各自为政：想让某个字段的存储成本从主网降到二层或数据库，各家只能自创私有路由约定，客户端无从预知该把 calldata 重放到哪。ERC-7700 把自己和 EIP-3668 并列成 CCIP 家族的两半：Read 管取回，Store 管送出去。

三个路由器里最值得琢磨的是数据库那一类。主网有节点共识，二层有验证者，数据库什么都没有，所以标准给它配了一整套自证流程：客户端先请用户对一个固定的密钥派生过程签名（sigKeygen），从签名确定性地导出签名密钥对，用私钥对写入的 calldata 签出 dataSig，数据和签名一并交给网关；日后任何查询者都应当能从网关同时拿回数据和签名，在 L1 上对着派生地址验真。这套流程把“谁写的数据”锁定到用户自己的签名上，数据库服务商降级成不透明的搬运工。读侧再配合 EIP-3668 验签，字段的生命周期才算闭环。对普通持有人，含义很直接：一个字段的存储地址从主网“搬家”到路由器，链上余额与安全边界没变，可字段的可用性从此多依赖一家网关的在线状态——查不到值时，先分清是不存在还是网关没应答。

它适合被理解为跨链存储生命周期里的写侧说明书：读有 CCIP-Read，写有 CCIP-Store，各管一段，revert 是它们共同的路标。本文为机制说明，不构成任何投资建议。