Aave 跨链通信抽象层 a.DI 工作原理介绍

TL;DR

a.DI（AaveDeliveryInfrastructure）是一个跨链通信抽象层，用于像AaveDAO这样的去中心化系统在网络间进行通信，以最小化任何底层桥接提供者的风险。

介绍

Aave跨链生态系统

从以太坊的v1开始，通过v2和v3，Aave已经成为一个跨越不同网络的系统。

即使流动性协议的实例是完全孤立的，对它们的控制权也在以太坊上，因为去中心化的Aave治理及其投票资产（AAVE，stkAAVE）都在以太坊上。

因此，治理决策的通信层是必不可少的。

当前Aave跨链治理的局限性

从第一次在非以太坊网络(Polygon)中部署Aavev2开始，引入了一个Aave跨链治理系统，允许以太坊上的Aave治理通过桥接决策来控制这些实例。

然而，即使系统极具创新，但由于桥基础设施在多年前处于非常早期阶段，它仍然存在一些限制。这些限制包括：

完全依赖于单个底层桥。目前的跨链治理体系需要“选择”一个单一的“桥接提供商”，一旦完成并连接，则完全依赖于该桥。

这就是为什么只有原生/官方桥被接受的原因，除了技术细节之外，它们是与其所连接的网络本身联系最紧密的实体(例如Polygon桥)。

尝试扩展到新网络时的摩擦。前一点的结果是，当将Aave扩展到新的网络时，只有当有本地/官方桥可用时，才有可能实现完全的链上去中心化治理，但情况并非总是如此(例如Avalanche)。

桥接技术的最新进展

在过去的两年中，桥接技术的前景发生了根本性的变化。虽然在为生产使用做好准备的技术确实很少(主要是原生/官方桥)，但现在有许多拥有健全基础设施的参与者，并且在该领域有更多不断开发的产品。

即使安全性在跨链通信中仍然是一个相当大的问题，对于像Aave这样的协议/区块链应用层来说，这些解决方案的激增清楚地表明，从Aave跨链治理开始，有些情况是可以得到改善的。

与Aave治理v3的关系

正如Aave治理v3的公告中所描述的那样，考虑到治理流程中包含的高水平的跨链通信，稳健的跨链基础设施十分重要。

因此，即使a.DI是一个独立的系统，它也是Aave治理v3的一个基本组件。

什么是a.DI?它是如何工作的?

a.DI(AaveDeliveryInfrastructure)是智能合约的跨链抽象层，没有任何链下组件，专注于在底层桥接技术上对AaveDAO进行最小信任假设，从而完全赋予其主权。

a.DI的设计原则

首先是DAO，但是通用的。a.DI是由深刻理解AaveDAO需求的社区成员设计。因此，重点是满足其当前和未来的需求。

但是，作为一个面向未来的需求设计，该系统也是一个相当通用的系统，可以适应几乎任何跨链通信需求。

完全控制，无信任。a.DI将对底层使用桥接器的信任降到最低。这意味着控制a.DI(Aave治理)的实体可以在恶意/被利用的情况下替换任何底层桥接器，在多个桥接器之间定义共识规则，甚至在没有桥接器功能的紧急事件中存活下来。

安全抽象，基于共识。保护桥是一个相当困难的挑战，过去几年中出现了许多漏洞。此外，即使对它们的安全模型进行深入评估也是非常复杂的工作，因为它们彼此之间差异很大，且组件的细粒度也不同。

a.DI方法改变了这种情况：通过基于共识和恢复机制，将最小可信的桥接提供者添加到集合中，从而提高了安全性。这对于像Aave治理这样的“慢”系统尤其适用。

良好的开发经验和明确定义的流程。对于DAO来说，运营开销是一个重要的问题，因此简单而良好的开发者体验以及对贡献者的良好指导是基础。a.DI提供的抽象概念也有助于解决这一问题。

a.DI的组件

通信流

在消息通信协议中，一切都以从一个地址发送的消息开始，以传递到另一个地址的消息结束。

但在内部，系统的工作原理如下:

发送阶段

1.用户(例如Aave治理)发送一串字节(消息)到跨链控制器智能合约(CCC)，即a.DI的入口点。

2.CCC通过其跨链转发器组件（CCF）将消息内部封装为一个交易：这是a.DI的内部格式，不要将其与区块链概念中的交易混淆。

3.CCF通过每个授权的桥接提供者发送交易，透明地处理与每个桥接提供者交互或支付桥接费用的方式。

接收阶段

1.每个授权网桥都通过适配器智能合约将a.DI交易发送给接收网络上的CCC。

2.在CCC中，跨链接收器（CCR）组件应用共识规则。例如，如果以太坊→Polygon之间的通信需要对授权的桥进行2-of-3共识，只有当其中有2个在CCR上传递等效交易时，才会将其转发到最终目的地。

3.在完成从a.DI的内部格式的解包并达成共识后，最终消息被转发到目标地址。

需要强调的是，a.DI应用与方向无关。前面的流程适用于任何连接的网络对：以太坊→Polygon，Polygon→以太坊，以太坊→Avalanche，或任何其他网络。

此外，可以通过a.DI抽象同链通信，这在Aave治理v3(以太坊→以太坊)等系统中非常重要。

控制模型（运行模式与紧急模式）

即使包括多个桥接提供商之间的共识机制，也可能存在一些情况，使得像Aave这样的治理无法完全控制其权限。例如，多个桥同时发生故障的情况可能会对治理造成“阻塞”，无法桥接决策并将其替换为有效的决策。

与此同时，添加一个拥有完全权力的第三方(如AaveGuardian)来取代桥会使系统变得毫无意义，事实上，即使不行使控制权，也会给这一第三方完全的控制权。

a.DI中包含的解决方案是区分系统的两种工作模式：运行模式和紧急模式。

运行模式。这是aDI的“标准”模式，在这种模式下，aDI对Aave治理的管理行为有完全的控制权：对于任何配置的更改(例如，授权或禁用网桥提供商，更改共识规则)，需要通过治理建议，该建议将通过a.DI发送消息，以最终更改其参数。

关于【Aave 跨链通信抽象层 a.DI 工作原理介绍】的延伸阅读

• 浅析Aave V4的核心要点——“统一流动性层”

  Aave V4将推出" 统一流动性层"，整合多个网络的流动性。类似于V3的Portal，但更高效灵活。通过模块化设计，Aave可更有效管理流动性，提高资金效率。升级还将允许添加新模块，如隔离池和RWA模块。Aave将成为无视链间流动性隔阂的DeFi协议，但需要信任假设。V4引入改进，如动态利率、流动性溢价、智能账户，构建Aave Network。旨在推动生态系统进一步采用，服务于10亿潜在用户。

• Aave v4 的一些思考：每个大协议都应该发链？

  Aave v4的改进旨在提高用户体验、降低治理成本、防止不良债务扩散，并为长期发展提供便利。其中包括统一流动性层、模糊控制利率、流动性溢价机制、智能账户和金库、动态风险参数配置、超额债务保护机制、与GHO稳定币的原生集成和计划推出的Aave Network。Aave计划推出的新网络层将作为GHO稳定币和借贷协议的核心枢纽，使用GHO支付费用，以Aave V4为枢纽，$AAVE作为主要质押资产。Aave未来将专注于稳定币市场，为GHO创造场景。Aave Labs将持续关注网络发展，选择最合适的技术方案。

除Aave治理之外，没有其他实体在运行模式中具有任何控制权。

紧急模式。现在让我们举个例子来说明之前的“阻塞”情况。

假设以太坊→Polygon在a.DI上有A、B和C三座授权桥，并采用2-of-3共识。此外，a.DI被配置为唯一可以向控制a.DI在Polygon和Aavev3Polygon的合约发送消息的一方。

由于某些边缘原因，B和C都停止运行和传递消息，这意味着Aave治理无法通过a.DI向控制a.DI和v3Polygon的合约传递消息，从而锁定两者。

为避免这种情况，a.DI包含了一个这样工作的机制：

以太坊上的Aave治理机制可以控制一个合约，通过提交标准治理提案，为一个特定的网络ID发出紧急事件激活的信号。

如果在以太坊上激活紧急事件，我们与Chainlink一起开发了一个系统(完全独立于a.DI本身)，该系统会自动检测并在信号网络上设置标志。

只要在受影响的网络上启用该标志，那里的a.DI就会检测到它，并自动更改自己的访问控制模型：一个Guardian实体将获得执行所谓的solveEmergency()操作的权限，实际上获得了替换网桥或更改其他配置的全部权力。之后，Guardian的权限将被移除，要再次激活紧急模式，需要在以太坊上引发新的紧急事件。

该系统采用了与Aavev3上的PriceOracleSentinel类似的方法，并允许一个相当强大的结果：在运行模式下，A.DI除了Aave治理本身外没有任何第三方控制。但是，如果Aave管理决定这样做（仅在这种情况下），像AaveGuardian这样的额外实体可以获得临时权力来解决任何问题，这在其他情况下是不可能的。

下图表显示了运行模式和紧急模式之间的区别。

底层桥配置

在设计a.DI的同时，我们一直在评估和集成不同的底层提供者，因为即使社区将来能够重新配置它，我们坚信第一个提案应该来自我们这边。

在整合/选择过程中考虑了以下几个方面:

多方桥只在有安全优势的情况下使用。根据网络的形态，在某些情况下，原生/官方桥与网络本身共享完全相同的安全性(例如Optimism))，而在其他情况下，网络和桥在技术上是分离的实体，具有不同的控制模型(例如Avalanche，没有原生/官方桥或PolygonPoS)。

经过验证的技术，没有重大的安全问题。在产品或团队维护方面，市场的最低成熟度是我们考虑的因素。

桥内部网络参与者之间的交集最小化。根据一般规则，所有桥提供程序都基于参与系统的某种类型的实体网络，通常用于监视和中继任务。

由于a.i.是基于共识的，因此特别重要的是，桥接提供者A上的参与者不能与共识集中的其他桥接提供者完全重叠。

在桥上进行有意义的构建尝试，以避免中心化。在桥的评估中，中心化通常是一个重要的考虑因素，但是a.DI被专门设计为具有抗中心化的弹性。这直接转化为我们对中心化候选人的评估：所有桥提供商都应该在去中心化方面做出有意义的尝试。但如果存在相对中心化的组件，且这不会严重损害安全性，我们认为它是可以接受的，并优先考虑拥有健全的基础设施，例如uptime。

目前，我们可以确认以下桥将进入最初的名单：

LayerZero

CCIP

Hyperlane

Aave所有原生/官方网络桥

与此同时，我们正在评估和整合额外的候选产品，这取决于发布前后的时间表。

常见问题解答

在网络的接收端，什么是可接受的共识?

视情况而定。2-of-3通常是一个很好的起点，如果存在额外可靠的选项，可以考虑扩展该比例。

是否存在“否决”信息的机制?

不。对a.DI的共识决定了什么是正确的，什么是错误的:在2-of-3共识中，如果两个桥一致，则消息是正确的。“暂停”系统的唯一方法是从以太坊引发紧急状态。

上层系统应该实施额外的保护。例如，Aave治理v3包含了Guardian的否决机制，并带有时间锁。

DAO的系统运行成本是多少?

成本取决于所使用的桥提供商及其定价机制。此外，a.DI层本身还有一些额外的Gas开销。

由于Aave治理(包括v2和v3)上的跨链通信几乎总是固定的字节大小，因此在实践中，消息传递的成本将非常低，大约为每条消息1-5美元。

除治理之外，a.DI还可以用于DAO跨链通信的其他需求吗?

是的，系统是通用的。根据具体情况，可能需要部署一个新的a.i.实例，以具有不同的共识规则和桥接提供程序，但这不应该成为障碍。

谁可以通过a.DI发送信息?

a.i的初始实例将被列入AaveGovernance智能合约的白名单。这是因为系统本身将用DAO的资金支付其成本，因此只有DAO愿意支付成本的消息才应该被允许。

如果发送消息时，中间的桥接程序出现问题，会发生什么情况?发送方需要重新发送吗?

一般来说，答案是否定的。a.DI在底层网桥的重试机制之上包含了一个重试机制，以避免出现以下情况：Aave治理发送消息→由于底层网桥导致消息传递无法通过→需要重新提交治理提案。

激活步骤和时间线

如前所述，a.DI与Aave治理v3紧密相连，在生产环境中同时激活两者。

在这篇文章之后，Aave治理v3的三个相关组件已经向社区展示：Aave治理v3本身、a.DI和AaveRobot(涉及到前两个系统的无权限自动化)。

激活之前的时间表和尚未完成步骤如下：

在发布本帖的同时，我们将为社区创建之前公布的快照，以初步批准Aave治理v3三合一组件。

这些要求将反映1级链上提案：至少320'000AAVE赞成票，赞成票和反对票之间有80'000票差值。

所有的安全程序都将完成，包括Certora和SigmaPrime的程序，这两个程序都已经非常完善。一旦完成，我们将发布最终的代码库。

我们将完成整个设置的准备工作，包括所有的部署和激活所有系统的AIP最终有效载荷。

一旦准备就绪，我们将发布该程序。

免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：MarsBit，如有侵权请联系删除。转载或引用请注明文章出处！

标签：a.DIAAVE精选