以太坊2层通用网桥

有了更加成熟的以太坊二层解决方案，ENS还应该能够为整个生态系统提供服务，同时让ENS用户获得Layer2解决方案带来的效率提升。由于vitalik的一篇文章提出了一种可能的方法，ENS团队和广大的ENS和L2社区一直在开发一种通用的“Layer2桥”，它使包括ENS在内的应用程序能够以避免信任的方式从多个脱机源检索数据，从而使跨平台的互操作成为可能。

在10月27日最近的一次工作会议上，我展示了这个想法的初步实施。我将在本文中详细解释这个解决方案。

目标

总之，layer-2和其他相关系统的工作原理是减少与以太坊交互的需求。它们将需要在链上保存和访问的状态移动到其他位置。同时，确保以太坊区块链上有足够的信息来验证数据的正确性。例如，在通用解决方案rollup中，rollup的状态存储在另一个系统中，只有见证数据（如Merkel root）存储在以太坊区块链上。通过访问见证数据和Layer2解决方案，参与者可以为Layer2系统中受保护的任何数据构建有效性证明，以太坊可以对此进行验证。

这个定义比大多数人认为的“Layer2”要宽泛——它还包括其他减少链上数据存储的工具，例如使用默克尔账户余额树的空投工具，以及触发事件但不在链上存储余额的代币。

对于ens和其他应用，关键问题是如何在存在许多不兼容的Layer2方案的世界中从某个系统中检索数据，即在不引入任何新的信任假设的情况下，不必成为所有二层方案的客户，也不必自己存储潜在有用的数据。

一种简单的方法是要求所有系统使用相同的见证数据格式。但是，这是不可能的，原因有二：一是见证数据的格式和类高度依赖于相关系统的实现细节，ZK rollup和optimal rollup使用的组件必须不同；二是客户端仍然无法实际获取数据。

实际方法必须满足以下条件：

客户机不需要为他们可能交互的每个系统提供明确的支持。

客户端必须能够验证返回的数据是否有效，**不要引入信任模，而不是引入相关L2方案中固有的假设。

该解决方案不需要对L2平台进行结构更改。

第三方必须能够在没有平台维护人员的支持和参与的情况下为二级平台开发接口。

解决方案概述

我们提出的解决方案的核心是一种标准化工具，它使客户机能够从外部系统、**服务中检索数据；以及一种验证返回数据是否正确的标准化方法。

因此，有两个主要组件：第一个是以太坊1层上的智能合约，它为客户提供了一个工具来发现**并验证**响应的正确性；第二个是**服务，它了解如何与给定的二级系统交互，以及如何为契约的目的格式化数据。

在该模中，数据获取过程分为三个步骤

向合同发送查询数据的请求。契约不直接返回所需的结果，而是返回两个值：**URL和calldata前缀。

向**发送一个httppost请求，请求与第一步相同的数据。**返回一个不透明的值，即解析器calldata。验证解析器calldata的起始位是在步骤1中获得的calldata前缀。

查询协定或与其交互以提供在步骤2中获得的解析器calldata。合同验证数据的有效性，如果结果有效，则返回结果或执行交易。

因为**服务负责理解如何与L2交互，所以这样一个简单的协议允许客户机从链中获取数据，而不需要客户机理解任何与L2相关的内容。为了使用系统，每个应用程序需要为其预期的交互L2实现和部署**服务和验证契约。在大多数应用程序中，这些**可以非常通用，从而减少不同应用程序之间的**负担。

重要的是，这三个步骤的过程可以完全从调用方抽象出来；理解协议的库可以使整个过程看起来像一个常规的Web3合约调用，也就是说，应用程序不仅不需要知道它在与哪个L2进行交互，但他们甚至不知道它是在和第二语言交互！

**返回误导或误导结果的能力受到协议本身的限制。契约实现的验证逻辑确保在第三步中找到任何无效的结果，在第二步中验证第一步契约返回的前缀；这些前缀放在**中，以对一个查询有效的答案响应另一个查询。

工作案例

我们可以使用一个ERC20代币合约预装一组余额和一个“Layer2”，它本身就是一个简单的静态默克尔树，来演示系统在实践中是如何工作的

契约preloadtoken是ERC20函数声明（地址addr）external}}

这个简单的解决方案有一个明显的问题：部署人员必须在部署时将所有余额填入地图中，这是一项非常昂贵的操作。他们会更愿意将数据存储在链外，然后让能够证明自己有余额的用户提取自己的金额。这可以通过默克尔树轻松实现：

契约preloadtoken是ERC20 return 0；}函数claimWithProof（addr，uint balance，bytes proof）externalmint（addr，balance）；声明的[addr]=true；}

（为了简化，我们省略了验证和证明功能的实现）

这种方法非常有效。合同的作者不需要花费太多以太坊来预装所有余额。默克尔的根就够了。当呼叫者想要索取余额时，他可以支付证明代币所有权的费用。

但是，现在调用方必须了解生成证明的过程，并知道从何处获取余额列表以生成其帐户的证明。如果我们能把第一个解决方案的接口（便利性）和第二个解决方案的效率结合起来，那就太完美了。这是我们的计划。

首先，我们添加一个方法来匹配首字母和

string gateway；函数requisiblebalance（addr addr）external view返回（字节前缀，string url）函数声明（address addr）外部视图返回（bytes prefix，string url）{return（带选择器的二进制编码( claimWithProof.selector索赔，addr），**）；

这些函数的调用方可以获得两个值：第一个值是后续回调的前缀；第二个值是**服务的URL。这个前缀保证了两件事：回调将用相关的proof函数响应，它的第一个参数将是提供的地址。这会阻止**用另一个地址的数据响应请求。

接下来，我们需要实现一个**服务来满足客户机的查询请求。以直接实现为例

常量参数=tokenInterface.decodeFunctionData（quot;claimquot;，数据）；常量余额=余额[地址]；常数证明=merkleTree.getProof公司（地址，余额）；返回merkleInterface.encodeFunctionData（quot;带证明的索赔quot;，[地址，平衡，证明]）；

为了简洁起见，我们再假设一个适当的函数

这里的**服务只需要为客户端发送的呼叫解码函数调用数据汇编一个证明，或者在实际的二级架构中，结合二级缓存收集一个证明，然后将结果代码放入对的调用中并返回给客户端。

**，客户机验证返回的calldata是否以契约断言的前缀开头，如果是，则使用事务将calldata发送到契约。

Nbsp；的实现类似，只是客户端使用calldata调用契约并将返回值作为调用的最终结果。

安全考虑和信任模

假设客户机信任原始合同—我们的意思是合同预期以特定的方式运行，这可以通过检查其发布的源代码进行验证—那么系统不会引入任何新的信任假设。尽管**的响应是一个外部进程，但其不良行为的范围仅限于拒绝服务。

首先，如果我们信任合同，我们也信任它开发一个**URL来响应我们的查询请求。其次，我们也可以相信它能够实现完全验证，并确保**的响应是准确的，要么在第一步指定calldata前缀，要么在**一步验证**的响应。

因此，尝试用不正确的值响应的**（无论它提交的是错误的数据还是不正确的证明）都会被执行验证步骤的契约发现。在用户的calldata前缀检查中可以找到一个**，该**尝试正确响应，但使用非用户发出的请求的相应结果进行响应。客户端可以检查契约的行为，以确保在交互开始之前可以完成这项工作（或者依赖于检查契约的人）。

**可以完全拒绝响应，即拒绝服务，这种情况可能由于恶意**或失败而发生。正因为如此，我们建议任何最终规范都应该使用户能够轻松地分叉服务并提供自己的**，就像用户可以分叉dapp前端一样。

Ens应用程序

Ens也将相对直接地使用这个系统。解析器可以实现本文描述的协议，可以用来解析任何数据字段。然后每个希望支持ENS数据存储和检索的L2可以部署一个新的解析器实现和相应的**。想要使用L2的用户只需将自己的记录存储在相应的L2中，并在以太坊上发送一次性事务，以指定相关的解析器地址以使用自己的域名。

为了使这个方案更通用，ENS还应该改进以支持某种形式的通配符解析，这样当一个域名无法被搜索到时，将向解析器咨询该域名的父域名–if”foo.example.ETH“如果它不存在，客户端将在解析器中搜索“示例.ETH“。此功能使其他系统能够存储ENs的整个子树，而不仅仅是单个域名的记录。

未决问题

尽管有些应用程序（如ENS）可以受益于由契约指定的**URL创建的附加的间接层，但是其他应用程序（如上面所示的代币契约）更好地编码为契约的ABI的一部分，以便用户更容易分叉。最终的解决方案是在不增加不必要的负担的情况下支持这两种选择。

目前，客户机无法将返回无效calldata（例如，提供无效证明）的**与仍将回滚的调用分开。需要制定一些规则来区分这两种情况—例如，如果证明数据未被验证，则合同需要使用特定的回滚原因。

它需要一个比以太坊L2通用网桥更吸引人的名字。

你自己试试吧

我文章的所有演示源代码都可以在这里找到。