The ZChains currently utilizes LevelDB for data storage, as well as an in-memory data store.
Throughout the ZChains, when modules need to interact with the underlying data store, they don't need to know which DB engine or service they're speaking to.
The DB layer is abstracted away between a module called Storage, which exports interfaces that modules query.
Each DB layer, for now only LevelDB, implements these methods separately, making sure they fit in with their implementation.
In order to make querying the LevelDB storage deterministic, and to avoid key storage clashing, the ZChains leverages prefixes and sub-prefixes when storing data
// Prefixes for the key-value storevar (// DIFFICULTY is the difficulty prefix DIFFICULTY = []byte("d")// HEADER is the header prefix HEADER = []byte("h")// HEAD is the chain head prefix HEAD = []byte("o")// FORK is the entry to store forks FORK = []byte("f")// CANONICAL is the prefix for the canonical chain numbers CANONICAL = []byte("c")// BODY is the prefix for bodies BODY = []byte("b")// RECEIPTS is the prefix for receipts RECEIPTS = []byte("r")// SNAPSHOTS is the prefix for snapshots SNAPSHOTS = []byte("s")// TX_LOOKUP_PREFIX is the prefix for transaction lookups TX_LOOKUP_PREFIX = []byte("l"))// Sub-prefixesvar ( HASH = []byte("hash") NUMBER = []byte("number") EMPTY = []byte("empty"))
Future Plans
The plans for the near future include adding some of the most popular DB solutions, such as: