ERC-5219: 合约资源请求

允许从合约请求资源

摘要

此 EIP 标准化了一个接口，用于向智能合约发出资源请求并接收类似 HTTP 的响应。

动机

以太坊是构建去中心化应用程序（称为 DApp）的最成熟的区块链。因此，以太坊 DApp 生态系统非常多样化。然而，困扰 DApp 的一个问题是它们并非完全去中心化。具体来说，要连接一个“去中心化”的应用程序，首先需要访问一个中心化的网站，其中包含 DApp 的前端代码，这带来了一些问题。以下是使用中心化网站与去中心化应用程序交互的一些风险：

• 信任最小化：需要信任的实体数量不必要地多
• 审查：中心化网站无法抵抗审查
• 永久性：该接口可能没有允许永久存储它的机制
• 互操作性：智能合约无法直接与 DApp 接口交互

规范

本文档中的关键词“必须”、“禁止”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按照 RFC 2119 中的描述进行解释。

名称解析

提出名称解析机制的 EIP 可以引用此 EIP，并且可以建议客户端支持他们的机制。 客户端也可以支持常规 DNS，如 RFC 1034 和 RFC 1035 中所定义的那样。

关注点分离

建议将应用程序逻辑与前端逻辑（实现 合约接口 中定义的接口的合约）分开。

合约接口

DApp 合约必须实现以下文件中定义的接口：合约接口。

给实现者的提示

为了节省 gas 成本，建议使用 message/external-body MIME 类型，该类型允许您指向智能合约可能无法访问的数据。 例如，以下响应将告诉客户端从 IPFS 获取数据：

statusCode: 200
body: THIS IS NOT REALLY THE BODY!  # 这不是真正的 body！
headers:
  - key: Content-type
    value: message/external-body; access-type=URL; URL="ipfs://11148a173fd3e32c0fa78b90fe42d305f202244e2739"

理由

选择 request 方法设为只读，因为所有数据都应该从解析后的 DApp 发送到合约。 原因如下：

• 提交交易以发送请求的成本很高，并且需要等待交易被挖掘，从而导致糟糕的用户体验。
• 复杂的前端逻辑不应存储在智能合约中，因为部署成本很高，并且最好在最终用户的机器上运行。
• 关注点分离：前端合约不必担心与后端智能合约交互。
• 其他 EIP 可以与 307 Temporary Redirect 状态代码结合使用，以请求状态变更操作。

没有模仿完整的 HTTP 请求，而是选择了高度精简的版本，原因如下：

• 唯一特别相关的 HTTP 方法是 GET
• 查询参数可以编码在资源中。
• 请求标头在很大程度上对于 GET 请求是不必要的。

向后兼容性

此 EIP 与 名称解析 部分中列出的所有标准向后兼容。

安全注意事项

访问普通 URL 的正常安全注意事项也适用于此，例如通过遵循 3XX 重定向可能导致隐私泄露。

版权

版权及相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Gavin John (@Pandapip1), "ERC-5219: 合约资源请求," Ethereum Improvement Proposals, no. 5219, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5219.