Support eth_getProof(EIP-1186)

[blckngm]

Propose-a-new-feature

IMO it would support the “right” way to implement ics-02 like light clients for axon: the light client will verify commitment path/value with the state root and the proof returned by eth_getProof.

eth_getProof is also widely supported practically (geth, parity, ganache, infura, etc.).

Alternatives you've considered

Verify commitment key/value with event/log. We'd need to emit an event when the commitment. It's more cumbersome and more likely to be vulnerable to replay attacks: a commitment can be cleared/updated and cannot be verified in new state roots, but a log can always be verified.

References

• https://eips.ethereum.org/EIPS/eip-1186
• https://docs.rs/patricia-trie/0.3.0/src/patricia_trie/lookup.rs.html#45-103

[driftluo]

https://eips.ethereum.org/EIPS/eip-1186 Didn't say how to implement this

[blckngm]

Yeah I guess we'd need to look into existing implementations (of both proof generation and verification) if we want to be compatible.

Or we can use some custom format if it's just for forcerelay.

[yangby-cryptape]

The status of EIP-1186 is stagnant.

ethereum/EIPs#1186 (comment) said:

API specs are now maintained at https://github.com/ethereum/execution-apis, not in the EIPs repository.
I'm going to close this issue since this repository isn't the right place for it anymore.

ethereum/EIPs#1186 (comment) said:

The EIP does not state that there should also be a field of the address which holds whatever address is being searched for. Geth returns this field in the proofs.

ethereum/EIPs#1186 (comment) said:

It would not surprise me in the slightest to find that this idea (not even an EIP, just a proposal for an idea for an EIP) is not in line with actual implementations.