diff --git a/docs/general/glossary.md b/docs/general/glossary.md index 50ed426fea3e..b698724998a0 100644 --- a/docs/general/glossary.md +++ b/docs/general/glossary.md @@ -427,12 +427,6 @@ governance allows decisions to be made transparently. Note that there are a vari algorithms for making these decisions, such as simple majority voting, adaptive quorum biasing, or identity-based quadratic voting. -## Online Message - -This is a message that is broadcast by a validator to verify to the network that the validator is -online, even if they haven't published a block this epoch. This is sometimes referred to as -"ImOnline". - ## Polkadot OpenGov Previously known as Governance v2 (Gov2) during early development, @@ -647,7 +641,7 @@ attacker would need to attack the entire ## Slashing The removal of a percentage of an account's DOT as a punishment for a validator acting maliciously -or incompetently (e.g., equivocating or remaining offline for an extended period). +or incompetently. ## Soft Fork diff --git a/docs/learn/learn-cryptography.md b/docs/learn/learn-cryptography.md index ea8058286644..4ea37b5d476f 100644 --- a/docs/learn/learn-cryptography.md +++ b/docs/learn/learn-cryptography.md @@ -101,7 +101,6 @@ broadcast this certificate via an extrinsic. - BABE: sr25519 - BEEFY: ecdsa - GRANDPA: ed25519 -- I'm Online: sr25519 - Parachain Assignment: sr25519 - Parachain Validator: ed25519 diff --git a/docs/learn/learn-nominator.md b/docs/learn/learn-nominator.md index afa8ea84b6e9..be502a0fd0d7 100644 --- a/docs/learn/learn-nominator.md +++ b/docs/learn/learn-nominator.md @@ -249,11 +249,11 @@ example, `ZUG CAPITAL/07` is one of the numerous validators belonging to the ope :::warning Single Operators with Multiple Validators -Recall that slashing is an additive function; the more validators offline or equivocating in a given -session, the harsher the penalties. Since validators that are controlled by a single operator are -more at risk of a "synchronized" failure, nominating them implies a greater risk of having a large -slash of your nominated funds. Generally, it is safer to nominate validators whose behavior is -independent of others in many ways (different hardware, geographic location, owner, etc.). +Recall that slashing is an additive function; the more validators equivocating in a given session, +the harsher the penalties. Since validators that are controlled by a single operator are more at +risk of a "synchronized" failure, nominating them implies a greater risk of having a large slash of +your nominated funds. Generally, it is safer to nominate validators whose behavior is independent of +others in many ways (different hardware, geographic location, owner, etc.). ::: @@ -300,9 +300,7 @@ over the validators' websites to see who they are, what kind of infrastructure s reputation, the vision behind the validator, and more. Any problematic behavior must be taken seriously. An example of problematic behavior will be if a -validator is regularly offline. In this case, nominators most likely would get fewer rewards. If -many validators are [unreachable](learn-staking.md#unresponsiveness), such validators and -corresponding nominators will be slashed. +validator is regularly offline. In this case, nominators will get fewer rewards. ![Validator Stats](../assets/validator_stats.png) @@ -354,10 +352,10 @@ As long as you have nominated more than one validator candidate, at least one of and you are nominating with enough stake to get into the solution set, your bonded stake will be fully distributed to one or more validators. That being said, you may not receive rewards if you nominated very few validator candidates and no one got elected, or your stake is small, and you are -not part of the [top 22,500 nominators](./learn-staking-advanced.md#bags-list), or the validator -you are nominating has 100% commission. It is generally wise to choose as many trustworthy -validators as you can {{ polkadot: (up to 16) :polkadot }}{{ kusama: (up to 24) :kusama }} to reduce -the risk of none of your nominated validators being elected. +not part of the [top 22,500 nominators](./learn-staking-advanced.md#bags-list), or the validator you +are nominating has 100% commission. It is generally wise to choose as many trustworthy validators as +you can {{ polkadot: (up to 16) :polkadot }}{{ kusama: (up to 24) :kusama }} to reduce the risk of +none of your nominated validators being elected. :::info Not receiving Staking Rewards? diff --git a/docs/learn/learn-staking-advanced.md b/docs/learn/learn-staking-advanced.md index 9ab02abc4167..f94c5a6b9127 100644 --- a/docs/learn/learn-staking-advanced.md +++ b/docs/learn/learn-staking-advanced.md @@ -260,10 +260,10 @@ since staking participation is changing dynamically, it works well as an indicat #### Commission Fees & Slashes -The network slashes a validator for a misbehavior (e.g. validator offline, equivocation, etc.) the -slashed amount is a fixed percentage (and not a fixed amount), which means that validators with more -stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to -shift their preferences and back less popular validators whom they consider to be trustworthy. +The network slashes a validator for a misbehavior. The slashed amount is a fixed percentage (and not +a fixed amount), which means that validators with more stake get slashed more DOT. Again, this is +done to provide nominators with an economic incentive to shift their preferences and back less +popular validators whom they consider to be trustworthy. Also, note that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validators are paid the same, validators @@ -275,57 +275,6 @@ reputation will be able to charge slightly higher commission fees (which is fair ## Slashing -### Unresponsiveness - -For every session, validators will send an "I'm online" heartbeat to indicate they are live. If a -validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as -unresponsive. Slashing may occur depending on the repeated offenses and how many other validators -were unresponsive or offline during the epoch. - -Validators should have a well-architected network infrastructure to ensure the node runs to reduce -the risk of slashing or chilling. A high availability setup is desirable, preferably with backup -nodes that kick in **only once the original node is verifiably offline** (to avoid double-signing -and being slashed for equivocation - see below). A comprehensive guide on validator setup is -available [here](../maintain/maintain-guides-secure-validator.md). - -Here is the formula for calculating slashing due to unresponsiveness: - - Let x = offenders, n = total no. validators in the active set - - min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07 - -The examples demonstrate how to calculate the slashing penalty for unresponsiveness. - -:::note - -In all of the examples, assume that there are 100 validators in the active set. - -::: - -No slashing would enact if <= 10% of all validators are unresponsive. - -For example, if exactly 10 validators were unresponsive, the expression 3 _ (x - (n / 10 + 1))) / n -would be 3 _ (10 - (100 / 10 + 1)) / 100 = 3 \* (10 - (10 + 1)) / 100 = -0.03 which is rounded to 0. - -:::note - -The minimum value between 0 and 1 is 0. 0 multiplied by 0.07 is 0. - -::: - -If 14 validators are unresponsive, then slashing would occur, as > 10% of validators are -unresponsive. - -The slashing penalty would be min((3 _ (14 - (100 / 10 + 1))) / 100, 1) _ 0.07 = min((3 _ (14 - -11))/100, 1) _ 0.07 = min(0.09, 1) \* 0.07 = 0.6% - -Similarly, if one-third of the validator set (around 33/100) are unresponsive, the slashing penalty -would be about 5%. - -The maximum slashing that can occur due to unresponsiveness is 7%. After around 45% of the -validators go offline, the expression 3 _ (x - (n / 10 + 1))) / n will go beyond 1. Hence, min((3 _ -(x - (n / 10 + 1))) / n, 1) \* 0.07 will be ceiled to 7%. - ### Equivocation **GRANDPA Equivocation**: A validator signs two or more votes in the same round on different chains. @@ -361,8 +310,7 @@ staking rewards as one), slashing grows exponentially. A single validator equivo Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down, but validator operators should be extremely careful in setting these up. If they do not have good coordination to manage signing machines, equivocation is -possible, and equivocation offenses are slashed at much higher rates than equivalent offline -offenses. +possible. If a validator is reported for any one of the offenses they will be removed from the validator set ([chilled](#chilling)) and they will not be paid while they are out. They will be considered diff --git a/docs/learn/learn-staking.md b/docs/learn/learn-staking.md index ee932cd6c4e4..45a6f20b484d 100644 --- a/docs/learn/learn-staking.md +++ b/docs/learn/learn-staking.md @@ -282,16 +282,7 @@ Understandably, most of the validator nodes run on cloud service providers that hardware specifications and high levels of availability and connectivity. Keep in mind that a validator in the active set is supposed to be fully online and available for producing blocks. If the active validator node goes offline due to network interruptions or a power outage, that -validator might be subject to -[slashing due to unresponsiveness](./learn-staking-advanced#unresponsiveness). As -[Polkadot's block production mechanism](./learn-consensus.md#block-production-babe) is reasonably -resilient to a small proportion of validators going offline, no slashing is imposed until 10% of the -validators in the active set go offline. Hence, if multiple nodes are running on a single cloud -service provider and go offline simultaneously due to an outage or due to a change in their terms -and conditions policy regarding the support of Proof-of-Stake (PoS) operations, the offline -validators and all the nominators backing them can be slashed up 7% of their stake on Polkadot. -Hence, it is recommended that you check if you are nominating the validator nodes that are running -on cloud service providers, and if they do, check if they allow for Proof-of-Stake operations. +validator will get fewer rewards. :::tip Checking Validators using Network Providers @@ -446,9 +437,8 @@ for details. For specific details about validator payouts, please see ### Slashing -Slashing will happen if a validator misbehaves (e.g. goes offline, attacks the network, or runs -modified software) in the network. They and their nominators will get slashed by losing a percentage -of their bonded/staked DOT. +Slashing will happen if a validator misbehaves in the network. They and their nominators will get +slashed by losing a percentage of their bonded/staked DOT. Any slashed DOT will be added to the [Treasury](./archive/learn-treasury.md). The rationale for this (rather than burning or distributing them as rewards) is that slashes may then be reverted by the @@ -487,15 +477,12 @@ particular levels are not implemented or referred to in the code or in the syste guidelines for different levels of severity for offenses. To understand how slash amounts are calculated, see the equations in the section below. -- Level 1: isolated [unresponsiveness](./learn-staking-advanced.md/#unresponsiveness), i.e. being - offline for an entire session. Generally no slashing, only [chilling](#chilling). -- Level 2: concurrent unresponsiveness or isolated - [equivocation](./learn-staking-advanced.md/#equivocation), slashes a very small amount of the - stake and chills. -- Level 3: misconducts unlikely to be accidental, but which do not harm the network's security to +- Level 1: Isolated [equivocation](./learn-staking-advanced.md/#equivocation), slashes a very small + amount of the stake. +- Level 2: misconducts unlikely to be accidental, but which do not harm the network's security to any large extent. Examples include concurrent equivocation or isolated cases of unjustified voting in [GRANDPA](learn-consensus.md). Slashes a moderately small amount of the stake and chills. -- Level 4: misconduct that poses serious security or monetary risk to the system, or mass collusion. +- Level 3: misconduct that poses serious security or monetary risk to the system, or mass collusion. Slashes all or most of the stake behind the validator and chills. If you want to know more details about slashing, please look at our diff --git a/docs/learn/learn-transactions.md b/docs/learn/learn-transactions.md index a432388b1d55..646789698064 100644 --- a/docs/learn/learn-transactions.md +++ b/docs/learn/learn-transactions.md @@ -50,10 +50,8 @@ account that has funds, and therefore {{ polkadot: Polkadot :polkadot }}{{ kusam can charge a transaction fee as a way to prevent spam. Unsigned transactions are for special cases where a user needs to submit an extrinsic from a key -pair that does not control funds. For example, validators submit unsigned transactions in the form -of "heartbeat" messages to indicate that they are online. These heartbeats must be signed by one of -the validator's [session keys](learn-cryptography.md). Session keys never control funds. Unsigned -transactions are only used in special cases because, since +pair that does not control funds. For example, validator's [session keys](learn-cryptography.md) +never control funds. Unsigned transactions are only used in special cases because, since {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} cannot charge a fee for them, each one needs its own, custom validation logic. diff --git a/docs/learn/xcm/testing.md b/docs/learn/xcm/testing.md index a2ef91b8d05c..ef63659392cc 100644 --- a/docs/learn/xcm/testing.md +++ b/docs/learn/xcm/testing.md @@ -41,8 +41,8 @@ An example of how the emulator is used for testing common good parachains can be The xcm-emulator uses the transport layer pallets. However, the messages do not utilize the same messaging infrastructure as live networks, as the transport mechanism is being mocked out. Also, -consensus related events are not tested, like disputes, staking and iamonline events. To test for -these events, parachains can use E2E tests. +consensus related events are not tested, like disputes and staking. To test for these events, +parachains can use E2E tests. ## End-to-End testing diff --git a/docs/maintain/maintain-errors.md b/docs/maintain/maintain-errors.md index a9b171263227..f936fb56844a 100644 --- a/docs/maintain/maintain-errors.md +++ b/docs/maintain/maintain-errors.md @@ -92,7 +92,7 @@ The below table is a reference to the errors that exists in Polkadot. It is gene runtime's metadata. | Pallet | Error | Documentation | -| ----------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | +| ----------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --- | | System (0) | | | | | InvalidSpecName (0) | The name of specification does not match between the current runtime and the new runtime. | | | SpecVersionNeedsToIncrease (1) | The specification version is not allowed to decrease between the current runtime and the new runtime. | @@ -165,10 +165,7 @@ runtime's metadata. | | TooSoon (3) | Cannot signal forced change so soon after last. | | | InvalidKeyOwnershipProof (4) | A key ownership proof provided as part of an equivocation report is invalid. | | | InvalidEquivocationProof (5) | An equivocation proof provided as part of an equivocation report is invalid. | -| | DuplicateOffenceReport (6) | A given equivocation report is valid but already previously reported. | -| ImOnline (12) | | | -| | InvalidKey (0) | Non existent public key. | -| | DuplicatedHeartbeat (1) | Duplicated heartbeat. | +| | DuplicateOffenceReport (6) | A given equivocation report is valid but already previously reported. | | | Democracy (14) | | | | | ValueLow (0) | Value too low | | | ProposalMissing (1) | Proposal does not exist | diff --git a/docs/maintain/maintain-guides-best-practices-to-avoid-slashes.md b/docs/maintain/maintain-guides-best-practices-to-avoid-slashes.md index 59878742b5bc..516072c6bc92 100644 --- a/docs/maintain/maintain-guides-best-practices-to-avoid-slashes.md +++ b/docs/maintain/maintain-guides-best-practices-to-avoid-slashes.md @@ -15,53 +15,17 @@ all instances, slashes are accompanied by a loss of nominators. A slash may occur under four circumstances: -1. Unresponsiveness – Slashing starts when 10% of the active validators set are offline and - increases in a linear manner until 44% of the validator set is offline; at this point, the slash - is held at 7% -2. Equivocation – A slash of 0.01% is applied with as little as a single evocation. The slashed +1. Equivocation – A slash of 0.01% is applied with as little as a single evocation. The slashed amount increases to 100% incrementally as more validators also equivocate. -3. Malicious action – This may result from a validator trying to represent the contents of a block +2. Malicious action – This may result from a validator trying to represent the contents of a block falsely. Slashing penalties of 100% may apply. -4. Application related (bug or otherwise) – The amount is unknown and may manifest as scenarios 1, - 2, and 3 above. +3. Application related (bug or otherwise) – The amount is unknown and may manifest as scenarios 1 + and 2 above. This article provides some best practices to prevent slashing based on lessons learned from previous slashes. It provides comments and guidance for all circumstances except for malicious action by the node operator. -## Unresponsiveness - -An offline event occurs when a validator does not produce a BLOCK or IMONLINE message within an -EPOCH. Isolated offline events do not result in a slash; however, the validator would not earn any -era points while offline. A slash for unresponsiveness occurs when 10% or more of the active -validators are offline at the same time. Check the Wiki section on -[slashing due to unresponsiveness](../learn/learn-staking-advanced.md#unresponsiveness) to learn -more about its specifics. - -The following are recommendations to validators to avoid slashing under liveliness for servers that -have historically functioned: - -1. Utilize systems to host your validator instance. Systemd should be configured to auto reboot the - service with a minimum 60-second delay. This configuration should aid with re-establishing the - instance under isolated failures with the binary. -2. A validator instance can demonstrate un-lively behaviour if it cannot sync new blocks. This may - result from insufficient disk space or a corrupt database. -3. Monitoring should be implemented that allows node operators to monitor connectivity network - connectivity to the peer-to-peer port of the validator instance. Monitoring should also be - implemented to ensure that there is <50 Block ‘drift’ between the target and best blocks. If - either event produces a failure, the node operator should be notified. The following are - recommendations to validators to avoid liveliness for new servers / migrated servers: -4. Ensure that the `--validator` flag is used when starting the validator instance -5. If switching keys, ensure that the correct session keys are applied -6. If migrating using a two-server approach, ensure that you don’t switch off the original server - too soon. -7. Ensure that the database on the new server is fully synchronized. -8. It is highly recommended to avoid hosting on providers that other validators may also utilize. - If the provider fails, there is a probability that one or more other validators would also fail - due to liveliness building to a slash. - There is a precedent that a slash may be forgiven if a single validator faces an offline event - when a larger operator also faces multiple offline events, resulting in a slash. - ## Equivocation Equivocation events can occur when a validator produces two or more of the same block; under this @@ -83,8 +47,6 @@ The following are scenarios that build towards slashes under equivocation: It is important to note that equivocation slashes occur with a single incident. This can happen if duplicated keystores are used for only a few seconds. A slash can result in losing nominators, and funds, removal from the Thousand Validator Programme, and reputational damage. - An offline event results in losing some funds but the retention of nominators and a fault under - the Thousand Validator Programme. ## Application Related @@ -102,9 +64,8 @@ obtain pristine binaries or source code and to ensure the security of their node ## Examples -| Network | Era | Event Type | Details | Action Taken | -| -------- | ---- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Polkadot | 774 | Small Equivocation | [The validator](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io/$165562246360408hKCfC:matrix.org?via=matrix.parity.io&via=corepaper.org&via=matrix.org) migrated servers and cloned the keystore folder. The on-chain event can be viewed [here](https://polkadot.subscan.io/extrinsic/11190109-0?event=11190109-5). | The validator did not submit a request for the slash to be canceled. | -| Kusama | 3329 | Small Equivocation | The validator operated a test machine with cloned keys; the test machine was online at the same time as the primary, which resulted in a slash. Details can be found [here](https://kusama.polkassembly.io/post/1343). | The validator requested a cancellation of the slash, but the council declined. | -| Kusama | 3995 | Small Equivocation | The validator noticed several errors, after which the client crashed, and a slash was applied. The validator recorded all events and opened GitHub issues to allow for technical opinions to be shared. Details can be found [here](https://kusama.polkassembly.io/post/1733). | The validator requested to cancel the slash. The council approved the request as they believed the error was not operator related. | -| Kusama | 4543 | Medium Unresponsiveness | A large amount of disputes flooded the network resulting in an application fault. The fault caused the client software to hang and as a result ~197 unique validators become unresponsive. Further details can be found [here](https://kusama.polkassembly.io/referenda/16). | The pending slash was cancelled and with runtime [9350](https://kusama.polkassembly.io/referenda/24) all lost nominations were restored. The application bug was addressed with client version [0.9.36](https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-36/1529) | +| Network | Era | Event Type | Details | Action Taken | +| -------- | ---- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | +| Polkadot | 774 | Small Equivocation | [The validator](https://matrix.to/#/!NZrbtteFeqYKCUGQtr:matrix.parity.io/$165562246360408hKCfC:matrix.org?via=matrix.parity.io&via=corepaper.org&via=matrix.org) migrated servers and cloned the keystore folder. The on-chain event can be viewed [here](https://polkadot.subscan.io/extrinsic/11190109-0?event=11190109-5). | The validator did not submit a request for the slash to be canceled. | +| Kusama | 3329 | Small Equivocation | The validator operated a test machine with cloned keys; the test machine was online at the same time as the primary, which resulted in a slash. Details can be found [here](https://kusama.polkassembly.io/post/1343). | The validator requested a cancellation of the slash, but the council declined. | +| Kusama | 3995 | Small Equivocation | The validator noticed several errors, after which the client crashed, and a slash was applied. The validator recorded all events and opened GitHub issues to allow for technical opinions to be shared. Details can be found [here](https://kusama.polkassembly.io/post/1733). | The validator requested to cancel the slash. The council approved the request as they believed the error was not operator related. | diff --git a/docs/maintain/maintain-guides-how-to-chill.md b/docs/maintain/maintain-guides-how-to-chill.md index c8149fd697e2..f217ac66100e 100644 --- a/docs/maintain/maintain-guides-how-to-chill.md +++ b/docs/maintain/maintain-guides-how-to-chill.md @@ -62,24 +62,6 @@ When you become an active validator, you will also need to reset your validator (commission, etc.). These can be configured as the same values set previously or something different. -## Involuntary Chills - -If a validator was unresponsive for an entire session, the validator bond would be chilled in a -process known as _involuntary chilling._ When a validator has been involuntarily chilled, it may -restrict the validator from being selected in the next election depending on the session in which it -was chilled (see considerations above). A chilled validator may re-declare the intent to validate at -any time. However, it is recommended that the validator attempts to determine the source of the -chill before doing so. - -Slashing may also result in an involuntary chill. However, in that scenario, the validator would -also lose their nominations. By this action, even if the validator re-declares its intent to -validate before session 5, there wouldn't be sufficient nominations to re-elect the node into the -active set. - -Nominators have the option to renominate a slashed validator using a display row in Polkadot-JS UI. -This row is displayed in the "Account Actions" tab for the nominator under a heading that says -"Renomination required". - ## Chill Other An unbounded and unlimited number of nominators and validators in Polkadot's NPoS is not possible diff --git a/docs/maintain/maintain-guides-how-to-upgrade.md b/docs/maintain/maintain-guides-how-to-upgrade.md index f9da350a0863..dfa730c3c4df 100644 --- a/docs/maintain/maintain-guides-how-to-upgrade.md +++ b/docs/maintain/maintain-guides-how-to-upgrade.md @@ -7,11 +7,11 @@ keywords: [upgrade, node, validator, release, session] slug: ../maintain-guides-how-to-upgrade --- -Validators perform critical functions for the network, and as such, have strict uptime requirements. -Validators may have to go offline for short-periods of time to upgrade client software or to upgrade -the host machine. Usually, standard client upgrades will only require you to stop the service, -replace the binary and restart the service. This operation can be executed within a session and if -performed correctly will not produce a slashable event. +Validators perform critical functions for the network by +[backing and including blocks](../learn/learn-parachains-protocol.md). Validators may have to go +offline for short-periods of time to upgrade client software or to upgrade the host machine. +Usually, standard client upgrades will only require you to stop the service, replace the binary and +restart the service. This operation can be executed within a session. Validators may also need to perform long-lead maintenance tasks that will span more than one session. Under these circumstances, an active validator may chill their stash and be removed from diff --git a/docs/maintain/maintain-guides-how-to-validate-polkadot.md b/docs/maintain/maintain-guides-how-to-validate-polkadot.md index 0b148ef0b5a9..07bcd234271d 100644 --- a/docs/maintain/maintain-guides-how-to-validate-polkadot.md +++ b/docs/maintain/maintain-guides-how-to-validate-polkadot.md @@ -156,8 +156,7 @@ sudo ntpq -p Skipping this can result in the validator node missing block authorship opportunities. If the clock is out of sync (even by a small amount), the blocks the validator produces may not get accepted by -the network. This will result in `ImOnline` heartbeats making it on chain, but zero allocated blocks -making it on chain. +the network. ::: diff --git a/docs/maintain/maintain-guides-secure-validator.md b/docs/maintain/maintain-guides-secure-validator.md index 32d9dd63006b..fb1c1236420c 100644 --- a/docs/maintain/maintain-guides-secure-validator.md +++ b/docs/maintain/maintain-guides-secure-validator.md @@ -32,9 +32,6 @@ doing.** Many expert validators have made mistakes in the past due to the handling of session keys. -Remember, even if your validator goes offline for some time, the offline slash is much more -forgiving than the equivocation or parachain validity slashing. - ## Key Management See the [Polkadot Keys guide](../learn/learn-cryptography.md) for more information on keys. The keys @@ -127,7 +124,6 @@ CONFIG_SECCOMP=y - Given that HA setups would always be at risk of double-signing and there's currently no built-in mechanism to prevent it, we propose having a single instance of the validator to avoid slashing. - Slashing penalties for being offline are much less than those for equivocation. ### Validators diff --git a/docs/maintain/maintain-guides-validator-community.md b/docs/maintain/maintain-guides-validator-community.md index 7e50d1ef4087..c914426b35f0 100644 --- a/docs/maintain/maintain-guides-validator-community.md +++ b/docs/maintain/maintain-guides-validator-community.md @@ -131,9 +131,9 @@ Some factors of architecture to highlight might include: Outlining how a validator runs its servers helps nominators understand how diversified a validator is. Does the Validator run in the cloud, on dedicated machines, in a co-located datacenter, or in a home residential setup? Do they run multiple nodes on the same machine? If every validator is hosted -in AWS, there is a risk of potential outages that cause large amounts of nodes to go offline, -causing slashing for unresponsiveness. Nominators may want to choose validators that have thoroughly -diversified the providers they use or the facilities they operate in. +in AWS, there is a risk of potential outages that cause large amounts of nodes to go offline. +Nominators may want to choose validators that have thoroughly diversified the providers they use or +the facilities they operate in. Additionally, how does a Validator contribute to decentralization? It can be helpful to outline these efforts so that the values of a Nominator and Validator are aligned.