Resolve DIDDocument from cached events

[nichonien]

Hi Team,

The did resolution to DIDDocument takes blockchain interaction to execute and sometimes may not be efficient for large number of resolution calls. If the resolver could have configurations / options to accept cached did events and fetch the events beyond the cached scope to create the DIDDoc it would be much more faster I guess.

So the resolver might look like, resolver(did, cachedEvent[], lastBlock). The lastBlock param would be the block number till where the events have been cached.

Let me know your thoughts. Thanks!

[clehner]

Hi @nichonien,

Sounds like a useful construct.

A query would still need to be made to the underlying blockchain or verifiable data registry, to see if there is new information that would invalidate the cache, right? Is the idea that only the block height needs to be queried?

It might also assist testing and particular applications to effectively enable constructing simple DID method implementations by pre-populating DID resolution results in the cache.

Related issue about caching internally to VC verification: #263.

Maybe lastBlock could be a DID resolution option (input metadata). It would just be a number, right? A non-blockchain generalization might be to use a timestamp.
Currently we have a no-cache binary option, from DID Resolution, although we're not yet making use of it.

Providing the cached DID resolutions, and implementing the lastBlock option, could be done independently.

[nichonien]

Thanks @clehner for sharing the ongoing work and resources to understand better. Looks like the team has already envisioned possibility of caching .

A query would still need to be made to the underlying blockchain or verifiable data registry, to see if there is new information that would invalidate the cache, right? Is the idea that only the block height needs to be queried?

Yes, so the API would receive the cached events and the lastBlock, so it is only needed to query the blockchain for events between lastBlock and latest.

It might also assist testing and particular applications to effectively enable constructing simple DID method implementations by pre-populating DID resolution results in the cache.

Agreed, also the caching system could always sync the last events from the blockchain even without the request for resolution. So if there is any use case for checking history of updates for did it could be very well performed with just the cached events. It would definitely open more possibility for efficient executions for different use cases.

hmm, the lastBlock could be part of resolution metadata, it would be number as the events should be cached with reference to blockchain and tech conventions and it should have no influence with a non-blockchain scope.

Providing the cached DID resolutions, and implementing the lastBlock option, could be done independently.

I didn't really understand your reference here.