以太坊合约把数据存去 Solana：ERC-7694 存储路由的机制与边界

NFT 元数据存在哪里，决定了它十年后还能不能被读到。常见的答案有 IPFS、Arweave、中心化服务器，而 ERC-7694 提供了另一个方向：数据可以直接路由到 Solana 链上保存，以太坊这边的合约只负责指路。按 ercs 仓库记录，这份提案状态为 Draft，创建于 2024 年 4 月 18 日，是 CCIP-Store 跨链存储路由协议（EIP-7700）的一个扩展分支。

路由怎么发生：用报错数据当门牌号

CCIP-Store 的玩法是：以太坊合约在自己存储该去哪的链上找不到答案时，不返回数据，而是抛出一个带参数的 error，让客户端拿着参数去正确的地方读写。ERC-7694 定义的 Solana 版本是 StorageRoutedToSolana，参数为两个 bytes32：Solana 程序的 programId 和托管数据的 account。programId 相当于 Solana 世界的合约地址，account 是具体存放数据的账户。合约里的 setValue 之类的函数遇到需要路由的存储节点时，直接 revert StorageRoutedToSolana(...)，客户端解析报错内容，把这次调用改发到 Solana 程序上执行。

这个设计和已有的 StorageRoutedToL2 路线一致：由合约主动用报错把客户端”指”到另一条链，读取方不需要预先维护一张全量路由表。

两条虚拟机之间的类型换算

EVM 和 SVM（Solana 虚拟机）架构不同，提案专门处理了数据类型的对应：bytes32 要转换成 Solana 的 PubKey 类型。提案指出 Solana 生态中已有不少流行自定义类型在语义上等同 EVM 常见类型，标准列出了换算表让两边的实现有统一口径，并给出示例：Solana 程序端的 setValue 收到 PubKey 形态的参数，而链下的 EVM 字节要先按规则转码。读完之后要把数据翻译回 EVM 语境，提案安排的是既有的 EIP-3668 路线：由一个兼容的 HTTP 网关把 Solana 状态包装成以太坊合约的链下读取响应。

对 NFT 元数据意味着什么，边界在哪

先说价值：如果元数据本体落在 Solana 账户里，读写都走账户模型，成本结构与以太坊 calldata 或 blob 不同，某些高频更新场景（例如动态属性）可能更合算；以太坊合约地址仍然可以像普通”链上地址”一样被引用，由客户端负责跨链。

一次读写要过的四道关

把一次经 ERC-7694 路由的元数据读取拆开看，链条上有四个薄弱环节。第一关是报错解析：客户端要正确识别 StorageRoutedToSolana 这个自定义 error，从两个 bytes32 参数还原出 Solana 端的程序与账户；实现不完善的钱包可能把整个调用当普通失败吞掉。第二关是类型换算：bytes32 转 PubKey 有既定规则，转换实现出一点偏差，指过去就是另一个账户。第三关是 Solana 端本身：账户是否存在、租金押金是否缴足、程序有没有被升级或关闭，都会改变”数据还在不在”的答案。第四关是读回翻译：走 EIP-3668 兼容网关时，网关服务器既是可用性依赖也是数据完整性依赖，它的响应和链上原始状态之间隔了一层人。四道关逐条对照，你大约能判断一个项目”我们的元数据永远在链上”这句话漏说了什么。核对这类声明时，建议直接问项目方要四个答案：路由合约地址、Solana 程序地址、网关域名和押金账户由谁续费——四个答案齐了，数据十年后可达性的路线图才可见。

再说边界。第一，账户有租金：Solana 账户占用存储要向网络缴纳押金，账户若因押金问题被清空，路由指过去只会发现空地址——“链上存储”不等于”永久存储”，这句话对这条路线同样成立。第二，跨链读取依赖网关：EIP-3668 网关是人为架设的翻译层，它的可用性与诚实性都是新的依赖点。第三，客户端支持是前提：提案明确假设钱包与浏览器配备了处理 Solana 交易的能力，现实中多数以太坊钱包不具备。第四，Draft 状态加小众采用，把它写进任何”现状描述”都要谨慎。本文为机制说明，不构成任何投资建议。