What is unique about Ancon Protocol, which took us months to grasp, it is that:
- With Vector Commitments, if the key of a node is binding, then we could have keys be IPLD Dag content addressable identifiers.
- The result is a DAG store verifiable by content (CID hash) and existence or non existentce (ICS23 + IAVL).
By applying this reasoning, and our focus on ownership and provenance, we can expect:
Any content store in an ad-hoc DAG network or IPFS without consensus, be verifiable by content addressable identifier and existence in a DAG network using an underlying IAVL tree.
But we are not discarding consensus entirely. If we keep advancing the idea, the protocol can be compared to Sidetree:
In Ancon Protocol, the proofs storage is offchain, to be useful, a genesis / root hash must be anchored, and any additional “cross chain” messaging must be also anchored. But for use cases like provenance of a DAG block, with no interactions with onchain, 100% offchain immutable changes, the protocol does not need to submit proofs. Only the last protocol hash needs to be relayed to the chain.
You get then cheap, almost free, verifiable data retrieval powered by one of the most mature vector commitments scheme created by Cosmos/Tendermint for IBC Protocol called ICS23.
To complete the feature, taking cues from Flow chain, protocol user needs to own their resources, which later, he can authorize, request authentication, delegate, encrypt and so on, … and like ZKSync, need to claim a DID compatible account, which is a path under the root hash.
This magic was finally tested yesterday in BSC Testnet, relayer working and everything, AnconProtocol.sol with a new brand refactoring, we got it working.
