解决方案概览

我们提议的方案的核心是一种标准化的工具，让客户端能够从一个外部系统 —— 一个网关服务 —— 处检索数据；以及一种标准化的方法，来验证返回的数据是正确的。

相应地，这里有两个主要的组成部分：第一个，是一个放在以太坊 Layer 1 上的智能合约，向客户端提供一个发现网关并验证网关响应正确性的工具；第二个，是一个网关服务，理解如何与给定的 L2 系统交互、以及如何为合约的用途而格式化数据。

在该模型下，获得数据的过程分三步：

1. 向合约发出查询数据的请求。合约并不直接返回所需的结果，而是返回两个值：一个 网关 URL，以及一个 calldata 前缀。
2. 向该网关发送一个 HTTP POST 请求，请求与第一步中相同的数据。网关返回一个不透明值（opaque value），resolver （解析器） calldata。验证该 解析器 calldata 的起始位就是第一步中得到的 calldata 前缀。
3. 查询合约，或者与之互动，提供第二步中得到的 解析器 calldata ，合约验证该数据的有效性，如果有效的话，返回 结果 或者执行交易。

因为负责理解如何与 L2 交互的是网关服务，所以这样一种简单的协议就可以让客户端从链下获得数据，并且不需要让客户端理解任何与 L2 相关的东西。为了使用这套系统，每一个应用都需要为自己意向交互的 L2 实现并部署一个网关服务和一个验证合约。在大部分使用，这些网关可以是非常通用的，降低了在不同应用间重复劳动的负担。

重要的是，这三个步骤的流程在调用者处可以完全抽象掉；一个理解这个协议的库就可以让整个流程看起来跟一个常规的 web3 合约调用一般无二，也就是说，不仅应用不需要知道自己在跟哪个 L2 交互，它们甚至完全不知道自己是在跟 L2 交互！

网关返回错误或者误导性结果的能力受到协议本身的限制。合约所实现的验证逻辑保证了任何无效的结果都会在第三步被发现，同时，合约在第一步中返回的前缀，在第二步中得到验证；这些都放置了网关用对某一次查询有效的答案来回应另一次查询。

工作案例

我们可以用一个预加载了一组余额的 ERC20 token 合约，以及一个本身是简单静态默克尔树的 「Layer 2」 来演示这条系统在实践中是如何运作的：