Using an MPC signer improves on security and availability, two important metrics for evaluating validators. Let’s see why.
Let us first define the terms:
Security, in this context, means the difficulty for an attacker to breach the validator server and access the private key. With the private key in hand, the attacker can fabricate signatures and create a “double-signing” event which leads to the validator being slashed.
Availability means the validator's ability to stay online and fulfill its signing duty under adversarial conditions, such as during a DDoS attack. Failing to maintain a high uptime leads to lowered yields for delegators.
Let's see a few types of validator setups and compare them based on these two criteria.
The simplest setup is to have a single server that runs a full node and holds the validator private key, which the full node uses to sign blocks.
By default, the validator private key is stored unencrypted in the disk. An attacker who has obtained access to the server can easily retrieve the key.
An attacker only needs to DDoS this one single server in order to bring the validator offline.
This is what most “institutional grade” validators use. Here, the sentry nodes form a private network that shields the validating node from the broader internet, while the key is stored on a hardware device.
The attacker needs to physically access the hardware device in order to retrieve the private key.
To bring the validator offline, the attacker needs to DDoS all 3 sentry nodes. However, the sole validating node remains a single point-of-failure. If it goes down (e.g. due to a power outage of the data center, or a failure of the hardware key) the validator will no longer be able to perform the signing duty. The 3 sentries won’t help in this situation.
In this setup, the validator’s private key is split into multiple “shards” using a technique known as Threshold Signature Scheme (TSS) and distributed to the corresponding number of servers. A parameter known as threshold defines the minimum number of shards required to produce a signature from the original private key.
For example, if a private key is split into 3 shards with a threshold of 2, then at least two nodes holding these shards must come together in order to sign a block. Essentially, the three nodes work like a 2-of-3 multisig to perform their validator duty.
In this 2-of-3 multisig setup, an attacker must breach at least 2 servers before they can collect enough shards to fabricate a signature, an improvement upon the single-server setup where breaching only one is sufficient.
Without a single point of failure, this setup can tolerate 1 server going down while still being able to perform the signing duty.
It is also worth noting that the multi-party setup can be further improved by using more shards (e.g. 3-of-5 instead of 2-of-3) or applying the same techniques mentioned in the previous setup (i.e. using sentries and hardware keys).
My validator has switched to a 2-of-3 multi-party setup using Horcrux.
It has since achieved an 100% signing record. The missing blocks on the left of the chart was during time while the validator setup was being migrated.