Struct Configuration

pub struct Configuration {
    pub me: SigningKey,
    pub chain_id: ChainID,
    pub block_sync_request_limit: u32,
    pub block_sync_server_advertise_time: Duration,
    pub block_sync_response_timeout: Duration,
    pub block_sync_blacklist_expiry_time: Duration,
    pub block_sync_trigger_min_view_difference: u64,
    pub block_sync_trigger_timeout: Duration,
    pub progress_msg_buffer_capacity: BufferSize,
    pub epoch_length: EpochLength,
    pub max_view_time: Duration,
    pub log_events: bool,
}

Stores the user-defined parameters required to start the replica, that is:

1. The replica’s keypair.
2. The chain ID of the target blockchain.
3. The sync request limit, which determines how many blocks should the replica request from its peer when syncing.
4. The sync response timeout (in seconds), which defines the maximum amount of time after which the replica should wait for a sync response.
5. The progress message buffer capacity, which defines the maximum allowed capacity of the progress message buffer. If this capacity is about to be exceeded, some messages might be removed to make space for new messages.
6. The length of an “epoch”, i.e., a sequence of views such that at the end of every such sequence replica should try to synchronise views with others via an all-to-all broadcast.
7. The maximum view time, which defines the duration after which the replica should timeout in the current view and move to the next view (unless the replica is synchronising views with other replicas at the end of an epoch).
8. The “Log Events” flag, if set to “true” then logs should be printed.

Chain ID

Each HotStuff-rs blockchain should be identified by a chain ID. This is included in votes and other messages so that replicas don’t mistake messages and blocks for one HotStuff-rs blockchain does not get mistaken for those for another blockchain. In most cases, having a chain ID that collides with another blockchain is harmless. But if your application is a Proof of Stake public blockchain, this may cause a slashable offence if you operate validators in two chains that use the same keypair. So ensure that you don’t operate a validator in two blockchains with the same keypair.

Sync response timeout

Durations stored in Configuration::block_sync_response_timeout must be “well below” u64::MAX seconds. A good limit is to cap them at u32::MAX.

In the most popular target platforms, Durations can only go up to u64::MAX seconds, so keeping returned durations lower than u64::MAX avoids overflows in calling code, which may add to the returned duration.

Log Events

HotStuff-rs logs using the log crate. To get these messages printed onto a terminal or to a file, set up a logging implementation.

Fields

me: SigningKey

chain_id: ChainID

block_sync_request_limit: u32

block_sync_server_advertise_time: Duration

block_sync_response_timeout: Duration

block_sync_blacklist_expiry_time: Duration

block_sync_trigger_min_view_difference: u64

block_sync_trigger_timeout: Duration

progress_msg_buffer_capacity: BufferSize

epoch_length: EpochLength

max_view_time: Duration

log_events: bool

Implementations

impl Configuration

pub fn builder() -> ConfigurationBuilder<((), (), (), (), (), (), (), (), (), (), (), ())>

Create a builder for building a Configuration. On the builder call the following methods to construct a valid Configuration.

Required:

• .me(...)
• .chain_id(...)
• .sync_request_limit(...)
• .sync_response_timeout(...)
• .progress_msg_buffer_capacity(...)
• .epoch_length(...)
• .max_view_time(...)
• .log_events(...)

Trait Implementations

impl Into<(HotStuffConfiguration, PacemakerConfiguration, BlockSyncClientConfiguration, BlockSyncServerConfiguration)> for Configuration

fn into( self, ) -> (HotStuffConfiguration, PacemakerConfiguration, BlockSyncClientConfiguration, BlockSyncServerConfiguration)

Converts this type into the (usually inferred) input type.