-
Notifications
You must be signed in to change notification settings - Fork 45
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
Question: could this theoretically deliver a proof of eth_call result? #16
Comments
Answering my own question, this is a sample tx eth_call style done against a ERC20 token asking for balance -- running the tx locally instead of remote node: This uses ethereumjs-vm 2.6.0. Bits and pieces liberally borrowed from https://github.com/MetaMask/eth-json-rpc-middleware/blob/master/vm.js
|
holy shit |
this is what I wanted someone to do. actually this would return a single proof for each value looked up - resulting in lots or repeated data. I've been hoping someone would do this though: In theory, you could combine all the data that must be "touched" by a tx into a special MPT that has only the proof nodes needed. Then the VM could use that as if it were the normal MPT. This code is cool. It's a great start. |
Yeah, I think there's a lot of room for making centralised nodes more trustable (really needed for UX) I'm currently working on next proof of concept in line -- running eth_call against just a known good block hash -- and no actual Ehereum node to talk to. .. where the block hash would be downloaded through IPFS, state trie navigated with IPLD and then storage trie same way (https://github.com/ipld/js-ipld-ethereum ) There's some partial support in Parity to act as such a source of IPFS objects but working to get storage trie available too. |
agreed. If you find anything that fits this repo feel free to make PR. If you are communicating with an eth-node we can maybe add some sort of If you are use IPFS you cant do that, but you could hack the MPT software to request from IPFS durring each |
Been playing with verifying ENS resolver results against a known good block hash, but that often takes a bit of poking around the contract to find right getStorageAt
Could this theoretically use ethereumjs-vm or the likes + storageAgainstBlockHash for SLOAD queries?
The text was updated successfully, but these errors were encountered: