We have CommitmentProof which stores one of:
ExistenceProofNonExistenceProofBatchProofCompressedBatchProof
In #389 BatchProof and CompressedBatchProof would be removed.
The ics23.VerifyMembership and ics23.VerifyNonMembership are as follows:
func VerifyMembership(spec *ProofSpec, root CommitmentRoot, proof *CommitmentProof, key []byte, value []byte) bool
func VerifyNonMembership(spec *ProofSpec, root CommitmentRoot, proof *CommitmentProof, key []byte) bool
Only ExistenceProof is valid for VerifyMembership and NonExistenceProof is only valid for VerifyNonMembership. These functions are ultimately proof.Verify(...)
CommitmentProof usage could be removed by treating ExistenceProof and NonExistenceProof as two distinct types, no overlapping api/interface. This would require some downstream changes to iavl, sdk, ibc-go. The main substantial change I can imagine is if any api's are along the lines of QueryProof where a commitment proof is construct of either an existence proof or non existence proof
We have
CommitmentProofwhich stores one of:ExistenceProofNonExistenceProofBatchProofCompressedBatchProofIn #389
BatchProofandCompressedBatchProofwould be removed.The
ics23.VerifyMembershipandics23.VerifyNonMembershipare as follows:Only
ExistenceProofis valid forVerifyMembershipandNonExistenceProofis only valid forVerifyNonMembership. These functions are ultimatelyproof.Verify(...)CommitmentProofusage could be removed by treatingExistenceProofandNonExistenceProofas two distinct types, no overlapping api/interface. This would require some downstream changes to iavl, sdk, ibc-go. The main substantial change I can imagine is if any api's are along the lines ofQueryProofwhere a commitment proof is construct of either an existence proof or non existence proof