Move Blockchain Toolkit storage providers to Neo Modules project

[devhawk]

The Neo3 version of Neo Express and Neo Debugger both depend on a RocksDB and Checkpoint implementation of Neo.Persistence.IStore. Currently, these live in the ngdseattle/persistence project. However, it feels like neo-modules is the correct repo for these storage providers.

The Blockchain Toolkit RocksDB provider is similar to the existing neo-modules RocksDB provider, with the following improvements

• Create column families on demand for faster startup. In preview 2 testing, the current neo-modules RocksDB provider took 10-15 seconds to start as it creates 256 column families on first run. For a production node, that will likely go thru this initialization once in its lifetime, this delay is perfectly fine. For a developer node, this delay is unacceptable.
• Checkpoint Management Blockchain Toolkit uses RocksDB for persistence because it can checkpoint a database while it's running. The Blockchain Toolkit RocksDB provider includes methods to create, restore and validate checkpoints.
• Read-Only Mode The Blockchain Toolkit RocksDB supports OpenReadOnly for use with the checkpoint provider (described below)

The Checkpoint Provider supports neo-express's checkpoint commands. This provider uses a Neo.Persistence.IReadOnlyStore instance and stores all changes in memory. This is primarily useful for test and debug scenarios.

Note, I don't feel strongly about where these developer focused storage providers should live. If the neo core dev community felt that neo-modules repo is for production modules and that these developer-scenario focused storage providers belong somewhere else. we can easily create a new repo with a name like neo-dev-modules for these (and future dev-scenario modules) to live.

[erikzhang]

@shargon

[shargon]

Create column families on demand for faster startup. In preview 2 testing, the current neo-modules RocksDB provider took 10-15 seconds to start as it creates 256 column families on first run. For a production node, that will likely go thru this initialization once in its lifetime, this delay is perfectly fine. For a developer node, this delay is unacceptable.

Agree, we should move prefix to an enum in order to know the current columns.

Checkpoint Management Blockchain Toolkit uses RocksDB for persistence because it can checkpoint a database while it's running. The Blockchain Toolkit RocksDB provider includes methods to create, restore and validate checkpoints.

It could be done only for rocksDb

Read-Only Mode The Blockchain Toolkit RocksDB supports OpenReadOnly for use with the checkpoint provider (described below)

Do you need this only for rocksDb?

[devhawk]

The Blockchain Toolkit RocksDB provider works w/ the current byte prefix approach, but I am 100% in favor of moving prefix to an enum.

Regarding checkpoint management, yes this is only for the RocksDB Provider. These capabilities are not / should not be exposed via IStore abstraction. Neo-Express explicitly checks if (Blockchain.Singleton.Store is RocksDbStore rocksDbStore) when attempting a live checkpoint operation

I only need OpenReadOnly for RocksDB - unlike neo-cli, neo-express does not provide end user extensibility via plugins. neo-express uses only the RocksDB or Checkpoint provider, though for future extensibility the checkpoint provider has been designed to work with any IReadOnlyStore instance.