cfxcore/consensus/config.rs
1use cfx_internal_common::ChainIdParams;
2
3use super::{pivot_hint::PivotHintConfig, ConsensusInnerConfig};
4
5#[derive(Clone)]
6pub struct ConsensusConfig {
7 /// Chain id configs.
8 pub chain_id: ChainIdParams,
9 /// When bench_mode is true, the PoW solution verification will be skipped.
10 /// The transaction execution will also be skipped and only return the
11 /// pair of (KECCAK_NULL_RLP, KECCAK_EMPTY_LIST_RLP) This is for testing
12 /// only
13 pub bench_mode: bool,
14 /// The configuration used by inner data
15 pub inner_conf: ConsensusInnerConfig,
16 /// The epoch bound for processing a transaction. For a transaction being
17 /// process, the epoch height of its enclosing block must be with in
18 /// [tx.epoch_height - transaction_epoch_bound, tx.epoch_height +
19 /// transaction_epoch_bound]
20 pub transaction_epoch_bound: u64,
21 /// The number of referees that are allowed for a block.
22 pub referee_bound: usize,
23 /// Epoch batch size used in log filtering.
24 /// Larger batch sizes may improve performance but might also prevent
25 /// consensus from making progress under high RPC load.
26 pub get_logs_epoch_batch_size: usize,
27
28 /// Limits on epoch and block number ranges during log filtering.
29 pub get_logs_filter_max_epoch_range: Option<u64>,
30 pub get_logs_filter_max_block_number_range: Option<u64>,
31 /// Max limiation for logs
32 pub get_logs_filter_max_limit: Option<usize>,
33
34 /// TODO: These parameters are only utilized in catch-up now.
35 /// TODO: They should be used in data garbage collection, too.
36 /// TODO: States, receipts, and block bodies need separate parameters.
37 /// The starting epoch that we need to sync its state and start replaying
38 /// transactions.
39 pub sync_state_starting_epoch: Option<u64>,
40 /// The number of extra epochs that we want to keep
41 /// states/receipts/transactions.
42 pub sync_state_epoch_gap: Option<u64>,
43
44 /// The file path and checksum for `PivotHint`
45 pub pivot_hint_conf: Option<PivotHintConfig>,
46}