Merge pull request #69 from Concordium/p8-proposal

P8 update proposal

README.md

@@ -24,6 +24,7 @@ The table lists already effective as well as *planned/draft* protocol updates.
 | 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 | Sep 30, 2024 | Oct 30, 2024 | [P7.txt](../main/updates/P7.txt) | [P7-commentary.txt](../main/commentary/P7-commentary.txt) | `e68ea0b16bbadfa5e5da768ed9afe0880bd572e29337fe6fb584f293ed7699d6` | 8a3495a1b24d30f239ed9ab52ed6ba26f26f52039d7b740c968882732f3d0baa | 11bb339c85b02d16c07984deeadb1c338871a49dd1527e129561b8c5b2fb1fb3 |
+| P8 | Suspension of inactive validators | - | - | [P8.txt](../main/updates/P8.txt) | [P8-commentary.txt](../main/commentary/P8-commentary.txt) | `f12e20b6936a6b1b736e95715e1654b92adb4226ef7601b4183895bee563f9da` | - | - |
 
 ## Website
 

commentary/P8-commentary.txt

@@ -0,0 +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
+of the stake was inactive, then the blockchain would halt.

source/index.rst

@@ -12,6 +12,7 @@ Concordium Interoperability Specifications
    updates/P5
    updates/P6
    updates/P7
+   updates/P8
 
 .. toctree::
    :maxdepth: 1

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:

updates/P8.txt

@@ -0,0 +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:
+
+- The initial value of the `maximum_missed_rounds` parameter.