From 5ebffec47e682f1b1920f1c93459d275e24b8ea8 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Tue, 3 Dec 2024 17:24:36 +0100 Subject: [PATCH 1/5] Draft proposal for P8 update. --- commentary/P8-commentary.txt | 29 ++++++++ updates/P8.txt | 135 +++++++++++++++++++++++++++++++++++ 2 files changed, 164 insertions(+) create mode 100644 commentary/P8-commentary.txt create mode 100644 updates/P8.txt diff --git a/commentary/P8-commentary.txt b/commentary/P8-commentary.txt new file mode 100644 index 0000000..6a15dc3 --- /dev/null +++ b/commentary/P8-commentary.txt @@ -0,0 +1,29 @@ + Protocol update commentary + +Protocol Version: 8 +Builds on Protocol Version: 7 + +Protocol version 8 adds support for suspending inactive validators. Inactive +validators degrade the performance and reliability of the blockchain, and +it is therefore desirable to exclude them where possible. + +The protocol for suspending validators requires them to miss producing blocks +multiple times in succession. This avoids overly penalising low-stakes +validators that may seldom have chances to produce blocks and may not be +included in the finalization committee. Such validators have few opportunities +to redeem themselves in the event of accidentally missing a single round, so +requiring multiple missed rounds should prevent unfairly suspending them. + +A suspended validator can be resumed manually by sending a transaction to do +so. A suspended validator will always be suspended for at least one epoch, but +otherwise incurs no specific penalty. Any accounts that delegate stake to a +suspended validator will remain delegating to it (unless they update their +delegation). + +Suspending inactive validators is intended to protect against validators that +are inactive as a result of accident or carelessness; it does not protect +against malicious validators. + +Note that it is impossible for more than one third of the stake to be +automatically suspended simultaneously. This is because if more than one third +of the stake was inactive, then the blockchain would halt. \ No newline at end of file diff --git a/updates/P8.txt b/updates/P8.txt new file mode 100644 index 0000000..535acb4 --- /dev/null +++ b/updates/P8.txt @@ -0,0 +1,135 @@ + Protocol update + +Protocol Version: 8 +Builds on Protocol Version: 7 + + Abstract + +This document describes the changes in Concordium protocol version 8 compared to +protocol version 7. + +The protocol change supports suspending inactive validators automatically when they +consistently fail to participate in the consensus protocol. Suspended validators +can be reactivated manually by a transaction from the validator's account. + + Background + +Validators in the Concordium consensus protocol play two related roles. First, they +propose blocks to add to the chain when they are chosen as the leader of a round. +The round leader is determined by a lottery weighted by the validator's effective +stake. If a validator fails to produce a block in its round, the round will +eventually time-out, progressing to the next round with no block produced. +Time-outs increase the confirmation time (that is, the time until a transaction is +finalized on the chain) and decrease the throughput (that is, the maximum number +of transactions the chain can incorporate in a given period of time). + +The second role of validators is to sign off on rounds by either attesting to a +valid block in the round, or to the fact that the round timed-out. To progress to +the next round, two thirds of the finalization committee (weighted by stake) must +agree. If more than one third of the committee does not sign off on a round, then +the block chain will simply stop producing blocks, unless and until two thirds of +the committee eventually signs off on the round. + +Inactive validators are therefore detrimental to the operation of the consensus +protocol. Protocol version 8 introduces a mechanism to automatically suspend +validators that consistently fail to participate in the protocol. Suspended +validators are excluded from the committee of validators, and will therefore +not be selected to propose blocks nor be required to sign off on round. +Consequently, suspended validators do not earn rewards for themselves or their +pool. + +The account associated with a suspended validator can lift the suspension by +sending a simple transaction. The validator will then be included in the +committee the next time it is determined. (The committee is determined one +epoch before each pay day.) + +The procedure for automatically suspending a validator is as follows: + +- For each current validator, continuously track the number of rounds in + which the validator was the round leader, but no block was produced. + +- At each payday, if the number of missed rounds for a validator exceeds a + threshold (determined by the "maximum missed rounds" chain parameter) + then mark the validator as "primed for suspension". + +- At each snapshot (that is, the start of an epoch prior to a payday), if + a validator is primed for suspension, then it is marked as suspended. + Suspended validators are not included in the calculation of the validator + committee. + +- Whenever a validator produces a block or signs a quorum or time-out + message, its missed rounds counter is reset and it is no longer marked as + primed for suspension. + + Changes + +The following behaviours are changed in protocol version 8. + +1. A new chain parameter, `maximum_missed_rounds`, is added. This is updated + by a level 2 update instruction (payload `ValidatorScoreParametersCPV3`) + that is authorized by the pool parameters keys. + +2. The validator record on accounts includes a new boolean flag indicating if + the validator is currently suspended. + +3. The validator pool reward details add a counter of the number of missed rounds + and whether the validator is primed for suspension. + +4. On executing each block: + + (a) Validators that signed the quorum certificate for the parent block + have their missed-round counter reset to zero and have their primed- + for-suspension flag cleared. + + (b) If the previous round timed out, for each missed round, the missed round + counter is incremented for the validator that was the leader of that + round (in the present epoch). + + (c) The validator that produced the block has its missed-round counter reset + to zero and its primed-for-suspension flag cleared. + +5. When executing a snapshot block (i.e. the first block of an epoch before a + pay day, in which the committee is determined for the upcoming pay day): + + (a) Validators that are suspended or were primed for suspension at the + start of the block are not included in the calculation of the + committee for the next payday. + + (b) Validators that were primed for suspension at the start of the block + are marked as suspended at the end of the block. + +6. When executing a pay day block (i.e. the first block of a new pay day, + in which rewards are paid out): + + (a) Validators with a missed-round counter that exceeds + `maximum_missed_rounds` are marked as primed for suspension. + + (b) Validators for the new pay day that were not validators for the + previous pay day begin with their missed-round counter at 0 and + their primed-for-suspension flag cleared. + +7. The `ConfigureValidator` (also known as `ConfigureBaker`) transaction + is extended with an optional boolean indicating whether the validator is + suspended. If present, this updates the suspended flag on the account's + validator record. When first configuring a validator, the field is not + required and the validator will not be suspended by default. + + Effects + +1. The `ConfigureValidator` transaction will produce a `BakerSuspended` or + `BakerResumed` event if it sets or clears the suspended flag, + respectively. + +2. Whenever a validator is marked as primed for suspension, a + `ValidatorPrimedForSuspension` event is added to the special events for + the block. + +3. Whenever a validator is automatically marked as suspended, a + `ValidatorSuspended` event is added to the special events for the block. + + Protocol update instruction + +The protocol update instruction is identified by the SHA256 hash of this +file. The instruction needs the following auxiliary data: + +- The initial value of the `maximum_missed_rounds` parameter. \ No newline at end of file From 0db89a1221213078f9f1d2e32b419f8af4ff6839 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Wed, 4 Dec 2024 11:58:48 +0100 Subject: [PATCH 2/5] Address comment. --- updates/P8.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/updates/P8.txt b/updates/P8.txt index 535acb4..914a85e 100644 --- a/updates/P8.txt +++ b/updates/P8.txt @@ -27,19 +27,18 @@ The second role of validators is to sign off on rounds by either attesting to a valid block in the round, or to the fact that the round timed-out. To progress to the next round, two thirds of the finalization committee (weighted by stake) must agree. If more than one third of the committee does not sign off on a round, then -the block chain will simply stop producing blocks, unless and until two thirds of -the committee eventually signs off on the round. +the blockchain halts until two thirds of the committee eventually agrees. Inactive validators are therefore detrimental to the operation of the consensus protocol. Protocol version 8 introduces a mechanism to automatically suspend validators that consistently fail to participate in the protocol. Suspended validators are excluded from the committee of validators, and will therefore -not be selected to propose blocks nor be required to sign off on round. +not be selected to propose blocks nor be required to sign off on rounds. Consequently, suspended validators do not earn rewards for themselves or their pool. The account associated with a suspended validator can lift the suspension by -sending a simple transaction. The validator will then be included in the +sending a transaction to do so. The validator will then be included in the committee the next time it is determined. (The committee is determined one epoch before each pay day.) @@ -106,7 +105,9 @@ The following behaviours are changed in protocol version 8. (b) Validators for the new pay day that were not validators for the previous pay day begin with their missed-round counter at 0 and - their primed-for-suspension flag cleared. + their primed-for-suspension flag cleared. Validators that + continue from the previous pay day maintain their missed-round + counter and primed-for-suspension flag. 7. The `ConfigureValidator` (also known as `ConfigureBaker`) transaction is extended with an optional boolean indicating whether the validator is From 9ce4b408d56e3c31c7eafe465e89ed6d81b97d37 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Fri, 3 Jan 2025 17:32:32 +0100 Subject: [PATCH 3/5] Address review comments. --- commentary/P8-commentary.txt | 32 +++++++++++++++++++++++++++----- updates/P8.txt | 11 ++++++----- 2 files changed, 33 insertions(+), 10 deletions(-) diff --git a/commentary/P8-commentary.txt b/commentary/P8-commentary.txt index 6a15dc3..c135477 100644 --- a/commentary/P8-commentary.txt +++ b/commentary/P8-commentary.txt @@ -8,11 +8,33 @@ validators degrade the performance and reliability of the blockchain, and it is therefore desirable to exclude them where possible. The protocol for suspending validators requires them to miss producing blocks -multiple times in succession. This avoids overly penalising low-stakes -validators that may seldom have chances to produce blocks and may not be -included in the finalization committee. Such validators have few opportunities -to redeem themselves in the event of accidentally missing a single round, so -requiring multiple missed rounds should prevent unfairly suspending them. +multiple times in succession. A validator with a low stake has a +correspondingly low chance of being the leader in any particular round, and so +it may take many days of inactivity before it reaches the threshold for being +suspended. On the other hand, a validator with a high stake may reach the +threshold in minutes or hours of inactivity. + +In any case, if the validator reaches the threshold by a payday, it is +considered "primed for suspension". This means that, if it remains inactive +until the next snapshot epoch, it will be suspended from the validator +committee, as determined at the snapshot epoch and effective from the +following (payday) epoch. If the validator becomes active before the snapshot, +as evidenced by producing a block or having its signature included in a quorum +certificate in a block, then it will no longer be considered primed for +suspension, and thus not be suspended. For a validator with a low stake that +is not included in the finalization committee, even if the node is brought +back on-line, it may not be round leader in that time, and so cannot prove +that it is active and thus avoid suspension. For a validator with a high +stake, especially if it is in the finalization committee, there will be ample +opportunities to prove itself to be active, and thus avoid suspension. + +In summary, a validator with a high stake could be suspended with a little +more than 23 hours of inactivity, while validators with lower stakes will +require longer. High-stake validators effectively have a grace period of +23 hours after hitting the threshold for missed blocks. Low-stake validators +may not be able to take advantage of the grace period after hitting the +threshold, but have to be inactive for a longer period of time to reach the +threshold in the first place. A suspended validator can be resumed manually by sending a transaction to do so. A suspended validator will always be suspended for at least one epoch, but diff --git a/updates/P8.txt b/updates/P8.txt index 914a85e..d3e900a 100644 --- a/updates/P8.txt +++ b/updates/P8.txt @@ -44,8 +44,9 @@ epoch before each pay day.) The procedure for automatically suspending a validator is as follows: -- For each current validator, continuously track the number of rounds in - which the validator was the round leader, but no block was produced. +- For each current validator, continuously track the number of missed rounds + since the validator last successfully produced a block. A missed round is a + round in which the validator was the round leader, but no block was produced. - At each payday, if the number of missed rounds for a validator exceeds a threshold (determined by the "maximum missed rounds" chain parameter) @@ -56,9 +57,9 @@ The procedure for automatically suspending a validator is as follows: Suspended validators are not included in the calculation of the validator committee. -- Whenever a validator produces a block or signs a quorum or time-out - message, its missed rounds counter is reset and it is no longer marked as - primed for suspension. +- Whenever a validator produces a block, or is a signatory of a quorum + certificate that is in a block, its missed rounds counter is reset and it is + no longer marked as primed for suspension. Changes From ed1fc418081de7e25b4b725eb86d906f1fb23a53 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Mon, 6 Jan 2025 11:19:51 +0100 Subject: [PATCH 4/5] Fix line endings. Add hashes and index. --- README.md | 3 +- commentary/P8-commentary.txt | 100 ++++++------- source/updates/P8.rst | 25 ++++ updates/P8.txt | 272 +++++++++++++++++------------------ 4 files changed, 213 insertions(+), 187 deletions(-) create mode 100644 source/updates/P8.rst diff --git a/README.md b/README.md index 9e2c7f5..8e7a7ab 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,8 @@ The table lists already effective as well as *planned/draft* protocol updates. | Sirius (P4) | Delegation and new contract state | Jun 13, 2022 | Jun 23, 2022 | [P4.txt](../main/updates/P4.txt) | [P4-commentary.txt](../main/commentary/P4-commentary.txt) | `20c6f246713e573fb5bfdf1e59c0a6f1a37cded34ff68fda4a60aa2ed9b151aa` | `4c135293c661cc57890aab1889e8263db70e3a857983e6aa7ffa5ea6806b9338` | `476093e74014d9c735de0173a653f094f15ee1a4d2693f24bddd184672723d98` | | P5 | Smart contract upgradability, performance improvements | Nov 22, 2022 | Dec 13, 2022 | [P5.txt](../main/updates/P5.txt) | [P5-commentary.txt](../main/commentary/P5-commentary.txt) | `af5684e70c1438e442066d017e4410af6da2b53bfa651a07d81efa2aa668db20` | `6ca196c7fa2f3e0e64b7fa9b6c7299c5196ff38122768b799fab612db31b2114` | `5443ee296c0a87af8631998e5e7edd80ac4edec5c64255bdf8415af6e4bd0f43` | | P6 | Concordium BFT consensus protocol, changes in Wasm validation and execution | Aug 21, 2023 | Sep 25, 2023 | [P6.txt](../main/updates/P6.txt) | [P6-commentary.txt](../main/commentary/P6-commentary.txt) | `ede9cf0b2185e9e8657f5c3fd8b6f30cef2f1ef4d9692aa4f6ef6a9fb4a762cd` | `358633697957ac1c3f91adc40f75d1ff951a11bc89826567a4118ce0371c17bf` | `5406c159c36841803d7eecba4aa5c21c6a72693a854ea88851218cfe8b31465c` | -| P7 | Smart contract costs and new queries, stake cooldown changes, disabling shielded transfers, revised block hashing | _planned Sep 30, 2024_ | _planned Oct 30, 2024_ | [P7.txt](../main/updates/P7.txt) | [P7-commentary.txt](../main/commentary/P7-commentary.txt) | `e68ea0b16bbadfa5e5da768ed9afe0880bd572e29337fe6fb584f293ed7699d6` | - | - | +| P7 | Smart contract costs and new queries, stake cooldown changes, disabling shielded transfers, revised block hashing | Sep 30, 2024 | Oct 30, 2024 | [P7.txt](../main/updates/P7.txt) | [P7-commentary.txt](../main/commentary/P7-commentary.txt) | `e68ea0b16bbadfa5e5da768ed9afe0880bd572e29337fe6fb584f293ed7699d6` | `0c3074f2d59c4561017f0d30dfe013e1fd54adb5fbddcee0e5509dfefcc5d049` | `684af26c3d6142893f8a72d5ae27f0a36cac23cd15889163fd7742edee991625` | +| P8 | Suspension of inactive validators | - | - | [P8.txt](../main/updates/P8.txt) | [P8-commentary.txt](../main/commentary/P8-commentary.txt) | `f12e20b6936a6b1b736e95715e1654b92adb4226ef7601b4183895bee563f9da` | - | - | ## Website diff --git a/commentary/P8-commentary.txt b/commentary/P8-commentary.txt index c135477..7529d9e 100644 --- a/commentary/P8-commentary.txt +++ b/commentary/P8-commentary.txt @@ -1,51 +1,51 @@ - Protocol update commentary - -Protocol Version: 8 -Builds on Protocol Version: 7 - -Protocol version 8 adds support for suspending inactive validators. Inactive -validators degrade the performance and reliability of the blockchain, and -it is therefore desirable to exclude them where possible. - -The protocol for suspending validators requires them to miss producing blocks -multiple times in succession. A validator with a low stake has a -correspondingly low chance of being the leader in any particular round, and so -it may take many days of inactivity before it reaches the threshold for being -suspended. On the other hand, a validator with a high stake may reach the -threshold in minutes or hours of inactivity. - -In any case, if the validator reaches the threshold by a payday, it is -considered "primed for suspension". This means that, if it remains inactive -until the next snapshot epoch, it will be suspended from the validator -committee, as determined at the snapshot epoch and effective from the -following (payday) epoch. If the validator becomes active before the snapshot, -as evidenced by producing a block or having its signature included in a quorum -certificate in a block, then it will no longer be considered primed for -suspension, and thus not be suspended. For a validator with a low stake that -is not included in the finalization committee, even if the node is brought -back on-line, it may not be round leader in that time, and so cannot prove -that it is active and thus avoid suspension. For a validator with a high -stake, especially if it is in the finalization committee, there will be ample -opportunities to prove itself to be active, and thus avoid suspension. - -In summary, a validator with a high stake could be suspended with a little -more than 23 hours of inactivity, while validators with lower stakes will -require longer. High-stake validators effectively have a grace period of -23 hours after hitting the threshold for missed blocks. Low-stake validators -may not be able to take advantage of the grace period after hitting the -threshold, but have to be inactive for a longer period of time to reach the -threshold in the first place. - -A suspended validator can be resumed manually by sending a transaction to do -so. A suspended validator will always be suspended for at least one epoch, but -otherwise incurs no specific penalty. Any accounts that delegate stake to a -suspended validator will remain delegating to it (unless they update their -delegation). - -Suspending inactive validators is intended to protect against validators that -are inactive as a result of accident or carelessness; it does not protect -against malicious validators. - -Note that it is impossible for more than one third of the stake to be -automatically suspended simultaneously. This is because if more than one third + Protocol update commentary + +Protocol Version: 8 +Builds on Protocol Version: 7 + +Protocol version 8 adds support for suspending inactive validators. Inactive +validators degrade the performance and reliability of the blockchain, and +it is therefore desirable to exclude them where possible. + +The protocol for suspending validators requires them to miss producing blocks +multiple times in succession. A validator with a low stake has a +correspondingly low chance of being the leader in any particular round, and so +it may take many days of inactivity before it reaches the threshold for being +suspended. On the other hand, a validator with a high stake may reach the +threshold in minutes or hours of inactivity. + +In any case, if the validator reaches the threshold by a payday, it is +considered "primed for suspension". This means that, if it remains inactive +until the next snapshot epoch, it will be suspended from the validator +committee, as determined at the snapshot epoch and effective from the +following (payday) epoch. If the validator becomes active before the snapshot, +as evidenced by producing a block or having its signature included in a quorum +certificate in a block, then it will no longer be considered primed for +suspension, and thus not be suspended. For a validator with a low stake that +is not included in the finalization committee, even if the node is brought +back on-line, it may not be round leader in that time, and so cannot prove +that it is active and thus avoid suspension. For a validator with a high +stake, especially if it is in the finalization committee, there will be ample +opportunities to prove itself to be active, and thus avoid suspension. + +In summary, a validator with a high stake could be suspended with a little +more than 23 hours of inactivity, while validators with lower stakes will +require longer. High-stake validators effectively have a grace period of +23 hours after hitting the threshold for missed blocks. Low-stake validators +may not be able to take advantage of the grace period after hitting the +threshold, but have to be inactive for a longer period of time to reach the +threshold in the first place. + +A suspended validator can be resumed manually by sending a transaction to do +so. A suspended validator will always be suspended for at least one epoch, but +otherwise incurs no specific penalty. Any accounts that delegate stake to a +suspended validator will remain delegating to it (unless they update their +delegation). + +Suspending inactive validators is intended to protect against validators that +are inactive as a result of accident or carelessness; it does not protect +against malicious validators. + +Note that it is impossible for more than one third of the stake to be +automatically suspended simultaneously. This is because if more than one third of the stake was inactive, then the blockchain would halt. \ No newline at end of file diff --git a/source/updates/P8.rst b/source/updates/P8.rst new file mode 100644 index 0000000..da8b77d --- /dev/null +++ b/source/updates/P8.rst @@ -0,0 +1,25 @@ +===================================================== +Protocol Update 8 - Suspension of inactive validators +===================================================== + +.. list-table:: + :stub-columns: 1 + + * - Effective on Testnet + - planned Q1, 2025 + * - Effective on Mainnet + - planned Q1, 2025 + * - Specification hash + - ``f12e20b6936a6b1b736e95715e1654b92adb4226ef7601b4183895bee563f9da`` + +Specification +============= + +.. include:: ../../updates/P8.txt + :literal: + +Commentary +========== + +.. include:: ../../commentary/P8-commentary.txt + :literal: diff --git a/updates/P8.txt b/updates/P8.txt index d3e900a..e80bb34 100644 --- a/updates/P8.txt +++ b/updates/P8.txt @@ -1,137 +1,137 @@ - Protocol update - -Protocol Version: 8 -Builds on Protocol Version: 7 - - Abstract - -This document describes the changes in Concordium protocol version 8 compared to -protocol version 7. - -The protocol change supports suspending inactive validators automatically when they -consistently fail to participate in the consensus protocol. Suspended validators -can be reactivated manually by a transaction from the validator's account. - - Background - -Validators in the Concordium consensus protocol play two related roles. First, they -propose blocks to add to the chain when they are chosen as the leader of a round. -The round leader is determined by a lottery weighted by the validator's effective -stake. If a validator fails to produce a block in its round, the round will -eventually time-out, progressing to the next round with no block produced. -Time-outs increase the confirmation time (that is, the time until a transaction is -finalized on the chain) and decrease the throughput (that is, the maximum number -of transactions the chain can incorporate in a given period of time). - -The second role of validators is to sign off on rounds by either attesting to a -valid block in the round, or to the fact that the round timed-out. To progress to -the next round, two thirds of the finalization committee (weighted by stake) must -agree. If more than one third of the committee does not sign off on a round, then -the blockchain halts until two thirds of the committee eventually agrees. - -Inactive validators are therefore detrimental to the operation of the consensus -protocol. Protocol version 8 introduces a mechanism to automatically suspend -validators that consistently fail to participate in the protocol. Suspended -validators are excluded from the committee of validators, and will therefore -not be selected to propose blocks nor be required to sign off on rounds. -Consequently, suspended validators do not earn rewards for themselves or their -pool. - -The account associated with a suspended validator can lift the suspension by -sending a transaction to do so. The validator will then be included in the -committee the next time it is determined. (The committee is determined one -epoch before each pay day.) - -The procedure for automatically suspending a validator is as follows: - -- For each current validator, continuously track the number of missed rounds - since the validator last successfully produced a block. A missed round is a - round in which the validator was the round leader, but no block was produced. - -- At each payday, if the number of missed rounds for a validator exceeds a - threshold (determined by the "maximum missed rounds" chain parameter) - then mark the validator as "primed for suspension". - -- At each snapshot (that is, the start of an epoch prior to a payday), if - a validator is primed for suspension, then it is marked as suspended. - Suspended validators are not included in the calculation of the validator - committee. - -- Whenever a validator produces a block, or is a signatory of a quorum - certificate that is in a block, its missed rounds counter is reset and it is - no longer marked as primed for suspension. - - Changes - -The following behaviours are changed in protocol version 8. - -1. A new chain parameter, `maximum_missed_rounds`, is added. This is updated - by a level 2 update instruction (payload `ValidatorScoreParametersCPV3`) - that is authorized by the pool parameters keys. - -2. The validator record on accounts includes a new boolean flag indicating if - the validator is currently suspended. - -3. The validator pool reward details add a counter of the number of missed rounds - and whether the validator is primed for suspension. - -4. On executing each block: - - (a) Validators that signed the quorum certificate for the parent block - have their missed-round counter reset to zero and have their primed- - for-suspension flag cleared. - - (b) If the previous round timed out, for each missed round, the missed round - counter is incremented for the validator that was the leader of that - round (in the present epoch). - - (c) The validator that produced the block has its missed-round counter reset - to zero and its primed-for-suspension flag cleared. - -5. When executing a snapshot block (i.e. the first block of an epoch before a - pay day, in which the committee is determined for the upcoming pay day): - - (a) Validators that are suspended or were primed for suspension at the - start of the block are not included in the calculation of the - committee for the next payday. - - (b) Validators that were primed for suspension at the start of the block - are marked as suspended at the end of the block. - -6. When executing a pay day block (i.e. the first block of a new pay day, - in which rewards are paid out): - - (a) Validators with a missed-round counter that exceeds - `maximum_missed_rounds` are marked as primed for suspension. - - (b) Validators for the new pay day that were not validators for the - previous pay day begin with their missed-round counter at 0 and - their primed-for-suspension flag cleared. Validators that - continue from the previous pay day maintain their missed-round - counter and primed-for-suspension flag. - -7. The `ConfigureValidator` (also known as `ConfigureBaker`) transaction - is extended with an optional boolean indicating whether the validator is - suspended. If present, this updates the suspended flag on the account's - validator record. When first configuring a validator, the field is not - required and the validator will not be suspended by default. - - Effects - -1. The `ConfigureValidator` transaction will produce a `BakerSuspended` or - `BakerResumed` event if it sets or clears the suspended flag, - respectively. - -2. Whenever a validator is marked as primed for suspension, a - `ValidatorPrimedForSuspension` event is added to the special events for - the block. - -3. Whenever a validator is automatically marked as suspended, a - `ValidatorSuspended` event is added to the special events for the block. - - Protocol update instruction - -The protocol update instruction is identified by the SHA256 hash of this -file. The instruction needs the following auxiliary data: - + Protocol update + +Protocol Version: 8 +Builds on Protocol Version: 7 + + Abstract + +This document describes the changes in Concordium protocol version 8 compared to +protocol version 7. + +The protocol change supports suspending inactive validators automatically when they +consistently fail to participate in the consensus protocol. Suspended validators +can be reactivated manually by a transaction from the validator's account. + + Background + +Validators in the Concordium consensus protocol play two related roles. First, they +propose blocks to add to the chain when they are chosen as the leader of a round. +The round leader is determined by a lottery weighted by the validator's effective +stake. If a validator fails to produce a block in its round, the round will +eventually time-out, progressing to the next round with no block produced. +Time-outs increase the confirmation time (that is, the time until a transaction is +finalized on the chain) and decrease the throughput (that is, the maximum number +of transactions the chain can incorporate in a given period of time). + +The second role of validators is to sign off on rounds by either attesting to a +valid block in the round, or to the fact that the round timed-out. To progress to +the next round, two thirds of the finalization committee (weighted by stake) must +agree. If more than one third of the committee does not sign off on a round, then +the blockchain halts until two thirds of the committee eventually agrees. + +Inactive validators are therefore detrimental to the operation of the consensus +protocol. Protocol version 8 introduces a mechanism to automatically suspend +validators that consistently fail to participate in the protocol. Suspended +validators are excluded from the committee of validators, and will therefore +not be selected to propose blocks nor be required to sign off on rounds. +Consequently, suspended validators do not earn rewards for themselves or their +pool. + +The account associated with a suspended validator can lift the suspension by +sending a transaction to do so. The validator will then be included in the +committee the next time it is determined. (The committee is determined one +epoch before each pay day.) + +The procedure for automatically suspending a validator is as follows: + +- For each current validator, continuously track the number of missed rounds + since the validator last successfully produced a block. A missed round is a + round in which the validator was the round leader, but no block was produced. + +- At each payday, if the number of missed rounds for a validator exceeds a + threshold (determined by the "maximum missed rounds" chain parameter) + then mark the validator as "primed for suspension". + +- At each snapshot (that is, the start of an epoch prior to a payday), if + a validator is primed for suspension, then it is marked as suspended. + Suspended validators are not included in the calculation of the validator + committee. + +- Whenever a validator produces a block, or is a signatory of a quorum + certificate that is in a block, its missed rounds counter is reset and it is + no longer marked as primed for suspension. + + Changes + +The following behaviours are changed in protocol version 8. + +1. A new chain parameter, `maximum_missed_rounds`, is added. This is updated + by a level 2 update instruction (payload `ValidatorScoreParametersCPV3`) + that is authorized by the pool parameters keys. + +2. The validator record on accounts includes a new boolean flag indicating if + the validator is currently suspended. + +3. The validator pool reward details add a counter of the number of missed rounds + and whether the validator is primed for suspension. + +4. On executing each block: + + (a) Validators that signed the quorum certificate for the parent block + have their missed-round counter reset to zero and have their primed- + for-suspension flag cleared. + + (b) If the previous round timed out, for each missed round, the missed round + counter is incremented for the validator that was the leader of that + round (in the present epoch). + + (c) The validator that produced the block has its missed-round counter reset + to zero and its primed-for-suspension flag cleared. + +5. When executing a snapshot block (i.e. the first block of an epoch before a + pay day, in which the committee is determined for the upcoming pay day): + + (a) Validators that are suspended or were primed for suspension at the + start of the block are not included in the calculation of the + committee for the next payday. + + (b) Validators that were primed for suspension at the start of the block + are marked as suspended at the end of the block. + +6. When executing a pay day block (i.e. the first block of a new pay day, + in which rewards are paid out): + + (a) Validators with a missed-round counter that exceeds + `maximum_missed_rounds` are marked as primed for suspension. + + (b) Validators for the new pay day that were not validators for the + previous pay day begin with their missed-round counter at 0 and + their primed-for-suspension flag cleared. Validators that + continue from the previous pay day maintain their missed-round + counter and primed-for-suspension flag. + +7. The `ConfigureValidator` (also known as `ConfigureBaker`) transaction + is extended with an optional boolean indicating whether the validator is + suspended. If present, this updates the suspended flag on the account's + validator record. When first configuring a validator, the field is not + required and the validator will not be suspended by default. + + Effects + +1. The `ConfigureValidator` transaction will produce a `BakerSuspended` or + `BakerResumed` event if it sets or clears the suspended flag, + respectively. + +2. Whenever a validator is marked as primed for suspension, a + `ValidatorPrimedForSuspension` event is added to the special events for + the block. + +3. Whenever a validator is automatically marked as suspended, a + `ValidatorSuspended` event is added to the special events for the block. + + Protocol update instruction + +The protocol update instruction is identified by the SHA256 hash of this +file. The instruction needs the following auxiliary data: + - The initial value of the `maximum_missed_rounds` parameter. \ No newline at end of file From 9c0c513e55ffbb8b1bdc33f926c6ffd7d5721add Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Mon, 6 Jan 2025 13:17:59 +0100 Subject: [PATCH 5/5] Add P8 to index. --- source/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/source/index.rst b/source/index.rst index 96f9899..11a1a68 100644 --- a/source/index.rst +++ b/source/index.rst @@ -12,6 +12,7 @@ Concordium Interoperability Specifications updates/P5 updates/P6 updates/P7 + updates/P8 .. toctree:: :maxdepth: 1