Hyperlane — 深度解析

Hyperlane — 深入解析

关于 Hyperlane 你需要知道的一切

我们最近发布了一篇 10,000 字的文章，比较了七个最著名的任意消息桥 (AMB)。

为了使文档更易于理解，我们将在每个星期五的 Substack 上将其分解为一系列“深入解析”，其中还将包括指向有关 AMB 的 Twitter Spaces 的链接。

首先是 Hyperlane！你可以在下面找到深入解析和我们的 加粗Twitter Spaces加粗 这里 加粗。

本文将探讨任意消息桥 (AMB) Hyperlane 的设计、安全性和信任假设，该桥提供跨链开发者工具，并专注于安全性。

在这里，我们将介绍以下内容：

• Hyperlane — 概述
• 工作原理 — 交易生命周期
• 安全特性
• 信任假设
• 团队
• 社区与资源

让我们开始吧！

概述

Hyperlane，以前称为 Abacus，是一种通用的链间消息传递协议，提供链上 API，用于跨链发送和接收消息。它主要是一个工具，旨在使开发者能够发送链之间的数据并创建原生跨链应用程序。它的主要区别在于 Hyperlane 明确关注通过 API 传递数据，以及它为 dApp 设置特定于应用程序的验证器所提供的灵活性。

Hyperlane 的一些最佳功能包括：

• 易于集成的API—— Hyperlane 提供了一个链上 API，可以集成到 dApp 中以发送和接收链间消息。 根据 Hyperlane，开发者可以在不到五分钟的时间内将简单的链间消息发送到预先部署的智能合约。
• 由特定于应用程序的验证器提供的本地安全性——应用程序可以添加自己的验证器集以实现安全目的（除了 Hyperlane 的权益证明协议之外）。
• 消息可观察性—— 应用程序可以跟踪链间消息，并在消息在目标链上处理时执行操作。该团队计划添加一个链间消息浏览器，以便在不久的将来实现完整的消息可观察性。
• 网络连通性——截至 2022 年 9 月，Hyperlane 支持跨七条链的任意消息传递和跨链合约调用：Arbitrum、Avalanche、BNB Chain、Celo、Ethereum、Optimism 和 Polygon。
• 原生链间 DAO 治理—— Hyperlane 由 DAO 治理，ABC 代币持有者有权通过从任何 Hyperlane 支持的链进行投票来提议和实施对 Hyperlane 协议的更改。
• 融资—— Hyperlane 在由 Variant 领投的种子轮融资中筹集了 1850 万美元。本轮融资的其他参与者包括加密金融服务公司 Galaxy Digital、CoinFund、Circle、Figment、Blockdaemon、Kraken Ventures 和 NFX。

工作原理 — 交易生命周期

Hyperlane 使用“收件箱”和“发件箱”智能合约来发送和接收链间消息。 Hyperlane 支持的每个链都有一个发件箱和 n-1 个收件箱（每个其他链一个）。使用 Hyperlane 发送和接收消息是一个分为三个步骤的过程：

• 步骤 1—— 应用程序在源链上调用 Outbox.dispatch()。每个消息都作为叶子插入到发件箱的 增量 Merkle 树 中（为了提高 gas 效率）。

注意：Outbox.dispatch() 函数包含与交易相关的所有信息（例如消息内容、目标链 ID 和接收者地址）。

• 步骤 2—— 最新的发件箱 Merkle 根由源链的验证器集签名。如果存在特定于应用程序的验证器（本地安全性），则此 Merkle 根也由它们签名。
• 步骤 3—— ARelayer 通过调用 InboxValidatorManager.process() 将消息传递给接收者。这样做会提供消息的 Merkle 证明、消息和步骤 2 中提到的已签名根。InboxValidatorManager 验证根是否已由验证器签名，然后调用 Inbox.process 验证 Merkle 证明。验证后，收件箱合约调用 recipient.handle() 函数，消息被传递到应用程序。

安全性

Hyperlane 提供以下安全功能：

• PoS 验证器集提供的经济安全性—— Hyperlane 的安全性依赖于委托权益证明协议。每个 Hyperlane 支持的链都有自己的验证器集，PoS 协议确保恶意行为会产生经济成本。
• 用户选择验证器—— 用户可以质押 ABC 代币并将它们委托给 Hyperlane 验证器。委托给他们的代币最多的验证器被选择为验证器集的一部分。还有一个过渡窗口，用户可以在其中提议更改验证器集的成员。
• 通过主权共识实现的特定于应用程序的安全性—— Hyperlane 为 AMB 领域引入了一种新风味。它借鉴了 Cosmos 的特定于应用程序的开发概念，并为开发者提供了增强其 dApp 安全性的灵活性。除了使用委托权益证明协议来保护 API 的安全之外，该协议为所有构建在 Hyperlane 上的 dApp 验证消息，应用程序还可以指定自己的验证器集。这使开发者能够设计自己的具有特定于应用程序的安全保证的验证器集。
• 抗审查性—— 与大多数 AMB 不同，Hyperlane 验证器不签署单个消息。相反，他们签署包含所有消息的发件箱的 Merkle 根，从而提高 Hyperlane 的抗审查性，因为验证器无法审查特定消息。
• 用于监督的瞭望塔—— Hyperlane 的设计包含“瞭望塔”，用于观察发件箱和相关的收件箱，以检测恶意验证器活动，例如审查或欺诈消息。如果瞭望塔检测到恶意活动，它可以将证据提交到源链并获得奖励。在这种情况下，验证器会因其质押的代币被削减而受到惩罚。

信任假设

Hyperlane 做出以下信任假设：

• 由验证器集进行的外部验证—— Hyperlane 使用特定于链的验证器集来签署从一个链到另一个链的消息。因此，设计中存在固有的信任，因为用户相信验证器会诚实地验证交易，并且不会串通窃取资金。

注意：有关 Hyperlane 的验证器集的具体细节，例如验证器的数量、质押的资本等，尚未公开。

• 每个链的安全性并不相同—— 每个 Hyperlane 支持的链都有自己的验证器集。这意味着 Hyperlane 不要求验证器存在于所有支持的链上。因此，如果由于验证器数量较少而导致经济安全性较低，则某些链可能不如其他链安全。但是，Hyperlane 为应用程序提供了选择他们想要跨链发送/接收消息的灵活性。因此，如果 dApp 得出结论认为特定链的安全性不足，它可以选择不集成该链。
• 削减质押的惩罚将始终阻止验证器串通—— Hyperlane 验证器的质押是绑定的，即如果他们恶意行事（串通或审查消息），他们的质押将被削减。虽然用户受到削减机制的保护，但存在一个假设，即它在所有情况下都提供经济安全性。但是，如果攻击成本（削减惩罚和声誉）低于通过串通可以窃取的资本金额，那么验证器更有可能串通和窃取资金，而不是诚实地行事。

团队

Hyperlane 的团队致力于构建工具，使开发者能够构建安全的链间应用程序。创始团队包括：

• 联合创始人—— Asa Oines、Nam Chu Hoai、Jon Kol、Zaki Manian（现在兼职）、Morgan Beller（现在兼职）。
• 工程—— Yorke Rhodes、Trevor Porter、Mattie Conover。
• 产品与增长—— Nosleepjon、Jen Aprahamian。

社区与资源

你可以通过以下方式了解有关 Hyperlane 的更多信息并及时了解其社区：

• 官方网站
• 文档
• Github
• Twitter
• Discord

结束语

Hyperlane 的愿景是提供安全的基础设施，使开发者能够构建更安全的链间应用程序。我们对 Hyperlane 正在构建的内容感到非常兴奋，并且迫不及待地想看看 AMB 结构为加密领域解锁了什么。

当然，LI.FI 感谢 Hyperlane 团队为文档/Twitter Spaces 提供的所有反馈和合作。

存在一个完整的 AMB 生态系统，可为 dApp 启用复杂的跨链功能。如果你有兴趣了解有关不同类型 AMB 的更多信息，请查看 LI.FI 的比较框架，该框架使读者能够快速评估 AMB 的优缺点。

立即开始使用 LI.FI

喜欢阅读我们的研究吗？请为博客鼓掌并表达你的支持！要了解有关我们的更多信息：

• 前往我们的链接门户 https://link3.to/lifi
• 阅读我们的 SDK“快速入门” docs.li.fi
• 在 Substack 上订阅我们的新闻通讯
• 关注我们的 Telegram 新闻通讯
• 在 Twitter 和 LinkedIn 上关注我们

• 原文链接： blog.li.fi/hyperlane-a-d...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～