80 lines
3.9 KiB
Markdown
80 lines
3.9 KiB
Markdown
|
---
|
||
|
|
eip: 5219
|
||
|
|
title: Contract Resource Requests
|
||
|
|
description: Allows the requesting of resources from contracts
|
||
|
|
author: Gavin John (@Pandapip1)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/pr-5219-discussion-contract-rest/9907
|
||
|
|
status: Final
|
||
|
|
type: Standards Track
|
||
|
|
category: ERC
|
||
|
|
created: 2022-07-10
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
This EIP standardizes an interface to make resource requests to smart contracts and to receive HTTP-like responses.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
|
||
|
|
Ethereum is the most-established blockchain for building decentralized applications (referred to as `DApp`s). Due to this, the Ethereum DApp ecosystem is very diverse. However, one issue that plagues DApps is the fact that they are not fully decentralized. Specifically, to interface a "decentralized" application, one first needs to access a *centralized* website containing the DApp's front-end code, presenting a few issues. The following are some risks associated with using centralized websites to interface with decentralized applications:
|
||
|
|
|
||
|
|
- Trust Minimization: An unnecessarily large number of entities need to be trusted
|
||
|
|
- Censorship: A centralized website is not resistant to being censored
|
||
|
|
- Permanence: The interface may not have a mechanism that permits it to be permanently stored
|
||
|
|
- Interoperability: Smart Contracts cannot directly interact with DApp interfaces
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
|
||
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
|
||
|
|
|
||
|
|
### Name Resolution
|
||
|
|
|
||
|
|
EIPs that propose a name resolution mechanism MAY reference this EIP and MAY recommend that clients support their mechanism. Clients MAY also support regular DNS, as defined in RFC 1034 and RFC 1035.
|
||
|
|
|
||
|
|
### Separation of Concerns
|
||
|
|
|
||
|
|
It is RECOMMENDED to separate the application logic from the front-end logic (the contract implementing the interface defined in [Contract Interface](#contract-interface)).
|
||
|
|
|
||
|
|
### Contract Interface
|
||
|
|
|
||
|
|
DApp contracts MUST implement the interface defined in the following file: [Contract Interface](../assets/eip-5219/IDecentralizedApp.sol).
|
||
|
|
|
||
|
|
### Note to Implementers
|
||
|
|
|
||
|
|
To save gas costs, it is recommended to use the `message/external-body` MIME-type, which allows you to point to data that the smart contract might not have access to. For example, the following response would tell a client to fetch the data off of IPFS:
|
||
|
|
|
||
|
|
```yaml
|
||
|
|
statusCode: 200
|
||
|
|
body: THIS IS NOT REALLY THE BODY!
|
||
|
|
headers:
|
||
|
|
- key: Content-type
|
||
|
|
value: message/external-body; access-type=URL; URL="ipfs://11148a173fd3e32c0fa78b90fe42d305f202244e2739"
|
||
|
|
```
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
The `request` method was chosen to be readonly because all data should be sent to the contract from the parsed DApp. Here are some reasons why:
|
||
|
|
|
||
|
|
- Submitting a transaction to send a request would be costly and would require waiting for the transaction to be mined, resulting in bad user experience.
|
||
|
|
- Complicated front-end logic should not be stored in the smart contract, as it would be costly to deploy and would be better run on the end-user's machine.
|
||
|
|
- Separation of Concerns: the front-end contract shouldn't have to worry about interacting with the back-end smart contract.
|
||
|
|
- Other EIPs can be used to request state changing operations in conjunction with a `307 Temporary Redirect` status code.
|
||
|
|
|
||
|
|
Instead of mimicking a full HTTP request, a highly slimmed version was chosen for the following reasons:
|
||
|
|
|
||
|
|
- The only particularly relevant HTTP method is `GET`
|
||
|
|
- Query parameters can be encoded in the resource.
|
||
|
|
- Request headers are, for the most part, unnecessary for `GET` requests.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
|
||
|
|
This EIP is backwards compatible with all standards listed in the [Name Resolution](#name-resolution) section.
|
||
|
|
|
||
|
|
## Security Considerations
|
||
|
|
|
||
|
|
The normal security considerations of accessing normal URLs apply here, such as potential privacy leakage by following `3XX` redirects.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|