Union：用零知识证明和 IBC 打通 Cosmos 与 EVM 的跨链层

它解决什么问题，给谁用

跨链通信的传统方案依赖中继器、多签或预言机，这些都会引入信任假设。Union 想用零知识证明来消除这些中间人。它验证的是目标链的共识，而不是某个第三方提供的签名。这个协议面向的是需要在 Cosmos 生态和 EVM 生态之间转移资产、NFT 或调用合约的开发者。比如你有一个 Cosmos 链上的应用，想把流动性送到以太坊，或者反过来。Union 的定位是基础设施层，不是应用本身。它提供通用消息传递和资产转移能力，具体业务逻辑由上层合约决定。

核心机制：共识验证而不是信任验证

Union 的文档强调它是基于 Consensus Verification 的，也就是直接验证另一条链的共识输出。它用 CometBLS 作为 Union 节点实现的共识引擎，这个名字暗示它把 BLS 签名聚合进了 CometBFT 风格的共识。零知识证明部分由 galoisd 负责，这是用 Go 和 Gnark 库写的证明器。它的工作方式是：galoisd 为某个区块的共识生成一个零知识证明，然后这个证明在目标链上被验证。这意味着你不需要信任任何中继者，因为证明本身保证了共识的有效性。voyager 是跨生态的中继器，用 Rust 写，负责把证明和消息从一个链搬到另一个链。它被描述为模块化和高性能，但具体性能数据在 README 里没有给出。

组件拆解：一个仓库，七种语言

Union 不是单一程序，而是一组组件的集合。uniond 是节点实现，用 Go 写，基于 CometBLS。galoisd 是证明器，也是 Go，但用 Gnark 做零知识电路。voyager 是 Rust 写的重器，负责在链间搬运消息。CosmWasm 合约栈和 light-clients 都是 Rust，用于 Cosmos 链上的智能合约和轻客户端。EVM 合约栈是 Solidity，部署在以太坊、Arbitrum 等链上。还有 unionvisor，一个用于生产环境的节点监督器，以及 drip 水龙头。前端有 app 和 site，分别是 Svelte 和 Astro 写的。这种多语言混合的好处是每个组件可以用最适合的语言，坏处是维护成本高，你需要同时懂 Go、Rust、Solidity 和 TypeScript 才能全面贡献。

快速启动：Nix 是唯一入口

Union 的快速启动方式很特别，它强制你用 Nix。README 给出的安装命令是 curl 脚本安装 Determinate Systems 的 Nix，然后进入开发环境。构建组件用 nix build .#uniond -L，或者 .#voyager，.#app。查看所有包用 nix flake show。开发环境用 nix develop，它会把 cargo、rustc、node、go 等依赖都装好，但不会影响系统其他部分。提交前要运行 nix run .#pre-commit -L 来格式化代码和检查拼写。这个流程对 Nix 用户很友好，但对不熟悉 Nix 的人来说是个陡峭的学习曲线。而且 README 明确说某些组件只能在 Linux 上构建，macOS 用户需要用 OrbStack 开一个 NixOS 虚拟机。

支持的链和标识符

README 列出了一张支持链的表格，包括主网和测试网。Ethereum 主网是 ethereum.1，测试网有 ethereum.11155111 和 ethereum.560048。Arbitrum 是 arbitrum.42161，Base 是 base.8453，Berachain 是 berachain.80094。Cosmos 生态有 Osmosis、Sei、Xion。Union 自己的主网是 union.union-1。这个标识符格式看起来是 链名.链ID，但具体含义文档里没有展开。要注意的是，Sui 只有测试网 sui.4c78adac，没有主网。这意味着如果你要部署到 Sui 主网，目前不行。另外，每个链的标识符必须准确匹配，否则连接会失败。

局限性和风险点

一个明显的局限是依赖 galoisd 证明器。零知识证明生成通常计算密集，虽然 README 没有给出具体资源需求，但你可以预期运行一个证明器节点需要相当的算力。另一个风险是 CometBLS 不是标准 CometBFT，它可能不兼容所有 Cosmos 链的共识。如果目标链的共识算法不匹配，Union 就无法验证它。还有，README 提到合约升级和连接配置都由去中心化治理控制，这意味着你无法自由调整连接参数，必须等待治理投票通过。对于快速迭代的团队，这可能是个障碍。最后，Nix 的强制使用可能让一些 CI 环境变得复杂，尤其是那些没有 Nix 缓存的私有 CI。

替代方案：IBC 原生 vs 零知识证明

如果你在 Cosmos 生态内部做跨链，标准 IBC 本身就是一个替代方案。IBC 不需要零知识证明，它依赖轻客户端和共识状态更新，但需要双方链都实现 IBC 协议。Union 的优势在于它能连接 EVM 链，这些链原生不支持 IBC。另一个替代是 LayerZero 或 Axelar 这类通用消息传递协议，它们通常使用预言机或多签来验证消息，信任模型不同。Union 的零知识证明路线在理论上更去信任，但代价是计算开销和实现复杂度。如果你的目标链都在 Cosmos 内，标准 IBC 可能更简单，不需要额外维护一个证明器。

维护和升级成本

Union 的仓库最近有活跃的发布，比如 uniond v1.3.0-rc2 和 bundle-union-testnet-10 的多个候选版本。这些预发布版本表明协议还在快速迭代，API 可能不稳定。使用测试网版本意味着你需要跟上发布节奏，否则可能被弃用。许可证是 Apache-2.0，这对商业使用友好，允许修改和再分发，但要注意它不提供专利保护，也没有 Copyleft 要求。升级成本主要在 galoisd 和 voyager，因为这两个组件涉及证明生成和中继逻辑，任何共识验证算法的变更都可能要求你重新部署证明器。文档建议查看 docs.union.build，但 README 本身没有提供升级路径的细节。

编辑结论

Union 适合那些需要跨 Cosmos 和 EVM 生态传递资产或消息、且不愿依赖多签或预言机的团队。它用零知识证明和 IBC 组合，把信任成本压到共识层。但如果你只做单链应用，或者团队没有 Rust 和 Nix 经验，它的上手门槛会很高。部署前先确认目标链是否在支持列表里，测试网和主网标识符要逐一核对。还要留意 galoisd 证明器的资源消耗，以及 CometBLS 是否被你的目标链共识接受。它的治理机制仍在演化，合约升级和连接配置都由链上治理控制，这意味着你无法单方面修改连接参数。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes