feat: ADR-040: ICS-23 proofs for SMT store

[roysc]

Description

Implements ICS-23 conformant proofs for the SMT-based KV store and defines the proof spec as part of ADR-040.

Closes: vulcanize#8

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules - n/a
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[roysc]

Commenting so the bot won't close - this builds on #9892 and will be un-drafted when that's merged

[codecov]

Codecov Report

Merging #10015 (998a94f) into master (9ce0844) will decrease coverage by 0.95%.
The diff coverage is 62.65%.

❗ Current head 998a94f differs from pull request most recent head 0ae8bd4. Consider uploading reports for the commit 0ae8bd4 to get more accurate results

@@            Coverage Diff             @@
##           master   #10015      +/-   ##
==========================================
- Coverage   65.85%   64.89%   -0.96%     
==========================================
  Files         659      616      -43     
  Lines       67511    59315    -8196     
==========================================
- Hits        44456    38493    -5963     
+ Misses      20469    18587    -1882     
+ Partials     2586     2235     -351     

Impacted Files	Coverage Δ
db/memdb/db.go	72.72% <ø> (ø)
store/rootmulti/proof.go	100.00% <ø> (+26.66%)	⬆️
store/types/commit_info.go	0.00% <0.00%> (ø)
store/types/proof.go	0.00% <0.00%> (ø)
store/types/store.go	66.66% <ø> (+1.96%)	⬆️
store/v2/dbadapter/store.go	0.00% <0.00%> (-97.15%)	⬇️
db/prefix/prefix.go	42.20% <26.08%> (ø)
store/v2/root/view_store.go	52.63% <52.63%> (ø)
store/v2/root/proof.go	58.62% <58.62%> (ø)
store/v2/smt/ics23.go	62.13% <62.13%> (ø)
... and 238 more

[roysc]

This depends on the SmtSpec introduced here cosmos/ics23#57, need to update go.mod once that is merged & tagged

[roysc]

There's an unfortunate consequence of how the SMT functions which may or may not be an issue here.

The SMT hashes keys to produce a path, so when a proof is created, the resulting CommitmentProof contains a Key field equal to the hash of the key used to query the store, rather than the key itself. This could be counterintuitive and less ergonomic for users.

req := abci.RequestQuery{
	Path:  "/store_name/key",
	Data:  []byte("key_name"),
	Prove: true,
}
res := store.Query(req)
// res.Key == req.Data
// but, res.ProofOps.Ops[0].Key == sha256(res.Key)

It doesn't seem like there should be major consequences for this as long as code that deals with proofs doesn't expect these fields to match. If nothing outside the SDK looks at them, it should be fine.

But if we do want to change it, it can't be changed within the SMT proof spec as is. There is LeafSpec.PrehashKey, but this just indicates hashing of the key path within the leaf node. In this case, the key is hashed to create the key path, so I think a proper solution would be to add a PrehashKey field to ProofSpec (defaulting to NO_HASH of course) to reflect this behavior.

[roysc]

Update: this depends on cosmos/ics23#61 - marking draft until that's merged

[roysc]

All the dependencies in https://github.com/confio/ics23 have been merged, so this is ready for review (it functions independently of #10174 which is also in-flight).

[robert-zaremba]

left one comment to address before merge - one error check is missing.

[robert-zaremba]

lat return value is an error - we must check it.

[roysc]

it's actually the list of keys in the map:

func ProofsFromMap(m map[string][]byte) ([]byte, map[string]*tmcrypto.Proof, []string) {

[robert-zaremba]

does this depends on the latest / not released changes in ibc repo?

[roysc]

No changes needed for ibc. But ics23 can bump to go/v0.7.0-rc, I'll update it