Model of the chain DB

Wrapper around addBlock that returns an AddBlockPromise.

The block number of the most recent "immutable" block, i.e. the oldest block we can roll back to. We cannot roll back the block itself.

Note that this is not necessarily the block at the tip of the ImmutableDB, because the background thread copying blocks to the ImmutableDB might not have caught up.

Return the immutable prefix of the current chain.

This is the longest of the given two chains:

1. The current chain with the longest suffix of weight at most k dropped.
2. The chain formed by the blocks in immutableDbChain, i.e., the "ImmutableDB". We need to take this case in consideration because the VolatileDB might have been wiped.

We need this because we do not allow rolling back more than weight k, but the background thread copying blocks from the VolatileDB to the ImmutableDB might not have caught up yet. This means we cannot use the tip of the ImmutableDB to know the most recent "immutable" block.

The slot number of the most recent "immutable" block (see immutableBlockNo).

This is used for garbage collection of the VolatileDB, which is done in terms of slot numbers, not in terms of block numbers.

While the model tracks whether it is closed or not, the queries and other functions in this module ignore this for simplicity. The mock ChainDB that wraps this model will throw a ClosedDBError whenever it is used while closed.

Return the volatile suffix of the current chain.

The opposite of immutableChain.

This is the shortest of the given two chain fragments:

1. The longest suffix of the current chain with weight at most k.
2. The suffix of the current chain not part of the immutableDbChain, i.e., the "ImmutableDB".

Functionality the block needs to support so that it can be used in the Model.

Copy all blocks on the current chain older than k to the "mock ImmutableDB" (immutableDbChain).

The ShouldGarbageCollect parameter determines if garbage collection should be performed after copying.

Idempotent.

Should the given block be garbage collected from the VolatileDB?

Blocks can be garbage collected when their slot number is older than the slot number of the immutable block (the block k blocks after the current tip).

Return True when the next block the given iterator would produced is eligible for garbage collection, i.e. the real implementation might have garbage collected it.

Return True when the model contains the block corresponding to the point and the block itself is eligible for garbage collection, i.e. the real implementation might have garbage collected it.

If the block is not in the model, return True, as it has likely been garbage-collected from the model too. Note that we cannot distinguish this case from a block that was never added to the model in the first place.

Look in the given blocks database for a fragment spanning from the given anchor to the given hash, and return the fragment in question, or Nothing.

The ImmutableDB

Update the LoE fragment, trigger chain selection and return the new tip point.

The VolatileDB