我们提议的方案的焦点是一种尺度化的东西，让客户端可以或许从一个外部系统 —— 一个网关处事 —— 处检索数据；以及一种尺度化的要领，来验证返回的数据是正确的。
return 0;这个简朴的办理方案有一个显而易见的问题：陈设者必需在陈设时将所有余额填充到 preload 映射中，这是一种很是昂贵的操纵。他们会更愿意把数据存储在链下，然后让可以或许证明本身拥有余额的用户来提取本身的数额。用默克尔树很容易就能实现这一点：
return (abi.encodeWithSelector(claimWithProof.selector, addr), gateway);
（完）
跟着走向成熟的 Layer-2 办理方案多了起来，ENS 也要能为整个生态系统提供处事，，同时让 ENS 用户可以或许得到 Layer-2 办理方案给他们带来的效率晋升。自 Vitalik 的一篇帖子提出了一种大概的要领之后，ENS 团队和宽大的 ENS 和 L2 社区也一直在开拓一种通用的 “Layer-2 桥”，让包罗 ENS 在内的应用，可以或许以免信任的方法在多个链下信源处检索数据，进而使跨平台的互操纵性成为大概。
假设客户端信任了原始合约 —— 我们的意思是，期望该合约会以特定的方法运行，而这可以通过查抄它宣布的源代码来验证 —— 那么这个系统就不会引入任何新的信任假设。固然网关的响应是一个外部流程，但其不良行为的范畴仅限于拒绝处事。
相应地，这里有两个主要的构成部门：第一个，是一个放在以太坊 Layer-1 上的智能合约，向客户端提供一个发明网关并验证网关响应正确性的东西；第二个，是一个网关处事，领略如何与给定的 L2 系统交互、以及如作甚合约的用途而名目化数据。
ENS 应用
接下来，我们需要实现一个网关处事来，可以满意客户端的查询请求。以 claim1 为例，很直接就能实现：
if(preload[addr] > 0) {
在 10 月 27 号最新的一次事情集会会议上，我演示了这个想法的一个劈头实现。本文中我会具体讲授这种办理方案。
一个幼稚的要领是，要求所有的系统都利用同样的 witness 数据名目。但这一点是不行能的，两个原因：第一，witness 数据的名目和范例都高度依赖于相干系统的实现细节，ZK Rollup 和 Optimistic Rollup 利用的元件肯定差异；第二，客户端仍然无法实际得到数据。
首先，我们插手了匹配初始 claim 的签名和 claimbleBalance 的要领：
因此，一个实验用不正确的值来响应的网关 —— 无论是提交了不正确的数据，照旧不正确的证明 —— 城市被执行验证步调的合约发明。一个实验正确响应、但利用非用户所发出请求的对应功效来响应的网关，会在用户的 calldata 前缀查抄中发明。客户端可以通过查抄合约的行为来担保这些 —— 可能依赖于某些人对合约的查抄 —— 都可以在开始交互前实现。
const proof = merkleTree.getProof(addr, balance);对付 ENS 和其它应用来说，要害问题在于，在一个存在很多互不兼容的 Layer-2 方案的世界里，如何能以信任最小化的方法 —— 也就是不引入任何新的信任假设 —— 从某个系统中检索数据，且不需要酿成所有 Layer-2 方案的客户端、本身来存储大概有用的数据 。
}实用的要领必需满意下列条件：
function claimableBalanceWithProof(address addr, uint balance, bytes proof) external view returns(uint) {function claim(address addr) external {
未办理的问题
return merkleInterface.encodeFunctionData("claimWithProof", [args.addr, balance, proof]);（再一次，为了简捷，我们假设已经有了包罗 getProof 函数在内的符合实现）
因为认真领略如何与 L2 交互的是网关处事，所以这样一种简朴的协议就可以让客户端从链下得到数据，而且不需要让客户端领略任何与 L2 相关的对象。为了利用这套系统，每一个应用都需要为本身意向交互的 L2 实现并陈设一个网关处事和一个验证合约。在大部门利用，这些网关可以长短常通用的，低落了在差异应用间反复劳动的承担。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
