Multikey nodes
This page contains information about how to manage multiple keys on a group of nodes.
Multikey architecture overview
The multikey feature allows a node instance to hold more than one key. These type of nodes used in multikey operations can be assimilated as a hybrid between an observer node and a validator. It behaves as an observer by holding in the validatorKey.pem file, a BLS key that will never be part of the consensus group. The node behaves also as a validator (or multiple validators) by monitoring and emitting consensus messages, whenever required on the behalf of the managed keys set.
Since an observer already performs block validation, it can be easily used to manage a group of validator keys and propose or validate blocks on behalf of the keys it possesses. To summarize, this type of node can use any provided keys, in any combination, to generate consensus messages provided that those used keys are part of the consensus group in the current round. With the multikey feature, the relationship now becomes n:2, providing that n is the number of keys managed by an entity.
The following description outlines the relationship between keys and nodes in single operation mode compared to multikey operation mode.
General implementation details
Nodes employing the multikey feature, in addition to determining the consensus group (a task typically performed by each node individually), have the capability to access and utilize the provided set of keys. They can use one or multiple keys in any combination if the node detects that at least one managed key is a part of the consensus group. The introduction of code changes to accommodate multikey nodes primarily impacting the consensus, keyManagement, and heartbeat packages.
Enhanced Security Through Virtual Peer IDs
The managing group, referred to as multikey nodes or the multikey group, enhances security by assigning validators' BLS information to "virtual" peer IDs. These virtual peer IDs are unique p2p identities that, unlike regular IDs, do not have a real address linked to them, making it impossible for the p2p network to establish a direct connection. This innovative approach adds an extra layer of security by obscuring the relationship between the validator BLS keys and the actual hosts managing those keys.
Enhanced Redundancy Sub-system for Multikey Operations
The redundancy sub-system has been enhanced to support multikey operations effectively, ensuring robustness across multiple fallback redundancy groups. A unique multikey fallback group will now independently monitor each key within a managed node for any missed consensus activities. This allows for a more resilient approach, where issues such as misconfiguration or unavailability in the primary group's nodes activate fallback mechanisms automatically.
For instance, if the primary multikey group is configured to manage keys from [key_0, key_1 ... key_e-1, key_e+1 ... key_n] (excluding key_e), and the redundancy multikey fallback group is set to [key_0, key_1 ... key_e-1, key_e, key_e+1 ... key_n], the system will trigger the fallback for key_e after detecting k missed consensus activities (such as proposing or signing a block) within the primary group. The parameter k is configurable via the prefs.toml file under the RedundancyLevel setting, ensuring flexibility in threshold adjustments for activating fallback operations.
Economics running multikey nodes
As for n managed keys we will need at least a group of nodes, there is a threshold that a staking operator will want to consider when deciding to switch the operation towards the multikey mode. The switch becomes attractive for the operator when he has more than one key. So, for the time being, when we have at least 2 keys that are either eligible or waiting, the switch to multikey mode becomes feasible.
Recommended Multikey Group Size for Node Operators
While there are no explicit constraints in the source code on the number of keys a multikey group can have, the OneFinity team advises node operators to limit themselves to 32 keys per group. Exceeding this recommended number could potentially harm the blockchain. Specifically, a node with an excessive number of keys might be able to propose multiple incorrect blocks in succession, thereby hindering block synchronization and cross-notarization processes.
Usage
allValidatorsKeys.pem file
Transitioning to multikey operation involves compiling all BLS keys into a single file named allValidatorsKeys.pem. This file should be located in the same directory as the validatorKey.pem file but can be specified elsewhere using the --all-validator-keys-pem-file binary flag. Below is an example of the contents of an allValidatorsKeys.pem file:
prefs.toml file
In systems where both NodeDisplayName and Identity fields are implemented across all managed and loaded BLS keys, there's a specific naming convention to follow. Specifically, the NodeDisplayName will have an appended order index for every managed key. As an illustration, consider a scenario with NodeDisplayName configured to example. In such cases, the naming convention for the managed keys would adhere to the following pattern:
If a subset of BLS keys must operate under a distinct identity or employ a different naming convention, the NamedIdentity section is particularly useful. Continuing with our example, to assign a new identity or node name to the 791c7e2bd6a5fb1371... key, the section should be defined as follows:
which will generate the naming as:
Security notes for the multikey nodes
The multi-key feature enables the use of multiple keys on a small group of nodes. At first glance, this appears to potentially weaken security by offering attackers more targets within a large staking provider. However, there are strategies to diminish these concerns, as outlined below:
Use the recommendation found in this page regarding the maximum number of keys per multikey group;
Ensure that each primary multi-key group has at least one backup multi-key group as a precautionary measure in case of any unforeseen issues.
Use the
NamedIdentityconfiguration explained above to obfuscate the BLS keys and their declared identity from the actual nodes that manage the keys.
Regarding point 3, each managed BLS key will create a virtual P2P identity that no node from the network can connect to, as it does not advertise the connection info but is only used to sign P2P messages. Associated with a separate named identity, the system will render the BLS key virtually unreachable, and its origin hidden from the multikey nodes. Therefore, node operators will need to apply the following changes to the prefs.toml file:
In the
[Preference]section, the two options calledNodeDisplayNameandIdentityshould be changed to terms different from those used in BLS definitions to avoid easy matching. Generic names likegatewayorobserverare suitable for this section. Additionally, completely random strings can be employed to facilitate the identification of nodes in the explorer. TheIdentityfield can be left empty.In the
[[NamedIdentity]]section, the two options calledNodeNameandIdentitywill be changed to the actual identities of the BLS keys, such as the staking provider brand names. They must be different from those defined in the[Preference]section.
In this manner, the operation will bear resemblance to the sentinel nodes encountered in other contexts. The key distinction in our scenario lies in the significantly simplified setup, as there's no need to maintain a separate network for the protected nodes. Implementing points 1, 2, and 3 will ensure that the security of our arrangement is on par with a _sentinel setup.
Configuration example
Let's assume we possess 5 BLS keys belonging to a staking provider named testing-staking-provider, and we aim to implement the security measures discussed earlier. For illustrative purposes, we have generated 5 random BLS keys. The allValidatorsKeys.pem file should therefore contain entries similar to the following:
Staking operators responsible for creating the allValidatorsKeys.pem file used on the chain should merge all keys from their respective validatorKey.pem files using a text editor. The merged content should look similar to the example provided.
For the prefs.toml file, we can have definitions like:
After starting the multikey nodes, within approximately 10 minutes, the explorer will reflect the changes. All nodes participating in the multikey group will broadcast their identity as an empty string, and their names will be depicted as s14. Conversely, the identities of the BLS keys will be named and identified as follows:
15eb03756...
tsp-00
testing-staking-provider
ff12bc7f4...
tsp-01
testing-staking-provider
3dec570c0...
tsp-02
testing-staking-provider
38a93e3c0...
tsp-03
testing-staking-provider
1fce426b6...
tsp-04
testing-staking-provider
Last updated