pub struct EpochSyncConfig {
pub disable_epoch_sync_for_bootstrapping: bool,
pub epoch_sync_horizon: u64,
pub ignore_epoch_sync_network_requests: bool,
pub timeout_for_epoch_sync: DurationAsStdSchemaProvider,
}
Expand description
EpochSyncConfig
JSON schema
{
"type": "object",
"required": [
"epoch_sync_horizon",
"timeout_for_epoch_sync"
],
"properties": {
"disable_epoch_sync_for_bootstrapping": {
"description": "If true, even if the node started from genesis, it will not perform epoch sync.\nThere should be no reason to set this flag in production, because on both mainnet\nand testnet it would be infeasible to catch up from genesis without epoch sync.",
"default": false,
"type": "boolean"
},
"epoch_sync_horizon": {
"description": "This serves as two purposes: (1) the node will not epoch sync and instead resort to\nheader sync, if the genesis block is within this many blocks from the current block;\n(2) the node will reject an epoch sync proof if the provided proof is for an epoch\nthat is more than this many blocks behind the current block.",
"type": "integer",
"format": "uint64",
"minimum": 0.0
},
"ignore_epoch_sync_network_requests": {
"description": "If true, the node will ignore epoch sync requests from the network. It is strongly\nrecommended not to set this flag, because it will prevent other nodes from\nbootstrapping. This flag is only included as a kill-switch and may be removed in a\nfuture release. Please note that epoch sync requests are heavily rate limited and\ncached, and therefore should not affect the performance of the node or introduce\nany non-negligible increase in network traffic.",
"default": false,
"type": "boolean"
},
"timeout_for_epoch_sync": {
"description": "Timeout for epoch sync requests. The node will continue retrying indefinitely even\nif this timeout is exceeded.",
"allOf": [
{
"$ref": "#/components/schemas/DurationAsStdSchemaProvider"
}
]
}
}
}
Fields§
§disable_epoch_sync_for_bootstrapping: bool
If true, even if the node started from genesis, it will not perform epoch sync. There should be no reason to set this flag in production, because on both mainnet and testnet it would be infeasible to catch up from genesis without epoch sync.
epoch_sync_horizon: u64
This serves as two purposes: (1) the node will not epoch sync and instead resort to header sync, if the genesis block is within this many blocks from the current block; (2) the node will reject an epoch sync proof if the provided proof is for an epoch that is more than this many blocks behind the current block.
ignore_epoch_sync_network_requests: bool
If true, the node will ignore epoch sync requests from the network. It is strongly recommended not to set this flag, because it will prevent other nodes from bootstrapping. This flag is only included as a kill-switch and may be removed in a future release. Please note that epoch sync requests are heavily rate limited and cached, and therefore should not affect the performance of the node or introduce any non-negligible increase in network traffic.
timeout_for_epoch_sync: DurationAsStdSchemaProvider
Timeout for epoch sync requests. The node will continue retrying indefinitely even if this timeout is exceeded.
Trait Implementations§
Source§impl Clone for EpochSyncConfig
impl Clone for EpochSyncConfig
Source§fn clone(&self) -> EpochSyncConfig
fn clone(&self) -> EpochSyncConfig
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read more