同一笔约定，不同的结算链

如果 Alice 与 Bob 已经谈好条件，为什么一定要把资产搬到 ArcBlock 的链？没有这个必要。市场发现层可以独立于结算链，而不同链上的资产应当使用各自适合、经过审计的执行机制。

这里的 chain-agnostic 是“协议能描述并选择不同结算适配器”，不是“任意两条链已经共享一个原子事务”。后一种保证需要额外的跨链设计。

Ethereum：签名协议加一个受限的执行器

一个通用 settlement contract 可以接收双方授权，检查资产、数量、收款地址、截止时间和订单是否已使用，然后在同一笔 Ethereum 交易中完成两边转移。失败回滚的是资产状态；已经消耗的 gas 并不会因为交易失败而免费。

链下意图可以用 EIP-712 的结构化数据签名，让域、类型和字段有明确编码。但 EIP-712 自己不提供重放保护。应用仍需定义订单 nonce、撤销和消费记录，绑定 chain ID、合约地址与接收者，避免一份签名被拿到错误的执行环境使用。1

签名也不等于 token 已授权转移。ERC-20 常通过 allowance 允许指定合约调用 transferFrom；支持 ERC-2612 的 token 可用 permit 签名设置授权，其他 token 不能凭愿望获得这项能力。合约钱包还需要适配 ERC-1271 等签名验证方式。2 3

安全执行器还要处理扣费型 token、回调重入、可冻结或可升级资产、精度与舍入，并验证实际收付结果。只把两次 transferFrom 放在一起，并不是可以直接上线的结算产品。对部分成交，原始授权应明确数量上限、比例与累计成交状态；对固定 deal，双方则可以签署完整确定的资产包。

Escrow 是另一种选择：先锁资产，再按条件释放。它改善某些交割确定性，却增加资本占用，并把退款、超时与升级权限变成新的安全边界。即时原子转移和预先托管不是同一种 UX。

Solana：同一事务中的程序与账户约束

Solana 事务可以包含多条指令，所有指令成功才提交状态，否则回滚。一个 settlement program 可以检查签名与账户，通过 CPI 调用 token program 完成两边转移。PDA 可作为程序控制的权限或托管地址，但并不是一个有私人密钥的钱包。4 5 6

直接让双方签同一事务，与先签长期订单消息、由执行者稍后提交，是两种设计。后者需要程序验证订单签名，维护已成交或撤销状态，检查期限，并严密绑定 mint、token account、owner、收款方和程序身份。不能只说“有签名就能扣 token”，底层 token 权限仍要成立。

Solana 的交易大小、账户锁和计算预算会限制一次组合的规模；Ethereum 的 gas、合约调用和拥堵形成另一组约束。哪个更合适，取决于已有资产、流动性、延迟需求与开发审计能力，不能凭一个吞吐数字决定。

原子性止于它能控制的边界

同链数字资产可以共享一次状态提交。跨链交换可能使用哈希时间锁、验证证明、流动性网络或桥，但会引入超时、最终性和额外信任假设。Bitcoin 的多签与 HTLC 也有自己的表达能力与约束，不宜把“支持 Bitcoin”写成一个无差别勾选框。

法币和现实权利更明显。链看见一个银行回执，不代表那笔银行款项不会撤回；转移一个 token，不代表房屋产权登记已完成。Oracle、银行、发行人、托管者或法院所承担的角色必须显示出来。

ArcBlock 原生 exchange 的价值是现成的协议语义；Ethereum 和 Solana 的价值包括通用可编程性及各自成熟的生态。值得复用的是已验证的结算、签名和资产标准。值得探索的是上面的市场协作层。最不值得做的，是为了制造独占优势重新发明托管、签名标准和未经审计的跨链桥。