区块链互操作性第一部分：互操作性问题与桥

区块链是孤立的分布式计算机网络，其中每个节点运行一个确定性程序，该程序产生一致的、可预测的输出。为了保持这种确定性，区块链网络无法访问外部信息，例如现实世界的温度、天气状况或异步 API 调用。虽然这种隔离提供了强大的安全保证和共识属性，但也造成了重大限制。一个关键的缺点是两个区块链无法本地相互通信，这被称为互操作性问题。

随着区块链生态系统发展到包含数百个网络（每个网络都具有独特的功能、资产和社区），跨链转移价值和数据的能力不足已成为一个主要瓶颈。解决区块链互操作性对于创建一个真正连接的去中心化生态系统至关重要，在该生态系统中，无论用户身处哪个链，都可以无缝地与应用程序和资产进行交互。

跨链通信用例

桥解决了区块链碎片化带来的实际问题。用户在一个链上持有资产，但需要在另一个链上使用它们，以访问特定的应用程序、降低费用或进入不同的流动性池。

访问不同链上的 DeFi 协议

用户在 Ethereum 上持有 USDC，但想使用 Solana 上提供更高收益的借贷协议。如果没有桥，他们需要将 USDC 出售为法币，购买 SOL，然后在 Solana 上重新购买 USDC，支付两次交易所费用和滑点。通过像 Wormhole 或 deBridge 这样的桥，他们可以在一笔交易中将 USDC 直接从 Ethereum 转移到 Solana，只需支付桥费用和 gas 成本。

通过 Layer 2 迁移优化 Gas 费用

在网络拥堵期间，Ethereum 主网 gas 费用可能达到每次交易 50-100 美元。用户将 ETH 或 ERC-20 代币桥接到 Layer 2 网络，如 Arbitrum 或 Optimism，在那里交易成本降至 0.10-1.00 美元。像 Hop Protocol 和 Stargate 这样的桥专门在 Ethereum 及其 rollup 之间转移资产，让用户保持相同的资产，同时将成本降低 99%。

跨链收益耕作和流动性提供

DeFi 用户在不同的链上追逐收益。流动性提供者可能会在 Uniswap (Ethereum) 上存入 USDC-ETH 流动性，然后将这些 LP 代币或底层资产桥接到 Trader Joe (Avalanche) 上提供流动性，以在激励转移时提供流动性。这不仅需要支持简单代币的桥，还需要支持包装资产和合成表示的桥。

生态系统之间 NFT 转移

NFT 收藏家和交易者在链之间桥接 NFT，以访问不同的市场或避免高 gas 费用。在 Ethereum 上铸造的 NFT 可能会桥接到 Polygon 以在费用较低的市场出售，或者移动到 Solana 以参与链特定的游戏或元宇宙项目。像 Wormhole Portal 这样的桥支持 NFT 桥接以及同质化代币。

多链 dApp 交互

一些应用程序同时在多个链上运行。用户可能会在 Ethereum 上存入抵押品，在 Arbitrum 上获得贷款，并使用这些资金在 Solana DEX 上进行交易，所有这些都在同一协议中进行。这需要消息传递桥，该桥不仅可以在链之间传递代币，还可以传递任意数据和合约调用。

流动性统一和套利

交易者使用桥来利用链之间的价格差异。如果 ETH 在 Ethereum 上的交易价格为 3000 美元，但在 Avalanche 上的交易价格为 3020 美元，则套利者将 ETH 桥接到 Avalanche，将其出售，将收益桥接回，并扣除费用后的差额。这种套利活动有助于统 一跨碎片化流动性池的价格。

访问链特定功能

不同的区块链具有独特的功能。Solana 为 DEX 交易提供高吞吐量。Ethereum 拥有最深入的 DeFi 生态系统。Polygon 提供廉价的 NFT 铸造。用户将资产桥接到当时提供他们需要的特定功能的任何链，然后在完成后桥接回来。

---

互操作性问题

区块链无法本地读取其他区块链的状态。这种隔离源于一个基本要求，即区块链网络中的每个节点都必须通过执行相同的确定性程序来独立验证所有状态转换。当节点处理交易时，它必须产生与每个其他诚实节点相同的结果。这就是共识的工作方式。

考虑一下当 Ethereum 上的智能合约需要验证 Solana 上是否发生了交易时会发生什么。Ethereum 虚拟机没有查询 Solana 状态的机制。即使它可以进行这样的查询，由于网络延迟、Solana 链重组或节点可用性，不同的 Ethereum 节点也可能在不同的时间收到不同的响应。这种不确定性将打破共识。节点会对合约的状态产生分歧，从而使区块链无法使用。

这个问题类似于预言机问题。正如区块链无法直接访问链下数据（如股票价格或天气信息）一样，它们也无法访问其他链的状态。两者都需要外部系统以保持确定性和安全性的方式将信息引入链上。

为什么状态隔离是根本

区块链共识取决于状态隔离。当 Ethereum 验证者处理区块 N 时，他们会针对状态 N-1 按顺序执行每笔交易，以生成状态 N。此计算必须是确定性的。给定相同的输入状态和交易，每个验证者都必须计算出相同的输出状态。

引入对外部区块链状态的依赖会破坏此模型。如果智能合约可以调用 getCurrentBlockHashOnSolana()，则不同的验证者可能会得到不同的答案。在稍有不同的时间运行的验证者会看到不同的 Solana 区块。与 Solana 节点网络连接不良的验证者可能会获得过时的数据或超时。由此产生的状态分歧将阻止验证者同意规范链。

此约束甚至适用于从其他链读取历史状态。虽然历史数据是不可变的，但区块链本质上并不相互信任。Ethereum 节点不运行 Solana 客户端，也无法验证 Solana 的共识规则。接受跨链状态需要信任关于该状态的外部声明，或者实现可以验证其他链状态的加密证明的验证逻辑。

信任问题

解决互操作性意味着解决信任问题。当用户锁定 Ethereum 上的 100 USDC 并期望在 Solana 上收到包装的 USDC 时，Solana 合约必须以某种方式验证 Ethereum 锁定是否实际发生。此验证不能依赖于 Solana 节点直接查询 Ethereum。这将导致上述不确定性问题。

相反，互操作性解决方案引入了观察一个链并将信息中继到另一个链的中间人。这些中间人可能是：

• 监控两个链的中心化服务器
• 签署关于跨链事件的 attestation 的验证者委员会
• 作为智能合约实现的轻客户端，可以验证其他链状态的证明

每种方法都涉及信任假设。中心化 relayer 可以通过谎报跨链事件来窃取资金。验证者委员会可以勾结。轻客户端实现可能存在错误，或者可能无法验证源链的完整安全性。

核心挑战在于 Chain A 无法以与验证自身状态相同的安全保证来验证 Chain B 的状态。这种基本限制意味着所有桥设计都在信任假设、资本效率和延迟之间进行权衡。

---

区块链桥的通用架构

区块链桥由三个组件组成，这些组件协同工作以跨链中继状态和转移资产：源链上的智能合约、目标链上的智能合约，以及连接它们的链下基础设施。

源链智能合约

源链合约处理触发跨链操作的初始操作。对于代币桥，这通常意味着锁定或销毁代币。对于消息传递桥，这意味着发出编码跨链消息的事件。

锁定和铸造桥在源链上使用 vault 合约，该合约持有存入的代币。当用户存入 100 USDC 时，合约会锁定这些代币并发出包含以下内容的事件：

• 用户的地址
• 目标链标识符
• 目标链上的接收者地址
• 代币类型和数量
• 唯一的交易 nonce

锁定合约必须防止双重支付。一旦代币被锁定以进行跨链转移，它们就无法在源链上提取，直到反向桥操作释放它们为止。这需要跟踪哪些存款已被处理并防止重放攻击，即相同存款事件被多次处理。

销毁和铸造桥销毁源链上的代币，而不是锁定它们。这种方法适用于包装资产（最初由桥本身铸造的代币）。当将包装的 Ethereum (WETH) 从 Polygon 桥接回 Ethereum 时，Polygon 合约会销毁 WETH 代币，因为它们是合成表示。然后，目标链释放原生 ETH 或铸造等效代币。

消息传递桥发出包含任意 calldata 而不仅仅是代币转账信息的事件。这些桥支持跨链合约调用。用户可能会触发 Chain A 上的一个函数，该函数对 Chain B 上的函数调用参数进行编码。源合约验证消息格式并发出一个事件，链下 relayer 将观察该事件。

目标链智能合约

目标链合约接收事件发生在源链上的证明，并执行相应的操作：铸造代币、释放锁定的资金或执行合约调用。

验证逻辑构成了目标合约的核心。他们必须回答：此事件是否确实发生在源链上？验证方法取决于桥的安全模型。

轻客户端桥通过维护源链区块头的视图来实现验证。当 relayer 提交存款证明时，合约会检查：

1. 区块头是源链规范历史的一部分
2. 该事件包含在该区块的交易收据中
3. Merkle 证明正确地将事件链接到区块的 receipt root

这要求目标合约跟踪源链区块头并验证共识规则。对于 Ethereum，这意味着验证来自验证者集合的签名。对于工作量证明链，这意味着检查区块头是否构成具有足够累积难度的有效链。

像 Wormhole 这样的多签桥使用更简单的验证模型。一组链下桥验证者节点观察源链事件并签署 attestation。目标合约检查是否有足够的桥验证者（quorum 阈值，如 2/3）签署了 attestation。这用去中心化换取了简单性，合约不需要理解源链共识，但安全性完全取决于验证者委员会的诚实。并且这些多签桥的验证比基于共识的桥更便宜。

代币铸造和释放在验证成功后发生。锁定和铸造桥铸造包装代币，这些代币代表锁定的源链资产。这些包装代币与锁定的资金 1:1 跟踪。所有目标链上的包装代币的总供应量不应超过源链上的锁定资金。目标合约通过仅在收到有效锁定存款证明时才进行铸造来维护此不变性。

链下组件

链下基础设施通过观察一个链上的事件并将证明提交给另一个链来连接源链和目标链。这包括 relayer、验证者、监视者和支持系统。

Relayer 监控源链事件并将证明提交给目标链。Relayer 运行两个链的完整节点（或连接到 RPC），监视与桥相关的事件，构建有效性证明，并广播包含这些证明的目标链交易。

对于轻客户端桥，relayer 提交来自源链的区块头，以使目标合约的视图保持最新。当用户发起转移时，他们还会提交特定事件的 Merkle 证明。Relayer 不需要被信任，因为目标合约以加密方式验证所有证明。Relayer 因成功提交证明而获得费用，从而激励他们维护基础设施。

对于验证者委员会桥，relayer 通常也是验证者。他们观察源链事件，签署 attestation，从其他验证者那里收集签名，并将聚合的签名提交给目标链。与轻客户端 relayer 不同，这些验证者必须受到信任，因为目标链不验证源链共识。

委员会型桥中的验证者将资本作为抵押品进行 staking。如果他们签署欺诈性证明（声称发生了实际上没有发生的事件），他们可能会被 slashing。这需要一种挑战机制，任何人都可以提交欺诈证明，表明验证者签署了无效的证明。挑战期会引入延迟。在挑战窗口关闭之前，转移不是最终的，通常为 10 分钟到几个小时。

监视者监控无效的跨链消息并提交欺诈证明。在乐观桥设计中，relayer 可以提交证明而无需立即验证，但监视者可以在争议窗口期间对其提出质疑。如果挑战成功，relayer 将失去他们的 bond 并且无效消息不会执行。这种模式通过仅在出现争议时才检查证明来降低链上验证成本。

API 和索引器为用户和应用程序提供基础设施来跟踪转移状态。当用户桥接代币时，他们需要知道转移何时完成。索引器监视两个链，跟踪桥交易的生命周期（发起、验证、执行、完成），并通过 REST API 或 websockets 提供状态。这些是便利服务。用户可以直接监控链，但索引器会聚合数据并提供更好的 UX。

一般来说，以上三个是大多数桥协议中存在的唯一组件，它们可能被称为不同的名称，但最终源智能合约会在用户发起桥请求时发出一个事件，链下组件将获取事件信息和必要的证明来证明该事件实际上存在于源链上，然后将此信息传递给目标链智能合约。目标智能合约将验证这些证明并根据验证状态执行后续操作。

---

区块链桥的类型

互操作性问题由桥来解决，但是桥如何解决这些问题为我们带来了桥的类型。有多种类型的桥，每种桥都以不同的方法、不同的安全模型和不同的架构来解决相同的问题。每种类型的桥接都有其自身的优点和缺点。例如，如果一个桥试图在几秒钟内完成桥接请求，那么它的局限性可能是乐观的安全模型。本节将解释值得注意的桥类型、每种桥的核心原则以及上述讨论的三个通用组件如何针对每种类型进行更改。

无需信任的桥

无需信任的桥（也称为基于共识或轻客户端桥）通过在目标链上重新计算源链的共识协议来验证跨链消息。目标链智能合约不信任外部验证者或预言机，而是直接验证加密证明：根据该链的共识规则，特定事件发生在源链上。安全假设与底层链的安全假设相匹配。除了信任源链和目标链共识机制之外，不需要额外的信任。示例包括 HyperBridge、SupraNova、Rainbow Bridge 和各种 zkBridge 实现。

考虑一个在 Ethereum 和 Binance 之间进行跨链消息传输的无需信任的桥。每当用户通过调用源桥智能合约上的桥函数（例如，sendMessageToBinance()）发起桥请求时，桥接工作流程就会开始。成功的源桥交易将发出事件 BridgeEvent()，其中包含用户要发送的消息、必要的信息（如接收者地址）以及桥 relayer 过滤桥事件所需的其他信息，以及目标链 ID 等目标信息。

event BridgeEvent(
    address indexed bridgeContract,
    uint256 indexed toChainId,
    uint256 indexed id,
    address sender,
    address recipient,
    bytes memory message
);
function sendMessageToBinance(address recipient, bytes memory message) public {
    // Basic require checks
    // 基本的要求检查
    emit BridgeEvent(
        address(this),
        BNB_CHAIN_ID,
        id++,
        msg.sender,
        recipient,
        message
    );
}

            SOLIDITY

现在，已发出源桥事件，在查看 relayer 操作之前，请尝试了解如何确定桥事件实际上是在 Ethereum 链上发出的？为了证明这一点，我们必须了解 Ethereum 区块链共识的工作方式以及事件如何在 Ethereum 区块中存储。

事件验证和状态证明

桥需要验证发出 bridge 事件的交易实际上是否存在于源区块链中。为了证明交易存在于区块链中，我们需要获得交易证明，这通常是 merkle 证明，其中桥交易是交易 merkle 树的叶子，树的 merkle 根将是区块的最终交易根。通常，此交易根将存在于区块的区块头中，该区块头最终由链验证者签名。特别是对于 Ethereumm，我们不需要验证此交易证明，因为 etheruem 区块头还将包含收据根，该收据根是从成功的 trransaction 输出收据构建的 merkle 根。这意味着通过验证桥交易的收据证明，我们可以说桥交易存在于源区块链中。但是，对于许多其他在其区块头中不包含收据的链（例如，Aptos、Supra），我们可能还需要验证交易证明。

桥需要验证的不仅仅是交易是否存在，还需要验证是否发出了特定事件或发生了状态更改。Ethereum 通过收据 trie 实现此目的。每个区块头都包含一个收据根，该根提交给所有交易收据，其中包括发出的事件。

为了证明 Ethereum 中发生了桥事件：

1. 交易收据证明：Merkle patricia trie 证明，表明交易收据存在于区块的收据 trie 中
2. 日志包含证明：收据包含具有特定主题和数据的日志（事件）
3. 区块终结性证明：区块头是已完成链的一部分（例如，超出 Ethereum 的 64-slot 完成）

目标合约验证 Merkle 证明结构：

verify(receiptTrieRoot, receiptProof, transactionIndex) → receipt
require(receipt.status == 1) // transaction succeeded
// 交易成功
require(receipt.logs[i].address == SOURCE_BRIDGE_CONTRACT)
require(receipt.logs[i].topics[0] == BRIDGE_EVENT_SIGNATURE)
require(receipt.logs[i].topics[1] == SOURCE_BRIDGE_CONTRACT)
require(receipt.logs[i].topics[2] == BNB_CHAIN_ID)
decode(receipt.logs[i].data) → (sender, recipient, message)

            SOLIDITY

某些协议验证状态证明，其工作方式类似，但证明帐户存储值而不是事件。为了验证一个帐户具有特定的存储槽值：

1. 帐户证明：从状态根到帐户状态的 Merkle patricia 证明
2. 存储证明：从帐户的存储根到特定存储槽的 Merkle patricia 证明

这允许验证任意合约状态（如锁定的代币余额），而无需信任外部证明。

共识验证 & Ethereum 同步委员会

如果没有区块头验证，仅凭交易和事件证明是不够的。Merkle 证明仅证明收据哈希到给定的根，攻击者可以伪造一个假收据，计算其 Merkle 根，并为此伪造的数据生成有效的证明。该证明验证正确，因为 Merkle 证明验证只是哈希计算：给定一个收据和兄弟哈希，任何人都可以计算 hash(receipt) + hash(siblings) = root。如果不验证根是否出现在合法的区块中，目标合约将无法区分真实收据和伪造收据。

区块头验证可以防止这种攻击。验证逻辑必须确认收据根（或交易根）存在于由源链的验证者签名的区块头中。这需要根据源链的共识规则验证区块头签名。

对于区块头验证，目标智能合约应该具有所有签署源链区块头的验证者公钥。并执行共识法定数量的正确签名以成功进行区块头验证。当源是一个像 ethereum 这样的链（其中验证者的总数为约 1M）时，在目标链上存储每个区块头的所有验证者是困难的。幸运的是，Ethereum 解决了这个问题，并在 altair fork upgrade 中引入了辅助共识同步委员会。同步委员会每 256 个 epoch（约 27 小时）随机选择 512 个验证者，他们与主要验证者集合一起证明 ethereum 区块头。但是，同步委员会共识不实现任何 slashing 机制，以在同步委员会参与者拒绝签署区块头时 slashing 他们，这会引入安全问题（有关详细信息，请参见本文的安全模型部分）。因此，在验证区块头时，我们可以验证同步委员会签名（更便宜），而不是验证完整的验证者签名（昂贵）。

目标桥合约存储当前的同步委员会集合（或对其的承诺）并验证区块签名。Ethereum 的同步委员会设计允许轻客户端跟踪每 12 秒签署区块头的 512 个验证者的轮换子集。当 relayer 提交区块头、事件证明时，合约验证：

1. BLS 签名聚合：至少 2/3 的同步委员会签署了标头
2. 必要的标头值有效性：标头值检查（如 slot 号落在当前的同步周期内）
3. 事件证明：Merkle 证明正确地将事件链接到标头的收据根

此外，relayer 必须提交同步委员会验证者集合的切换更改，因为当前的同步委员会验证者集合仅对当前周期（256 个 epoch）有效，并且在下一个周期中将选择一组新的 512 个验证者。这意味着下一个周期发出的所有事件只能使用新的同步委员会公钥进行验证。因此，relayer 还应该检查同步委员会的切换并使用必要的切换证明更新目标桥智能合约上的验证者集合。同样有必要生成同步委员会切换的证明。在 ethereum 的情况下，这些证明只是签名验证，因为下一个周期的新同步委员会将由当前的同步委员会集合签名。因此，验证此签名有助于我们更新新的同步委员会。

此验证链（事件 merkle 证明 -> 区块头中的收据根 -> 标头上的同步委员会签名 -> 同步委员会轮换证明）确立了加密确定性，即事件发生在源链上。不同的共识机制使用不同的证明类型、签名方案和验证者集合大小，但验证逻辑遵循相同的模式：证明事件存在于交易中，证明交易存在于区块中，证明区块已由共识验证者签名。

Relayer 操作和激励

在无需信任的桥中，relayer 的工作非常复杂，因为 relayer 必须生成区块和状态证明。Relayer 必须监听事件，并根据源共识规则获取/生成必要的zkBridges：像 zkSNARK 这样的证明系统可以压缩共识验证。无需在链上验证数百个签名，证明者生成一个 SNARK，证明“我正确地验证了 N 个签名，并且它们满足共识规则。” 无论 N 如何，链上验证者都以恒定时间（约 30 万 gas）检查 SNARK 证明。这大大降低了具有大量验证者的链的成本。

可信/多重签名桥

可信桥（也称为验证者委员会或多重签名桥）通过来自可信任验证者集的证明来验证跨链消息，而不是通过加密共识证明。目标合约不验证源链的链上共识，而是信任桥验证者委员会观察源链事件并签署证明，确认这些事件已发生。安全模型取决于验证者委员会的诚实性，用户必须信任阈值多数（通常为 2/3 或更高）不会串通签署欺诈性证明。

考虑一个在以太坊和币安之间传输消息的可信桥。用户通过调用源桥合约来发起桥请求，该合约发出与非信任桥中相同的 BridgeEvent()：

event BridgeEvent(
    address indexed bridgeContract,
    uint256 indexed toChainId,
    uint256 indexed id,
    address sender,
    address recipient,
    bytes memory message
);

function sendMessageToBinance(address recipient, bytes memory message) public {
    emit BridgeEvent(
        address(this),
        BNB_CHAIN_ID,
        id++,
        msg.sender,
        recipient,
        message
    );
}

            SOLIDITY

架构上的差异在于此事件如何在目标链上得到验证。

证明和签名验证

桥验证者运行源链和目标链的全节点（或连接到 RPC）。当在以太坊上发出 BridgeEvent() 时，每个验证者都会观察该事件，等待足够的确认（以避免重组问题），并签署包含以下内容的证明消息：

attestation = {
    sourceChainId: 1,  // 以太坊
    destChainId: 56,   // 币安
    eventId: 12345,
    sourceContract: 0x...,
    sender: 0x...,
    recipient: 0x...,
    message: 0x...,
    blockNumber: 18500000,
    blockHash: 0x...
}

            DEFAULT

每个验证者都使用其私钥签署此证明：signature = sign(hash(attestation), validatorPrivateKey)。验证者通过点对点 gossip 网络共享签名，或将其直接提交到目标链。

目标桥合约维护当前的验证者集及其公钥。当收集到足够的签名（满足 2/3 或 13/19 验证者等阈值）时，任何一方都可以将证明包提交到目标合约：

struct Attestation {
    uint256 sourceChainId;
    uint256 destChainId;
    uint256 eventId;
    address sourceContract;
    address sender;
    address recipient;
    bytes message;
    uint256 blockNumber;
    bytes32 blockHash;
}

function submitAttestation(
    Attestation calldata att,
    bytes[] calldata signatures
) external {
    require(signatures.length >= threshold, "Insufficient signatures");
    require(!processedEvents[att.eventId], "Already processed");

    bytes32 attHash = keccak256(abi.encode(att));
    uint256 validSigs = 0;

    for (uint i = 0; i < signatures.length; i++) {
        address signer = recoverSigner(attHash, signatures[i]);
        if (isValidator(signer) && !seenSigners[signer]) {
            validSigs++;
            seenSigners[signer] = true;
        }
    }

    require(validSigs >= threshold, "Threshold not met");

    processedEvents[att.eventId] = true;
    // 执行跨链消息
    executeMessage(att.recipient, att.message);
}

            SOLIDITY

验证过程的 gas 成本远低于非信任桥。恢复 ECDSA 签名每次花费约 3,000 gas。对于具有 2/3 阈值（需要 9 个签名）的 13 个验证者集，验证成本约为 27,000 gas 加上存储操作。这与非信任桥中同步委员会 BLS 验证的 300-400k gas 相比。

验证者集管理

桥协议定义了一个验证者集，运营商信任其诚实地进行证明。验证者的选择和管理因协议而异：

许可验证者：桥协议根据声誉、股份或治理投票选择验证者。 Wormhole 使用由 Wormhole DAO 选择的 19 个“Guardian”。 Multichain（以前称为 Anyswap）使用由已知实体运营的联合验证者集。

质押验证者：验证者必须质押抵押品（在桥 token 或原生链 token 中）才能参与。 Axelar 要求验证者质押 AXL token。如果验证者签署欺诈性证明，他们的股份可以通过挑战机制被削减。

轮换验证者集：一些协议定期轮换验证者以降低中心化风险。目标合约必须通过验证当前验证者集是否签署了批准新集的证明来处理验证者集更新：

function updateValidatorSet(
    address[] calldata newValidators,
    bytes[] calldata signatures
) external {
    require(signatures.length >= currentThreshold, "Insufficient signatures");

    bytes32 updateHash = keccak256(abi.encode(newValidators, nextEpoch));
    uint256 validSigs = verifySignatures(updateHash, signatures);

    require(validSigs >= currentThreshold, "Threshold not met");

    // 更新验证者集
    validators = newValidators;
    epoch = nextEpoch;
}

            SOLIDITY

阈值配置平衡了安全性和活跃性。 2/3 阈值（拜占庭容错标准）允许系统容忍多达 1/3 的恶意或离线验证者。像 3/4 或 13/19 这样的更高阈值提高了安全性，但降低了活跃性。必须有更多的验证者保持在线和诚实。

桥验证者操作

与非信任桥中继者相比，桥验证者执行的操作更简单，因为他们不生成共识证明：

事件监控：验证者运行两个链的全节点或连接到 RPC 端点。他们订阅源链上的桥合约事件并监控新的 BridgeEvent() 发出。

确认等待：检测到事件后，验证者会等待确认阈值（例如，以太坊上 64 个区块以实现最终性），以避免签署来自重组区块的事件。这会增加延迟，但可以防止签署无效事件。

证明签名：一旦通过足够的确认，验证者将签署证明消息并通过 P2P gossip 网络将其广播给其他验证者，或将其直接提交到目标链。

中继提交：验证者自己或第三方中继者聚合签名并将证明包提交到目标合约。一些协议通过向提交者支付 gas 退款或少量费用来激励此行为。

验证者的信任模型与非信任中继者根本不同。桥验证者可以通过签署欺诈性证明（声称发生了没有发生的事件）来窃取资金。防止这种情况需要：

削减机制：验证者质押抵押品，如果他们签署可证明的欺诈性证明，这些抵押品将被削减。任何人都可以提交欺诈证明，表明验证者签署了不存在事件的证明。

经济安全：桥中锁定的总价值 (TVL) 不应超过总质押抵押品乘以安全系数。如果 TVL > total_stake，验证者有经济动机串通并窃取资金。

声誉和法律协议：一些桥依赖于验证者的声誉或法律合同，而不是纯粹的加密经济安全。这适用于验证者是具有法律责任的已知实体的联邦桥。

对于不同的桥设计，证明签名和中继提交步骤可能会发生变化。交互式多重签名桥设置将使用 P2P gossip 通道来收集和聚合所有证明，并将它们作为单个交易中继。但在桥节点的非交互式设置中，每个节点将签署其证明并立即提交到目标合约。

延迟和成本优势

与非信任桥相比，可信桥实现了显着更低的延迟和成本：

延迟：在源链确认期（例如，以太坊最终确定为 13 分钟）之后，验证者可以在几秒钟内签署和提交证明。以太坊源的总延迟范围为 13-15 分钟，而非信任桥中相同的最终性等待加上生成共识证明的额外时间。

Gas 成本：目标链验证每次签名花费约 3,000 gas。对于需要 9 个签名的 13 个验证者集：签名验证约 27,000 gas 加上执行开销约 50,000 gas = 总计约 77,000 gas。这与使用同步委员会的非信任桥的 300-400k gas 相比，或完整验证者集验证的数百万 gas 相比。

运营成本：验证者不需要生成复杂的 Merkle 证明或共识证明。运行桥验证者需要两个链的全节点和基本的签名基础设施，每月花费 100-500 美元，而非信任桥更昂贵的证明生成基础设施。

注意：像 Hyperloop 这样的博弈论设计尝试通过在时间窗口内转移的总价值不超过验证者股份来使多重签名桥变为非信任桥。这不会为桥节点串通和执行恶意活动产生经济动机。

基于意图的桥

基于意图的桥将用户目标与执行路径分开。用户表达他们期望的结果（在链 B 上接收 token X），而不是指定如何实现它。solvers（第三方流动性提供商）争夺通过在目标链上预先提供资金来满足这些意图，然后在验证后在源链上要求报销。这种架构颠倒了传统的桥流程：用户不是锁定资金并等待跨链证明，而是立即收到资金，而 solvers 异步处理结算。

来源：由多重证明存储证明驱动的 L2 和以太坊之间基于意图的桥

架构和工作流程

用户将 token 存入源链托管合约并指定他们的意图：

struct Intent {
    address sender;
    address recipient;
    uint256 sourceChainId;
    uint256 destChainId;
    address inputToken;
    address outputToken;
    uint256 inputAmount;
    uint256 minOutputAmount;
    uint256 deadline;
    bytes32 intentId;
}

function submitIntent(Intent calldata intent) external {
    require(msg.sender == intent.sender, "Invalid sender");
    require(block.timestamp <= intent.deadline, "Expired");

    // 将用户资金锁定在托管中
    IERC20(intent.inputToken).transferFrom(
        intent.sender,
        address(this),
        intent.inputAmount
    );

    emit IntentCreated(intent.intentId, intent);
}

            SOLIDITY

Solver 履行和结算

Solvers 监控跨链的意图事件。当 solver 识别出有利可图的意图时，他们使用自己的资金在目标链上执行转移：

// 在目标链上
function fulfillIntent(
    bytes32 intentId,
    address recipient,
    address token,
    uint256 amount
) external {
    require(msg.sender == registeredSolver, "Unauthorized solver");

    // Solver 立即向用户发送资金
    IERC20(token).transferFrom(msg.sender, recipient, amount);

    emit IntentFulfilled(intentId, msg.sender, recipient, amount);
}

            SOLIDITY

在目标链上履行意图后，solver 必须证明履行情况才能在源链上索取托管资金。验证机制因协议而异：

存储证明验证：solver 提交零知识或有效性证明，表明目标链合约发出了 IntentFulfilled 事件。像 Herodotus 或 Axiom 这样的协议生成存储状态更改的证明，允许源链合约验证履行交易是否发生，而无需运行完整的轻客户端。

乐观验证：solver 声称他们履行了意图并提交了证据（交易哈希、区块号）。该声明进入挑战期（通常为 10-30 分钟）。任何观察者都可以通过证明履行没有发生或不符合意图规范来提出异议。如果没有出现异议，solver 将收到托管资金。

原生消息传递：对于 L2 到 L1 的桥，solver 可以使用 L2 的原生消息传递来证明履行情况。这继承了 L2 的安全假设，但增加了延迟（Optimistic Rollups 为 7 天）。

源链结算合约验证证明并释放资金：

function claimEscrow(
    Intent calldata intent,
    bytes calldata proof
) external {
    require(!claimed[intent.intentId], "Already claimed");

    // 验证 solver 是否在目标链上履行了意图
    require(verifyFulfillment(intent, proof), "Invalid proof");

    claimed[intent.intentId] = true;

    // 将资金释放给 solver
    IERC20(intent.inputToken).transfer(msg.sender, intent.inputAmount);
}

            SOLIDITY

延迟和用户体验优势

基于意图的桥在求解器资本效率的代价下优化了面向用户的速度：

用户的即时结算：几秒钟到几分钟内用户即可在目标链上收到资金（与求解器执行交易的速度一样快）。 这消除了非信任桥所需的 13 分钟以太坊最终性等待时间。 用户无需等待共识证明或验证者证明。

求解器的延迟结算：求解器在索取托管资金之前等待证明生成和验证。 使用存储证明，这需要 5-15 分钟。 使用乐观验证，挑战期会增加 10-30 分钟。 使用原生 L2 消息传递，可能需要几天时间。 这种资本锁定意味着求解器必须拥有深厚的流动性或收取更高的费用以弥补机会成本。

gas 成本效率：用户仅在源链上支付 gas（用于存入托管）。 求解器支付目标链 gas 和源链索赔 gas，但可以批量处理多个索赔以分摊成本。 总 gas 成本与非信任桥相似或更低，因为验证是针对每个索赔进行一次，而不是针对每个用户交易。

MEV 保护：求解器承担 MEV 风险。 由于用户指定了最低输出量，并且求解器竞相履行意图，因此用户可以免受会影响直接交换的三明治攻击和抢先交易的侵害。 具有更好 MEV 提取能力的求解器可以提供更好的利率，从而产生竞争压力。

基于意图的桥代表了设计空间中的一个不同点：通过将资本和运营复杂性转移到专门的求解器来优化用户体验和速度。 这使得它们适合需要快速跨链执行的应用程序（DEX 聚合器、跨链交换、游戏），但不太适合用户宁愿不信任求解器流动性和验证机制的高价值转移。

了解更多：这篇文章概述了基于意图的桥接。本系列的第 3 部分将深入介绍基于意图的桥接，包括详细的协议比较、求解器经济学、证明机制和安全注意事项。另请参阅：。

L2 Bridge

L2 桥通过使用共享的以太坊 L1 作为消息传递层，实现不同 Layer 2 网络（Arbitrum 到 Polygon，Optimism 到 zkSync）之间的传输。从 L2-A 到 L2-B 的传输需要源 L2 在 L1 上最终确定一条消息，然后由目标 L2 使用该消息。这种 L2→L1→L2 路径会引入显着的延迟：像 Arbitrum 和 Optimism 这样的 Optimistic Rollups 在 L1 提款最终确定之前会强制执行 7 天的挑战期，而 zkRollups 则需要从几分钟到几小时不等的证明生成和提交延迟。

由于每个 L2 都有独立的最终性要求，因此延迟会加剧。即使是具有更快 L1 结算的 zkRollups 仍然需要等待 L1 区块最终确定（在以太坊上为 13 分钟）以及目标 L2 来处理传入消息。原生 L2→L1→L2 传输的总用户面临延迟范围从 20 分钟（zkRollup 到 zkRollup）到 7 天以上（Optimistic Rollup 到任何 L2）。

像 Hop 这样的协议通过称为 Bonders 的流动性提供商来解决这个问题。 当用户发起传输时，Bonders 会立即在目标 L2 上预付流动性，方法是铸造 hToken（中间包装的 token），用户可以通过自动做市商将其交换为原生 token。 Bonder 锁定抵押品（传输价值的 110%）并等待规范的 L2→L1→L2 消息结算。 在挑战期过去而没有欺诈证明之后，Bonder 解锁他们的抵押品并索取原始用户资金。 这为用户提供了即时结算，同时 Bonders 承担了资本锁定成本。

安全性依赖于密码学证明和经济股份。 L1 消息路径保证传输最终将正确完成。 如果 Bonders 失败或恶意行事，用户仍然可以在等待 L1 最终确定后使用原生桥。 Bonders 必须锁定抵押品，如果他们绑定虚假传输，这些抵押品将被削减。 Bonders 质押的资本越多，系统的安全性就越高。 这种设计为用户提供了快速传输（不到一分钟），同时保持与底层 L1 相同的安全性。

侧链桥

侧链是独立的区块链，它们运行自己的共识机制，与以太坊主网分开。与将状态数据发布到 L1 以确保安全的 Layer 2 rollups 不同，像 Polygon PoS、Gnosis Chain 和 Skale 这样的侧链维护自己的验证者集和区块生成规则。这种独立性允许侧链优化不同的性能特征，例如更快的区块时间、更低的费用、替代共识算法。这也意味着它们不继承以太坊的安全性。

侧链桥使用双向Hook机制在主网和侧链之间传输资产。当用户将 token 从以太坊桥接到侧链时，桥合约在主网上锁定这些 token 并在侧链上铸造等效的 token。反转该过程会烧毁侧链 token 并解锁原始主网 token。该桥在锁定的主网资产和流通的侧链 token 之间保持 1:1 的Hook。

---

区块链桥的类型 - 按用例划分

上面讨论的桥类型按其技术架构和安全模型对协议进行分类。用户通常会遇到按用例组织的桥：桥启用的内容，而不是其工作方式。

消息传递桥

消息传递桥启用了简单的 token 传输之外的任意跨链通信。它们允许一个链上的智能合约调用另一个链上的函数，传递数据和执行指令。这启用了跨链治理、跨链 NFT 操作和多链应用程序逻辑。

示例：LayerZero、Axelar、Wormhole、IBC (Cosmos)、Chainlink CCIP、Hyperlane、HyperBridge、SupraNova。

资产转移桥

资产转移桥专门用于在链之间移动 token。 它们在传输可替代 token 或包装资产时优化速度、成本和流动性。 许多实现在两侧都有流动性池，以实现即时交换，而不是等待跨链验证。

示例：Hop Protocol、Stargate、Synapse、Across Protocol、Connext、Celer cBridge。

应用程序特定桥

应用程序特定桥服务于单个区块链或应用程序生态系统。 它们针对该特定环境进行优化，而不是提供通用桥接。 L2 规范桥属于此类，为特定区块链迁移或生态系统集成构建的桥也是如此。

示例：Polygon PoS 桥、Arbitrum 桥、Optimism 桥、Avalanche 桥、zkSync 桥、Base 桥。

---

安全考虑

桥代表了区块链系统中受攻击最多的攻击面。 最大的加密货币黑客攻击以桥协议为目标（Ronin：6.24 亿美元、Poly Network：6.11 亿美元、Wormhole：3.26 亿美元）。 无论它们是许可的还是无需许可的，链下组件都会产生这种漏洞。 这些组件成为安全模型中最薄弱的环节。

即使是声称除底层链之外不添加信任假设的非信任桥，也面临着基本的安全限制。 非信任的以太坊桥应该仅继承以太坊现有的安全假设。 考虑对以太坊进行 51% 的攻击。 许多人认为这会破坏一切，但即使在多数攻击下，区块链通常也会保持某些属性。 在此类攻击之后，以太坊可能会回滚到正确的状态，从而保留一些安全保证。

如果非信任桥确实没有添加额外的假设，那么它们应该在源链上从 51% 的攻击中幸存下来或恢复。 事实并非如此。 当源链遇到共识失败时，基于该链共识证明构建的桥也会失败。 该桥无法区分合法共识和攻击者控制的共识。 Vitalik Buterin 在此处详细解释了此限制。

安全模型和信任假设

非信任桥

非信任桥继承了两个链的安全属性：

诚实多数假设：源链的共识必须是安全的。 如果 51% 的比特币矿工串通或 2/3 的以太坊验证者串通，他们可以创建从未发生过的事件的欺诈性证明。

最终性要求：目标合约必须仅接受来自最终确定区块的事件。 对于以太坊，这意味着等待最终确认（64 个插槽，约 13 分钟）。 对于像比特币这样的概率最终确认链，这意味着等待足够的确认（例如，100 个区块）。

活跃性：非信任桥中的中继者不能进行任何恶意活动并破坏桥的安全性。 但是，中继者可能会导致活跃性攻击，即所有中继者都脱机并拒绝在目标上提交交易，因为中继者是无需许可的，因此这种攻击是可能的。 但是，通过良好的桥设计激励机制，其中多个中继者竞争以获得每个桥请求的奖励，这可以得到解决。

与可信桥相比，主要优势在于这些假设已经存在。 用户已经信任源链和目标链。 该桥没有添加除相信智能合约代码正确实现验证之外的额外信任要求。

以太坊同步委员会的安全性：同步委员会缺乏削减机制。 未能以同步委员会成员身份签署区块头的验证者除了错过证明奖励外，不会面临任何处罚。 这创建了一个活跃性假设：该桥依赖于至少 2/3 的同步委员会是诚实和在线的。 与因含糊不清或无效证明而面临削减的共识层验证者不同，同步委员会中的拜占庭多数可以签署无效的区块头而不会面临股份削减的风险。 在 Polkadot 论坛中阅读有关同步委员会安全性的更多分析。 总结是，同步委员会的勾结都是极低概率的。 即使有 50% 的完整以太坊验证者集是不诚实的，每天（纪元）尝试一次接管，持续 5 年，即大约 1825 次接管尝试，几乎不可能发生接管。

可信桥

可信桥引入了底层链之外的信任假设：

诚实多数的验证者：该桥假设至少有阈值验证者（例如，2/3）不会串通签署欺诈性证明。 如果此假设被打破，资金可能会被盗，除了削减之外没有追索权（这仅在链上可证明欺诈的情况下才有效）。

验证者活跃性：如果太多验证者离线，则桥会停止。 在 2/3 阈值的情况下，如果超过 1/3 的验证者离线或拒绝签名，则无法处理任何新的跨链消息。

验证者集信任：用户必须信任选择和轮换验证者的机制。 如果选择过程是中心化的或被捕获，则可以添加恶意验证者。

削减有效性：对于质押验证者桥，削减仅在链上可证明欺诈性证明的情况下才有效。 如果验证者只是拒绝签署合法事件（审查），他们通常无法被削减。

关键风险在于验证者集是一个比完整源链和目标链更小的攻击面。 破坏 13-19 个验证者中的 2/3 比攻击以太坊的共识更容易。 这使得可信桥适合于较低价值的转移或验证者具有强大的链下责任的场景，但对于保护数十亿美元的 TVL 来说风险很高。

一些协议尝试通过混合方法来减少信任。 Axelar 将验证者集与二次投票和削减相结合。 Synapse 使用乐观验证，验证者立即证明，但观察者可以在争议期内提出质疑。 这些设计牺牲了一些延迟/成本优势以提高安全性。

基于意图的桥接

基于意图的桥与基于共识或多重签名的桥引入了不同的信任假设：

求解器流动性风险：求解器在收到补偿之前提供资金。 如果验证系统失败或源链遇到长时间停机，求解器的资金将保持锁定状态。 这会产生资本效率问题。 求解器必须跨多个链维护流动性，并且无法立即重复使用资本。

验证机制信任：安全性取决于如何验证履行情况。 存储证明系统继承了源链的安全性（任何人都可以验证链上的证明）。 乐观系统假设至少有一个诚实的观察者监控欺诈行为。 原生消息传递继承了 L2 的信任假设。

审查和活跃性：如果求解器拒绝履行意图（审查）或所有求解器都离线，则桥会停止新的传输。 一些协议实施了回退机制，允许用户在超时后撤回他们的托管资金，但这会增加合法传输的延迟。

求解器中心化：高资本要求和基础设施复杂性创建了进入壁垒。 如果少数求解器占主导地位，他们可能会串通以提取 MEV，审查交易或要求不公平的费用。 协议通过求解器声誉系统，削减不当行为或驱动竞争定价的拍卖机制来解决此问题。

侧链

安全模型完全取决于侧链的共识和桥验证者。 如果侧链的验证者集受到破坏或桥合约存在漏洞，则资金可能会被盗，而无法追索以太坊的安全性。 用户信任侧链的独立共识，而不是依赖以太坊验证者或以太坊状态的密码学证明。 这使得侧链适合于优先考虑吞吐量和低成本而非最大安全性的应用程序，但对于高价值资产存储来说风险很高。

什么使桥梁良好？

没有一种桥梁设计最适合所有情况。 最佳选择取决于要桥接的特定链和应用程序要求。

非信任桥通过继承底层链的安全性而没有额外的信任假设来提供最强的安全性。 当源链具有快速的最终性（zkRollups 为几分钟，而不是 Optimistic Rollups 为 7 天），共识证明易于验证（同步委员会中的 512 个验证者与 1M 个完整的验证者集相比），目标链 gas 成本足够低以使证明验证经济，并且无需许可的中继者可以在合理的费用结构下有利可图地运营时，它们效果最佳。 当验证成本太高或最终确定需要太长时间时，非信任桥变得不切实际。 在昂贵的链上验证完整的共识证明每天可能花费数百万 gas。 等待 Optimistic Rollup 最终确定 7 天会导致不良的用户体验。

当源链最终确定缓慢或验证成本高昂时，用户将速度置于最大安全性之上，应用程序处理可以接受信任权衡的较低价值转移，并且存在强大的监控和争议系统可以捕获不当行为时，可信或基于意图的桥可以提供更好的延迟和更低的成本。 可信桥需要良好的激励设计才能保持安全。 削减机制应惩罚签署欺诈性证明的验证者。 总锁定价值不应超过验证者抵押品。 经济激励必须使串通不盈利。 对于多重签名桥，将时间窗口内转移的价值限制为小于总验证者股份，这可以消除串通的盈利动机。

良好的桥梁设计可以在特定用例中平衡安全性、速度和成本。 高价值资产转移证明了非信任桥的成本和延迟是合理的。 快速跨链交换和游戏应用程序受益于具有即时结算的基于意图的桥。 应用程序特定的 L2 桥可以针对其特定链和用例进行优化。 最佳桥是根据可接受的成本和延迟权衡来满足你的安全要求的桥。

• 原文链接： themj0ln1r.github.io/wri...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～