Ancon Protocol implementation
What is a Vector Commitment
From Cosmos SDK Specs we get
A vector commitment is a construction that produces a constant-size, binding commitment to an indexed vector of elements and short membership and/or non-membership proofs for any indices & elements in the vector. This specification enumerates the functions and properties required of commitment constructions used in the IBC protocol. In particular, commitments utilised in IBC are required to be positionally binding: they must be able to prove existence or nonexistence of values at specific positions (indices).
Motivation
In order to provide a guarantee of a particular state transition having occurred on one chain which can be verified on another chain, IBC requires an efficient cryptographic construction to prove inclusion or non-inclusion of particular values at particular paths in state.
We then use these cryptographic construction to verify a transaction which ocurred or “commited” in one chain in another chain.
What will Ancon Protocol use these signatures?
We manage to get this rock solid recently, is not easy to implement, it goes something like:
- Enable IAVL Store for one or more keys (ie mount)
- Learn for a few weeks all about ICS23
- After that, you use CommitKVStoreManager, use the CommitMultiStore, unwrap, then make it queryable.
Then exactly these three steps
- ConvertProofs
- CombineProofs
- Calculate root from previous result
This how it looks when queried in Ancon Protocol
And this is how EVM / Solidity returns when calculating root and verifying combined proof
The ICS23 CommitmentProof (combined) in JSON
With this, we’ll get going on our next cross chain ownership task, which is Flow and Cadence. We will migrate this code base to Cadence to have Ancon DID NFT Metadata Ownership by way of Vector Commitments for Dag-CBOR IPLD based stores.
— IFESA / Rogelio Morrell C.
