Registry Persistence: Serialization and Storage

I devoted this week to implementing registry persistence, a term meaning that the state of the registry is stored on disk and preserved between restarts of the client. Implementing registry persistence primarily consists of two parts: (1) authoring the code that converts the registry data structure into a format that can be stored on disk (serialization), and (2) authoring the procedures that read and write this data to disk. Here I describe what I did this week towards these ends.

–––––

The Registry State Requires Persistence

The staker registry is a RAM data structure that keeps track of the state and balances of all stakers that sign blocks as part of the qPoS protocol. Examples of registry state information include public keys that can change staker ownership, sign blocks, or spend from the staker balance. Registry state also includes how many blocks a staker has been assigned, missed, and produced, and a recent history of blocks. The registry also has a queue that is updated each block and regenerated each round, and much more state information required to stay synchronized with the blockchain.

So that clients do not need to replay the entire blockchain to determine the state of the registry at startup, it is necessary to store the registry state to disk periodically. This week I researched and coded the most essential parts of this storage process.

–––––

Researching the Existing Persistence Framework

Since persistence is not directly related to blockchain consensus or the user experience, I haven’t had much interaction with the existing persistence code since I started working on blockchain technology. For this reason, most of my time this week was spent researching in detail how the Stealth client, which is based on Bitcoin, handles blockchain persistence. I always try to integrate new code as seamlessly and sensibly as possible into the existing framework, and this requires a fairly detailed understanding of the codebase. It also can save a lot of effort that would otherwise get sunk into re-inventing solutions that already exist. In summary, I studied and experimented with (1) the serialize.h source file (formatting for storage), (2) the txdb-leveldb.* source files (procedures to write to disk), and (3) the LevelDB application programming interface (API).

–––––

Key Registry Persistence Decisions

This week my main coding accomplishments were (1) completing the formatting code for registry serialization and (2) authoring the read/write procedures for the serialized registry data. Additionally, I have made and reworked a number of design decisions, some of which contrast the decisions I presented last week.

Registry persistence will be incorporated into the existing blockchain persistence code.

I spent some time this week refactoring the existing blockchain persistence code so that the basic read/write functionality could be shared with the registry through an object oriented interface. In other words, a parent class would handle the lowest level interaction with LevelDB and specialized child classes would handle specific read/write operations for the blockchain and registry separately. However, since I decided that persistence of the registry will be simple snapshots, only two procedures to (1) read and (2) write the serialized registry data are needed. For this reason, I reverted the refactoring and am adding these two procedures without any other notable restructuring of the existing classes.

Registry persistence will exist solely as snapshots, taken every 720 blocks.

This decision is different from what I said last week, where I decided registry persistence would be updated every block. I decided that blockwise updates would require an overly-complicated implementation and would also be undesirable from an efficiency perspective. Additionally, after having better learned the strengths of LevelDB, writing periodic snapshots would actually be more efficient than writing small updates every block. Read operations would be more efficient too, because only a single snapshot is required on startup.

Another reason for using snapshots as the sole method of registry persistence is that the qPoS protocol already requires keeping snapshots for blockchain reorganizations. The robustness of a blockchain protocol requires the ability to recover when consensus breaks down and the chain forks. If a client gets on the wrong fork, it must reorganize blocks to get on the right fork, once it determines that it was on the wrong fork. Nearly all blockchain-based cryptocurrencies have this ability to reorganize. For qPoS, reorganization requires reverting the ledger state back to a common snapshot, then going forward on the correct chain. In qPoS, a full registry snapshot is stored to disk every 720 blocks (1 hour). For more information, reorganization in qPoS is described more extensively in the Whitepaper.

–––––

Registry Replay and Snapshot Requirements

Replay from the Latest Snapshot will be Fast

On restart, as many as 720 blocks will need to be replayed to update the state of the registry to the most recent stored block. This replay actually turns out to be a very lightweight computational burden because all stored blocks have already been validated. That means these stored blocks don’t need to be revalidated, which would be computationally expensive because of cryptographic checks like signature validation. Instead, these blocks only need to be used to replay the registry state, which requires only computationally simple operations like addition, subtraction, multiplication, division, and bitwise operations. In short, a replay of 720 blocks is expected to require less than one second, which should be unnoticable during startup. In fact, by default, the present Stealth client (and many other Bitcoin-based cryptocurrency clients) does a full validation of the most recent 2000 blocks, which usually takes a few seconds at most.

Registry Snapshots Require Insignificant Disk Storage

One concern might be how much space the registry snapshots will require on disk. The following inputs are needed to calculate this storage requirement:

1. A snapshot is taken every hour.
2. Snapshots are stored for four days.
3. Each snapshot is expected to be around 0.15 MB.

Given these inputs, the disk space needed to hold all registry snapshots is expected to be less than 15 MB total, representing a practically negligible storage requirement relative to the size of even the smallest available SSD drives.

–––––

Hondo

https://www.stealth.org