Create method to track ledger RevEntry writes and compare wallet to ledger state to help in restored-from-backup scenario

[swcurran]

Add a mechanism to the wallet to track in the database what ledger RevEntry writes are made and included that in a startup (or Admin API endpoint?) check that the wallet is in sync with the ledger.

The concern is that when a wallet must be restored from backups we have a way to check if the wallet is in sync with the ledger. For some objects (DIDs, Schema, Cred Defs, RevRegs), we can just check if the ledger objects created by the wallet exist on the ledger. However, I don't think that can be done for RevEntries. If it is not possible then let's make it possible by storing information in the database when we write a RevEntry.

[swcurran]

@andrewwhitehead @esune -- does this capture it? Are my assumptions correct? What do we do if we find the wallet does NOT contain all of the RevEntries?

[esune]

Should/could we just track a timestamp holding the last time the agent synced up with the ledger, regardless of whether that is a read or write action, and store it in the wallet in the non-secret storage?

[swcurran]

I don't see that reads are helpful. I was thinking initially we would have a "magic place" to just store the timestamp, but I didn't know how relevant that would be. As I thought about it I thought it would be more useful to have the ledger timestamp stored with the related object. And that is easy, except (AFAIK) for RevEntry (and maybe ATTRIB?).

[esune]

I thought about reads as we would have a more accurate description of when the agent last synced with the ledger, regardless of whether it wrote something to it.

I do not know enough to weigh in about the benefits of storing the timestamp and the related object. However a question comes to mind: the timestamp will need to be stored in non-secret storage so that external backup processes can potentially read it without having access to the wallet - unless we go with an admin endpoint and add this info to the /status endpont ( I believe we have one), we may still want to store this kind of info in a non-encrypted location so that we don't rely on having the right keys to obtain it. In this case, wouldn't storing the related object potentially be exposing information that should otherwise be encrypted?

[swcurran]

Ah...I didn't think the backup process would see it. How do you foresee that happening?

[esune]

I am not yet sure that is essential, but I think it would be handy to be able to restore the backup and just query the appropriate db/table to pull that information. @WadeBarnes may have thoughts since he is the backup-container mastermind.

[esune]

Transferred issue from von repo to keep it alive in case this is still something we need to look at. Ifnot, it can be closed.

@swcurran @andrewwhitehead could you please chime in based on the current status of revocation and the direction the community is taking?