Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EIP-5219: Contract Resource Requests #5219

Merged
merged 23 commits into from
Jul 28, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions EIPS/eip-5219.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
---
eip: 5219
title: Contract Resource Requests
description: Allows the requesting of resources from contracts
author: Pandapip1 (@Pandapip1)
discussions-to: https://ethereum-magicians.org/t/pr-5219-discussion-contract-rest/9907
status: Draft
type: Standards Track
category: ERC
created: 2022-07-10
---

## Abstract

This EIP introduces an interface allowing clients 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).

## 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 quite possibly the worst user-experience possible.
- Complicated front-end logic should not be stored in the smart contract, as it would be costly to deploy and would be better ran 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

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
16 changes: 16 additions & 0 deletions assets/eip-5219/IDecentralizedApp.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;

struct KeyValue {
string key;
string value;
}

interface IDecentralizedApp {
/// @notice Send an HTTP GET-like request to this contract
/// @param resource The resource to request (e.g. "/asdf/1234" turns in to ["asdf", "1234"])
/// @return statusCode The HTTP status code (e.g. 200)
/// @return body The body of the response
Pandapip1 marked this conversation as resolved.
Show resolved Hide resolved
/// @return headers A list of header names (e.g. [{ key: "Content-Type", value: "application/json" }])
function request(string[] memory resource) external view returns (uint8 statusCode, string memory body, KeyValue[] headers);
}