Block storage

[gurghet]

In its target state, Feeless will hold the entire nano DAG (blockchain). It will implement at least 3 different modalities to store it.

Traditional modality (historian)

In the traditional modality the entire blockchain is stored on disk in a similar way as to how the reference implementation store it: all blocks are stored preliminarily, in case of rollbacks blocks will be dropped. A pointer will be held for each chain so that no rollback is possible before said pointer. This implements cementing, an established process in the nano network. This modality should achieve maximum speed.

Pruned modality

In this modality chains will be pruned, so that only the frontier is kept for each chain. This is an experimental process in the nano network. This modality should achieve minimum storage cost.

Dual storage modality

With dual storage some chains or blocks are moved to slower and cheaper storage. There is currently no alignment on how to do this and which criteria to use to discriminate what to put in secondary storage. This modality should achieve a good balance of speed and low storage cost.

Suggested actions

Tactically, we should complete the implementation of the traditional modality before anything else but strategically we should keep in mind that the code should be malleable enough to accept the two different modalities described above.

To aid development, I would suggest to ignore cementing in a first instance. This means that, in case an existing block needs to be stored a rollback will always be triggered. Once the rollback feature is proven to work correctly cementing can be done.

• basic storage
  • open
  • state
  • change
  • send
  • receive
• indexes (frontiers, accounts, pending...)
• rollback
  • open
  • state
  • change
  • send
  • receive
• cementing
• pruning
• dual storage