Purpose

This document describes design of a simple key-value storage that can be integrated in the Dynamic Protocol State.

Design

Requirements

Ideally we would like to implement a generic key-value store that can work with any data and have an API for querying and updating the data.

• Supports arbitrary data.
• External updates to the key-value store is performed using special service event which is emitted from smart contract.
• Nodes can incorporate values in the key-value store without using the special service event, but it has to be done collectively otherwise replicas will disagree on leader’s proposal and consensus will not be reached.
• Key-value store supports adding, removing keys.
• Key-value store supports mutating data by key.
• Consensus committee must agree on content of the key-value store.

Initial version

It’s a big effort to implement a generic key-value store with properties that we have outlined in previous section. In the initial implementation we will have a slightly simpler variant, which is still protected by consensus agreement and allows updates via smart contract, but has limited flexibility w.r.t. storing data. Specifically, for the initial implementation we will use a fixed structure with pre-determined keys whose values can be updated, without ability to add or remove keys.

Specifically we will implement the following:

• Supports updating fixed set of protocol-specified key-value pairs (known in advance).

  While it depends on the specific context of the key-value pair, we probably want to support a notion of “undefined” / “not set”. Some pairs might include “not set” as a legal value, while others might not.

• Updates to the key-value store is performed using special service events which are emitted from system smart contracts. The key-value store can be changed through the following means (otherwise it’s immutable on block-by-block basis):

  • processing a special service event which is sealed in the block
  • leader and replicas follow a protocol-prescribed state machine for evolving the protocol state, which may include view-triggered changes for example

• Consensus committee must agree(=reach consensus) on content of the key-value store.

This is a good starting point which allows us to confirm that everything works. In future revisions, we will have the option to extend the design with a more sophisticated storage system (if desired).

High-level design