跨链桥的安全危机

跨链价值转移在当下的技术框架下可以说是“从根上就有问题”的。仅在 2022 年，与跨链桥相关的安全事件就给用户带来了超过 20 亿美元的损失（数据来源：CNBC、CoinDesk 等）。其中，Ronin Bridge 单次被盗金额高达 6.25 亿美元，Wormhole 损失约 3.2 亿美元，Nomad 事件也造成了约 1.9 亿美元的资金损失。

从这些案例中，我们可以清晰地看到一个共同模式：跨链桥往往将大量资产集中在托管型智能合约中，从而形成极具吸引力的“攻击金库”。一旦合约设计、权限管理或密钥管理出现纰漏，攻击者就有机会“一锅端走”巨量资产。

然而问题并不仅限于安全维度。包装代币所带来的流动性碎片化，同样在消耗整个多链生态的效率与用户体验。用户不得不在同一种资产的多个版本之间反复切换，例如以太坊上的 WBTC、Polygon 上的 renBTC、BNB Chain 上的 BTCB 等。每一个包装层都增加了额外的对手方风险与赎回摩擦，也加重了用户在资产管理、记账和风险识别上的心智负担。所谓“统一的多链经济体”，在现实中仍然被复杂的底层技术结构牢牢束缚。

如果我们能够从根本上不再依赖跨链桥，会怎样？不是试图打造一个“更安全的桥”，而是让跨链桥本身变得不再必要。这正是 NEAR Chain Signatures 所代表的范式转变。

Chain Signatures：NEAR Intents 背后的底层引擎

在这一架构下，Chain Signatures 是支撑 NEAR Intents 的底层密码学技术。

例如，社区中曾有这样的讨论：Infinex 集成了 NEAR Intents，并计划支持受保护的 ZEC 交易，这意味着用户可以在 Infinex 内部不同钱包之间转移资金，而无需在公开链上暴露具体交易细节。这里所依赖的底层能力，正是 Chain Signatures 所提供的跨链签名与执行机制。

通过 Chain Signatures，NEAR 账户可以在多条区块链上发起签名并执行交易，账户的主体不仅可以是普通用户，也可以是智能合约甚至 AI agent。这一能力依托多方安全计算（MPC）实现，为 NEAR Intents 的多链功能提供了坚实基础。

在应用层，像 Ledger 这样的硬件钱包也已经集成了 NEAR Intents。用户在 Ledger 钱包中，通过相关集成即可使用 NEAR Intents 提交自己的目标，即所谓“意图（intent）”，之后由人工或者 AI agent 在包括以太坊、比特币、NEAR 在内的多条链上完成具体执行。换言之，用户不再需要自行设计复杂的跨链路径，而是只需表达“我想要的结果是什么”。

从实际数据来看，NEAR Intents 的增长与采用速度本身已经为这套模型背书。相关统计可以在公开的 Dune 仪表盘中查看，成交量与活跃用户均呈现出非常明显的加速趋势。

签名驱动的全新范式

与传统跨链桥将资产锁入合约并在目标链上铸造包装代币的模式不同，NEAR 的 Chain Signatures 选择从根本模型上“翻转思路”。在这一范式下，一个 NEAR 账户并不会将资产交付给桥，而是直接在外部区块链上为相应交易进行签名，从而在原生链上完成转移与操作。

在这个过程中，没有托管资产的跨链桥合约，也没有包装代币的铸造与赎回，整个流程只依赖密码学签名本身即可完成跨链操作。这种模式的基础，是多方安全计算（MPC）协议。MPC 允许多个相互独立的参与方在不泄露各自私钥份额的前提下，共同完成一笔交易的签名，整个过程中不存在任何一方单独掌握完整私钥的情况。

在 NEAR 主网上，当前运行的是一个由 8 个节点组成的 MPC 网络，这一网络通过 v1.signer 智能合约进行协调。所有签名操作都通过该合约触发与管理，对外呈现的是标准化的合约调用接口，对内则是分布式的门限签名流程。从地址推导到签名执行：实际运作方式

在具体实现上，整个流程大致可以分为“地址推导”和“签名执行”两个阶段。

首先是地址推导。对于同一个 NEAR 账户，可以根据不同链和路径信息，推导出对应的外链地址，例如：

将 alice.near 与 "bitcoin-1" 以及 MPC 公钥组合，可以推导出一个比特币地址 bc1q...

将 alice.near 与 "ethereum-1" 以及 MPC 公钥组合，可以推导出以太坊地址 0x...

将 alice.near 与 "zcash-1" 以及 MPC 公钥组合，可以推导出 Zcash 的透明地址 t1...

这类推导是确定性的：同一个 NEAR 账户配合同一条路径和同一组公共参数，总是会得到相同的外链地址。对用户而言，这意味着自己可以稳定地“拥有”这些外链地址，而无需在任何地方持有一串传统意义上的私钥，也无需担心“私钥泄露”这一常见风险。

当用户需要在某条外部链上发起一笔交易时，则进入签名执行阶段。以 Alice 想在比特币网络上发送一笔交易为例，她会在 NEAR 上调用 v1.signer 合约的签名方法，并传入对应的交易哈希、路径信息以及签名算法版本。合约在收到请求后将执行权交给 MPC 网络，由 8 个节点共同启动门限签名流程。每个节点负责生成自己的签名份额，任何单个节点都无法凭一己之力生成完整有效的签名，只有在分布式协作完成后，最终的聚合签名才会返回给合约。

在签名结果返回给 Alice 后，她可以将这笔已经完整签名的比特币交易广播到比特币网络。整个过程不涉及跨链桥的托管与转移，也没有产生任何包装代币，她只是以自己在比特币网络上的地址所有者身份完成了一次标准交易。

目前，系统支持两类主要签名算法：一类是基于 Secp256k1 的签名，用于比特币、以太坊以及大多数 EVM 链；另一类是基于 Ed25519 的签名，用于 Solana、Stellar、TON 等链。相关的示例脚本与实现可以在公开的 GitHub 仓库中查看。

ZCash 案例：隐私协议与链抽象的交汇

ZCash 的集成是检验 Chain Signatures 能力与边界的一个关键样本。一方面，ZCash 通过 zk-SNARK 提供强隐私保护能力，是许多关注金融隐私用户的重要工具；另一方面，它对协议实现提出了更高的技术要求，也能真实暴露当前架构尚未覆盖到的部分。

ZCash 同时支持透明地址（t-address）和受保护地址（z-address）两大类地址体系。透明地址与比特币类似，交易信息在链上公开展示，包括发送方、接收方与金额等；受保护地址则通过零知识证明实现高度隐私，链上只验证交易“有效性”，而不会暴露具体细节。

在现阶段，Chain Signatures 只能为 ZCash 推导透明地址并完成相关签名，这并不是产品层面的刻意取舍，而是受限于协议实现的阶段性技术现实。推导标准地址仅依赖于公钥和路径，而构造一笔针对受保护地址的交易则必须完成 ZCash 特定的 zk-SNARK 证明生成，这属于另外一类复杂的密码学协议流程，尚未被纳入当前 Chain Signatures 的能力范畴。

因此，在使用 ZCash 时，用户如果希望最终获得受保护地址上的隐私效果，需要通过一个由 NEAR Intents 与 ZCash 钱包共同完成的两步流程。

两步式隐私路径：从结算到“入池”

在实践中，用户通常会经历以下两个阶段。

第一步是在 NEAR Intents 上完成原子结算。

假设 Alice 提交了一个意图：“用 100 USDC 换取 ZEC”。某个 solver 接单后，会通过自己的流动性渠道完成兑换，然后把 ZEC 转入 Alice 由 Chain Signatures 推导出的 ZCash 透明地址，例如由 alice.near + "zcash-1" 推导得到的临时地址。整个兑换完成后，这笔转账在 ZCash 链上的记录是公开可见的。与此同时，NEAR 上的 Verifier 合约会根据链上证明来判断 solver 是否履约，只有在对方完成 ZEC 转账的前提下，Alice 对应的 USDC 才会被释放给 solver，实现一种无需信任的原子结算机制。

第二步则是由 Alice 自己在 ZCash 钱包中发起“入池”操作。

她可以在 Zashi 等钱包中，从那个临时透明地址发起一笔标准的 z_sendmany 交易，将资金转入长期使用的受保护地址（z-address）。在这笔交易确认后，她的 ZEC 余额就正式转移到 shielded pool 中。链上可见的信息仅限于有一部分资产被 shield 了，原始兑换交易与她长期地址之间的关联在密码学层面被切断，从而完成隐私保护。

这种双步骤设计，一方面保持了 NEAR Intents 在跨链结算上的无托管与可验证性，另一方面也尽可能利用了 ZCash 现有的隐私基础设施，使二者在各自协议不做根本修改的前提下实现较高程度的协同。

NEAR Intents：如何编排跨链的原子执行

在整个系统中，Chain Signatures 负责提供“可以在多链上安全签名”的底层能力，但真正负责跨链交换逻辑编排的，是 NEAR Intents 架构本身。

在逻辑上，可以将其拆分为三个层次：

第一层是用户与应用层。

用户通过钱包或 dApp 提交自己的意图，表达的是“希望达成什么结果”，而不是“希望通过哪条路径、在哪个 DEX 或哪个桥上完成”。这种抽象极大减轻了用户对底层细节的关注。

第二层是 solver 网络。

这是一个由多家做市方、流动性提供者组成的竞争性市场，它们从去中心化交易所、中心化交易所以及场外交易渠道汇聚流动性，并对用户意图进行竞价。谁能够提供更优的价格、更快的执行，谁就更容易在竞争中胜出。

第三层是 Verifier 合约。

它部署在 NEAR 链上，承担着“无需信任托管与原子结算”的角色。通过 NEP-245 所支持的条件执行机制，Verifier 可以确保在跨链交换中，要么双方的义务都被完全履行，要么整个交易回滚，任一方都不会单方面承担风险。

以一个具体示例来说明：

当 Alice 提交“用 Arbitrum 上的 100 USDC 换取 ZEC”这一意图后，多名 solver 会对该意图进行报价与响应。最终胜出的 solver 将负责在 ZCash 链上将 ZEC 打到 Alice 的透明地址，并向 Verifier 合约提交相应的证明。Verifier 验证通过后，才会将 Arbitrum 上锁定的 100 USDC 释放给该 solver。之后，Alice 可以根据自己的隐私需求，在 ZCash 钱包中完成从透明地址到受保护地址的迁移。

从公开数据来看，NEAR Intents 已经处理了超过 18 亿美元的累计成交量，月活用户数超过二十三万，过去 30 天的成交量占历史总量的比重已经接近一半，整体增长趋势更接近“加速上升的曲线”，而非缓慢线性增长。

现实中的取舍：安全性与体验的平衡

从解决问题的角度来看，Chain Signatures 与 NEAR Intents 联合带来的优势非常明显。

首先，资产始终停留在各自的原生链上，系统中不存在一个将多条链资产集中托管的“跨链金库”，因此也就不存在类似传统跨链桥那样集中的单点失败风险。

其次，用户可以直接使用原生资产进行交易，无需依赖包装代币，自然也就不存在包装代币的赎回风险或流动性折价问题。

再次，整个签名过程基于 MPC 协议，用户从头到尾保有对自己账户的控制权，而不是将资产托付给第三方托管机构或跨链桥合约。

最后，通过 Verifier 合约实现的条件执行，使得跨链交换具备类似原子交换的安全属性，极大降低了对手方违约的风险。

与这些优点相对应，当前架构也存在一些现实局限。

对 ZCash 用户而言，隐私目前仍然是一个“分两步实现”的过程，用户需要在 NEAR Intents 完成交换后，再自己将资产从透明地址迁移到受保护地址。这意味着结算阶段那笔 ZEC 转账在链上是公开可见的，也要求用户对 t-address 与 z-address 的差别有一定理解。另一方面，由于 Chain Signatures 尚不具备生成 ZCash zk-SNARK 证明的能力，它暂时无法直接支持从 NEAR 一键完成到 z-address 的全链路隐私操作。

总体而言，与传统跨链桥相比，这一方案在系统性安全上具有显著优势，因为它避免了大额集中托管带来的巨大攻击面；与完全中心化的交易平台相比，它在体验上仍然略显不够“无感”，但在信任模型和可验证性上处于完全不同的维度。隐私模型也保持了坦诚：用户最终可以获得强隐私保护，但过程中依然存在一个公开且可审计的中间阶段。

面向未来的演进空间

从架构设计的角度看，当前的实现并不是终点，而是一个具有扩展能力的起点。

虽然现阶段 Chain Signatures 无法直接生成 ZCash 所需的 zk-SNARK 证明，但从理论上讲，MPC 网络有可能通过扩展来支持更多类型的密码学证明系统。v1.signer 合约中预留的 vote_add_domains 方法，为新增签名域与算法留出了治理与升级空间。如果未来在工程上投入足够多的资源，不排除针对 z-address 的直接支持会以某种形态出现。

在更短期的时间尺度上，钱包层的产品改进可能会更快落地。例如，Zashi 等钱包完全可以在发现某个 t-address 收到资金后，自动弹出提示，引导用户完成“入池”操作，甚至在获得授权的前提下，自动发起 z_sendmany 交易。通过这种方式，当前需要用户手动操作的“两步流程”，在体验上可以被收敛为一个连续的引导式过程，从而显著降低隐私路径的使用门槛。

开发者视角：生产级基础设施，而非实验性原型

需要强调的一点是，Chain Signatures 已经在 NEAR 主网上以生产环境形式运行，它并不是停留在论文或实验室阶段的概念。开发者今天就可以基于它构建多链相关应用。

在实际开发中，调用流程大致如下：

开发者可以通过 near-api-js 获取某个 NEAR 账户实例，然后调用 v1.signer 合约的 sign 方法，传入待签名交易哈希、路径和签名算法版本，得到签名结果后再与具体链上交易组合并广播。相关的 MPC 实现、JavaScript 工具库、多链示例项目以及 Intents Verifier 合约源码，都可以在公开的 GitHub 仓库中找到，方便开发者查阅与集成。

结论：用密码学替代托管信任

从更宏观的视角来看，Chain Signatures 所代表的是一种对跨链互操作性的根本性重构。它并不试图在原有跨链桥模式上“打补丁”，而是直接回到“谁有权签名、谁有权动用资产”这一最核心的问题上，利用密码学与协议协调机制来重建多链协作的基础。

在这一模型中，我们不再把信任交付给集中托管的跨链桥合约，而是交付给经过审计与验证的开源协议实现与成熟的密码学方法。ZCash 集成一方面让我们看到了当前架构在隐私场景中的技术边界，例如透明地址的中转阶段；另一方面也证明了一种“无需托管、无需桥合约”的跨链执行机制已经真正走向生产环境，并在真实资金规模下稳定运行且持续增长。

多链基础设施的未来，或许并不在于打造出一个“完美的桥”，而在于让跨链桥本身从系统结构中逐渐退场。通过像 Chain Signatures 与 NEAR Intents 这样的设计，我们正在向这一目标更近一步。