EIP-5219 Discussion: Contract Resource Requests

I must be misunderstanding something then because it looks like your proposition is to turn an HTTP GET request into a single contract call where you pass a bunch of strings to it, rather than dispatching it to the appropriate function directly and doing the string to type conversion elsewhere. By doing it the way you have it specified, you are putting a lot of work on the EVM that could be done in some middleware component which feels like a bad trade since EVM execution is many many many orders of magnitude more costly than middleware execution.

The idea here is that there will be minimal computation performed inside the request function. Take the following rapidly made request function that may or may not work, for example. I expect that most of the request functions that will be made will look extremely similar to the following:

function request(string[] memory resource) external view returns (uint8 statusCode, string memory body, KeyValue[] headers) {
    bytes32 hash = keccak256(abi.encode(resource));
    if (bodyMap[hash] == "") {
        return 404, someIPFSMultihashFor404, standardIPFSReturnHeaders;
    }
    return 200, bodyMap[hash], standardIPFSReturnHeaders;
}

Considering it’s a view function that is meant to never be called by an external contract, the only noticeable cost will be during deployment (to store the bytecode in the contract and initialize someIPFSMultihashFor404 and standardIPFSReturnHeaders) and when updating bodyMap.

For example, I have pandapip1.eth (well, I don’t, but I would like to), and decide to point it to address 0x1234567..., a smart contract implementing this EIP. When a web browser visits pandapip1.eth, assuming I have no A, AAAA, CNAME, or SRV DNS records, the request function will be called with a resource of [] (no path). Say I have a link to /my-cool-project, and the user clicks on it. Then, the request function will be called with a resource of ['my-cool-project']. With the proposed IPFS content type, the whole website doesn’t need to be stored on Ethereum, but has all the advantages of this EIP, minus the permanence/

What is the advantage of this over just adding a record to pandapip1.eth that points at an IPFS root?

The ability to add more complex logic if it is needed. Most of the time, it isn’t (yay!), but I could imagine a use-case (such as a blockchain explorer) that could benefit from this functionality.

Do you have an example of adding more complex logic (even a contrived example would be fine for this purpose)?

A balance explorer. The resource would be the string representation of the address you’re inspecting.

What would that look like if this EIP was implemented?

So, there would be a mix.

The best example would be SPAs (single-page applications) with their front-end code fully on the Ethereum mainnet. While it would cost a fortune to push updates, the website will remain for the rest of time.

Alternatively, with the new content type, they could host the code on IPFS. While it might eventually disappear, the advantage of this over returning a tree would be that any URL would be resolved, not just ones in the tree. While I can imagine a block explorer being written as a SPA, the fact that an infinite number of URLs need to be resolved to the same thing means that this standard is flexible enough for that use-case.

Things get interesting when you consider rollups or cheap sidechains. While initially, hosting a website fully on a sidechain might seem like a stupid idea, I argue it’s superior to the current system for two reasons:

  1. It might actually be more cost-efficient than the current hosting situation
  2. It’s more decentralized than hosting on a single fully centralized hosting platform like Hostinger.

I hope to see the first two scenarios most frequently, but I would argue even the third (“worst-case”) scenario is better than what we have currently.

One could host a blockchain explorer as an IPFS SPA and just use anchor or query string routing for data. There is no need to have a separate IPFS page for every block/transaction/whatever.

That being said, I don’t see how a block explorer would fit into this paradigm as much of the information one would want can’t be acquired from a contract (but can be acquired from an Ethereum client).


As a more high level argument, something with a replication factor of Y where Y < X will necessarily always be cheaper to host than something with a replication factor of X. Ethereum is a database with an RF of like 10,000 while IPFS is a database with an RF of 0-n (where n is the number of people who have recently browsed the site plus people who have pinned the site). With the introduction of Filecoin, RF changes to m-n, where m is the RF that IPFS has determined is enough to provide robust availability guarantees (I don’t actually know what m is, but it is > 1).

While this isn’t a blocker for the EIP, I’m not convinced there exists a future where this EIP would make sense for anyone as I think it is better in basically all scenarios to use something purpose built for data storage like IPFS than to use something like Ethereum which is an insanely expensive database.