Open p4u opened 3 years ago
Can we get a rough estimation on the complexity of implementing this ?
Bump 😁
Bumping too.
This can be closed:
Is there any plan to support proofs for blocks older than 1k blocks?
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"requested block is too old, block must be within 1000 blocks of the head block number (currently 18033669)"}}
Is there any plan to support proofs for blocks older than 1k blocks?
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"requested block is too old, block must be within 1000 blocks of the head block number (currently 18033669)"}}
You could parameterize this constant https://github.com/ledgerwatch/erigon/blob/devel/turbo/jsonrpc/eth_call.go#L318 and make it work for you with more blocks - if you're ok with the performance penalties.
System information
Expected behaviour
Support EIP-1186 https://eips.ethereum.org/EIPS/eip-1186 in order to use the web3 rpc method
eth_getProof
.Geth and OpenEthereum already support it, see https://github.com/ethereum/EIPs/issues/1186
This EIP allows offchain merkle proof verification, i.e a token holder can demonstrate to an offchain service that he/she actually holds tokens for a specific contract. The only information that needs to keep the offchain service is the Ethereum block State hash.
We wrote some helpers that, in combination with the EIP1186 support, could bring a new stack of offchain (or sidechain) validation services: https://github.com/vocdoni/eth-storage-proof
In order to use the EIP1186 on a different block than the current one, its required an Ethereum Archive Node (at least in Geth and OpenEthereum). TurboGeth is much more efficient in terms of disk space, so having an archive node is cheaper and more realistic. That would become a very interesting use case for using TurboGeth (IMHO).
Actual behaviour
return &stub, fmt.Errorf(NotImplemented, "eth_getProof")
Steps to reproduce the behaviour
Just call the
eth_getProof
rpc method.Backtrace