Redundancy Setup

Redundancy in OneFinity Validator Nodes

OneFinity allows setting up hot-standby nodes for each Main Validator, enhancing high availability by using the same validatorKey.pem across 'n' additional nodes. These nodes, hosted on separate servers, synchronize with the Main Validator and take over automatically if it fails. Configuration differentiation is achieved with a specific setting in the prefs.toml file.

Configuring Hot Standby Nodes with RedundancyLevel

The RedundancyLevel setting in the prefs.toml configuration file enables the management of hot-standby nodes in a network. It determines the behavior and role of each node in relation to the Main Validator. Here's a breakdown of how to effectively use this option:

• Main Validator (RedundancyLevel=0): A node with this setting is designated as the Main Validator. It is responsible for proposing and signing blocks. If the RedundancyLevel is unset, the node defaults to 0, making it the Main Validator. This ensures seamless backward compatibility and does not affect existing validators during upgrades.

• Hot-Standby Nodes (RedundancyLevel=positive value): Nodes configured with a positive RedundancyLevel act as backups. They synchronize with the network and shuffle between shards, mirroring the Main Validator, but do not sign blocks. The value set indicates the node's priority in the automatic fail-over sequence. For example:

  • A node with RedundancyLevel=1 becomes active after 5 (level*5) missed rounds by the Main Validator.

  • A node with RedundancyLevel=3 activates after 15 (level*5) missed rounds, or 10 rounds following the first hot-standby, whichever comes first.

• Inactive Standby Nodes (RedundancyLevel=large or negative value): Setting a large value (e.g., 1 million) or a negative value (e.g., -1) ensures that the node remains passive. It will not produce/sign blocks but will stay synchronized with the network.

This setup provides a robust and adaptable network framework, guaranteeing stable block creation and verification, even with disruptions.

GUIDELINES FOR REDUNDANCY LEVEL CONFIGURATION

• Unique Redundancy Levels: Ensure each node has a unique RedundancyLevel. Nodes with identical RedundancyLevel values may sign blocks simultaneously, which doesn't impact the protocol now, but future updates will penalize double signing through slashing of the BLS key's stake.

• Main Validator Recovery: If the Main Validator (RedundancyLevel 0) becomes online again, hot-standby nodes will automatically switch back to standby mode.

• Public Key Privacy: Hot-standby nodes use a different, automatically generated public key for network advertisement. This hides the actual public key that will be used for signing header blocks, enhancing security.

Improved Mitigation Against DDoS Attacks Using BLS Public Keys

The implementation of BLS public keys enhances security by making it more challenging for attackers to target all IP addresses associated with a given validator. This is achieved through a mechanism where, in the event of the Main Validator being compromised, the hot-standby nodes only reveal their association with the BLS public key when necessary for block signing, maintaining their anonymity at other times. This strategic reveal ensures that:

• Hot-standby nodes remain under the radar, not drawing unnecessary attention that could lead to a DDoS attack. They only become visible to the network when they step in to sign blocks, minimizing their exposed footprint.

• Signature continuity is maintained. The activation of hot-standby nodes to sign blocks does not necessitate re-verification of BLS signatures by the network, ensuring a seamless transition and uninterrupted consensus process.

• Strategic functionality of hot-standby nodes. The deployment of random BLS keys on these nodes serves several critical functions, notably enhancing their ability to remain undetected when not actively participating in the consensus process, thereby significantly reducing the risk of attack.

This approach adds a layer of protection against DDoS attacks, safeguarding the network by concealing the full scope of IP addresses associated with it and ensuring the resilience and integrity of the consensus process.