search

WebOfTrust / keripy

Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
https://keripy.readthedocs.io/en/latest/
Apache License 2.0
56 stars 53 forks source link

Support for source seal anchors and discovery for seals that are anchored in Merkle Trees and bound to the KEL via a Merkle root seal. #846

Open SmithSamuelM opened 1 month ago

SmithSamuelM commented 1 month ago

Feature request description/rationale

Currently source seal couples can be used to percolate the less expensive validation of an event that is bound or anchored in some KEL. The two types of events that use this type of anchoring are delegated key events and transaction event log related events like revocation registry events.

When the anchor (binding seal) is placed in the seal list (anchor list) in the a field, a validator can discover it by walking the KEL either forward or backward and comparing every seal in every seal list against the seal (event said and event sn) of the anchored event.

When the validator is given a source seal couple, the couple points to the anchoring event's SAID and SN. This means that instead of walking the KEL to find the anchor, the validator merely needs to compare against the anchors in one event. This is a performance optimization enabled by percolating the source seal couplethat points to the anchoring event by attaching it to with the event being anchored.

When the event is anchored in a merkle treee which in tern is anchored with its merkel root discovery by walking the KEL no longer works. The validator would have have to have all the full Merkle tree or be able to query all the anchored Merkle trees.

So in the future, we may want to impose a discovery requirement that enables validators to query some watcher designated by the Sealer (anchorer) which will have the source seal attached to the anchored event with an API for querying the associated Merkle tree.

Related to this is the current problem of promiscuous witness services that are also acting as watchers for all other kels besides the KEL for which they are the witness. This fails when someone queries the witness for the source seal of a kel for which the witness is a witness becasue the witness does not need the anchoring seal to validate and accept into its kel the anchored event so it discards the source seal should it be attached.

The fix is for the validator to walk the kel of the Sealer and find the anchor or to get a source seal from a valid watcher of the anchored kel or have it percolated to them.

iFergal commented 6 days ago

@SmithSamuelM I have a related question. If multiple credentials are bulk issued and anchored via a single Merkle root seal - is this a Merkle tree of various individual iss/bis/rev/brv events (1-1 event to ACDC) ? Or a single iss/bis event could bulk issue 100 credentials?

I know this is completely an ACDC implementation detail but curious going forward what keripy (or teripy) would plan on doing.

For now I don't need Merkle roots but I want to plan ahead for my ACDC discovery use case.

(little bit off the main focus of this post, so apologies)

SmithSamuelM commented 5 days ago

KERI doesn't have visibility in what a seal represents, by design. This means that the semantics of a particular seal are hidden from observation. This also applies to Merkle tree root seals. So the type of merkle tree, what is in the merkle tree etc are all hidden semantic details that KERI does not know about. The users of a particular seal just discover the semantics Out of Band (OOB) to KERI. This can be private to those users.

An ecosystem of users could decide to create public interoperable semantics for Merkle trees and then seal them in a KEL. Once discovered, a particular seal can be verified against the OOB discovery of the actual Merkle tree with known semantics so sealed (anchored). AFAIK no one has come up with public interoperable semantics for any type of Merkel tree for ACDCs.

iFergal commented 5 days ago

@SmithSamuelM Yep I know - I was more so wondering if you had a view of how those public interoperable semantics should look like. But no worries if nothing has been planned out there, thanks!