Implement EIP-1186 eth_getProof

[kpp]

Description

Implements https://docs.alchemy.com/reference/eth-getproof

Linked Issues

• Fixes Implement eth_getProof #1527

[eyusufatik]

can you base this on v0.5.5 release branch?

we can merge it to nightly later on.

[eyusufatik]

note:

in ethereum accounts have storage root

so root -> account -> storage

you have 2 proofs that are actually continiuations on the state tree.

we use a different tree and accounts and storages live on different parts of this tree

that's why account storage root is not a thing in Citrea.

so we can return two different proofs, one for the AccountInfo and one for the storage queried. We'll need to explain in our docs how to verify proof from eth_getProof, but it's fine.

so leave storage root empty and put two proofs, one for account being read, one for the storage queried.

[orkunkilic]

so we can return two different proofs, one for the AccountInfo and one for the storage queried. We'll need to explain in our docs how to verify proof from eth_getProof, but it's fine.

then I highly suggest renaming this endpoint into something else. Most people will query it and their program/library will panic.

[kpp]

can you base this on v0.5.5 release branch?

Yes, but I wanted to ported it into 0.5.5 later

[eyusufatik]

so we can return two different proofs, one for the AccountInfo and one for the storage queried. We'll need to explain in our docs how to verify proof from eth_getProof, but it's fine.

then I highly suggest renaming this endpoint into something else. Most people will query it and their program/library will panic.

The response will have the same output format. Do you still think it’s a problem? We can have a verification code snippet in our docs for js

[orkunkilic]

so we can return two different proofs, one for the AccountInfo and one for the storage queried. We'll need to explain in our docs how to verify proof from eth_getProof, but it's fine.

then I highly suggest renaming this endpoint into something else. Most people will query it and their program/library will panic.

The response will have the same output format. Do you still think it’s a problem? We can have a verification code snippet in our docs for js

If the output format doesn't blow up the caller client, then its ok. verification algorithm is not an issue as long as its documented (or even added as an endpoint?)

[eyusufatik]

this feels weird? why a vec of single length?

I thought the storage proof was a vec of merkle nodes that should be hashed?

[kpp]

That's because let proof: sov_state::storage::StorageProof<<<C as Spec>::Storage as Storage>::Proof> = working_set.get_with_proof(storage_key); - the real type is generic. I would need to hack into trait Proof to properly serialize it with rlp.

Do we need it?

[eyusufatik]

we can force the rpc implementation to have NativeStorage = ProverStorage

so we get a concrete type for the Proof

then we can apply eth-like serialization to the proof

[eyusufatik]

PR looks ok.

some testing we need:

• regular old e2e tests with Rust verification of the proof
• web3py test (bin/citrea/tests/evm/ethers_js)
• ethersjs test (bin/citrea/tests/evm/web3_py)