search

web3 / web3.js

Collection of comprehensive TypeScript libraries for Interaction with the Ethereum JSON RPC API and utility functions.
https://web3js.org/
Other
19.25k stars 4.93k forks source link

Support for authenticating data based on eth_getProof #4751

Closed d10r closed 9 months ago

d10r commented 2 years ago

Is there an existing issue for this?

Feature Request

All popular Ethereum clients now implement the API eth_getProof as defined in EIP-1186. Also, web3.js already provides a wrapper to that via web3.eth.getProof.
It's however not trivial to verify such a proof in a Dapp, as was already pointed out in the first reaction to that EIP (the code snippet provided in the response doesn't really do the job - see this reaction and other comments in that conversation).

I think getProof could become much more valuable and useful if web3.js would also provide a method for verifying such proofs.

From the conversation around the EIP I gather that there's currently at least 2 publicly available implementations of verification:

It's my understanding that the latter is not an implementation which could readily be used by a Dapp. It may however be instructive for implementing this functionality in web3.js.

Use Cases

Any Dapp and Wallet fetching data from a remote RPC web3 provider could increase their safety by authenticating that data.

Why I believe this is relevant: Just recently, this blog post of Moxie caught quite some attention.
Among the criticisms there's the observation that nowadays typical Dapps just consume unauthenticated data they're provided with by remote RPCs. I think this is an important point which should bother all web3 devs and it seems to me that with eth_getProof we have almost everything needed to fix this issue.

I think the history of eth_getProof is also instructive: The development of EIP-1186 took place at a time when some of us were still running full nodes bundled with the wallet (remember Mist?). With that becoming infeasible, the promise was for light clients to solve the problem of allowing for decentralized Dapps with good UX. The slock.it team was then working on an IOT use case where even the light client approach was infeasible due to resource constraints. They came up with EIP-1186 as a mitigation which allows to use resource-friendly remote RPCs while keeping data authenticated.

Today we know that the light client approach didn't succeed either (in the sense that it didn't become the default for how Dapps communicate with the network) and take the model of Dapps operating with remote RPCs by default as granted.
While I believe that's a reasonable outcome with regards to ux and devx, I also believe that having data provided by those RPCs authenticated would be an important and valuable improvement, especially considering how close we already are (at least that's what it looks like to me).
I think the reason why very few (I actually don't know of any) Dapps use getProof for data authentication is that implementing verification would require a detailed understanding of low-level protocol details. That's not the abstraction layer many Dapp developers are familiar with - I guess many aren't even aware about this possibility.
If however web3.js would provide tooling for easy data verification and clear instructions and sample code for how to use it, I think a lot of Dapps may start using this.

Implementation Ideas

A basic version of verification support could be a method verifyProof (probably in the utils package) which takes the output of getProof and verifies it. While figuring out the arguments for getProof still requires a pretty good understanding of the EVM storage model, that's an abstraction level Solidity devs should be somewhat familiar with and thus a knowledge set I believe already considerably more widespread than an understanding of the lower level data structures.

An extended version of verification support could add a flag for individual data fetching methods which automatically authenticates data it provides. E.g. the options argument to methods.myMethod.call could have an additional flag authenticated.

Feature Examples/References

No response

Are you willing to implement this feature?

nazarhussain commented 2 years ago

@d10r Thanks for reaching to us with this request. I believe it would certainly be a nice feature. But considering our focus right now on 4.x rewrite, we will consider it after alpha release.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

mconnelly8 commented 9 months ago

EIP-1186 hasn't been approved, so closing this issue.