-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eth_call signature combined with block number is a unique identifier #87
Comments
I would love this issue to be tagged for review at the next meeting! Seems a useful primitive worthy of a CAIP |
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 |
This is really interesting! |
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: |
I think the vulcanize team / https://www.laconic.com/ are about to release a light client doing what you mention using ETH-IPLD. |
@TimDaub are we still on to discuss this at tomorrow's meeting? |
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? |
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. |
Reminder-- meeting next week, would love to discuss! |
Discussed on today's call:
|
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. |
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 I think this is awesome and could have great implications for CACAOs based on on-chain state. |
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 |
One task that originates from this issue is starting to integrate the block number tag into the CAIP-19 identifier: #119 |
I implemented/specified the block number tag in |
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
then I by hashing the function signature:
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 auint8 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
Additionally, this would translate nicely into JSON RPC calls too.
The text was updated successfully, but these errors were encountered: