EIP-4804: Web3 URL to EVM Call Message Translation

[qizhou]

Some updates on EIP-4804

1. name type is replaced by address type
2. add a principle to highlight that EIP-4804 should be maximum compatible with the HTTP-URL standard so that existing Web2 users can migrate to Web3 easily with minimal knowledge of this standard.

The second one is inspired by our discussion of interoperability with SVG (or more generally, any on-chain Web content), which is one of the most applications we want to support. Please take a look.

@SamWilsn

If you’re using a gateway (like foo.test), I’m guessing the full URL would look something like https://example.eth.foo.test/balanceOf/bar.eth#uint256? If the gateway is returning the raw data, it wouldn’t be able to access the anchor… So it makes sense to put it in the path component.

Yes, the URL may look like
https://example.eth.foo.test/balanceOf/bar.eth#uint256 or
https://foo.test/example.eth/balanceOf/bar.eth#uint256

where the ipfs’s gateway has similar link to resolve ipfs resources.

@qizhou

Q3: If types are supplied, where to put the input argument types and return types (which can be a tuple)? E.g.,

1. web3://foo.eth/balanceOf(address):(uint256)/bar.eth
2. web3://foo.eth/balanceOf(address)->(uint256)/bar.eth
3. web3://foo.eth/balanceOf->(uint256)/address!bar.eth
4. web3://foo.eth->(uint256)/balanceOf/address!bar.eth

Given the principle that we want to maximize compatibility with HTTP-URL, we the 5th option may be
5. web3://foo.eth/balanceOf/address!bar.eth?returnType=(uint256)

which is more like a standard HTTP-URL.