TL;DR
a.DI（Aave Delivery Infrastructure）是一个跨链通信抽象层，用于像Aave DAO这样的去中心化系统在网络间进行通信，以最小化任何底层桥接提供者的风险。
介绍
Aave跨链生态系统
从以太坊的v1开始，通过v2和v3，Aave已经成为一个跨越不同网络的系统。
即使流动性协议的实例是完全孤立的，对它们的控制权也在以太坊上，因为去中心化的Aave治理及其投票资产（AAVE，stkAAVE）都在以太坊上。
因此，治理决策的通信层是必不可少的。
当前Aave跨链治理的局限性
从第一次在非以太坊网络(Polygon)中部署Aave v2开始，引入了一个Aave跨链治理系统，允许以太坊上的Aave治理通过桥接决策来控制这些实例。
然而，即使系统极具创新，但由于桥基础设施在多年前处于非常早期阶段，它仍然存在一些限制。这些限制包括：
完全依赖于单个底层桥。目前的跨链治理体系需要“选择”一个单一的“桥接提供商”，一旦完成并连接，则完全依赖于该桥。
这就是为什么只有原生/官方桥被接受的原因，除了技术细节之外，它们是与其所连接的网络本身联系最紧密的实体(例如Polygon桥)。
尝试扩展到新网络时的摩擦。前一点的结果是，当将Aave扩展到新的网络时，只有当有本地/官方桥可用时，才有可能实现完全的链上去中心化治理，但情况并非总是如此(例如Avalanche)。
桥接技术的最新进展
在过去的两年中，桥接技术的前景发生了根本性的变化。虽然在为生产使用做好准备的技术确实很少(主要是原生/官方桥)，但现在有许多拥有健全基础设施的参与者，并且在该领域有更多不断开发的产品。
即使安全性在跨链通信中仍然是一个相当大的问题，对于像Aave这样的协议/区块链应用层来说，这些解决方案的激增清楚地表明，从Aave跨链治理开始，有些情况是可以得到改善的。
与Aave治理v3的关系
正如Aave治理v3的公告中所描述的那样，考虑到治理流程中包含的高水平的跨链通信，稳健的跨链基础设施十分重要。
因此，即使a.DI是一个独立的系统，它也是Aave治理v3的一个基本组件。
什么是a.DI? 它是如何工作的?
a.DI (Aave Delivery Infrastructure)是智能合约的跨链抽象层，没有任何链下组件，专注于在底层桥接技术上对Aave DAO进行最小信任假设，从而完全赋予其主权。
a.DI的设计原则
首先是DAO，但是通用的。a.DI是由深刻理解Aave DAO需求的社区成员设计。因此，重点是满足其当前和未来的需求。
但是，作为一个面向未来的需求设计，该系统也是一个相当通用的系统，可以适应几乎任何跨链通信需求。
完全控制，无信任。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这样的治理无法完全控制其权限。例如，多个桥同时发生故障的情况可能会对治理造成“阻塞”，无法桥接决策并将其替换为有效的决策。
与此同时，添加一个拥有完全权力的第三方(如Aave Guardian)来取代桥会使系统变得毫无意义，事实上，即使不行使控制权，也会给这一第三方完全的控制权。
a.DI中包含的解决方案是区分系统的两种工作模式：运行模式和紧急模式。
运行模式。这是aDI的“标准”模式，在这种模式下，aDI对Aave治理的管理行为有完全的控制权：对于任何配置的更改(例如，授权或禁用网桥提供商，更改共识规则)，需要通过治理建议，该建议将通过a.DI发送消息，以最终更改其参数。
除Aave治理之外，没有其他实体在运行模式中具有任何控制权。
紧急模式。现在让我们举个例子来说明之前的“阻塞”情况。
假设以太坊 → Polygon 在 a.DI 上有 A、B 和 C 三座授权桥，并采用 2-of-3 共识。此外，a.DI 被配置为唯一可以向控制 a.DI 在 Polygon 和 Aave v3 Polygon 的合约发送消息的一方。
由于某些边缘原因，B和C都停止运行和传递消息，这意味着Aave治理无法通过a.DI向控制a.DI和v3Polygon的合约传递消息，从而锁定两者。
为避免这种情况，a.DI包含了一个这样工作的机制：
以太坊上的Aave治理机制可以控制一个合约，通过提交标准治理提案，为一个特定的网络ID发出紧急事件激活的信号。
如果在以太坊上激活紧急事件，我们与Chainlink一起开发了一个系统(完全独立于a.DI本身)，该系统会自动检测并在信号网络上设置标志。
只要在受影响的网络上启用该标志，那里的a.DI就会检测到它，并自动更改自己的访问控制模型：一个Guardian实体将获得执行所谓的solveEmergency()操作的权限，实际上获得了替换网桥或更改其他配置的全部权力。之后，Guardian的权限将被移除，要再次激活紧急模式，需要在以太坊上引发新的紧急事件。
该系统采用了与Aave v3上的Price Oracle Sentinel类似的方法，并允许一个相当强大的结果：在运行模式下，A.DI除了Aave治理本身外没有任何第三方控制。但是，如果Aave管理决定这样做（仅在这种情况下），像AaveGuardian这样的额外实体可以获得临时权力来解决任何问题，这在其他情况下是不可能的。
下图表显示了运行模式和紧急模式之间的区别。
底层桥配置
在设计a.DI的同时，我们一直在评估和集成不同的底层提供者，因为即使社区将来能够重新配置它，我们坚信第一个提案应该来自我们这边。
在整合/选择过程中考虑了以下几个方面:
多方桥只在有安全优势的情况下使用。根据网络的形态，在某些情况下，原生/官方桥与网络本身共享完全相同的安全性(例如Optimism))，而在其他情况下，网络和桥在技术上是分离的实体，具有不同的控制模型(例如Avalanche，没有原生/官方桥或Polygon PoS)。
经过验证的技术，没有重大的安全问题。在产品或团队维护方面，市场的最低成熟度是我们考虑的因素。
桥内部网络参与者之间的交集最小化。根据一般规则，所有桥提供程序都基于参与系统的某种类型的实体网络，通常用于监视和中继任务。
由于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的初始实例将被列入Aave Governance智能合约的白名单。这是因为系统本身将用DAO的资金支付其成本，因此只有DAO愿意支付成本的消息才应该被允许。
如果发送消息时，中间的桥接程序出现问题，会发生什么情况?发送方需要重新发送吗?
一般来说，答案是否定的。a.DI在底层网桥的重试机制之上包含了一个重试机制，以避免出现以下情况：Aave治理发送消息→由于底层网桥导致消息传递无法通过→需要重新提交治理提案。
激活步骤和时间线
如前所述，a.DI与Aave 治理 v3紧密相连，在生产环境中同时激活两者。
在这篇文章之后，Aave 治理 v3的三个相关组件已经向社区展示：Aave 治理 v3本身、a.DI和Aave Robot(涉及到前两个系统的无权限自动化)。
激活之前的时间表和尚未完成步骤如下：
在发布本帖的同时，我们将为社区创建之前公布的快照，以初步批准Aave 治理 v3三合一组件。
这些要求将反映 1 级链上提案：至少 320’000 AAVE 赞成票，赞成票和反对票之间有 80’000 票差值。
所有的安全程序都将完成，包括Certora和SigmaPrime的程序，这两个程序都已经非常完善。一旦完成，我们将发布最终的代码库。
我们将完成整个设置的准备工作，包括所有的部署和激活所有系统的AIP最终有效载荷。
一旦准备就绪，我们将发布该程序。
微信扫一扫 
