ERC-5219: Contract Resource Requests


  Ethereum Improvement Proposals
        
        
          
            
              
            
          
        

        AllCoreNetworkingInterfaceERCMetaInformational

      



      
        
  
    

  
    
    
    
    
    
      Standards Track: ERC
    
  
  
    
      ERC-5219: Contract Resource Requests
    
    
      
        
      
    
    
      
        
      
    
  

  Allows the requesting of resources from contracts

  	Authors	Gavin John (@Pandapip1)
	Created	2022-07-10


  


  

  
    Table of Contents

    	Abstract
	Motivation
	Specification
    	Name Resolution
	Separation of Concerns
	Contract Interface
	Note to Implementers


  
	Rationale
	Backwards Compatibility
	Security Considerations
	Copyright



  


  
      
      
         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 DApps). 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
      
      
    


DApp contracts MUST implement the interface defined in the following file: Contract Interface.

  
    
      
      
         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:


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 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.


  Citation

  Please cite this document as:

  
  Gavin John (@Pandapip1), "ERC-5219: Contract Resource Requests," Ethereum Improvement Proposals, no. 5219, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5219.






      
    
  

  

    Ethereum Improvement Proposals


    
      
        	Ethereum Improvement Proposals


      


      	 ethereum/EIPs





      
        Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.