eth_call signature combined with block number is a unique identifier about caips HOT 16 OPEN

So apparently there's a "hidden" json-rpc endpoint in geth: https://eips.ethereum.org/EIPS/eip-1186

This means that we can go from eip155:1/contractAddress/blockNumber/callSignature to a merkle proof. We can encode this merkle proof as IPLD using dag-eth.

I think this is awesome and could have great implications for CACAOs based on on-chain state.
cc @ukstv @wyc

from caips.

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

from caips.

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.

from caips.

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

from caips.

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.

from caips.

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

from caips.

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

from caips.

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

from caips.

@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?

from caips.

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

from caips.

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

from caips.

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

from caips.

btw: I'm planning to slowly implement this in https://neume.network and the next step is defining the block number tag (if it hasn't been defined already).

Recently saw https://github.com/gitcoinco/metagraph too. It could benefit from it as well.

from caips.

Linking this thread here as there seems to be overlap: https://ethereum-magicians.org/t/eip-4804-web3-url-to-evm-call-message-translation/8300?u=timdaub

from caips.

One task that originates from this issue is starting to integrate the block number tag into the CAIP-19 identifier: #119

from caips.

I implemented/specified the block number tag in

• #119
• ChainAgnostic/caip-js#25

from caips.