Skip to content

Commit e78c5b1

Browse files
td202td202
authored
Merge pull request #69 from Concordium/p8-proposal
P8 update proposal
2 parents 9a37f87 + 9c0c513 commit e78c5b1

File tree

5 files changed

+215
-0
lines changed

5 files changed

+215
-0
lines changed

‎README.md

+1
Original file line numberDiff line numberDiff line change
@@ -24,6 +24,7 @@ The table lists already effective as well as *planned/draft* protocol updates.
2424
| 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` |
2525
| 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` |
2626
| 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 |
27+
| P8 | Suspension of inactive validators | - | - | [P8.txt](../main/updates/P8.txt) | [P8-commentary.txt](../main/commentary/P8-commentary.txt) | `f12e20b6936a6b1b736e95715e1654b92adb4226ef7601b4183895bee563f9da` | - | - |
2728

2829
## Website
2930

‎commentary/P8-commentary.txt

+51
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
Protocol update commentary
2+
3+
Protocol Version: 8
4+
Builds on Protocol Version: 7
5+
6+
Protocol version 8 adds support for suspending inactive validators. Inactive
7+
validators degrade the performance and reliability of the blockchain, and
8+
it is therefore desirable to exclude them where possible.
9+
10+
The protocol for suspending validators requires them to miss producing blocks
11+
multiple times in succession. A validator with a low stake has a
12+
correspondingly low chance of being the leader in any particular round, and so
13+
it may take many days of inactivity before it reaches the threshold for being
14+
suspended. On the other hand, a validator with a high stake may reach the
15+
threshold in minutes or hours of inactivity.
16+
17+
In any case, if the validator reaches the threshold by a payday, it is
18+
considered "primed for suspension". This means that, if it remains inactive
19+
until the next snapshot epoch, it will be suspended from the validator
20+
committee, as determined at the snapshot epoch and effective from the
21+
following (payday) epoch. If the validator becomes active before the snapshot,
22+
as evidenced by producing a block or having its signature included in a quorum
23+
certificate in a block, then it will no longer be considered primed for
24+
suspension, and thus not be suspended. For a validator with a low stake that
25+
is not included in the finalization committee, even if the node is brought
26+
back on-line, it may not be round leader in that time, and so cannot prove
27+
that it is active and thus avoid suspension. For a validator with a high
28+
stake, especially if it is in the finalization committee, there will be ample
29+
opportunities to prove itself to be active, and thus avoid suspension.
30+
31+
In summary, a validator with a high stake could be suspended with a little
32+
more than 23 hours of inactivity, while validators with lower stakes will
33+
require longer. High-stake validators effectively have a grace period of
34+
23 hours after hitting the threshold for missed blocks. Low-stake validators
35+
may not be able to take advantage of the grace period after hitting the
36+
threshold, but have to be inactive for a longer period of time to reach the
37+
threshold in the first place.
38+
39+
A suspended validator can be resumed manually by sending a transaction to do
40+
so. A suspended validator will always be suspended for at least one epoch, but
41+
otherwise incurs no specific penalty. Any accounts that delegate stake to a
42+
suspended validator will remain delegating to it (unless they update their
43+
delegation).
44+
45+
Suspending inactive validators is intended to protect against validators that
46+
are inactive as a result of accident or carelessness; it does not protect
47+
against malicious validators.
48+
49+
Note that it is impossible for more than one third of the stake to be
50+
automatically suspended simultaneously. This is because if more than one third
51+
of the stake was inactive, then the blockchain would halt.

‎source/index.rst

+1
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,7 @@ Concordium Interoperability Specifications
1212
updates/P5
1313
updates/P6
1414
updates/P7
15+
updates/P8
1516

1617
.. toctree::
1718
:maxdepth: 1

‎source/updates/P8.rst

+25
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
=====================================================
2+
Protocol Update 8 - Suspension of inactive validators
3+
=====================================================
4+
5+
.. list-table::
6+
:stub-columns: 1
7+
8+
* - Effective on Testnet
9+
- planned Q1, 2025
10+
* - Effective on Mainnet
11+
- planned Q1, 2025
12+
* - Specification hash
13+
- ``f12e20b6936a6b1b736e95715e1654b92adb4226ef7601b4183895bee563f9da``
14+
15+
Specification
16+
=============
17+
18+
.. include:: ../../updates/P8.txt
19+
:literal:
20+
21+
Commentary
22+
==========
23+
24+
.. include:: ../../commentary/P8-commentary.txt
25+
:literal:

‎updates/P8.txt

+137
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,137 @@
1+
Protocol update
2+
3+
Protocol Version: 8
4+
Builds on Protocol Version: 7
5+
6+
Abstract
7+
8+
This document describes the changes in Concordium protocol version 8 compared to
9+
protocol version 7.
10+
11+
The protocol change supports suspending inactive validators automatically when they
12+
consistently fail to participate in the consensus protocol. Suspended validators
13+
can be reactivated manually by a transaction from the validator's account.
14+
15+
Background
16+
17+
Validators in the Concordium consensus protocol play two related roles. First, they
18+
propose blocks to add to the chain when they are chosen as the leader of a round.
19+
The round leader is determined by a lottery weighted by the validator's effective
20+
stake. If a validator fails to produce a block in its round, the round will
21+
eventually time-out, progressing to the next round with no block produced.
22+
Time-outs increase the confirmation time (that is, the time until a transaction is
23+
finalized on the chain) and decrease the throughput (that is, the maximum number
24+
of transactions the chain can incorporate in a given period of time).
25+
26+
The second role of validators is to sign off on rounds by either attesting to a
27+
valid block in the round, or to the fact that the round timed-out. To progress to
28+
the next round, two thirds of the finalization committee (weighted by stake) must
29+
agree. If more than one third of the committee does not sign off on a round, then
30+
the blockchain halts until two thirds of the committee eventually agrees.
31+
32+
Inactive validators are therefore detrimental to the operation of the consensus
33+
protocol. Protocol version 8 introduces a mechanism to automatically suspend
34+
validators that consistently fail to participate in the protocol. Suspended
35+
validators are excluded from the committee of validators, and will therefore
36+
not be selected to propose blocks nor be required to sign off on rounds.
37+
Consequently, suspended validators do not earn rewards for themselves or their
38+
pool.
39+
40+
The account associated with a suspended validator can lift the suspension by
41+
sending a transaction to do so. The validator will then be included in the
42+
committee the next time it is determined. (The committee is determined one
43+
epoch before each pay day.)
44+
45+
The procedure for automatically suspending a validator is as follows:
46+
47+
- For each current validator, continuously track the number of missed rounds
48+
since the validator last successfully produced a block. A missed round is a
49+
round in which the validator was the round leader, but no block was produced.
50+
51+
- At each payday, if the number of missed rounds for a validator exceeds a
52+
threshold (determined by the "maximum missed rounds" chain parameter)
53+
then mark the validator as "primed for suspension".
54+
55+
- At each snapshot (that is, the start of an epoch prior to a payday), if
56+
a validator is primed for suspension, then it is marked as suspended.
57+
Suspended validators are not included in the calculation of the validator
58+
committee.
59+
60+
- Whenever a validator produces a block, or is a signatory of a quorum
61+
certificate that is in a block, its missed rounds counter is reset and it is
62+
no longer marked as primed for suspension.
63+
64+
Changes
65+
66+
The following behaviours are changed in protocol version 8.
67+
68+
1. A new chain parameter, `maximum_missed_rounds`, is added. This is updated
69+
by a level 2 update instruction (payload `ValidatorScoreParametersCPV3`)
70+
that is authorized by the pool parameters keys.
71+
72+
2. The validator record on accounts includes a new boolean flag indicating if
73+
the validator is currently suspended.
74+
75+
3. The validator pool reward details add a counter of the number of missed rounds
76+
and whether the validator is primed for suspension.
77+
78+
4. On executing each block:
79+
80+
(a) Validators that signed the quorum certificate for the parent block
81+
have their missed-round counter reset to zero and have their primed-
82+
for-suspension flag cleared.
83+
84+
(b) If the previous round timed out, for each missed round, the missed round
85+
counter is incremented for the validator that was the leader of that
86+
round (in the present epoch).
87+
88+
(c) The validator that produced the block has its missed-round counter reset
89+
to zero and its primed-for-suspension flag cleared.
90+
91+
5. When executing a snapshot block (i.e. the first block of an epoch before a
92+
pay day, in which the committee is determined for the upcoming pay day):
93+
94+
(a) Validators that are suspended or were primed for suspension at the
95+
start of the block are not included in the calculation of the
96+
committee for the next payday.
97+
98+
(b) Validators that were primed for suspension at the start of the block
99+
are marked as suspended at the end of the block.
100+
101+
6. When executing a pay day block (i.e. the first block of a new pay day,
102+
in which rewards are paid out):
103+
104+
(a) Validators with a missed-round counter that exceeds
105+
`maximum_missed_rounds` are marked as primed for suspension.
106+
107+
(b) Validators for the new pay day that were not validators for the
108+
previous pay day begin with their missed-round counter at 0 and
109+
their primed-for-suspension flag cleared. Validators that
110+
continue from the previous pay day maintain their missed-round
111+
counter and primed-for-suspension flag.
112+
113+
7. The `ConfigureValidator` (also known as `ConfigureBaker`) transaction
114+
is extended with an optional boolean indicating whether the validator is
115+
suspended. If present, this updates the suspended flag on the account's
116+
validator record. When first configuring a validator, the field is not
117+
required and the validator will not be suspended by default.
118+
119+
Effects
120+
121+
1. The `ConfigureValidator` transaction will produce a `BakerSuspended` or
122+
`BakerResumed` event if it sets or clears the suspended flag,
123+
respectively.
124+
125+
2. Whenever a validator is marked as primed for suspension, a
126+
`ValidatorPrimedForSuspension` event is added to the special events for
127+
the block.
128+
129+
3. Whenever a validator is automatically marked as suspended, a
130+
`ValidatorSuspended` event is added to the special events for the block.
131+
132+
Protocol update instruction
133+
134+
The protocol update instruction is identified by the SHA256 hash of this
135+
file. The instruction needs the following auxiliary data:
136+
137+
- The initial value of the `maximum_missed_rounds` parameter.

0 commit comments

Comments
 (0)