ERC-6358 跨链同步：一份签名怎么在多条链上各自执行

主流的跨链代币走的是锁定加铸造：源链锁进桥约，目标链发影子币，两边账本靠桥的验证逻辑互相作证。2023 年 1 月 17 日起草、目前处于 Review 状态的 ERC-6358 试的是另一条路：不锁不铸，每链都部署同一份代币合约，用户把同一笔签好名的交易投进来，各链合约各自验签执行，靠顺序对齐保证状态最终一致。提案给这套体系起的名字很宏大，Omniverse，账户则叫 Omniverse Account，推荐用 secp256k1 曲线的一个公钥来表示——同一个公钥，在以太坊上是账户，在别的链上还是它自己。

一笔交易的六件套

跨链执行单元叫 o-transaction，结构体定得很死：nonce 用 uint128，chainId 用 uint32，加上发起合约地址、发起账户、payload 与签名。payload 是业务数据，由开发者自定，建议的代币格式里是转出方、转入方与数额。每条链上的代币合约被称为 Abstract Node——抽象节点，它们各自记录的状态被视为同一份全局状态的副本。流程按原文推演：用户 A 的账户 nonce 是 k，她在任意一条链调用 sendOmniverseTransaction 提交 nonce 为 k+1 的交易；本链合约验签、查余额或 NFT 归属、确认 nonce 正好是 k+1，然后发布这笔交易并落一个 TransactionSent 事件。关键在下一句：这笔交易不应立即执行，要等一段时间。等待期内，其他链上的同步器——拿签名说话的链下搬运程序——把这份已签交易投到自己那条链的合约上，各链验签通过、窗口结束后分别执行。

顺序即一致性

整套设计里最重的担子压在 nonce 上。所有链的合约都维护同一个账户计数器，副本之间的一致性不靠额外的中继证明体系，靠的是同一份签名在各链被重复验证、且每一笔都必须 nonce 严格递增一位。乱序到达的交易会被拒，重放的会被拒，某条链掉线一段时间后重新追赶时，也只按 nonce 顺序补投。钱包侧的配套查询是 getTransactionCount 与余额归属的 omniverseBalanceOf、omniverseOwnerOf，读的就是各链本地那份计数器与状态。

对藏家，这个模型的后果值得逐条过一遍。它没有传统跨链桥的资产锁定环节，也就不产生锁定资产是否真实存在的证明负担——每条链上的副本都是原生部署的合约记账，不依赖某座桥的金库审计报告。但它换来了另一组问题：执行有等待窗口，跨链动作不是原子瞬间，窗口内各链状态确实不一致；某条链的同步器网络若长时间无人搬运，那条链上的状态就落后，用户在 A 链显示的余额与 B 链能花掉的并不总是同一时刻的同一数字；同步器激励由发行方设计，服务费和挖矿式的补偿方案是否可持续，决定了这种滞后会否常态化。提案把最终一致性说得很清楚，而最终一致在日常语言里约等于暂时没有。

还要留意发起链字段的作用。o-transaction 里写死了 chainId 与 initiateSC，同一份签名只能认领一个起点，防止一笔交易被多链各自解释。但每条链的合约只做本地验签加 nonce 匹配，它无法知道签名者在另一条链上是否签过另一份同序号的不同内容。也就是说，顺序一致只保证各副本账本不分叉，不保证每一笔都符合签名者当时的完整业务意愿——私钥持有者本人若对同一 nonce 签了两份不同的 payload，规则只会先收先到的那一份，另一份在各链被拒。对普通用户，结论朴素：跨链场景下每次签名核对清楚内容与时序，签名本身就是你给所有链下达的那道命令。

本文为机制说明，不构成任何投资建议。