# Microledger built on top of KERI components

Thanks to the seals mechanism built into IXN event, a first-class citizen of KEL, one is able to anchor anything and anytime into the event log. The main limitation, however, is that it must be under the form of some-kind-of-digest, so any arbitrary data, that this digest is computed from, must be stored somewhere else. Depending on the use case, it may or may not be significant to keep digests-only event log or a more generic version of it, which is able to handle `any` data.

Digests-only event log is a good example of proof of provenance, where anyone, if under disposal of data stored in log, is able to cryptographically verify provenance of the data. If furthermore event log is cryptographically bound to an identifier (which is the case in KEL), one is able to verify the authenicity of the data.

Digests-only event log may also be kept public as it stores digests. Furthermore one may assume it is constantly growing in size as more events are added, because digests are fixed length, no matter how big the input data was.

One may argue that digests-only event log is not enough, in some cases, especially where the need of [event sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) characteristics are significant. In essence, where a continuous stream of events needs to be tracked in a verifiable way. Examples:
* Changes to sensitive schema;
* ...

### Root of trust

Any event log, in order to be considered verifiable, must be a chain of events, where `event_{n}` contains cryptographic digest of `event_{n-1}`. If furthermore `event_{0}` is cryptographically bound to the creator (identifier prefix), it goes under the control of the prefix. Event log is then cryptographically verifiable starting from the prefix up to last event in the log.

Above characteristic does not imply, however, that the event log is trusted at anytime during its existence. For that an additional mechanism is required to exists that may confirm that over the whole lifetime of given event log, it was consistent and cryptographically verifiable.

KEL's are considered verifiable at anytime, because other parts of the network exist, that take care of this property. If it is considered trusted, it can be proven.

Any other event log built as a chain of events requires either to be anchored into another source of trust, like `DLT` or follow similar behavior to KEL.

### Event log with seals

....

### Time problem

None of the KERI basic building blocks include any mechanism that would be time related. There is a reason for that as in decentralized world managing proper time is diffcult to achieve. However, in anything that is a log of changes, time is an ally, especially when it is required to execute a query against such log. Where there is query mechanism in case of such logs, querying by time must be a first class citizen.

## Building blocks

KEL assumes proof of provenance characteristic, but somehow lacks ability

First companion is TEL, which keeps track of all the changes to the state of given entry.

### Sample API

Example: tracking schema changes:

let ledger = new Ledger();
ledger.anchor({ foot: { "length": "i8", smell: "string" } }); 
// ^ state: { foot: { "length": "i8", smell: "string" } }

// Some time later the schema needs to be extended:
ledger.anchor({ foot: { "length": "i8", smell: "string", isBroken: "bool" } });
// ^ state: { foot: { "length": "i8", smell: "string", isBroken: "bool" } }

As the TEL is also involved, we're able to