Risks
In this section, we will discuss how validators may be subject to certain penalties, or risks incurred due to their activity.
This section is not intended to be exhaustive.
Actions prejudicial to the network
The following actions result in the punitive seizure of the security deposit:
Double validating: A dishonest validator may try to validate two blocks at the same block height in the chain. In case of double validating, 5% of the frozen deposit is forfeited.
Double (pre)attestation: A dishonest validator could attempt to (pre)attest two blocks at the same block height in the chain. In case of double (pre)attestation, 50% of the frozen deposit is forfeited.
Seed slash: A validator is asked to provide random seeds to feed into the validator selection algorithm. To avoid the algorithm being deterministic, the seeds are given in a hashed form. The validator has to deliver in the following cycle the seeds corresponding to the hashes sent. If they do not do so, they do not earn a reward but may still get back the associated deposit.
The protocol allows a window of five cycles during which an accuser may demonstrate evidence of double validating or double attestation (several times if necessary). The dishonest validator will then lose the security deposit(s) placed for the fake operation up to the latest point in the cycle (which may be costly, especially if the validator has done a lot of validating/attesting over the relevant period).
Security deposits and penalties
To discourage double validating / attestation a security deposit is required.
The security deposit remains in the account but is locked up for a period of five cycles (around two weeks). The corresponding mav are always taken into account when calculating slots, but they cannot be spent or used as a new security deposit until they have been released again.
All security deposits are frozen when rights for a cycle are being drawn. On mainnet, rights for a cycle are determined 5 cycles in advance, and a delegate has a specific deposit associated to each cycle. We only retain one deposit: the highest deposit of all cycles in a timeframe of 7 cycles, so that we are always able to punish proportionally to the capacity to harm in this timeframe. If a validator double signs, that is, double validates or double (pre)attests (the latter implies voting for two different proposals at the same round), the frozen deposit is slashed. The slashed amount for double validating is equal to 5% of the frozen deposit . mav. The slashed amount for double (pre)attesting is equal to 50% of the frozen deposit.
Validators are advised to hold at least 10% of the total number of mav used for validating purposes. By default, the required deposits are automatically determined to maximize the active stake. However, no extra validating/attestation slots will be assigned to a delegator who does not have enough security deposit.
When a double validating/attestation is observed, an accusing validator may provide evidence in a block for a period of five cycles starting from the fake operation. As a reward for the accuser, half the culpable validator's deposit goes to the accuser. The other half of the deposit is destroyed.
Attacks
The attacks potentially targeting a validator include:
DoS (denial of service attack): Suppose Bob knows that Alice is about to validate a block with priority 0. He may decide to launch a DoS attack to prevent Alice from publishing her block correctly, thus damaging Alice's reputation. If the attack is sustained, and if Bob appears toward the top of the list of potential validators (especially if he has priority 1), then he may also be able to steal Alice's block.
Theft or loss of a private key: Holding the private key is the only way to gain access to the associated mav and to sign various operations. Thus it is vital to keep the private key safe and secure (e.g. in a hardware wallet).
Over-delegation
A security deposit is required to validate and attest properly. This amount remains locked up over a timeframe of seven cycles. In addition, a validator cannot spend mav that has been delegated to them or use them as security deposits.
A validator is said to be over-delegated when they do not have sufficient funds themselves relative to their stake. However, they do not miss the acquired slots because of a lack of security deposit.
The over-delegated validator will not maximize its staking power, since more mav are delegated compared to what it should own (at least 10% of the total staking balance).
To keep a portion of its balance spendable, a validator can set a deposit limit:
mavkit-client set deposit limit for <delegate> to <deposit_limit>
And unset this limit with the command:
mavkit-client unset deposit limit for <delegate>
Inactivity
A validator who refuses or is unable to validate or attest for five cycles will be treated as inactive by the chain, and can no longer be picked as a validator.
The inactive validator must wait for seven cycles after reactivating their account, before they can validate again.
This mechanism is designed to ensure that a validator who is no longer active, does not slow down the chain.