桥评估报告

桥评估报告

目录

总结

Uniswap DAO 使用跨链消息协议（桥）来传递来自以太坊的治理决策到已部署 Uniswap V3 合约的目标链。此用例的功能性和非功能性需求在下方定义。

桥是复杂的系统；Uniswap 基金会的桥评估委员会开发了一个框架，用于在 DAO 用例的背景下评估它们。

委员会评估了六座桥，并批准了两座用于 DAO 的跨链治理用例；其他的将在未来几个月内根据其持续发展情况再次审查。

委员会确定多桥架构可能是 Uniswap DAO 跨链治理用例的最佳选择，但指出提供此功能的协议尚处于起步阶段，尚未成熟到可以立即实施。委员会为多桥跨链消息架构的持续发展提供了建议，。

委员会提出了一些当前可以实施的建议，以提高 Uniswap 现有跨链部署的安全性。

基金会希望这成为关于跨链治理的众多报告中的第一份，也是第一组桥评估；后续资助计划用于持续的长期研发以及特别的桥评估和重新评估。

介绍

2022 年 12 月 11 日，Uniswap 论坛收到了一份关于在 BNB 链上正式部署 Uniswap v3 的提案，该提案获得了社区的支持。讨论迅速转移到哪个桥协议将用于跨链治理目的的问题上。在近 100 篇帖子中，社区成员提出了 Celer、DeBridge、Wormhole 和 LayerZero 作为潜在的选择。对话内容非常技术性，有时也充满争议，各个桥团队成员直接权衡每种提议解决方案的成本和收益。

https://app.uniswap.org/#/vote/2/31

备选文本

该提案最终获得通过，Uniswap 通过使用 Wormhole 作为治理桥部署在 BNB 链上。投票前的讨论清楚地表明，跨链消息传递和支持它的协议占据了一个新兴且复杂的设计空间。期望典型的 Uniswap 治理代表理解所提出的每种桥接解决方案的复杂性是不切实际的，尤其是在设计和实现本身不是静态的情况下。对代表来说，桥的信息来源是另一个复杂因素；对于不深入了解跨链消息传递细微之处的代表来说，可能不得不信任对其观点有偏见的来源。

在 BNB 链投票之后，为了更好地让 Uniswap 社区为今后做出此类决策做好准备，Uniswap 基金会召集了一个跨链桥评估委员会，以生成以下报告。委员会的目标，正如讨论其成立的治理论坛帖子中所定义的那样：

支持代表和社区成员做出与跨链部署相关的明智决策

为桥提供商提供流程清晰度.

消除未来所有治理利益相关者的治理流程效率低下。

基金会认为，本报告通过定义已被评估为适合 Uniswap 跨链治理用例的桥提供商、发布进行这些评估的框架以及为利益相关者在评估涉及跨链消息传递的治理提案时提供讨论基础，从而实现了所有三个目标。

展望未来

在本报告发布后，Uniswap 基金会计划立即资助一个与跨链治理相关的工作流程。这项工作的范围包括：

持续监控先前评估的跨链协议的开发，并报告这些协议的变更，

成为对评估框架和一般跨链问题有疑问的社区成员的联络点，以及

实施本报告附录 2 中的部分或全部架构建议。

特别的桥评估或重新评估（基金会计划补贴这些资助，但由于每次评估可能需要 100 小时的工程工作，因此要求请求评估或重新评估的桥也做出贡献）。

如果在先前评估的协议中发现重大变更，如协议对安全性和活跃性做出的保证发生变化（定义如下），这些变更将在本 Notion 文档的备忘录中注明，并将排队等待重新评估。此外，先前评估的协议可以在发布新功能后主动要求重新评估。

免责声明

以下文件由桥评估委员会为 Uniswap 基金会准备，委员会成员是基金会为此明确目的而聘请的。它仅供参考，不应作为投资建议或法律建议依赖。

Uniswap 基金会的桥评估委员会进行了本文所述的尽职调查，以尽其所能地确定每个桥协议在执行 Uniswap DAO 的治理用例所需的特定功能方面的适用性。这种确定可能是不完整的，委员会对协议的评估不应被解释为表明在该协议在 Uniswap DAO 的跨链治理用例或其他情况下的使用是无风险的。

委员会在其评估中依据的信息可能会经常更改，恕不另行通知。因此，虽然他们在本文档中的建议代表了委员会和基金会在发布之日的意见，但情况可能需要对先前批准的协议进行新的评估，并更改委员会与该协议相关的建议。虽然 Uniswap 基金会将努力资助一个团队，以便及时了解跨链消息传递领域的最新事件，但基金会不保证任何此类团队都能够在情况发生变化时实时更新这些建议。

跨链消息传递桥是复杂的系统，在高度对抗性的空间中运行。虽然委员会已建议某些桥可用于 Uniswap DAO 的治理用例，但如果这些桥的实施不正确，可能会破坏委员会做出决定的属性。那些寻求实施推荐桥的人应注意他们这样做的用例，并在在生产环境中使用桥之前，寻求该领域专家的帮助。Uniswap 基金会作为一个整体，以及桥评估委员会或其任何成员，均不对任何消息传递桥的安全性、安全性或可靠性做出任何保证，并且每个人均不对他人使用任何此类桥承担任何责任。

任何桥评估委员会成员均未持有本文审查的任何桥协议中的代币或股权。

Uniswap DAO 的跨链治理用例和本报告的范围

Uniswap DAO 的跨链治理用例的功能性要求是能够将消息从 DAO 基于以太坊的治理合约发送到非以太坊链上的 Uniswap V3 部署。此用例的非功能性需求将在下方更深入地讨论。为了实现 Uniswap 基金会的目标，跨链桥评估委员会创建了一个尽职调查框架，以通过此用例的视角评估跨链消息传递协议，并将其应用于六座桥。在创建此框架时，未考虑其他用例。

重要的是要注意这个狭窄的范围；Uniswap 基金会希望强调，下面详细介绍的框架只能用于评估此用例的跨链消息传递协议。

此外，在本报告中未被视为适合 Uniswap DAO 的跨链治理用例的桥可能仍然适合具有不同要求的其他协议、应用程序和团队。这是因为不同的用例需要与跨链协议相关的不同的功能性和非功能性考虑因素。此外，其他应用程序可能没有此用例施加的相同约束，例如拥有和运营单独基础设施的能力。同样重要的是要注意，今天未选择的桥可能会因其未来几个月和几年的发展方式而变得适合 Uniswap DAO 的跨链治理用例。

Uniswap 实体

有三个不同的实体名称中带有 Uniswap。重要的是要了解这些实体及其与本报告的关系之间的区别。

Uniswap Labs 是一家私有公司，发明了 Uniswap 协议。Uniswap 协议是一组智能合约，可在以太坊和其他基于 evm 的区块链上实现交易和自动流动性供应。Uniswap Labs 是一家协议研发和软件公司。Uniswap Labs 没有参与桥评估委员会的选拔或本报告的编写，以下文档中的任何内容均不应被解释为该公司的意见或建议。

Uniswap DAO 是以太坊区块链上的一组智能合约，用于管理 Uniswap 协议。DAO 的代币持有者投票决定由 Governor Bravo 式的 治理设置执行的提案。这些代币持有者有时在本报告中被称为“Uniswap 社区”。DAO 的合约持有

owner

以太坊部署中 Uniswap 协议的角色，使代币持有者能够更改协议的某些参数。如果代币持有者投票决定，Governor 合约还可以控制协议的远程部署，如下面 详细 介绍的那样。此外，如果代币持有者投票决定，Governor 合约可以调用任何任意函数。

Uniswap 基金会由 DAO 投票创建并提供资金，以便将 UNI 从 DAO 的金库发送到由基金会董事会成员控制的多重签名。此投票之前进行了一次对话，澄清了该组织的使命和目的：支持 Uniswap 协议及其支持生态系统的去中心化增长和可持续性。Uniswap 基金会召集了桥评估委员会，以服务于该使命。本报告是该委员会的产出。

当前状态：Uniswap 治理如何运作

概述

Uniswap DAO 对 Uniswap 协议的治理通过 Compound 的 Governor Bravo 合约的一个分支进行管理，该分支允许 mainnet 上的 UNI 代币持有者使用 propose → vote → queue→ execute 模式来提议和执行函数调用。虽然 Governor 合约可以调用任何函数，但协议本身的治理表面积很小；除了拥有更改数量有限的协议参数的唯一权限外，治理合约还拥有和控制协议的金库资产和 ENS 名称。

治理流程 从社区提案开始，该提案在最终进行最终链上投票和执行之前，会经历迭代和一轮链下投票。如果提案通过最终的链上投票，它将在时间锁合约中排队，在此之后，建议的更改可以在 2 天的延迟后执行。在 2 天的延迟后，任何有足够资金支付交易费用的以太坊帐户都可以调用相关的

execute

功能。延迟使不同意更改的利益相关者有足够的时间选择退出协议。

下图说明了此流程的链上部分，该流程用于更改以太坊上 Uniswap V3 部署的协议级参数的提案。

跨链治理

其他区块链网络上的 Uniswap 协议部署没有自己的治理合约，而是通过以太坊网络上的标准流程进行治理。这意味着对远程链上的 Uniswap 协议部署的任何拟议更新都必须首先通过以太坊上的 Uniswap DAO 治理流程，如果获得批准，则该决策将通过任意消息传递桥传递到远程链以供执行。

下图以高级别说明了此流程。

到目前为止，任何将 Uniswap 协议部署到新链的提案还包括提名哪个桥将用于中继此类消息。对于Layer2链上的部署，已使用该链的本机桥，并且委员会建议继续采取此做法，原因在附录 4 中讨论。下表显示了如何处理每个部署的跨链消息传递：

链	类型	桥类型
Arbitrum	L2	本机桥
Avalanche	L1	LayerZero
BNB	L1	Wormhole
Boba	L2	本机桥
Celo	L1	Optics
Gnosis	侧链	Wormhole
Moonbeam	L1	Wormhole
Optimism	L2	本机桥
Polygon	侧链	本机桥

跨链治理的未来状态

Uniswap DAO 的跨链治理用例的主要功能要求是能够将治理消息从以太坊发送到远程链以供执行。因此，此要求在设想的未来状态中保持不变。至少，这应包括 Uniswap 协议当前已部署的十个远程链。

Uniswap DAO 在执行此用例时面临的主要挑战是：

安全故障：受损的跨链桥可能导致无效的治理操作在远程部署上提交和执行。

活跃性故障：单个跨链桥的长时间故障可能会严重延迟或完全阻止远程部署的治理。

审查：任何具有足够控制权的实体（或实体组）都可以阻止有效的治理消息传递到已部署的链。

要了解有关如何得出这些挑战的更多信息，请参阅附录 1。

为了减轻与前三个挑战相关的风险，委员会建立了一个框架来评估跨链协议，该框架基于它们在安全，活跃性和抗审查性方面提供强大保证的程度。由于此类故障对目标链上 Uniswap 协议部署的潜在影响，因此对安全性和活跃性的权重更高。

桥评估方法

委员会的评估方法包括三个主要要素：

一个用于评估跨链协议的综合框架。此框架在下方 链接。

协议必须跨框架的各个维度满足的明确标准和质量标准，以满足 Uniswap DAO 对其跨链治理用例的要求。

一个用于评估协议的两步流程，旨在优化功效和效率。

下面将更详细地讨论每个要素：

评估框架

跨链协议是复杂的系统，由跨越不同网络和执行环境的众多组件组成。它们需要考虑各种安全考虑因素、假设和权衡，以及协调具有不同激励机制和信任模型的不同参与者。因此，评估跨链协议需要仔细考虑各种因素。

为了确保对这些协议进行全面而一致的分析，有必要采取整体而系统的方法。为此，委员会采用了 跨链风险框架，该框架先前由 [t]（https://crosschainriskframework.github.io/authors/contributions/）[委员会的三名成员](https://crosschainriskframework.github.io/authors/contributions/) 撰写。该框架识别、分类和分析了此类基础设施的设计、实施和运营中固有的关键风险要素。该框架介绍了以下讨论的四个广泛的风险类别：

协议架构风险：包含源于协议设计的风险，包括其主要验证机制和其他在架构上具有重要意义的组件，这些组件会影响与协议相关的基本安全属性、假设和信任模型。

协议实施风险：包括与协议规范的实施相关的风险。构建跨链协议涉及创建复杂的链上和链下组件，同时考虑不同编程语言、框架和执行环境的特性和缺陷。

协议运营风险：指因不同组件的运营安全和管理而产生的各种风险，通常由具有不同信任假设和激励机制的不同参与者承担。这可能包括升级和管理桥智能合约，以及运营链下系统，例如外部验证器节点。

网络风险：跨链协议依赖于对基础网络的安全性和活跃性保证的某些假设。因此，这些协议对其可以提供的保证具有根本性的限制。此风险类别包括跨链协议如何处理任何给定网络中对此类假设的违规行为，以及如何减轻对其他连接的网络和应用程序的影响。

基于跨链风险框架和用例的高级要求，委员会创建了一个专门为满足 Uniswap 需求量身定制的全面评估框架。此评估框架扩展了四个广泛的风险类别，以定义 20 个子类别和 130 多个评估问题。评估框架为推理每个协议的属性和识别关注领域提供了一种有条不紊的方法。

要应用此框架，需要收集和仔细审查各种信息来源。这些信息来源包括文档，例如白皮书、用户指南和技术文档；审计报告；研究论文；源代码，包括智能合约、链下组件、测试和脚本；以及链上和链下数据。此外，还对桥运营商及其业务进行了尽职调查。评估还涉及与桥团队的多次讨论。

完整的评估框架可在此处获得此处。

评估标准

如上所述，评估框架基于 Uniswap DAO 的跨链治理用例的高级规范以及由此产生的特定要求。在高层级，定义了一组理想的属性，用于指导评估框架的应用。

委员会在分析协议时，在许多维度上应用了高标准，并考虑了受损桥对目标链上 Uniswap 协议部署的风险。但是，委员会的要求也因与跨链协议当前状态相关的实际考虑因素而有所缓和。随着该领域的成熟，预计这些标准会不断发展。虽然对这些标准的详细讨论超出了本节的范围，但下面的一些小节中讨论了一些关键考虑因素。

协议架构风险 - 验证机制

委员会评估的所有跨链协议都需要一组验证器来证明跨链消息的有效性。这些协议的安全性取决于这些验证器的诚实和可靠的运营。这些协议依赖于两种模型之一来确保验证器按相应方式运营。第一种模型假设运营这些验证器的实体的声誉以及采取法律行动的可能性会阻止它们的不当行为。此模型称为 权限证明 模型。第二种模型涉及密码经济保证，其中验证器因偏离协议而面临经济处罚。此模型称为 权益证明 模型。因此，协议的验证器集以及管理其行为的机制的合理性是确定协议安全属性的关键因素。

在评估验证器集时，委员会采用了一种整体方法，考虑了多个因素，包括该集的组成、去中心化、运营效率和可持续性。关于验证器集成的组成，委员会审查了每个验证器是否由具有足够规模、声誉和水准的不同法人实体运营。此外，还审查了适用于这些验证器的其他结构性保证，例如合同协议以及基于实体所在地的法律追索权的可能性。这对于部分或全部依赖这些特性的安全性的协议（即权限证明）尤其重要。在分析中，未充分满足这些标准或无法收集到充分尽职调查信息的实体将被排除在外。

同样，验证器集的去中心化也在多个维度上进行了评估。考虑的因素之一是验证器集的大小以及确保安全性和活跃性的阈值。此因素与围绕验证器集的水准和组成的考虑因素结合考虑。这些参数的具体要求是通过从过去黑客事件和协议失败中获得的经验和见解，以及通过分析与多个验证器失败相关的各种合理的风险情景（包括勾结、妥协或外生事件（财务、法律、监管等）的影响）来获得的。此外，委员会还评估了验证器的运营安全实践、正常运行时间以及验证消息的活动。

总之，委员会关注的与协议架构相关的理想属性包括：

高安全性、活跃性和抗审查性，可以可靠地承受合理级别的可能工程故障、黑客攻击、经济攻击和勾结。

由具有明确的基础设施运营经验和成熟度的高素质实体组成的验证器集。

独立、高效、受监控、激励和多样化的验证器集。

强大的密码经济保证，具有充分分散的权益和稳定的代币动态（如果适用）。

对管理验证器集的安全属性以及各个验证器的状态、活动和跟踪记录的公开可审计性。

协议实施和运营风险

到目前为止，实施和运营失败一直是跨链协议最主要的风险来源。因此，该团队应用了高标准和严格的评估程序来发现这些因素可能带来的风险。

委员会关注的与协议实施相关的理想属性包括：

强大而成熟的实施，它是开源的，与协议的规范保持一致，并且具有大量的测试和高质量的审计。

清晰、详细和准确的技术文档，充分描述了协议，包括其设计、安全属性、假设和核心组件。

明确的应急响应机制和程序。

围绕与协议更改相关的治理和运营程序的清晰性和透明度。

管理权限（包括合约升级）应充分分配，并具有明确指定的信任假设以及透明、负责和可执行的治理程序。

对关键协议基础设施的运营的公开可审计性，以及围绕核心不变性和异常行为的监控和警报。

网络风险

在评估网络风险时，委员会检查了协议如何处理各种网络终结性模型，以及源于与终结性相关的任何假设的失败。此外，委员会还检查了协议为防止一个链中的安全故障影响生态系统中的其他连接链并影响协议运营而实施的措施。

注意：协议有很多方法可以达到使其适合 Uniswap DAO 的跨链治理用例的成熟度级别。评估框架很复杂，因为它考虑了协议可以做出的不同的设计、实施和运营决策以及权衡。这可能会使评估框架乍一看难以理解和应用。委员会采取的方法是将评估属性在概念上分为必要类别和有用类别。

必要项包括与协议的技术安全属性相关的属性，并在评估框架（在上方 链接）中标记为高重要性。它们被认为是强制性的，并使用标准计算机科学技术尽可能客观地进行评估。在这方面，使用 IETF RFC 2119 术语，协议必须被评估为安全和实时，并且必须能够在目标环境中面对一系列运营考虑因素时保持安全性和实时性。

有用的属性包括围绕协议的非安全方面的考虑因素。这些包括协议的持续稳定性和可持续性。在这方面，使用 IETF RFC 2119 术语，协议应该具有足够的公众监督、社区支持和最佳实践，以确保在面对不断发展和确定的威胁时稳定运行。

评估流程

委员会遵循一个两步流程来评估协议。第一阶段包括评估协议的核心属性、设计选择和假设；以及对其实施和运营实践的高级审查。在此阶段满足相关标准的协议进入第二阶段。第二阶段包括使用不同的分析技术对所有四个风险类别进行严格的评估，包括更深入地探索源代码以及链上和链下数据。使用此方法来优化委员会的时间和资源。因此，应该注意的是，对于未立即批准使用的协议，通过进一步分析可能会出现更多关注领域。该团队确保在整个过程中与桥团队沟通并获得澄清。

桥评估分析概述

通过委员会的深入研究和各个桥团队的合作，委员会得出结论，Axelar 和 Wormhole 这两座桥显示出足够的前景，可以供 Uniswap DAO 在跨链治理中使用。Wormhole 正在接受持续监控，以了解影响其核心安全模型的更改。Axelar 已获得有条件批准，等待即将发生的从多重签名治理的转变，这将不会影响其核心安全模型。

批准的桥是那些满足必要的安全要求并证明与评估框架显着对齐的桥，尽管建议的改进预计将由每个桥在发展过程中实施。显然，跨链解决方案领域具有相当大的增长潜力，委员会强烈鼓励协议将风险框架用作指导资源。

委员会的评估仅限于桥的默认设置，该设置易于获得，无需额外的开销。

名称	自以下时间起生效	结论	分析总结
Wormhole	2021 年 8 月	委员会批准在所有跨链部署中使用。	对 Wormhole 的分析得出结论，就其当前状态而言，它满足评估框架中概述的 Uniswap DAO 跨链治理用例的要求。验证器集包含许多信誉良好的实体，并且验证器的数量和安全阈值都设置为令人满意的级别。此外，协议的实施及其运营实践似乎经过了充分的考虑，自 2022 年 2 月的漏洞事件以来，其 DevSecOps 实践和事件响应程序已进行了重大改进。但是，委员会发现了一些需要改进的领域，并建议定期监控任何可能影响协议安全状况的重大变更。
Axelar	2022 年 1 月	委员会批准在所有跨链部署中使用，但如果到 2023 年 7 月 31 日多重签名尚未更新，则重新评估	对 Axelar 的分析得出结论，它有条件地满足评估框架中概述的 Uniswap DAO 跨链治理用例的要求。Axelar 采用具有健全密码经济保证的权益证明机制来保护协议。该协议设计的各个方面似乎都经过了充分的考虑。验证器集的大小以及确保安全性和活跃性的阈值是足够的。它的技术堆栈构建符合高标准，并且该团队保持良好的开发实践，对细节高度关注并积极进行持续改进。委员会关注的一个来源是管理协议关键方面的 4/8 多重签名。Axelar 已传达其计划在 2023 年第二季度放弃对此多重签名的依赖，委员会对此过程进行了权衡。委员会建议 Uniswap DAO 采用 Axelar，前提是成功过渡到放弃此多重签名。此外，委员会建议持续监控更新以识别协议中需要改进的领域。
LayerZero	2022 年 3 月	建议根据待处理的升级进行重新评估。	在评估当前版本的 LayerZero 协议后，委员会得出结论，它目前不满足评估框架中概述的 Uniswap DAO 跨链治理用例的全部要求，但正在朝着实现这一目标的方向发展。LayerZero 采用两种类型的验证器组合来保护协议：预言机和中继器。但是，目前，预言机和中继器的可用选项未提供 Uniswap 用例所需的去中心化和安全性级别。LayerZero 计划对其预言机和中继器集进行升级，这可能会解决这些问题。<br>对计划更新的粗略分析很有希望。委员会承认 LayerZero 正在用于 Avalanche 部署。委员会鼓励 LayerZero 团队迅速采取行动来实施此升级，并建议在新的配置已运行至少三个月并已达到足够的使用量后重新评估该协议，因为验证器集的性能是协议可以围绕安全性和活跃性提供的保证的关键因素。<br>注意：LayerZero 的评估是在其最近的更新之前进行的，该更新采用 ZK 客户端作为额外的验证选项。此更新可能会解决委员会确定的一些关键问题，但尚未进行评估。
Celer	2022 年 1 月	建议监控发展，以便在未来几个季度重新审视。	在评估当前版本的 Celer 协议后，委员会得出结论，它目前不满足评估框架中概述的 Uniswap DAO 跨链治理用例的要求。Celer 采用权益证明机制来保护协议。但是，当前权益的分配以及缺乏正常运行的削减机制，引发了对协议可以提供的安全保证的担忧。此外，围绕验证器集的操作以及管理重要协议更新的操作流程缺乏透明度，突出了需要显着改进的领域。在代码库的成熟度方面也存在显着改进的领域，例如进行更高质量的审计和改进文档。委员会认识到该团队正在努力解决这些问题，因此建议 Uniswap 社区在至少六个月后重新评估该协议，前提是这些问题得到实质性改善。
DeBridge	2022 年 2 月	建议监控发展，以便在未来几个季度重新审视。	在评估当前版本的 deBridge 协议后，委员会得出结论，它目前不满足评估框架中概述的 Uniswap DAO 跨链治理用例的要求。deBridge 采用权益证明机制来保护协议。尽管该协议目抢跑正常并成功处理消息流量，但预计其某些安全保证将在引入 deBridge 治理代币并实施其计划的削减和委托质押系统后发生变化对于那些满足 Uniswap DAO 跨链治理用例要求的桥，已包含整个评估框架的摘要。对于那些不满足 DAO 跨链治理用例要求的桥，下面是相关问题的总结。所有桥团队都收到了更详细的评估报告，其中包括委员会的进一步建议。

桥评估

虫洞（Wormhole）

Axelar

LayerZero

Celer

deBridge

Multichain

架构建议

正如在需求部分中讨论的那样，Uniswap DAO 的跨链治理流程需要强大的安全保障。虽然委员会的严格评估有助于识别众多风险并选择具有良好安全属性的协议子集，但重要的是要承认跨链协议仍然可能因各种原因而受到损害或失败。由于这种失败对 Uniswap DAO 的潜在影响可能很大，因此有必要考虑提供更好抵抗此类失败的方法。此外，正如在安全挑战 4中讨论的那样，如果协议安全失败，利益相关者可能没有足够的时间做出响应并减轻无效跨链治理消息的影响。此外，各个桥协议的评估并未直接解决未来跨链治理状态的可扩展性和灵活性要求。

为了解决这些限制，委员会建议社区考虑对 Uniswap DAO 的跨链治理进行以下两项结构性更改：

1. 目标链上的时间锁合约

目前，从以太坊发送到远程 Uniswap 协议部署的所有治理消息在收到后会立即执行。这给远程部署带来了重大安全风险。如果桥受到攻击，可能会在远程部署上创建并执行无效的治理消息，而不会给利益相关者任何反应时间。

目标链上的时间锁合约可以通过延迟任何治理消息的执行一段时间来解决此问题。有关此方法的设计注意事项和具体建议，请参见附录 3。

2. 用于跨链治理的多桥架构

提高 安全性并实现 Uniswap DAO 跨链治理的可扩展性和灵活性的一种有前景的方法是使用多桥架构。这种方法将多个经过验证的桥合并到一个统一的跨链基础设施中，用于中继消息。从以太坊通过此基础设施发送的跨链消息同时通过多个跨链协议进行中继。在目的地，收集来自各个桥的消息。如果法定数量的桥中继同一消息，则认为该消息有效，并执行关联的操作。

这种方法具有几个关键优势。首先，它通过跨多个桥验证跨链消息来提高安全保障。其次，它通过多个桥提供冗余来提高活跃性和审查阻力保证。第三，它为不同 Uniswap 部署中的跨链治理提供了一个通用架构。这减少了与集成新 Uniswap 协议部署相关的现有摩擦、延迟和风险，使其更具可扩展性。它还通过允许更无缝地集成新的跨链协议以及随着时间的推移逐渐淘汰不再使用的协议来实现灵活性。

附录 3 讨论了与多桥架构相关的架构注意事项，并分析了三种潜在的解决方案：Hashi、多消息聚合 (MMA) 和 Hyperlane。虽然这些解决方案尚未投入生产，但委员会建议 Uniswap 社区监控其发展，并在出现满足 Uniswap DAO 要求的成熟解决方案后最终迁移到多桥架构。

结论

总之，Uniswap 基金会桥评估委员会的成立揭示了为 Uniswap DAO 的跨链治理用例选择和集成桥所固有的挑战和复杂性。委员会的调查结果强调了跨链空间的复杂性，以及持续检查和改进桥的必要性。

委员会认为，虫洞和 Axelar 桥目前适合 DAO 用于管理未来跨链部署中的治理消息，但建议社区持续审查它们和其他桥提供商。

重要的是要承认评估过程的局限性，并提供具体的建议来降低与已批准协议相关的风险。虽然进行了严格的评估，但委员会可能无法完全了解某些方面，这可能会导致协议中未发现的潜在问题领域。此外，评估代表了特定时间点的快照，并未考虑未来可能发生的潜在重大变化。

为了解决这些限制并加强我们的风险缓解措施，委员会提出以下建议：

定期评估已批准的协议：对已批准的协议进行定期评估，以确保持续了解其运营方面并识别任何新出现的问题。这将使 Uniswap 社区能够保持对协议安全性和有效性的最新了解。

自动监控关键属性和不变量：为 DAO 用例批准的跨链协议实施自动监控工具可以帮助我们持续监控其关键属性和不变量。通过为相关事件设置警报，Uniswap 社区可以及时响应可能影响协议完整性的任何潜在安全问题或变更。探索可用的 SaaS 工具来实现此目的可以提供有价值的见解并增强我们的监控能力。

与桥团队签订合同协议：委员会建议与桥团队建立合同协议，其中概述了向 Uniswap 基金会披露的特定要求。这些协议将包含两种类型的披露，旨在确保透明度并为基金会提供必要的信息，以便有效地响应与安全相关的事件和协议变更：

a. 及时披露影响协议安全的事件：桥团队有义务披露任何可能对协议安全产生重大影响的事件。这将包括披露对验证者集的大小、质量或功效的任何更改，以及修改安全参数（例如多重签名阈值或验证者阈值）的计划。这种主动披露将使基金会能够评估影响并在必要时采取适当的措施。

b. 计划的协议变更的充分通知期：桥团队需要为计划的协议变更向基金会提供足够的通知期，这些变更将影响 Uniswap DAO 对相关桥的实施。例如，如果某个协议决定删除对特定链的支持，则将给予基金会充足的时间来启动治理流程并对阈值或其他相关参数进行必要的更新。

通过实施这些建议，Uniswap 基金会旨在加强 DAO 的风险管理实践，并确保 Uniswap 社区能够充分应对任何潜在的安全事件或协议变更。透明度、定期评估、自动监控和合同协议将有助于建立更安全、更强大的跨链治理基础设施，从而提高 Uniswap 协议生态系统的整体弹性。

桥委员会成员

桥评估委员会的遴选过程包括全面的评估，其中包括深入的面试、参考调查、评估他们在桥方面的专业知识以及确保公正性。这些成员包括：

姓名（A→Z）	社交	背景
Ben O’Neill	领英 | 推特	前 Chaos Labs 业务运营副总裁
David Hyland-Wood	领英	跨学科工程师，曾任 ConsenSys Software 的首席研究员
Ermyas Abebe	领英 | 推特	跨链风险框架的共同开发者，这是一个用于评估跨链协议风险的综合资源，之前是 ConsenSys 的首席研究科学家
Jasraj “Jazzy” Bedi	领英 | 推特	Zellic 的联合创始人、CTO
Kimberly Adams	领英 | 推特	Bridge Network 的前联合创始人
Mikerah Quintyne-Collins	推特	HashCloak 的创始人、CEO
Peter Robinson	领英 | 推特	Immutable 的区块链研究主管，也是跨链风险框架的共同开发者
Robert Chen	推特	OtterSec 的创始人、CTO
Sean Casey	领英	Enzyme 的联合 CTO、协议开发主管（Avantgarde）

附录 1：Uniswap DAO 的跨链治理用例的要求和约束

Uniswap DAO 跨链治理用例的主要功能要求是能够将治理消息从以太坊发送到远程链以供执行。因此，此要求在设想的未来状态中保持不变。至少，这应包括目前部署 Uniswap 协议的十个远程链。

以下是关于此用例范围的特定假设：

治理场所：以太坊主网上的 Uniswap 协议时间锁合约 是跨链部署治理决策的唯一来源。

单向消息传递：跨链消息仅从以太坊流向远程部署。

决策终局性：所有跨链消息都封装了与远程部署相关的最终治理决策。一旦批准执行治理决策，就无法取消。

仅限 EVM 链：远程链的执行环境是以太坊虚拟机。

以下是关于此用例的非功能特性的假设：

低频率：影响远程部署的协议级治理变更很少发生。

延迟容忍度：治理行动不是时间关键型事件，可以容忍一定的延迟。

成本：由于该用例涉及不常见的跨链消息传递并具有较高的延迟，因此跨链交易和桥接成本不是重要的约束因素。

基于以上定义的范围，委员会确定了与 Uniswap 协议跨链治理的未来状态相关的几个关键的非功能性需求和约束。这些是：

安全性：拟议的解决方案应首先确保只有来自 Uniswap 协议以太坊治理合约的有效治理消息才能传输到目标链，并且所有此类消息都应及时中继。

可扩展性：拟议的解决方案应通过减少与集成新的 Uniswap 协议部署相关的当前摩擦和风险，使 Uniswap DAO 能够无缝地将 Uniswap 协议扩展到其他链。此外，Uniswap DAO 的跨链治理用例可能会超出其当前定义的范围发展。因此，拟议的解决方案应具有足够的可扩展性以支持这些不断发展的需求。

灵活性：跨链协议正在迅速发展。新的协议将继续出现（例如，有效性证明桥），而现有协议可能会失效或发生重大变化。适应此类变化，同时最大限度地减少对远程链上 Uniswap 协议部署的干扰和风险的能力将是一个重要的考虑因素。

最大限度地降低复杂性和开销：某些跨链协议可能需要大量的集成工作和运营开销才能用于该用例。这可能包括需要特定于应用程序的基础设施、召集新的验证器集或需要显着额外的开发和维护工作。这些因素可能会引入新的信任假设、安全权衡和风险来源，同时还会增加复杂性和成本。

这些要求指导了委员会关于 Uniswap 协议跨链治理理想未来状态的建议。这些建议在附录 2 和 3 中单独讨论。另一方面，委员会对特定协议的评估主要受安全要求的指导，如下文进一步讨论的要求以及与最大限度地降低复杂性和开销相关的约束。

跨链治理中的安全性

要了解与跨链治理相关的安全挑战，首先了解以太坊上治理 Uniswap 合约所附带的隐式安全保证非常有用。这些是：

保证 1：根据协议的链上治理流程，更新 Uniswap 合约的任何治理行动都保证有效。

保证 2：任何已批准的治理行动都保证最终执行。

保证 3：如果利益相关者不同意已批准的治理行动，他们有足够的时间在相关变更生效之前选择退出协议。

在管理远程部署时，必须首先使用跨链协议将治理决策从以太坊中继到远程部署。这会带来安全风险，因为此类协议可能会以几种关键方式失败：

瞬时故障：这种类型的故障可能涉及跨链基础设施或底层网络的临时中断，导致消息延迟或丢失。跨链协议通常旨在通过在服务恢复后重试来优雅地处理这些情况。由于治理用例可以容忍高延迟，因此这些类型的故障被认为是良性的。

永久性或长时间的故障：这种类型的故障可能会永久切断与远程 Uniswap 部署的跨链治理链接。

拜占庭故障：已完全或部分受损的桥会给 Uniswap DAO 带来各种风险。此类故障可能对远程部署产生的影响包括：

主动审查消息（效果类似于永久性或长时间的故障）。

在多桥架构的上下文中，质疑其他桥发送的有效治理消息。

将无效的治理消息提交到目标链。

因此，Uniswap 协议的跨链治理面临以下关键安全挑战：

挑战 1（安全故障）：受损的跨链桥可能导致在远程部署上提交和执行无效的治理行动，从而违反安全保证 1。

挑战 2（活跃性故障）：单个跨链桥的长时间故障可能会显着延迟或完全阻止远程部署的治理，从而违反安全保证 2。

挑战 3（审查）：任何具有足够控制权的实体（或实体组）都可以阻止有效治理消息传递到已部署的链，从而违反安全保证 2。

挑战 4：如果桥受到攻击，可能会立即创建并在远程部署上执行无效消息，从而使利益相关者没有时间做出反应，从而违反安全保证 3。

附录 2：多桥设计注意事项

Uniswap DAO 的跨链治理流程需要强大的安全保证。尽管委员会的严格评估有助于发现显着风险并确定具有良好安全属性的协议子集，但重要的是要承认跨链协议仍然可能因各种原因而受到损害或失败。这种失败对 Uniswap DAO 的潜在影响可能很大。因此，对于 Uniswap 协议跨链治理的未来状态而言，必须能够抵御任何特定跨链协议的故障。

提高跨链治理的安全性和弹性的潜在方法是多桥架构。这种方法将多个经过验证的桥合并到一个统一的跨链基础设施中，用于中继消息。从以太坊通过此基础设施发送的跨链消息同时通过多个跨链协议进行中继。在目的地，收集来自各个桥的消息。如果法定数量的桥中继同一消息，则认为该消息有效，并执行关联的操作。

这种方法具有以下主要优点：

通过跨多个桥验证跨链消息来提高安全保证。

通过多个桥提供冗余来提高活跃性和审查阻力保证。

通过允许更无缝地集成新的跨链协议以及随着时间的推移逐渐淘汰不再使用的协议来提高灵活性。这也减少了供应商锁定，尤其是在与跨链标准接口（例如 ERC-5164）结合使用时。

为不同 Uniswap 协议部署链中的跨链治理提供通用架构。这可以减少与新 Uniswap 协议部署相关的摩擦、延迟和风险，以及与提出跨链治理行动相关的摩擦、延迟和风险。

但是，这种方法会增加跨链治理的复杂性、开销和成本。因此，仅在 此架构的优势非常大时才建议使用。具体而言，一旦确定了足够数量的满足用例最低要求的桥（委员会建议三个，根据下文中的讨论），将为 Uniswap 协议的 L1 和侧链部署提出一种多桥架构。排除 L2 部署的基本原理在 附录 4 中讨论。此外，该提案承认目前没有多桥基础设施的成熟实现。因此，它讨论了相关的实施和运营考虑因素。

架构注意事项

本节讨论多桥架构的关键架构注意事项。它首先概述要考虑的故障模式，然后使用它来讨论核心安全注意事项，最后概述围绕消息结构和语义的注意事项。

故障模式

跨链协议可能会以各种方式失败。每种故障的可能性及其影响可能差异很大。多桥架构应考虑各个桥和多桥基础设施的故障模式。以下进一步讨论这些故障模式。

单桥故障模式：

瞬时故障：这种类型的故障可能涉及跨链基础设施或底层网络的临时中断，导致消息延迟或丢失。跨链协议通常旨在通过在服务恢复后重试来优雅地处理这些情况。由于治理用例可以容忍高延迟，因此这些类型的故障被认为是良性的。

永久性或长时间的故障：这种类型的故障构成了永久切断与远程 Uniswap 协议部署的跨链治理链接的风险。

拜占庭故障：已完全或部分受损的桥会给 Uniswap DAO 带来各种风险。此类故障可能对远程部署产生的影响包括：

主动审查消息（效果类似于 1.b）。

在多桥架构的上下文中，质疑其他桥发送的有效治理消息。

将无效的治理消息提交到目标链。

多桥故障模式：在多桥架构中，故障可能来自单个桥（如上所示），也可能来自 与多桥基础设施本身相关的合约和组件。根据影响范围，委员会确定了两类故障模式：

非仲裁故障：这些类型的故障会影响小于验证治理消息所需的仲裁数量的桥的子集。在这种故障存在的情况下，多桥基础设施仍然可以正常工作，因此可用于中继解决该问题的补救性治理更新。

仲裁故障：这些类型的故障会影响法定数量的桥，从而导致多桥基础设施完全故障。此类别中的故障模式在效果上可能与 1.b 或 1.c. 中描述的故障模式相似。

安全

多桥架构可以提高对单个桥的故障的弹性（1 类故障）。但是，仅仅聚合跨链协议是不够的，甚至可能会增加 Uniswap DAO 面临的跨链故障影响，这可能会导致仲裁故障（2.b 类）。

本节讨论确保附加安全性的两个核心注意事项。

桥集

桥集是指由多桥基础设施聚合的跨链协议。其大小和组成是多桥基础设施安全性的重要决定因素。

大小：为了从此架构中获得有意义的收益，需要有足够数量的桥（最好是具有不同的架构）来构成桥集。为此，至少需要三个桥协议。这是因为具有两个桥（假设为 2-of-2 仲裁）的多桥设置可以提高安全性，但也会增加活跃性失败的风险。如果其中一个桥发生故障，则整个通道都会发生故障，而无法通过第二个桥进行补救。三个桥（假设为 2-of-3 仲裁）能够容忍一个桥的故障。虽然预计更多的桥可以提高附加安全性，但在超过一定程度后，附加桥的收益可能会变得微不足道，尤其是在考虑到管理大型桥集中不断增加的成本和复杂性开销时。确定上限要等到有足够的协议满足纳入的严格要求时才能确定。

组成：集合中每个桥的安全属性都会影响多桥协议的安全性。因此，至关重要的是要确保多桥架构中的每个桥都满足本报告中概述的安全要求和评估标准。这降低了单个桥出现故障的可能性（1 类故障），从而降低了仲裁故障的可能性（2.b 类）。

与桥集的组成相关的另一个设计考虑因素是，是否应在所有远程 Uniswap 协议部署中使用相同的桥集，或者是否应根据需要按链变化。前者提供了一个概念上更简单的模型，但要求集合中的所有桥都支持将部署 Uniswap 协议的每个链。实际上，这会产生许多约束：

它将链特定的桥排除在桥集之外。

它要求桥集中的所有桥继续支持将部署 Uniswap 协议的所有链，这很难保证。

它阻止包含可能提供更高安全性但未与所有必需链建立连接的桥（例如，zk 桥）。

Uniswap 协议在链上的扩展将受到桥集中连接性最差的桥的约束。

出于这些原因，建议多桥架构的设计在桥集在不同目标之间的组成中提供灵活性。

桥仲裁

在多桥架构中，仅当法定数量的桥证实跨链消息时，才认为消息有效。此法定数量通常涉及安全性和活跃性之间的权衡。

两个极端说明了这种权衡。安全阈值为“n-of-n”（其中 n 是集合中桥的数量）会显着提高安全性，但会降低活跃性，因为单个桥的故障会停止系统。另一方面，阈值为“1-of-n”会显着提高活跃性和抗审查性，但会降低安全性，因为单个桥的故障（1.c 类）会危及系统。

因此，仲裁阈值应基于各种注意事项来平衡安全性和活跃性。随着集成更多桥，远程 Uniswap 协议部署会更多地暴露于桥故障，因此阈值应考虑这一点。此外，阈值应确保集合中最多可以达到一个仲裁。这可以防止以下情况：受到攻击的桥的仲裁阻止了诚实仲裁的运行（1.c.ii 类）或违反了安全性（1.c.iii 类）。因此，委员会暂时建议使用多数 (>50%) 作为安全阈值。

实施注意事项

多桥架构的实施主要包括一组链上合约，这些合约在 Uniswap 协议合约和特定的桥消息合约之间建立接口。虽然这是一个相对较薄的层，但它仍然存在实施风险的可能性。

目前，没有多桥架构的实现是完整的、经过实战检验的，并且适合 Uniswap DAO 的跨链治理用例。评估框架定义了一系列用于评估和降低实施风险的标准，委员会建议 Uniswap 社区将其应用于正在考虑的多桥选项。此外，Uniswap 基金会正在资助进一步的工作，以构建特定于多桥架构的评估框架。

此外，委员会建议 Uniswap 社区考虑使用跨链通信标准接口用于桥适配器。这可以降低复杂性、开销和运营风险。委员会简要审查了 ERC-5164 作为实现此目的的可能候选者，并认为它很有希望。但是，需要进一步分析以确定此标准是否考虑了各种跨链协议的各种特性。

委员会审查了三个多桥项目的进展，以评估当前的格局：Hashi（由 Gnosis 提供）、Hyperlane 和多消息聚合 (MMA)。

Hashi

Hashi 是一种通过源链上的一组“中继器”跨链调度任意哈希的协议，然后由目标链上相应的“预言机”获取。应用程序可以定义自己的预言机集和仲裁阈值，并在目标链上执行哈希满足仲裁要求的消息。（Hashi 最初是为了调度区块头而设计的，然后可用于为单个消息提供 Merkle 证明，尽管该团队已将该机制推广为支持任何哈希，包括原始消息。从长远来看，区块头路由仍然可以证明更有效和更方便，因为单个区块中包含的消息和其他数据是一对多的）。

积极评价

它是一种独立的产品，专为跨链消息传递中的附加安全性而构建。

Gnosis 支持，可能会得到很好的维护并在生态系统中使用。

用于多桥消息传输的最通用的、最小状态架构。

注意事项

尚未投入生产

正在进行审计

尚未提供漏洞赏金

Hyperlane

Hyperlane 是一种通用消息传递协议，允许应用程序使用“ISM”（链间安全模块）定义任意消息验证逻辑，或者使用其自己的 PoS 验证器集。从理论上讲，由于允许使用任何符合 ISM 接口的智能合约，因此应用程序可以将任意验证组合在一起，例如聚合多个其他桥的结果。换句话说，它可以纯粹用作多桥聚合架构。

积极评价

用于生成消息、接收消息以及通过 ISM 验证这些消息的核心逻辑已经过审核并且已经看到了有意义的消息吞吐量

Hyperlane 允许应用程序选择不同的验证机制，从而原生支持多桥设计。

Hyperlane 提供 250 万美元的大量 Immunefi 漏洞赏金

注意事项

虽然 Hyperlane 提供了有关如何使用其 AggregationISM 实现多桥的文档和指南，但特定桥的 ISM 和调度Hook实现仍然是必需的。

尚不清楚（尚未评估）Uniswap DAO 是否希望使用 Hyperlane 验证器作为其验证机制的一部分。

当前，Hyperlane 多重签名可以完全升级核心邮箱合约。这会产生多重签名接管或破坏远程链上 Uniswap DAO 所有权的可能性。为避免此风险，Uniswap DAO 可以部署其自己的邮箱合约。但是，需要仔细考虑此类合约的可维护性。

多消息聚合 (MMA)

MMA 是一个从 Uniswap 论坛构思的项目，专门用于为 Uniswap DAO 提供多桥架构。它通过源链和目标链上符合 ERC-5164 的桥适配器来调度消息。它允许应用程序定义桥集和仲裁阈值。迄今为止，MMA 由 Celer 团队成员和 Uniswap 社区成员构建。在本报告的制作过程中，另一个项目表示有兴趣帮助开发和维护 MMA 代码库，Uniswap 基金会正在帮助协调这些参与者以推动该项目向前发展。

积极评价

由于 MMA 是专门为 Uniswap DAO 构建的，因此从理论上讲，代码复杂性不应超出 Uniswap DAO 的用例要求

到目前为止，该团队已表示愿意与委员会的建议合作，以满足架构和测试覆盖率需求

一个新的团队已经与基金会联系，希望参与研究、开发和维护

桥适配器尝试实施 ERC-5164（尚未完全评估）

注意事项

由于 MMA 是专门为 Uniswap DAO 构建的，因此由于 DAO 将是其第一个也是唯一的用户，因此很难将该架构视为经过实战检验的架构

由于 MMA 专门为 Uniswap DAO 构建，因此需要考虑协议的长期维护

多桥运营注意事项

委员会建议以下关于多桥架构的运营注意事项。

谨慎迁移：建议分阶段采用多桥架构。虽然这可能会增加开销，但它可以显着降低现有 Uniswap 部署的风险。此渐进式迁移的具体细节应在日后确定。 加速跨链治理行动：一旦桥出现故障，Uniswap DAO的治理机构必须能够迅速对桥集和仲裁阈值进行相关的配置更改，这一点至关重要。未能做到这一点可能会导致在先前的问题得到解决之前发生后续故障，从而增加仲裁失败的风险（类型 2.b），从而破坏安全性和活跃性。 虽然这种情况不太可能发生，但后果仍然很严重，并且会影响所有依赖多桥架构的 Uniswap 远程部署。 因此，必须尽可能降低这种风险。

当前的治理流程无法实现及时的事件响应。 因此，委员会鼓励社区探索各种方案，以加快此目的的安全关键治理行动的流程。

持续监控：委员会建议 Uniswap DAO 采用相关基础设施来监控构成桥集的关键属性和不变量。 这使 Uniswap 社区能够及早发现需要缓解的潜在关注源。

定期评估：委员会建议 Uniswap 社区定期评估桥集中的各个桥，以确保它们满足协议的严格安全要求。

委员会的建议

委员会认为，Uniswap DAO 的需求最好通过多桥架构来满足。 然而，当前的多桥项目仍在开发中，尚未准备好投入生产。 在该领域不断成熟的同时，委员会就未来采用多桥架构提出以下具体建议：

Uniswap 基金会资助一项评估 ERC-5164 作为各种跨链协议的标准接口的适用性的工作。 此评估可以与桥团队协商进行，他们对协议的特定设计功能有更好的了解。

如果 ERC-5164 被认为是合适的标准，委员会建议 Uniswap 基金会要求选定的桥为其协议构建符合 ERC-5164 的桥适配器。

与多桥协议团队合作，确保他们开发并集成 ERC-5164 兼容桥适配器的连接器。

附录 3：跨链治理流程

时间锁

目前，从以太坊发送到远程 Uniswap 部署的所有治理消息在收到后立即执行。 此模型如下图所示，由 Polygon、Arbitrum、Optimism、Celo、BNB 和 Avalanche 上的所有 Uniswap DAO 跨链桥实施。

这对远程部署的利益相关者构成风险。 如果桥被破坏，则可能会在远程部署上创建并执行无效的治理消息，而利益相关者没有时间做出反应。 此问题被确定为 Uniswap DAO 跨链治理未来状态应解决的安全挑战之一（即安全挑战 4）。

为了解决之前陈述的问题，委员会建议在以太坊主网上的时间锁旁边使用目标链上的时间锁。 此解决方案涉及在收到治理消息和执行治理消息之间增加一段特定的时间。 通过实施时间锁，利益相关者有时间对可能由受损的桥创建的任何无效治理消息做出反应。

远程链上的此时间锁应在以太坊上完成治理时间锁后进行。 在此模型中，远程时间锁的目的仅在于减轻由受损桥造成的无效治理行动的影响。

总的来说，这是一个简单的解决方案，只需要更改远程部署，而不需要更改以太坊上的治理合约。 扩展的时间锁使不同意有效治理行动的利益相关者有更多时间选择退出协议，这总的来说是积极的，但代价是由于需要通过两个时间锁，远程链上的治理行动速度较慢。

此选项可以为每个远程部署单独实施，从而可以分阶段将现有部署迁移到此流程。 它可以首先应用于新部署，然后逐步推出现有的 Uniswap 协议桥。 因此，新链的部署不需要任何额外的治理开销； 迁移现有部署的提案和实施方案必须进行社区投票。

消息验证检查

委员会建议执行以下三个额外的消息验证检查，以进一步确保跨链治理执行的完整性，并减轻潜在的攻击媒介。

消息过期：未能成功在远程部署上执行、被放弃或被另一条消息取代的跨链治理消息可能会被重新提交，并在未来某个时间由某人执行，从而导致未知的效果。 如果导致消息第一次失败的条件在第二次执行期间不再成立，则可能会发生这种情况。

解决此问题的一种方法是为消息定义一个生存时间 (Time-To-Live)，之后这些消息将被视为已过期且无效。 该持续时间应考虑潜在的网络拥塞和远程网络上的活跃性故障。 此类事件的可能性可能因每个链而异。 延迟还应考虑底层桥的任何重大延迟特征，例如乐观桥接协议，以及桥停机的可能性。

消息排序：已批准彼此接近的跨链治理消息可能需要按特定顺序应用，其中一条消息依赖于另一条消息已被首先执行。 但是，由于跨链治理消息的执行是无需许可的，因此实体可能会在第一条消息之前执行第二条消息，从而导致意外的影响。

为了解决这个问题，一种方法是让基于 nonce 的消息单元排序。 在这种方法中，发送方合约将递增的 nonce 包含到每条消息中。 目标链检查以确保每条新消息的 nonce 都来自先前执行的消息。

但是，这种方法需要健全的重试机制，以便无法执行特定消息不会阻止后续消息的执行。 此外，如果消息过期机制到位，则需要一种使用过期消息的 nonce 的方法。 还应考虑与此方法相关的其他极端情况。

消息重放保护：重新执行已执行的跨链治理消息可能会对 Uniswap 协议部署产生意外的影响。 必须采取保护措施来防止这种情况发生。 尽管有多种解决此问题的方法，但如上所述，拥有消息排序方案可以隐式地提供此保护。

这些验证主要将在桥适配器中实施，尽管底层协议可能会部分支持上述某些功能。 例如，LayerZero 通过每个应用程序的顺序 nonce 来强制执行消息排序，而 Wormhole 不保证消息排序。

委员会建议 Uniswap 社区认真考虑上述建议，并在现有和未来的 Uniswap 协议部署中实施这些建议。 这些建议已经生效于 Wormhole 桥适配器中，该适配器目前正在 BNB、Gnosis 和 MoonBeam 部署中使用。 适配器实施与上述建议之间的一个主要区别是，Wormhole 适配器使用单调递增的 nonce 序列，而不是单元序列 nonce。 为了解决对消息排序的担忧，委员会建议今后使用单元序列 nonce。

附录 4：原生桥与治理标准化

背景

随着 Layer 2 在以太坊的可扩展性路线图中变得越来越重要，并且多个此类协议获得了有意义的吸引力，Uniswap 协议在此类链上的部署可能会增加。 目前，Uniswap V3 已部署在四个以太坊 Layer 2 协议上：Arbitrum、Optimism、zkSync 和 Boba，以及部署到 Polygon zkEVM 和 StarkNet 的活跃提案。

Layer 2 (L2) 协议与其底层 Layer 1 (L1) 紧密相连，并从中获得安全性。 因此，两者之间的原生桥通常是两者之间最安全的通信通道。 因此，Uniswap DAO 已将原生 L2 桥用于 Arbitrum 和 Optimism 部署。

通过委员会的研究，我们研究了是否应根据设想的 Uniswap DAO 跨链治理架构的变更来更改使用原生桥进行 L2 部署的模型。 具体来说，我们考虑了 Uniswap 协议到以太坊 L2 的部署是应使用批准的桥还是未来的多桥架构，而不是 L2 的原生桥。

请注意，本文档不涵盖 Polygon 等侧链。 虽然它们通常被称为 Layer 2 解决方案，但它们在技术上不是 Layer 2，因为它们不会直接从以太坊继承安全性。

L2 原生桥的背景

L2 与其底层 L1 之间的通信涉及两个具有不同安全属性的不同方面：

从 L1 发送到 L2 的消息（L1→L2，称为“存款”），以及

从 L2 发送到 L1 的消息（L2→L1，称为“提款”）

后者需要验证机制，例如欺诈和有效性证明，以使 L1 确信 L2 中的状态。 然而，前者是我们用例的主要关注点，本质上是无需信任的。 这是因为 L2 的规范交易账本位于 L1 中。 L1 上的合约提交给 L2 的消息会自动包含在 L2 的账本中，供 L2 的验证器和节点处理。 因此，此过程不需要任何其他中介，并且是 L2 自身系统的组成部分。 这使得 L1→L2 通信通道从设计角度来看是最安全的选择。

但是，L2 桥仍然存在实施和运营风险。 例如，2022 年底在 Arbitrum 的桥上发现了一个严重漏洞，并且大多数 L2 桥合约仍然可以由主要中心化的各方升级。 因此，从理论上讲，可以通过 L2 桥发送无效消息，或者消息可能无法传递（违反安全要求 1）。 然而，与其他桥不同的是，由于 L1→L2 桥是 L2 系统的组成部分，因此任何此类破坏都可能影响 L2 中的所有应用程序，并且需要链重组。

决策选项

L2 部署的跨链治理未来状态有两种选择。 第一种是维持现状，并进行少量更改以改善边缘的安全性。 第二种选择是使用多个桥与远程 L2 部署进行通信，以提高安全性和弹性。 上一节中讨论了每一个选项。

选项 1：对 L2 部署使用原生桥

此选项涉及继续仅对现有和未来的 L2 部署使用原生桥。 虽然各个 L2 桥的具体设计结构存在差异，但原生桥的一般安全属性是相同的。

优点：

简单性：该方法没有引入任何用于在以太坊和远程 L2 部署之间进行通信的新基础设施。 它仅依赖于 L2 的核心基础设施（即，L1→L2 桥）。

低成本：只需中继一条消息即可在 L2 部署上生效治理行动。 这会产生相对较低的交易和桥接成本。

低迁移工作量：此选项不需要迁移到新架构，从而降低了成本、工作量、延迟，并且无需社区治理参与。

成熟度：L2 的 L1→L2 桥是 L2 链的组成部分，该链已经过大量实战测试，并被与该生态系统交互的许多其他应用程序使用。

缺点：

安全性：此远程部署暴露于规范桥的实施和运营风险。 例如，2022 年底在 Arbitrum 的桥上发现了一个严重漏洞，并且大多数 L2 桥合约仍然可以由主要中心化的各方升级。

运营工作量：不同的 L2 具有不同的桥接口。 这些差异给治理行动的提案者的工作增加了一些复杂性，从而引入了摩擦、风险和延迟。

选项 2：对 L2 部署使用多桥架构

此选项涉及统一 L2 的跨链治理架构与 L1 和侧链的跨链治理架构。 具体来说，使用多个桥（包括原生桥）与 L2 部署进行通信。 这样做主要原因是为了提高安全性和弹性。 尽管需要澄清许多技术细节才能准确评估此选项的可行性，但下面提供的广泛分析足以与选项 1 进行比较。

优点：

安全性和弹性：使用多个桥可以实现累加安全性，这可以降低与底层 L2 桥故障相关的风险并提高弹性。 Arbitrum 桥到 Uniswap 协议在那里部署的失败可能是通过拥有冗余的通信通道来帮助该模型的示例。

减少运营工作量：该选项提供了一个统一的接口，通过该接口可以与 L2、L1 和侧链进行交互，从而可能减少集成和运营工作量。

缺点：

增加复杂性：将新的基础设施引入 L1→L2 通信通道，这会产生新的实施和运营风险来源。

增加多桥架构的复杂性：包含 L2 桥可能会强制将其他功能和复杂性引入多桥架构。 例如，可能需要考虑为各种桥添加权重以对齐隐含的安全性，或者为不同的目标配置动态阈值。

增加成本：该方法需要发送与连接 L1 和 L2 的桥一样多的消息，从而增加了交易和桥接成本。

增加风险：该方法的复杂性增加了实施和运营风险的可能性。

不确定的安全性：通过该选项提供更高的安全性而不降低现有安全性的具体配置可能并不容易确定和推理。

决策结果

委员会建议继续对 L2 使用原生桥，原因如下：

虽然选项 2 可能比选项 1 提供一些安全改进，但它带来了显着的复杂性和开销。 这些复杂性可能会引入其他的实施和运营风险，从而抵消这些好处。

选项 2 会将复杂性强加到多桥架构中，这可能会影响其他远程部署的安全性。

影响 L2 消息基础设施的安全故障类型可能等同于 L2 链的严重故障。 这将需要重组 L2，从而恢复对远程 Uniswap 协议部署的任何恶意更新。 这进一步降低了抢先引入复杂基础设施以防范此极端情况的效用。

为了降低使用原生桥引起的担忧，委员会建议对现有和未来的 L2 部署架构进行以下更改。

在 L2 部署上使用时间锁机制，如上文有关目标链上的时间锁的部分所述。

考虑一种选择，其中单独的多重签名可以取消在时间锁合约中排队的恶意消息，从而防止任何恶意更新

采用跨链通信的标准接口，例如 ERC-5164，该接口可用于所有 L2 桥。 这最大限度地减少了集成和运营开销。

在指定官方 Uniswap 协议部署和集成跨链治理之前，审查新的 L2 及其桥实施。

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