跨链消息传递与共享流动性:LayerZero v2、Hyperlane 和 IBC 3.0 的安全模型
像 LayerZero v2、Hyperlane 和 IBC 3.0 这样的互操作性协议,正成为多链 DeFi 生态系统的关键基础设施。它们各自采用不同的方法来实现跨链消息传递和共享流动性,并拥有独特的安全模型:
- LayerZero v2 – 使用去中心化验证者网络 (DVN) 的证明聚合模型
- Hyperlane – 通常使用多签验证者委员会的模块化框架
- IBC 3.0 – 在 Cosmos 生态系统中采用信任最小化中继器的轻客户端协议
本报告将分析每种协议的安全机制,比较轻客户端、多重签名和证明聚合的优缺点,并探讨它们对 DeFi 可组合性和流动性的影响。我们还将审视当前的实现方式、威胁模型和采用水平,最后展望这些设计选择如何影响多链 DeFi 的长期可行性。
领先跨链协议的安全机制
LayerZero v2:通过去中心化验证者网络 (DVN) 实现证明聚合
LayerZero v2 是一个全链消息传递协议,强调模块化、应用可配置的安全层。其核心思想是让应用程序通过一个或多个独立的去中心化验证者网络 (DVN) 来保护消息,这些网络共同为跨链消息提供证明。在 LayerZero 的证明聚合模型中,每个 DVN 本质上是一组验证者,可以独立验证消息(例如,通过检查区块证明或签名)。应用程序可以要求来自多个 DVN 的聚合证明,才能接受一条消息,从而形成一个阈值“安全堆栈”。
默认情况下,LayerZero 提供了一些开箱即用的 DVN——例如,一个由 LayerZero Labs 运营的 DVN,它使用 2/3 多签验证;以及一个由 Google Cloud 运行的 DVN。但关键是,开发者可以混合搭配 DVN:例如,有人可能要求一个 “1 of 3 of 5” 的配置,这意味着一个特定的 DVN 必须签名,外加其他 5 个 DVN 中的任意 2 个。这种灵活性允许将不同的验证方法(轻客户端、zk 证明、预言机等)组合成一个聚合证明。实际上,LayerZero v2 将 v1 的超轻节点模型(依赖于一个中继器 + 一个预言机)推广为跨 DVN 的 X-of-Y-of-N 多签聚合。应用程序在每条链上的 LayerZero 端点合约只有在所需 DVN 群体为该消息写入有效证明后,才会传递消息。
安全特性: LayerZero 的方法是信任最小化的,只要所需集合中至少有一个 DVN 是诚实的(或者一个 zk 证明是有效的,等等)。通过让应用程序将自己的 DVN 作为必需的签名者,LayerZero 甚至允许应用程序否决任何未经其团队验证者批准的消息。这可以显著增强安全性(以中心化为代价),确保任何跨链消息在没有应用程序签名的情况下都无法执行。另一方面,开发者可以选择一个更去中心化的 DVN 群体(例如,15 个独立网络中的 5 个)以获得更强的信任分布。LayerZero 称之为“应用拥有的安全”:每个应用通过配置其 DVN 来选择安全性、成本和性能之间的权衡。所有 DVN 的证明最终都由不可变的 LayerZero 端点合约在链上验证,从而保留了一个无需许可的传输层。缺点是,安全性仅与所选的 DVN 一样强大——如果配置的 DVN 相互勾结或被攻破,它们可能会批准欺诈性的跨链消息。因此,每个应用程序都有责任选择稳健的 DVN,否则将面临较弱的安全风险。
Hyperlane:采用模块化 ISM 的多签验证者模型
Hyperlane 是一个互操作性框架,其核心是一个链上的链间安全模块 (ISM),该模块在消息传递到目标链之前对其进行验证。在最简单(也是默认)的配置中,Hyperlane 的 ISM 使用一个多重签名验证者集:一个由链下验证者组成的委员会对源链发出的证明(通常是所有出站消息的默克尔根)进行签名,并且在目标链 上需要达到一个签名阈值。换句话说,Hyperlane 依赖于一个需许可的验证者群体来确认“消息 X 确实在链 A 上发出”,这类似于区块链的共识,但在桥接层面。例如,Wormhole 使用 19 个守护者和 13/19 的多签机制——Hyperlane 的方法在精神上是相似的(尽管 Hyperlane 与 Wormhole 不同)。
一个关键特性是,Hyperlane 在协议层面没有一个单一的内嵌验证者集。相反,任何人都可以运行验证者,不同的应用程序可以部署具有不同验证者列表和阈值的 ISM 合约。Hyperlane 协议提供了默认的 ISM 部署(带有一组由团队引导的验证者),但开发者可以自由地为他们的应用自定义验证者集甚至安全模型。事实上,Hyperlane 支持多种类型的 ISM,包括一个结合多种验证方法的聚合 ISM,以及一个根据消息参数选择 ISM 的路由 ISM。例如,一个应用可以要求 Hyperlane 多签和一个外部桥(如 Wormhole 或 Axelar)都进行签名——通过冗余实现更高的安全标准。
安全特性: Hyperlane 多签模型的基础安全性来自于其大多数验证者的诚实。如果达到阈值(例如,8 个中的 5 个)的验证者相互勾结,他们可以签署一条欺诈性消息,因此信任假设大约是 N-of-M 多签信任。Hyperlane 正在通过与 EigenLayer 再质押集成来解决这一风险,创建了一个经济安全模块 (ESM),要求验证者投入可被罚没的质押 ETH 以惩罚不当行为。这个“主动验证服务 (AVS)”意味着,如果一个 Hyperlane 验证者签署了一条无效消息(即实际上不在源链历史中的消息),任何人都可以在以太坊上提交证明来罚没该验证者的质押。这通过经济上抑制欺诈行为,显著增强了安全模型——Hyperlane 的跨链消息变得由以太坊的经济权重保障,而不仅仅是验证者的社会声誉。然而,一个权衡是,依赖以太坊进行罚没会引入对以太坊活性的依赖,并假设欺诈证明能够及时提交。在活性方面,Hyperlane 警告说,如果没有足够的验证者在线以满足阈值,消息传递可能会停止。该协议通过允许灵活的阈值配置来缓解这个问题——例如,使用更大的验证者集,以便偶尔的停机不会使网络停滞。总的来说,Hyperlane 的模块化多签方法提供了灵活性和可升级性(应用选择自己的安全模型或组合多个来源),但代价是增加了对验证者集的信任。这是一个比真正的轻客户端更弱的信任模型,但随着最近的创新(如再质押抵押品和罚没),它在实践中可以接近类似的安全保证,同时更容易在多条链上部署。
IBC 3.0:采用信任最小化中继器的轻客户端
在 Cosmos 生态系统中广泛使用的链间通信协议 (IBC) 采取了一种根本不同的方法:它使用链上轻客户端来验证跨链状态,而不是引入一个新的验证者集。在 IBC 中,每对链都建立一个连接,其中链 B 持有链 A 的轻客户端(反之亦然)。这个轻客户端本质上是另一条链共识的简化副本(例如,跟踪验证者集签名或区块哈希)。当链 A 向链 B 发送消息(一个 IBC 数据包)时,一个中继器(一个链下参与者)将一个证明(数据包的默克尔证明和最新的区块头)带到链 B。然后,链 B 的 IBC 模块使用链上轻客户端来验证该证明在链 A 的共识规则下是否有效。如果证明通过(即数据包已在 A 链的最终区块中提交),消息将被接受并传递到 B 链的目标模块。本质上,链 B 直接信任链 A 的共识,而不是一个中介——这就是为什么 IBC 通常被称为信任最小化的互操作性。
IBC 3.0 指的是该协议的最新演进(大约在 2025 年),它引入了性能和功能升级:用于降低延迟的并行中继、用于特定用例的自定义通道类型,以及用于读取远程状态的链间查询。值得注意的是,这些都没有改变核心的轻客户端安全模型——它们增强了速度和功能。例如,并行中继意味着多个中继器可以同时传递数据包以避免瓶颈,从而在不牺牲安全性的情况下提高活性。链间查询 (ICQ) 允许链 A 上的合约向链 B 请求数据(并附带证明),然后由 A 链上 B 的轻客户端进行验证。这扩展了 IBC 的能力,从代币转移到更通用的跨链数据访问,仍然以经过验证的轻客户端证明为基础。
安全特性: IBC 的安全保证与源链的完整性一样强大。如果链 A 拥有诚实的多数(或配置的共识阈值),并且链 B 上 A 的轻客户端是最新的,那么任何被接受的数据包必须来自 A 链上的一个有效区块。无需信任任何桥接验证者或预言机——唯一的信任假设是两条链的原生共识和一些参数,如轻客户端的信任期(超过该期限旧的区块头会过期)。IBC 中的中继器不必被信任;它们无法伪造有效的区块头或数据包,因为这些都无法通过验证。最坏的情况下,一个恶意或离线的中继器可以审查或延迟消息,但任何人都可以运行中继器,所以只要至少有一个诚实的中继器存在,活性最终是可以实现的。这是一个非常强大的安全模型:默认情况下是去中心化和无需许可的,反映了链本身的属性。其权衡在于成本和复杂性——在另一条链上运行一个轻客户端(特别是高吞吐量链的轻客户端)可能会消耗大量资源(存储验证者集变更、验证签名等)。对于使用 Tendermint/BFT 的 Cosmos SDK 链来说,这个成本是可控的,IBC 非常高效;但要集成异构链(如以太坊或 Solana),则需要复杂的客户端实现或新的密码学技术。事实上,通过 IBC 桥接非 Cosmos 链的进展较慢——像 Polymer 和 Composable 这样的项目正在研究轻客户端或 zk 证明,以将 IBC 扩展到以太坊等其他链。IBC 3.0 的改进(例如,优化的轻客户端、支持不同的验证方法)旨在降低这些成本。总而言之,IBC 的轻客户端模型提供了最强的信任保证(完全没有外部验证者)和稳固的活性(假定有多个中继器),但代价是更高的实现复杂性和对所有参与链都必须支持 IBC 协议的限制。
比较轻客户端、多重签名和证明聚合
每种安全模型——轻客户端 (IBC)、验证者多签 (Hyperlane) 和聚合证明 (LayerZero)——都有其独特的优缺点。下面我们从关键维度对它们进行比较:
安全保证
-
轻客户端 (IBC): 通过将链上验 证锚定到源链的共识,提供最高的安全性。没有新的信任层;如果你信任源区块链(例如 Cosmos Hub 或以太坊)不会双出块,你就可以信任它发送的消息。这最大限度地减少了额外的信任假设和攻击面。然而,如果源链的验证者集被破坏(例如,在 Tendermint 中超过 ⅓ 或在 PoS 链中超过 ½ 的验证者作恶),轻客户端可能会被喂入一个欺诈性的区块头。在实践中,IBC 通道通常建立在经济安全的链之间,并且轻客户端可以设置参数(如信任期和区块最终性要求)来降低风险。总的来说,信任最小化是轻客户端模型最强的优势——每条消息都有其有效性的加密证明。
-
多签验证者 (Hyperlane 及类似桥): 安全性取决于一组链下签名者的诚实度。一个典型的阈值(例如,⅔ 的验证者)必须对每个跨链消息或状态检查点进行签名。好处是,通过足够多的信誉良好或有经济质押的验证者,这可以变得相当安全。例如,Wormhole 的 19 个守护者或 Hyperlane 的默认委员会必须集体勾结才能攻破系统。缺点是这引入了一个新的信任假设:除了链本身,用户还必须信任桥的委员会。这在一些黑客攻击中已被证明是失败点(例如,如果私钥被盗或内部人员勾结)。像 Hyperlane 的再质押 ETH 抵押品这样的举措为该模型增加了经济安全性——签署无效数据的验证者可以在以太坊上被自动罚没。这使得多签桥在安全性上更接近区块链(通过经济惩罚欺诈),但它仍然不如轻客户端那样信任最小化。简而言之,多签在信任保证方面较弱:它依赖于一小部分人的多数,尽管罚没和审计可以增强信心。
-
证明聚合 (LayerZero v2): 这在某种程度上是一个 中间地带。如果一个应用程序将其安全堆栈配置为包含一个轻客户端 DVN 或一个 zk 证明 DVN,那么对于这些检查,其保证可以接近 IBC 级别(数学和链共识)。如果它使用一个基于委员会的 DVN(如 LayerZero 的 2/3 默认 DVN 或一个 Axelar 适配器),那么它就继承了该多签的信任假设。LayerZero 模型的优势在于你可以独立地组合多个验证者。例如,同时要求“一个 zk 证明有效”和“Chainlink 预言机说区块头是 X”和“我们自己的验证者签名”可以极大地减少攻击可能性(攻击者需要同时攻破所有这些)。此外,通过允许应用强制要求自己的 DVN,LayerZero 确保在没有应用同意的情况下,任何消息都不会执行(如果这样配置的话)。弱点在于,如果开发者选择了一个宽松的安全配置(为了更低的费用或更快的速度),他们可能会削弱安全性——例如,使用一个由未知方运行的单一 DVN 将类似于信任单个验证者。LayerZero 本身是无偏见的,将这些选择留给应用开发者,这意味着安全性仅与所选的 DVN 一样好。总而言之,证明聚合可以提供非常强的安全性(甚至比单个轻客户端更高,通过要求多个独立的证明),但如果配置不当,也可能导致弱设置。它很灵活:应用可以为高价值交易提高安全性(例如,要求多个大型 DVN),并为低价值交易降低安全性。
活性与可用性
-
轻客户端 (IBC): 活性取决于中继器和轻客户端保持更新。积极的一面是任何人都可以运行中继器,因此系统不依赖于一组特定的节点——如果一个中继器停止工作,另一个可以接替。IBC 3.0 的并行中继通过不将所有数据包序列化到一条路径上,进一步提高了可用性。在实践中,IBC 连接非常可靠,但在某些情况下活性可能会受到影响:例如,如果长时间没有中继器发布更新,轻客户端可能会过期(例如,如果信任期在没有更新的情况下过去),然后通道会为了安全而关闭。然而,这种情况很少见,并且可以通过活跃的中继器网络来缓解。另一个活性考虑因素是:IBC 数据包受源链最终性的影响——例如,在 Tendermint 中等待 1-2 个区块(几秒钟)是标准做法。总的来说,只要至少有一个活跃的中继器,IBC 就能提供高可用性,并且对于已确认的区块,延迟通常很低(秒级)。这里没有像多签中那样验证者群体离线的概念;区块链自身的共识最终性是主要的延迟因素。
-
多签验证者 (Hyperlane): 如果验证者集很小,活性可能是一个弱点。例如,如果一个桥有 5/8 的多签,而 4 个验证者离线或无法联系,跨链消息传递就会停止,因为无法满足阈值。Hyperlane 文档指出,验证者停机可能会导致消息传递停止,具体取决于配置的阈值。这部分解释了为什么选择更大的委员会或更低的阈值(以牺牲安全性为代价)来提高正常运行时间。Hyperlane 的设计允许在需要时部署新的验证者或切换 ISM,但这种变更可能需要协调/治理。多签桥的优势在于,一旦收集到阈值签名,确认通常很快——无需在目标链上等待源链的区块最终性,因为多签证明本身就是最终性。在实践中,许多多签桥在几秒钟内就能签名和中继消息。因此,对于某些链,延迟可以与轻客 户端相当甚至更低。瓶颈在于验证者速度慢或地理分布广泛,或者涉及任何手动步骤。总而言之,多签模型在大多数时候可以具有高活性和低延迟,但它们存在活性风险集中在验证者集——如果太多验证者崩溃或它们之间发生网络分区,桥实际上就宕机了。
-
证明聚合 (LayerZero): 这里的活性取决于每个 DVN 和中继器的可用性。一条消息必须从所需的 DVN 收集签名/证明,然后被中继到目标链。好的一面是DVN 独立运作——如果一个 DVN(在一组 DVN 中)宕机但不是必需的(只是“M of N”的一部分),只要满足阈值,消息仍然可以继续。LayerZero 的模型明确允许配置群体以容忍一些 DVN 故障。例如,一个“2 of 5”的 DVN 集可以处理 3 个 DVN 离线而协议不停止。此外,因为任何人都可以扮演最终的执行者/中继器角色,消息传递没有单点故障——如果主中继器失败,用户或其他方可以带着证明调用合约(这类似于 IBC 中的无需许可的中继器概念)。因此,LayerZero v2 通过不将系统绑定到一个中间人,力求实现抗审查性和活性。然而,如果必需的 DVN是安全堆栈的一部分(比如一个应用要求自己的 DVN 始终签名),那么该 DVN 就是一个活性依赖:如果它离线,消息将暂停,直到它恢复或安全策略被更改。总的来说,证明聚合可以配置得非常稳健(通过冗余的 DVN 和任何方中继),使得所有验证者同时宕机的可能性很小。权衡是,联系多个 DVN 可能会引入更多的延迟(例如,等待多个签名),相比于单个更快的多签。但这些 DVN 可以并行运行,许多 DVN(如预言机网络或轻客户端)可以快速响应。因此,LayerZero 可以实现高活性和低延迟,但具体性能取决于 DVN 的设置方式(有些可能会等待源链的几个区块确认等,这可能会为了安全而增加延迟)。
成本与复杂性
-
轻客户端 (IBC): 这种方法往往实现复杂但一旦在兼容链上设置好后使用成本低。复杂性在于为每种类型的区块链编写一个正确的轻客户端实现——本质上,你是在将链 A 的共识规则编码到链 B 的智能合约中。对于具有相似共识的 Cosmos SDK 链来说,这很简单,但将 IBC 扩展到 Cosmos 之外需要大量的工程工作(例如,为 Polkadot 的 GRANDPA 最终性构建轻客户端,或计划为以太坊轻客户端使用 zk 证明)。这些实现并非易事,且必须高度安全。还有链上存储开销:轻客户端需要为另一条链存储最近的验证者集或状态根信息。这会增加链上的状态大小和证明验证成本。因此,直接在以太坊主网上运行 IBC(验证 Cosmos 的区块头)在 gas 方面会很昂贵——这也是像 Polymer 这样的项目正在创建一个以太坊 rollup 来将这些轻客户端托管在主网之外的原因之一。在 Cosmos 生态系统内,IBC 交易非常高效(通常只需几美分的 gas),因为轻客户端验证(ed25519 签名、默克尔证明)在协议层面得到了很好的优化。对用户来说,使用 IBC 的成本相对较低,中继器只需在目标链上支付正常的交易费(他们可以通过 ICS-29 中间件获得费用激励)。总而言之,IBC 的成本主要体现在前期的开发复杂性上,但一旦运行起来,它就提供了一个原生的、费用高效的传输方式。连接的众多 Cosmos 链(100+ 个区域)共享一个共同的实现,这通过标准化帮助管理了复杂性。
-
多签桥 (Hyperlane/Wormhole/等): 这里的实现复杂性通常较低——核心的桥接合约主要需要根据存储的公钥验证一组签名。这个逻辑比一个完整的轻客户端要简单。链下验证者软件确实引入了操作复杂性(观察链事件的服务器、维护消息的默克尔树、协调签名收集等),但这由桥运营商管理并保持在链下。链上成本:验证几个签名(比如 2 或 5 个 ECDSA 签名)不是太贵,但肯定比单个阈值签名或哈希检查要消耗更多的 gas。一些桥使用聚合签名方案(例如 BLS)来将链上成本降低到 1 次签名验证。总的来说,在以太坊或类似链上进行多签验证的成本中等(每个 ECDSA 签名检查约 3000 gas)。如果一个桥需要 10 个签名,那仅验证就需要约 3 万 gas,再加上存储新的默克尔根等。考虑到跨链转账是高价值操作,这通常是可以接受的,但成本会累积。从开发者/用户的角度来看,与多签桥交互很简单:你存入或调用一个发送函数,剩下的由验证者/中继器在链下处理,然后提交一个证明。对于应用开发者来说,复杂性很小,因为他们只需集成桥的 API/合约。一个复杂性考虑是添加新链——每个验证者都必须为每个新链运行一个节点或索引器来观察消息,这可能是一个协调上的难题(在一些多签设计中,这被认为是扩展的瓶颈)。Hyperlane 的答案是无需许可的验证者(如果 ISM 包含他们,任何人都可以为一个链加入),但部署 ISM 的应用程序仍然需要初始设置这些密钥。总的来说,多签模型更容易在异构链之间引导(无需为每条链定制轻客户端),这使得它们能更快地推向市场,但它们会产生链下的操作复杂性和中 等的链上验证成本。
-
证明聚合 (LayerZero): 这里的复杂性在于协调多种可能的验证方法。LayerZero 提供了一个标准化的接口(Endpoint 和 MessageLib 合约),并期望 DVN 遵守特定的验证 API。从应用程序的角度来看,使用 LayerZero 非常简单(只需调用
lzSend并实现lzReceive回调),但在底层,有很多事情在发生。每个 DVN 可能有自己的链下基础设施(一些 DVN 本身就是迷你桥,比如一个 Axelar 网络或一个 Chainlink 预言机服务)。协议本身很复杂,因为它必须安全地聚合不同类型的证明——例如,一个 DVN 可能提供一个 EVM 区块证明,另一个提供一个 SNARK,再一个提供一个签名等,合约必须依次验证每一个。优点是,大部分这种复杂性都被 LayerZero 的框架抽象掉了。成本取决于需要多少以及何种类型的证明:验证一个 snark 可能很昂贵(链上 zk 证明验证可能消耗数十万 gas),而验证几个签名则更便宜。LayerZero 让应用决定他们愿意为每条消息的安全性支付多少。还有一个为 DVN 的工作付费的概念——消息负载中包含 DVN 服务的费用。例如,应用可以附加费用来激励 DVN 和执行者及时处理消息。这增加了一个成本维度:一个更安全的配置(使用许多 DVN 或昂贵的证明)将花费更多的费用,而一个简单的 1-of-1 DVN(像单个中继器)可能非常便宜但安全性较低。可升级性和治理也是复杂性的一部分:因为应用可以改变它们的安全堆栈,需要有一个治理过程或一个管理员密钥来做这件事——这本身就是一个需要管理的信任/复杂性点。总而言之,通过 LayerZero 的证明聚合高度灵活但底层复杂。每条消息的成本可以通过选择高效的 DVN 来优化(例 如,使用一个优化的超轻客户端,或利用现有预言机网络的规模经济)。许多开发者会发现其即插即用的特性(提供默认设置)很有吸引力——例如,为了方便简单地使用默认的 DVN 集——但这如果不被理解,也可能导致次优的信任假设。
可升级性与治理
-
轻客户端 (IBC): IBC 连接和客户端可以通过参与链上的链上治理提案进行升级(特别是如果轻客户端需要修复或为源链的硬分叉进行更新)。升级 IBC 协议本身(比如从 IBC 2.0 升级到 3.0 的功能)也需要链治理来采用新版本的软件。这意味着 IBC 有一个深思熟虑的升级路径——变更缓慢且需要共识,但这与其安全第一的方法是一致的。没有单一实体可以一键切换;每条链的治理必须批准对客户端或参数的更改。好处是这可以防止可能引入漏洞的单方面更改。坏处是敏捷性较差——例如,如果在轻客户端中发现一个 bug,可能需要跨多条链进行协调的治理投票才能修复(尽管有紧急协调机制)。从 dApp 的角度来看,IBC 并没有真正的“应用级治理”——它是链提供的基础设施。应用程序只使用 IBC 模块(如代币转移或链间账户)并依赖于链的安全性。因此,治理和升级发生在区块链层面(Hub 和 Zone 的治理)。一个有趣的新 IBC 特性是自定义通道和路由(例如,像 Polymer 或 Nexus 这样的中心枢纽),它们可以允许在不中断应用的情况下切换底层的验证方法。但总的来说,IBC 是稳定和标准化的——可升级性是可能的但 不频繁,这有助于其可靠性。
-
多签桥 (Hyperlane/Wormhole): 这些系统通常有一个管理员或治理机制来升级合约、更改验证者集或修改参数。例如,向集合中添加新验证者或轮换密钥可能需要桥所有者的多签或 DAO 投票。Hyperlane 的无需许可特性意味着任何用户都可以部署他们自己的带有自定义验证者集的 ISM,但如果使用默认设置,Hyperlane 团队或社区可能控制更新。可升级性是一把双刃剑:一方面,易于升级/改进,另一方面,它可能是一个中心化风险(如果一个特权密钥可以升级桥合约,该密钥理论上可以卷走桥上的资产)。一个治理良好的协议会限制这一点(例如,时间锁定升级,或使用去中心化治理)。Hyperlane 的理念是模块化——因此一个应用甚至可以通过切换 ISM 等方式绕过一个失败的组件。这赋予了开发者应对威胁的能力(例如,如果一组验证者被怀疑受到攻击,应用可以迅速切换到不同的安全模型)。治理开销在于应用需要决定它们的安全模型,并可能需要管理自己验证者的密钥或关注 Hyperlane 核心协议的更新。总而言之,基于多签的系统更易于升级(合约通常是可升级的,委员会是可配置的),这对于快速改进和添加新链是好事,但它需要对治理过程的信任。过去许多桥的漏洞都是通过被攻破的升级密钥或有缺陷的治理发生的,所以这个领域必须小心处理。从好的方面看,添加对新链的支持可能就像部署合约并让验证者为其运行节点一样简单——无需根本性的协议变更。
-
证明聚合 (LayerZero): LayerZero 宣称其拥有一个不可变的传输层(端点合约不可升级),但验证模块(消息库和 DVN 适配器)是仅追加和可配置的。实际上,这意味着每条链上的核心 LayerZero 合约保持固定(提供一个稳定的接口),而新的 DVN 或验证选项可以随着时间的推移添加,而无需改变核心。应用程序开发者可以控制他们的安全堆栈:他们可以添加或移除 DVN,更改确认区块深度等。这是应用层面上的一种可升级性。例如,如果某个 DVN 被弃用或出现了一个新的、更好的 DVN(比如一个更快的 zk 客户端),应用团队可以将其集成到他们的配置中——从而使 dApp 面向未来。好处是显而易见的:应用不会被昨天的安全技术所束缚;它们可以(在适当谨慎的情况下)适应新的发展。然而,这引发了治理问题:应用内部由谁来决定更改 DVN 集? 理想情况下,如果应用是去中心化的,更改将通过治理进行,或者如果他们想要不可变性,则会硬编码。如果单个管理员可以更改安全堆栈,那就是一个信任点(他们可以在恶意升级中降低安全要求)。LayerZero 自己的指导意见鼓励为这类更改建立稳健的治理,甚至在需要时使某些方面不可变。另一个治理方面是费用管理——支付给 DVN 和中继器的费用可以调整,而不一致的激励措施可能会影响性能(尽管默认情况下市场力量应该会调整费用)。总而言之,LayerZero 的模型在添加新的验证方法方面具有高度的可扩展性和可升级性(这对于长期互操作性非常棒),但责任在于每个应用程序要负责任地治理这些升级。LayerZero 的基础合约是不可变的,以确保传输层不会被卷走或审查,这让人相信消息传递管道本身在升级过程中保持完整。
为了总结比较,下表突出了关键差异:
| 方面 | IBC (轻客户端) | Hyperlane (多重签名) | LayerZero v2 (聚合) |
|---|---|---|---|
| 信任模型 | 信任源链的共识(无额外信任)。 | 信任一个桥接验证者委员会(例如,多签阈值)。罚没可以降低风险。 | 信任取决于所选的 DVN。可以模拟轻客户端或多签,或混合使用(信任所选验证者中的至少一个)。 |
| 安全性 | 最高——通过轻客户端提供有效性的加密证明。攻击需要攻破源链或轻客户端。 | 如果委员会是诚实的多数,则安全性强,但弱于轻客户端。委员会勾结或密钥泄露是主要威胁。 | 可能非常高——可以要求多个独立的证明(例如,zk + 多签 + 预言机)。但可配置的安全性意味着它只与所选的最弱 DVN 一样强大。 |
| 活性 | 只要至少有一个中继器活跃,就非常好。并行中继器和快速最终性链提供近乎实时的交付。 | 正常情况下良好(签名速度快)。但依赖于验证者的正常运行时间。阈值群体停机 = 停止。扩展到新链需要委员会支持。 | 非常好;多个 DVN 提供冗余,任何用户都可以中继交易。如果配置不当,必需的 DVN 可能成为单点故障。延迟可以调整(例如,等待确认 vs. 速度)。 |
| 成本 | 实现客户端的前期复杂性高。链上验证共识(签名、默克尔证明),但在 Cosmos 中已优化。在 IBC 原生环境中每条消息成本低;在非原生链上若无特殊解决方案可能很昂贵。 | 核心合约的开发复杂性较低。链上成本随每条消息的签名数量而变化。验证者的链下运营成本(每条链上的节点)。如果签名多,gas 可能高于轻客户端,但通常可控。 | 中到高复杂性。每条消息的成本各不相同:每个 DVN 证明(签名或 SNARK)都会增加验证 gas。应用为服务支付 DVN 费用。可以通过为低价值消息选择更少或更便宜的证明来优化成本。 |
| 可升级性 | 协议通过链治理演进(缓慢、保守)。轻客户端更新需要协调,但标准化使其保持稳定。添加新链需要构建/批准新的客户端类型。 | 灵活——验证者集和 ISM 可以通过治理或管理员更改。更容易快速集成新链。如果升级密钥或治理被攻破则存在风险。通常是可升级的合约(需要信任管理员)。 | 高度模块化——可以添加新的 DVN/验证方法而无需更改核心。应用可以根据需要更改安全配置。核心端点不可变(无中心化升级),但应用级治理需要对安全更改进行管理以避免滥用。 |
对 DeFi 可组合性和共享流动性的影响
跨链消息传递为可组合性——不同链上的 DeFi 合约进行交互的能力——解锁了强大的新模式,并实现了共享流动性——将跨链资产汇集起来,如同在一个市场中。上述讨论的安全模型影响着协议能够多么自信和无缝地利用跨链功能。下面我们探讨每种方法如何支持多链 DeFi,并附上真实案例:
-
通过 LayerZero 实现的全链 DeFi (Stargate, Radiant, Tapioca): LayerZero 的通用消息传递和全链同质化代币 (OFT) 标准旨在打破流动性孤岛。例如,Stargate Finance 使用 LayerZero 实现了一个用于原生资产桥接的统一流动性池——而不是在每条链上都 有零散的池子,所有链上的 Stargate 合约都接入一个共同的池子,而 LayerZero 消息处理跨链的锁定/释放逻辑。这使得 Stargate 的桥接月交易量超过 8 亿美元,展示了显著的共享流动性。通过依赖 LayerZero 的安全性(Stargate 可能使用了一套稳健的 DVN),用户可以高度自信地转移资产,相信消息的真实性。Radiant Capital 是另一个例子——一个跨链借贷协议,用户可以在一条链上存款,在另一条链上借款。它利用 LayerZero 消息来协调跨链的账户状态,有效地创建了一个跨多个网络的借贷市场。同样,Tapioca(一个全链货币市场)使用 LayerZero v2,甚至运行自己的 DVN 作为必需的验证者来保护其消息。这些例子表明,凭借灵活的安全性,LayerZero 可以支持复杂的跨链操作,如信用检查、抵押品移动和跨链清算。可组合性来自于 LayerZero 的“OApp”标准(全链应用),它让开发者可以在多条链上部署相同的合约,并通过消息传递进行协调。用户与任何一条链的实例交互,体验到的应用如同一个统一的系统。安全模型允许微调:例如,大额转账或清算可能需要更多的 DVN 签名(为了安全),而小额操作则通过更快/更便宜的路径。这种灵活性确保了安全性和用户体验都不必一刀切。在实践中,LayerZero 的模型极大地增强了共享流动性,这体现在数十个项目采用 OFT 作为其代币标准(因此一个代币可以“全链”存在,而不是作为独立的包装资产)。例如,稳定币和治理代币可以使用 OFT 在所有链上维持一个单一的总供应量——避免了早期包装代币所困扰的流动性碎片化和套利问题。总的来说,通过提供一个可靠的消息层并让应用控制信任模型,LayerZero 催生了新的多链 DeFi 设计,这些设计将多条链视为一个生态系统。权衡之处在于,用户和项目必须理解每个全链应用的信任假设(因为它们可能不同)。但像 OFT 这样的标准和广泛使用的默认 DVN 有助于使这一点更加统一。
-
IBC 中的链间账户和服务 (Cosmos DeFi): 在 Cosmos 世界中,IBC 已经实现了一系列丰富的跨链功能,远不止代币转移。一个旗舰功能是链间账户 (ICA),它允许一个区块链(或链 A 上的用户)像本地账户一样控制链 B 上的账户。这是通过携带交易的 IBC 数据包完成的。例如,Cosmos Hub 可以在 Osmosis 上使用一个链间账户,代表用户进行质押或交换代币——所有操作都从 Hub 发起。一个具体的 DeFi 用例是 Stride 的流动性质押协议:Stride(一条链)从用户那里接收像 ATOM 这样的代币,然后使用 ICA,在 Cosmos Hub 上远程质押这些 ATOM,再向用户发行 stATOM(流动性质押的 ATOM)。整个流程是无需信任且通过 IBC 自动化的——Stride 的模块控制着 Hub 上的一个账户,执行委托和取消委托的交易,并通过确认和超时机制确保安全。这展示了跨链可组合性:两条主权链无缝地执行一个联合工作流(在这里质押,在那里铸造代币)。另一个例子是 Osmosis(一个 DEX 链),它使用 IBC 从 95+ 个连接的链中引入资产。任何区域的用户都可以通过 IBC 发送他们的代币在 Osmosis 上进行交换。得益于 IBC 的高安全性,Osmosis 和其他协议可以自信地将 IBC 代币视为真实的(无需信任的托管人)。这使得 Osmosis 成为最大的链间 DEX 之一,据报道其每日 IBC 转账量超过了许多桥接系统。此外,随着 IBC 3.0 中的链间查询 (ICQ),一条链上的智能合约可以以信任最小化的方式从另一条链获取数据(如价格、利率或头寸)。 这可以实现,例如,一个链间收益聚合器,它查询多个区域的收益率,并相应地重新分配资产,所有这些都通过 IBC 消息完成。IBC 的轻客户端模型对可组合性的关键影响是信心和中立性:链保持主权,但可以交互而不用担心第三方桥的风险。像 Composable Finance 和 Polymer 这样的项目甚至正在将 IBC 扩展到非 Cosmos 生态系统(Polkadot、以太坊),以利用这些能力。结果可能是未来任何采用 IBC 客户端标准的链都可以插入一个“通用的区块链互联网”。Cosmos 中的共享流动性已经相当可观——例如,Cosmos Hub 的原生 DEX (Gravity DEX) 和其他 DEX 都依赖 IBC 来汇集来自不同区域的流动性。然而,到目前为止的一个限制是,Cosmos DeFi 大多是异步的:你在一条链上发起,结果在另一条链上发生,有轻微的延迟(秒级)。这对于交易和质押等操作来说没问题,但更复杂的同步可组合性(如跨链闪电贷)由于根本的延迟而仍然无法实现。尽管如此,由 IBC 实现的跨链 DeFi 范围很广:多链收益农场(将资金移至收益最高的地方)、跨链治理(一条链投票通过治理数据包在另一条链上执行操作),甚至链间安全,即消费者链利用提供者链的验证者集(通过 IBC 验证数据包)。总而言之,IBC 的安全通道在 Cosmos 中培育了一个链间经济——在这个经济中,项目可以在不同的链上专业化,但通过信任最小化的消息流畅地协同工作。共享流动性体现在资产流向 Osmosis 以及在各区域间自由流动的 Cosmos 原生稳定币的兴起等方面。
-
混合及其他多链方法 (Hyperlane 及其他): Hyperlane 的无需许可连接愿景催生了像用于桥接资产的 Warp Routes 和跨越各种生态系统 的链间 dApp 等概念。例如,一个 Warp Route 可能允许以太坊上的 ERC-20 代币被传送到 Solana 程序,底层使用 Hyperlane 的消息层。一个面向用户的具体实现是 Hyperlane 的 Nexus 桥,它提供了一个 UI,用于通过 Hyperlane 的基础设施在多条链之间转移资产。通过使用模块化的安全模型,Hyperlane 可以为每条路径定制安全性:一笔小额转账可能通过一个简单的快速路径(仅由 Hyperlane 验证者签名),而一笔大额转账可能需要一个聚合的 ISM(Hyperlane + Wormhole + Axelar 都进行证明)。这确保了高价值的流动性转移由多个桥共同保障——增加了例如跨链转移 1000 万美元资产的信心(需要同时攻破多个网络才能窃取),但代价是更高的复杂性/费用。在可组合性方面,Hyperlane 实现了他们所称的**“合约互操作性”——一旦消息被传递,链 A 上的智能合约可以像本地调用一样调用链 B 上的函数。开发者集成 Hyperlane SDK 可以轻松地分派这些跨链调用。一个例子可能是一个跨链 DEX 聚合器,它部分存在于以太坊,部分存在于 BNB 链,使用 Hyperlane 消息在两者之间进行套利。因为 Hyperlane 支持 EVM 和非 EVM 链(甚至早期工作已涉及 CosmWasm 和 MoveVM 的集成),它渴望连接“任何链,任何虚拟机”。这种广泛的覆盖范围可以通过桥接那些原本不易连接的生态系统来增加共享流动性。然而,Hyperlane 在大规模 DeFi 中的实际采用仍在增长。它在桥接方面的交易量尚未达到 Wormhole 或 LayerZero 的水平,但其无需许可的特性吸引了实验。例如,一些项目使用 Hyperlane 快速将应用特定的 rollup 连接到以太坊,因为他们可以设置自己的验证者集,而无需等待复杂的轻客户端解决方案。随着再质押 (EigenLayer) 的发展,Hyperlane 可能会通过为任何 rollup 提供以太坊级别的安全性和相对较低的延迟而获得更多采用。这可能会加速新的多链组合——例如,一个 Optimism rollup 和一个 Polygon zk-rollup 通过 Hyperlane AVS 交换消息,每条消息如果欺诈都会有被罚没的 ETH 作为保障。对可组合性的影响是,即使是没有共享标准的生态系统(如以太坊和任意 L2)也可以得到一个双方都信任的桥接合约(因为它是经济上安全的)。随着时间的推移,这可能会产生一个相互连接的 DeFi 应用网络,其中可组合性由开发者“调控”**(选择为哪些调用使用哪些安全模块)。
在所有这些案例中,安全模型与可组合性之间的相互作用是显而易见的。项目只有在安全性坚如磐石的情况下,才会将大量的流动性池委托给跨链系统——因此推动了信任最小化或经济安全的设计。同时,集成的简易性(开发者体验)和灵活性影响着团队在利用多条链方面的创造力。LayerZero 和 Hyperlane 专注于为开发者提供简单性(只需导入一个 SDK 并使用熟悉的发送/接收调用),而 IBC 作为更底层的协议,需要更多对模块的理解,可能由链开发者而非应用开发者来处理。尽管如此,这三者都在推动一个未来,即用户与多链 dApp 交互时无需知道自己在哪条链上——应用无缝地从任何地方获取流动性和功能。例如,一个借贷应用的用户可能在链 A 上存款,甚至没有意识到借款是从链 B 的池子中发生的——所有这些都由跨链消息和适当的验证来覆盖。