claim 调用解码函数调用数据，组装一个证明 —— 或者，在一个实际的 L2 方案中，参考 L2 来组装出一个证明 —— 然后将结果编码放在对 claimWithProof 的调用中，返回给客户端。
最后，客户端验证返回的 calldata 是否以合约所断言的前缀开始，如果是，则使用交易发送 calldata 给合约。
安全考虑和信任模型假设客户端信任了原始合约 —— 我们的意思是，期望该合约会以特定的方式运行，而这可以通过检查它发布的源代码来验证 —— 那么这个系统就不会引入任何新的信任假设。虽然网关的响应是一个外部流程，但其不良行为的范围仅限于拒绝服务。 首先，如果我们信任合约，我们同样也会信任它来制定一个网关 URL 来回应我们的查询请求。其次，我们也可以信任它来实现充分的验证、保证网关的响应是准确的，既可以通过在第一步中指定 calldata 前缀、也可以通过在最后一步中验证网关的响应来保证。 因此，一个尝试用不正确的值来响应的网关 —— 无论是提交了不正确的数据，还是不正确的证明 —— 都会被执行验证步骤的合约发现。一个尝试正确响应、但使用非用户所发出请求的对应结果来响应的网关，会在用户的 calldata 前缀检查中发现。客户端可以通过检查合约的行为来保证这些 —— 或者依赖于某些人对合约的检查 —— 都可以在开始交互前实现。 网关可以完全拒绝响应，也就是拒绝服务，而且这种情况确实可能因为网关恶意或者故障而发生。因为这一点，我们提议，任意最终规范，都应该让用户易于 fork 服务，并提供自己的网关；就像现在用户能够 fork dApp 的前端一样。 ENS 应用ENS 使用这套系统也会相对直接一些。解析器可以实现本文所述的协议，用于解析任何的数据字段，然后每一个希望支持 ENS 数据的存储和检索的 L2 都可以部署新的解析器实现和相应的网关。希望使用 L2 的用户只需存储自己的记录到合适的 L2 中，并在以太坊上发送一笔一次性的交易来指定相关的解析器地址，来使用自己的域名。 为了让这个方案更通用，ENS 也应该改进，以支持某种形式的通配符解析（wildcard resolution），使得搜索域名失败时会向解析器咨询该域名的父域名 —— 如果 「foo.example.eth」 不存在，那客户端就会在解析器内搜索 「example.eth」。这一功能使得其它系统可以存储 ENS 的整个子树，而不仅仅是单个域名的记录。 未解决的问题
|