eth_call signature combined with block number is a unique identifier

[TimDaub]

For any evm-compatible chain, by generating the data necessary to execute a JSON-RPC "eth_call", combined with a block number, this may yield a unique identity.

Say in block x+1 I commit the following contract on-chain

contract {
  function foo(uint8 bar) public returns (uint8) {
    return bar + 1;
  }
}

then I by hashing the function signature:

bytes4(sha3("foo(uint8)"))

I can generate the commonly known 4 byte function signature. But with the help of the contract abi specification I can also generate a specific call signature that combines the function signature with actual inputs. In a library of mine, I'm doing this using web3-eth-abi.

So e.g. combining the result of bytes4(sha3("foo(uint8)")) and a uint8 5 yields another hash that uniquely identifies calling an on-chain function with a certain value.

That in itself isn't interesting yet as this type of identifier can change depending on when you call the RPC endpoint as e.g. new blocks could alter the outcome of the call. However, if you were to make this call towards a specific confirmed block, then you'd always get the same deterministic outcome, which means that "eth_call" signature and block number are a unique identifier for a datum on an evm chain.

If e.g. I wanted to know the price of a Uniswap pool pair e.g. ETH/USDC 2 weeks ago (or x blocks ago), if we had a CAIP identifier, we could start identifying the exact price using a CAIP ID. E.g. we could use a similar structure as CAIP-22

eip155:1/contractAddress/blockNumber/callSignature

Additionally, this would translate nicely into JSON RPC calls too.

[bumblefudge]

I would love this issue to be tagged for review at the next meeting! Seems a useful primitive worthy of a CAIP

[ligi]

I dropped him a mail - was too late for the meeting yesterday - but maybe we can have him at the next one - would also love to see his CAIPs discussed at the next meeting
Anyway will give you permissions to add labels

[oed]

This is really interesting!
There's also some intersection between this and representing the ethereum blockchain in IPLD. With that you can essentially generate a merkleproof of any state at any point in time and sync it across the network using IPFS.

[TimDaub]

yeah. It'd also be awesome to cache the answer to this identity on the node level as we have definite rules for it's immutability (the fork choice rules of e.g. Ethereum). I had this idea when I was thinking of a p2p oracle network that can surface blockchain data for me [1, 2].

But actually, it is useful for other tasks too as e.g. caching.

It's been a while but consider that e.g. this identifier would also allow a browser-based service worker to cache previous requests to an Ethereum fullnode in browser cache: A proof of concept is here: https://github.com/rugpullindex/web3-service-worker-cache

And if that's the case, then it'd also allow a swarm of nodes answering a potential request in replacement of asking the full node. It's an old blog post, but essentially using webtorrent where the magnet link is the calldata signature outlined in this issue here would allow to probably reduce 99% of all infura directed web3 JSON-RPC calls: https://rugpullindex.com/blog/2021-03-01/scaling-ethereum-one-tx-at-a-time#ethtorrentADecentralizedWeb3Provider

references:

• 1: https://rugpullindex.com/blog/2021-12-19/community-crawler
• 2: https://rugpullindex.com/blog/2021-12-25/data-source-validation-theory

[oed]

I think the vulcanize team / https://www.laconic.com/ are about to release a light client doing what you mention using ETH-IPLD.

[bumblefudge]

@TimDaub are we still on to discuss this at tomorrow's meeting?
Info here ChainAgnostic/CASA#14

[TimDaub]

@TimDaub are we still on to discuss this at tomorrow's meeting? Info here ChainAgnostic/CASA#14

Thanks for making me aware. I want to present and discuss the idea in a meeting but I just saw that tomorrow, I won't be able to make time. When's the next possibility?

[bumblefudge]

4 weeks from tomorrow at the same time! Please smash the calendar-subscribe button here: ChainAgnostic/CASA#14

[TimDaub]

4 weeks from tomorrow at the same time! Please smash the calendar-subscribe button here: ChainAgnostic/CASA#14

ok, then I'll be at the one on March 10. If anyone else wants to drive this proposal in today's meeting, feel free to do so. All information should be in the issue here.

[bumblefudge]

Reminder-- meeting next week, would love to discuss!

[bumblefudge]

Discussed on today's call:

• start with a PR defining just blockheight URN (CAIP 2 + 10 + ___)
• future spec PR about callSignatures should
  • include a reference to an implementation if there is one
  • consider VMs where blockheight is optional and/or defaults to /LATEST
  • consider post-merge blockHeight "previewing" (ahead of finality)
  • tag TrueBlocks people for review :D