Struct ClientDatabaseOptions 

pub struct ClientDatabaseOptions<GBB, StorageBackend> {
    pub write_buffer_size: usize,
    pub block_confirmation_depth: BlockNumber,
    pub soft_confirmation_depth: BlockNumber,
    pub max_fork_tips: NonZeroUsize,
    pub max_fork_tip_distance: BlockNumber,
    pub genesis_block_builder: GBB,
    pub storage_backend: StorageBackend,
}

Options for ClientDatabase.

Lifecycle of a block, by block offset from the best block with block number n, with block_confirmation_depth = 5 and soft_confirmation_depth = 2 as an example:

block   block   fork       written   block details
offset  number  blocks     to disk   in memory
        n + 1                                    next best block, being imported
     0  n       accepted   no        yes         best block
     1  n - 1   accepted   no        yes
     2  n - 2   accepted   yes       yes         soft-confirmed <- soft_confirmation_depth
     3  n - 3   accepted   yes       yes         soft-confirmed
     4  n - 4   rejected   yes       yes         confirmed once n + 1 is imported
     5  n - 5   rejected   yes       no          confirmed <- block_confirmation_depth
   ...

When block n is built, the block at n - block_confirmation_depth is confirmed (see ConsensusConstants::block_confirmation_depth), and the database marks the same block as confirmed. Fork blocks are only accepted above block offset block_confirmation_depth - 1. The block there is only confirmed once n + 1 is imported, but it already can’t change: a fork block next to it would start a reorg of block_confirmation_depth blocks, more than the largest allowed reorg of block_confirmation_depth - 1 blocks. Soft-confirmed blocks are only written to disk early, a reorg can still revert them.

Importing n + 1 on any fork makes it the best block and shifts all block offsets by one. Then other blocks at block offset block_confirmation_depth - 1 are pruned with their descendants, the block at block offset block_confirmation_depth is confirmed, which drops its block details (MMR and system contract states) from memory, and blocks that reached block offset soft_confirmation_depth are written to disk. Block details of confirmed blocks are only left on disk, [ChainInfo::header_with_details()] doesn’t return them.

Fields

write_buffer_size: usize

Write buffer size.

Larger buffer allows buffering more async writes for improved responsiveness but requires more RAM. Zero buffer size means all writes must be completed before returning from the operation that triggered it. Non-zero buffer means writes can happen in the background.

The recommended value is 5.

block_confirmation_depth: BlockNumber

Block confirmation depth, the value of ConsensusConstants::block_confirmation_depth.

Fork blocks are only accepted above block offset block_confirmation_depth - 1 from the best block, other blocks at that block offset are pruned with their descendants, and blocks are confirmed at block offset block_confirmation_depth (see the block lifecycle in ClientDatabaseOptions).

Must be at least 2.

soft_confirmation_depth: BlockNumber

Soft confirmation depth for blocks.

Doesn’t prevent forking on the consensus level but makes it extremely unlikely.

This parameter determines how many blocks are retained in memory before being written to disk. Writing discarded blocks to disk is a waste of resources, so they are retained in memory before being soft-confirmed and written to disk for longer-term storage.

Blocks are persisted as soon as they reach this depth. More recent blocks may be lost if the node is not shut down gracefully (crash, killed by the OS, etc.).

A smaller number reduces memory usage while increasing the probability of unnecessary disk writes. A larger number increases memory usage and the number of blocks that may be lost this way, while avoiding unnecessary disk writes.

The recommended value is 3 blocks.

max_fork_tips: NonZeroUsize

Defines how many fork tips should be maintained in total.

As natural forks occur, there may be more than one tip in existence, with only one of them being considered “canonical”. This parameter defines how many of these tips to maintain in a sort of LRU style cache. Tips beyond this limit that were not extended for a long time will be pruned automatically.

A larger number results in higher memory usage and higher complexity of pruning algorithms.

The recommended value is 3 blocks.

max_fork_tip_distance: BlockNumber

Max distance between fork tip and the best block.

When forks are deeper than this, they will be pruned, even without reaching the max_fork_tips limit. This essentially means the tip was not extended for some time, and while it is theoretically possible for the chain to continue from this tip, the probability is so small that it is not worth storing it.

A larger value results in higher memory usage and higher complexity of pruning algorithms.

Fork blocks at block offset block_confirmation_depth - 1 and deeper are pruned regardless (see the block lifecycle in ClientDatabaseOptions), so values of block_confirmation_depth - 2 and larger all have the same effect as no limit.

The recommended value is 5 blocks.

genesis_block_builder: GBB

Genesis block builder is responsible to create genesis block and corresponding state for bootstrapping purposes.

storage_backend: StorageBackend

Storage backend to use for storing and retrieving storage items

Trait Implementations

impl<GBB: Clone, StorageBackend: Clone> Clone for ClientDatabaseOptions<GBB, StorageBackend>

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<GBB: Copy, StorageBackend: Copy> Copy for ClientDatabaseOptions<GBB, StorageBackend>

impl<GBB: Debug, StorageBackend: Debug> Debug for ClientDatabaseOptions<GBB, StorageBackend>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.