From 0ac9ccfb604ad9500fd168667195082a9560d305 Mon Sep 17 00:00:00 2001 From: Diane Gallois-Wong Date: Fri, 3 May 2024 19:38:21 +0200 Subject: [PATCH 1/6] Doc/AI: AI will automatically activate 5 cycles into Paris --- docs/paris/adaptive_issuance.rst | 68 ++++++++++++++++---------------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/docs/paris/adaptive_issuance.rst b/docs/paris/adaptive_issuance.rst index 4bfdd429af17..e05634ee3ab2 100644 --- a/docs/paris/adaptive_issuance.rst +++ b/docs/paris/adaptive_issuance.rst @@ -57,9 +57,8 @@ The values for participation rewards and the LB subsidy, if any, are currently defined by the Tezos protocol using fixed constants. -The Adaptive-Issuance/Staking proposal -introduces the possibility to activate Adaptive Issuance: a mechanism where the amount of -participation rewards depends on the global **staked funds ratio** – that is, the +Adaptive Issuance lets the amount of participation rewards depend on +the global **staked funds ratio** – that is, the ratio of staked tez to the total supply. This lets issuance roughly match the *actual* security budget the chain requires, the amount needed to encourage participants to stake and produce blocks, but *no more*. @@ -133,7 +132,9 @@ as follows. Where: -- ``ai_activation_cycle`` is the first cycle with Adaptive Issuance active. +- ``ai_activation_cycle`` is the first cycle with Adaptive Issuance + active, that is, :ref:`5 cycles after the activation of the Paris + protocol`. - ``initial_period`` is a predefined period of time, set to 1 month in Paris. - ``transition_period`` is a predefined period of time, set to 5 months in Paris. @@ -146,7 +147,10 @@ The issuance minimum ratio for Adaptive Issuance curve is then defined as follow Where: -- ``issuance_ratio_initial_min`` (4.5%) is the initial minimum value. At the time of Adaptive Issuance‘s activation, the issuance rate is kept above this bound for the initial period. +- ``issuance_ratio_initial_min`` (4.5%) is the initial minimum + value. At the time of :ref:`Adaptive Issuance + activation`, the issuance rate is kept + above this bound for the initial period. - ``issuance_ratio_global_min`` (0.25%) is the final value for the lower bound, reached at the end of the transition period. @@ -159,7 +163,10 @@ The issuance maximum ratio for Adaptive Issuance curve is then defined as follow Where: -- ``issuance_ratio_initial_max`` (5.5%) controls the initial maximum value. At the time of Adaptive Issuance‘s activation, the issuance rate is kept below this bound for the initial period. +- ``issuance_ratio_initial_max`` (5.5%) controls the initial maximum + value. At the time of :ref:`Adaptive Issuance + activation`, the issuance rate is kept + below this bound for the initial period. - ``issuance_ratio_global_max`` (10%) is the final value for the upper bound, reached at the end of the transition period. .. _staked_ratio_paris: @@ -273,12 +280,13 @@ Finally, as mentioned before, the nominal adaptive issuance rate [1]_ for a cycl Adaptive rewards ---------------- -Before adaptive issuance activation, participation rewards -are fixed values defined by protocol constants. With the -proposed mechanism, the adaptive issuance rate -provides instead a budget for the whole cycle, which gets allocated -equally to each block of the cycle and distributed between the various -rewards, in proportion to their relative :ref:`weights `. +Before :ref:`Adaptive Issuance activation`, +participation rewards are fixed values defined by protocol +constants. With the new mechanism, the adaptive issuance rate provides +instead a budget for the whole cycle, which gets allocated equally to +each block of the cycle and distributed between the various rewards, +in proportion to their relative :ref:`weights +`. .. _rewards_weights_paris: @@ -446,7 +454,9 @@ automatically shared between delegates and their stakers, delegates can use this parameter to collect an *edge* from the rewards attributable to their stakers. -If and when the Adaptive-Issuance/Staking proposal activates, freezing and unfreezing of staked funds +After :ref:`the activation of Adaptive Issuance and +Staking`, freezing and unfreezing of staked +funds will be controlled directly by delegates and stakers, and will no longer be automatic. This entails that staked funds are frozen until manually unfrozen by stakers. This is a two step process which spans for at least @@ -461,8 +471,8 @@ the same name introduced for :ref:`implicit accounts `: only +**NB** Until :ref:`the activation of Adaptive Issuance and Staking +`, only *delegates* can stake funds and the relative weight of staked and delegated funds remains unchanged. In the current implementation, only *implicit accounts* can become stakers. In other words, smart contracts @@ -586,16 +596,17 @@ unfinalizable unstake request for token staked with the old delegate. .. _feature_activation_paris: -Feature activation vs protocol activation -========================================= +Activation of Adaptive Issuance and Staking +=========================================== -Should the Adaptive-Issuance/Staking proposal be accepted by the community, and -once the protocol becomes active on Tezos Mainnet, most of the features -described in this document will **not** be enabled by default, only -latent possibilities in the protocol, waiting for a separate activation. +The Adaptive Issuance and Staking features will not be active +immediately at the start of the Paris protocol. Instead, Adaptive +Issuance and Staking will be automatically activated **5 cycles, that +is, around 2 weeks** after the activation of Paris, in order to give +the community enough time to get ready for these features. -In particular, the following changes will require additional approval -from delegates via separate feature activation vote mechanism: +Here is the list of features and related changes that will only become +active 5 cycles into the Paris protocol: - Adaptive issuance – including notably the changes to the computation of consensus rewards. @@ -604,10 +615,6 @@ from delegates via separate feature activation vote mechanism: **stake** funds. - The changes in weight for staked and delegated funds towards the computation of baking and voting rights. - -Other changes described earlier would be enabled from the Adaptive-Issuance/Staking proposal’s -activation: - - The new interface for stake manipulation based on *pseudo-operations*. Note that this entails the deprecation of the ``set/unset deposits limit`` interface and also the end of automatic @@ -622,13 +629,6 @@ activation: formulas, but these are defined so that they match the previous values when :ref:`Adaptive Issuance ` is not active. - -**NB** In the implementation in the Adaptive-Issuance/Staking proposal, the issuance rate -is computed 3 cycles in advance. Thus, in the first 3 cycles where is -active, the protocol does not use the :ref:`adaptive reward -formula ` and keeps using the current reward -values. - .. [1] Note that if the nominal annual issuance rate is :math:`r`, the annualized rate is close to :math:`\IL{\exp{r} - 1}` as it is -- GitLab From bc8450dc8d71a00593af1e5d900b7ae1c23dc003 Mon Sep 17 00:00:00 2001 From: Diane Gallois-Wong Date: Fri, 3 May 2024 15:18:09 +0200 Subject: [PATCH 2/6] Doc/adaptive_slashing: unforbidding --- docs/paris/adaptive_slashing.rst | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/docs/paris/adaptive_slashing.rst b/docs/paris/adaptive_slashing.rst index f1c3c8e16642..72196bce41fb 100644 --- a/docs/paris/adaptive_slashing.rst +++ b/docs/paris/adaptive_slashing.rst @@ -133,8 +133,28 @@ Given that slashing occurs with a delay, immediate action at denunciation time is necessary upon clear evidence of a baker's misbehavior to prevent further misconduct, or to protect the baker against their own faulty setup. Any double-signing denunciation -immediately triggers the beginning of a forbidden period that lasts at -least 2 cycles, to make sure the slashing occurs before accepting new -attestations or blocks from the baker. Note that it is still possible -for one baker to commit multiple double signings, but only if they all -happen before any corresponding denunciation gets included in a block. +immediately triggers the beginning of a **forbidden period** that +lasts at least 2 cycles, to make sure the slashing occurs before +accepting new attestations or blocks from the baker. + +Note that it is still possible for one baker to commit multiple double +signings, but only if they all happen before any corresponding +denunciation gets included in a block. + +This forbidding is lifted as soon as both following conditions are +met: + +* all pending slashings for the delegate have occurred, and + +* the current total frozen stake for the delegate (sum of the + :ref:`staking balances` of the delegate itself + and its stakers) is at least as high as the :ref:`active + stake` that was used ``CONSENSUS_RIGHTS_DELAY`` + cycles ago to compute the consensus rights for the next cycle. + +The second condition may be fulfilled when the delegate and/or stakers +stake additional funds so that the total frozen stake grows back to +its pre-slashing value, thus matching the rights computed before the +slashing. Or it may be fulfilled ``CONSENSUS_RIGHTS_DELAY`` cycles +after the slashing, when the rights for the next cycle are finally +based on the post-slashing stake. -- GitLab From 7a0283319a082a0d8999a95b506a7f68927ba66b Mon Sep 17 00:00:00 2001 From: Lucas Randazzo Date: Tue, 30 Apr 2024 18:10:18 +0200 Subject: [PATCH 3/6] Doc/consensus: update considering AI --- docs/paris/consensus.rst | 135 +++++++++++++++++++-------------------- 1 file changed, 66 insertions(+), 69 deletions(-) diff --git a/docs/paris/consensus.rst b/docs/paris/consensus.rst index 5e904ca6938f..3351e5d7bc2d 100644 --- a/docs/paris/consensus.rst +++ b/docs/paris/consensus.rst @@ -140,48 +140,49 @@ should be taken at round 0, meaning that the time between blocks would be .. _active_stake_paris: -Validator selection: staking balance, active stake, and frozen deposits +Validator selection: staking balance and active stake ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Validator selection is based on the stake, as in Emmy*, with the exception that -it is based on the delegate's *active stake* instead of its *staking -balance*. Let us first (re)define these and related concepts. +Validator selection is based on the staking balance of a delegate, as in Emmy*. +Let us first (re)define these and related concepts. -- The *(maximal) staking balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the +- The *consensus balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the balances of all accounts that have delegated to it. It must be at least ``MINIMAL_STAKE`` tez, otherwise the delegate cannot be selected as a validator. - The *active stake* of a delegate is the amount of tez with which - it participates in consensus. It is at most its + it participates in consensus. It is at most its maximal staking balance. We explain below how it is computed. -- The *frozen deposit* represents the delegate's skin in the game: in the case that the - delegate behaves badly, its frozen deposit is partly slashed (see - :ref:`slashing_paris`). - The frozen deposits are updated at the end of each cycle. It must be at least - ``MINIMAL_FROZEN_STAKE`` tez, otherwise the delegate cannot be selected as a - validator. +- The *staking balance* represents the delegate's skin in the game: in + the case that the delegate behaves badly, its staking balance is + partly :ref:`slashed`. This staking balance must be + at least ``MINIMAL_FROZEN_STAKE`` tez, otherwise the delegate cannot + be selected as a validator. Note that until the :ref:`activation of + Adaptive Issuance and Staking`, the + staking balance is automatically updated at the end of each cycle to + maximize the active stake. - The *spendable balance* of a delegate is its full balance - minus the frozen deposits. + minus its staking balance. We state next the RPCs which allow to retrieve these types of balances, and also some invariants about them (Note that these are just invariants, not definitions; for instance, the frozen deposits are computed in terms of the full balance, not the other way around.): -- ``delegated balance`` represents the total amount of tokens delegated by others to a +- ``delegated balance`` represents the total amount of tokens delegated or staked by others to a given delegate; it excludes the delegate's full balance; it is obtained with ``../context/delegates//delegated_balance`` -- ``staking balance = full balance + delegated balance``; it is obtained with +- ``consensus balance = full balance + delegated balance``; it is obtained with ``../context/delegates//staking_balance`` -- ``full balance = spendable balance + frozen deposit``; it is obtained with +- ``full balance = spendable balance + staking balance``; it is obtained with ``../context/delegates//full_balance`` -- ``frozen deposit`` is obtained with ``../context/delegates//frozen_deposits`` +- ``staking balance`` is obtained with ``../context/delegates//frozen_deposits`` - ``spendable balance`` is obtained with ``../context/contracts//balance`` -Delegates can set an upper limit to their frozen deposits with the +Until Adaptive Issuance, delegates can set an upper limit to their staking balance with the command ``octez-client set deposits limit for to ``, and unset this limit with the command ``octez-client unset deposits limit for ``. These commands are implemented -using a new manager operation ``Set_deposits_limit``. +using the manager operation ``Set_deposits_limit``. When emitting such a command in cycle ``c``, it affects the automatic deposit at the end of this cycle, and thus the consensus rights set for cycle ``(c + 1) + CONSENSUS_RIGHTS_DELAY + 1``. @@ -203,28 +204,31 @@ before updating the delegates' :ref:`activity status`. block* or *having a preattestation or attestation included in a final block*. -Intuitively, the active stake is set to 10 times the delegate's chosen frozen -deposit limit, without going beyond its available staking balance, -nor its maximum staking capacity (determined by its full balance). -More precisely, the active stake is the minimum between: +Intuitively, the active stake is set to 10 times the delegate's staking balance, +without going beyond its consensus balance. +More precisely, the active stake is: -- the delegate's staking balance, and -- 10 times the delegate's *deposit cap*, i.e. ``deposit_cap * 100 / deposit_percentage``. If the delegate has not set a frozen deposit limit, ``deposit_cap`` is its full balance. Otherwise ``deposit_cap`` is the minimum between its full balance and the frozen deposit limit set by the delegate. +- the delegate's staking balance, +- its stakers' staking balance (up to a limit, see + :ref:`limit_of_staking_over_baking`), +- and the liquid delegated balance + the spendable balance, up to 9 times the delegate's staking balance. + +Before Adaptive Issuance, each part weighs equally when computing the baking and voting rights. After Adaptive Issuance, the frozen balances (non-liquid, non-spendable) are weighed for twice as much per tez as the liquid part. Let's take some examples. Say that the full balance of a delegate is ``1000`` tez. -Then its theoretical maximum staking balance is -``10000`` tez. The following table lists some scenarios (assuming for +Then, without external staking, its theoretical maximum active stake is +``10000`` tez. The following table lists some scenarios before Adaptive Issuance (assuming for simplicity no changes in the delegate's full and staking balances -during the last 8 cycles). +during the last 5 cycles). .. list-table:: :widths: 20 20 20 20 20 :header-rows: 1 - * - Staking balance + * - Consensus balance - Frozen deposit limit - Active stake - - Frozen deposit + - Staking balance - Spendable balance * - 9000 - -- @@ -251,7 +255,7 @@ We note in passing that this new schema basically solves the main problem of over-delegation: a delegate will not fail anymore to bake and attest because of an insufficient balance to pay the deposit. However, a delegate can still be over-delegated, and it will be -rewarded based on its active stake, not on its staking balance. +rewarded based on its active stake, not on its consensus balance. Economic Incentives ~~~~~~~~~~~~~~~~~~~ @@ -267,15 +271,12 @@ behavior. Notable changes however are as follows: obtain a quorum, is rewarded with a bonus. * Attesting rewards are shared equally among all validators. Participation above a minimal threshold per cycle is however required. -* Deposits are no longer frozen and unfrozen, instead a percentage of the active - stake is always locked. A delegate with an empty deposit cannot bake nor - (pre)attest. * Validators are rewarded instantaneously for baking blocks and including extra attestations, and not at the end of the cycle like in Emmy*. * At the end of a cycle ``c``, the following actions happen: - - the selection of the consensus committee cycle ``c + CONSENSUS_RIGHTS_DELAY``, based on the current active stake distribution, - the distribution of attesting rewards, - - the adjustment of frozen deposits. + - the adjustment of stake balances, + - the selection of the consensus committee cycle ``c + CONSENSUS_RIGHTS_DELAY``, based on the current active stake distribution. Fees @@ -326,9 +327,9 @@ cycle represents at least ``MINIMAL_PARTICIPATION_RATIO`` of the delegate's expe validator slots for the current cycle (which is ``BLOCKS_PER_CYCLE * CONSENSUS_COMMITTEE_SIZE * active_stake / total_active_stake``). -Regarding the concrete values for rewards, we first fix the total reward per +Regarding the concrete values for rewards, before Adaptive Issuance, we first fix the total reward per level, call it ``total_rewards``, to ``80 / blocks_per_minute`` tez. -Assuming ``blocks_per_minute = 6``, ``total_rewards`` is 13.33 tez. +Assuming ``blocks_per_minute = 7.5``, ``total_rewards`` is 10.67 tez. With Adaptive Issuance, this value changes dynamically over time but for the sake of example, we will assume that the reward value stays the same as above. We define: - ``BAKING_REWARD_FIXED_PORTION := baking_reward_ratio * total_rewards`` @@ -340,16 +341,16 @@ where: - ``baking_reward_ratio`` to ``1 / 4``, - ``bonus_ratio`` to ``1 / 3``. -Thus, we obtain ``BAKING_REWARD_FIXED_PORTION = 3.33`` tez, -(maximum) ``bonus = 3.33`` tez, and ``attesting_rewards = 6.67`` tez. +Thus, we obtain ``BAKING_REWARD_FIXED_PORTION = 2.67`` tez, +(maximum) ``bonus = 2.67`` tez, and ``attesting_rewards = 5.33`` tez. The bonus per additional attestation slot is in turn ``bonus / (CONSENSUS_COMMITTEE_SIZE / 3)`` (because there are at most ``CONSENSUS_COMMITTEE_SIZE / 3`` validator slots corresponding to the additional attestations included in a block). The rewards per attestation slot are ``attesting_rewards / CONSENSUS_COMMITTEE_SIZE``. Assuming ``CONSENSUS_COMMITTEE_SIZE = 7000``, we obtain a bonus per slot of -``3.33 / (7000 / 3) = 0.001427`` tez and an attesting -rewards per slot of ``6.67 / 7000 = 0.000952`` tez. +``2.67 / (7000 / 3) = 0.001143`` tez and an attesting +rewards per slot of ``5.33 / 7000 = 0.000761`` tez. Let's take an example. Say a block has round 1, is proposed by delegate B, and contains the payload from round 0 produced by delegate @@ -357,15 +358,15 @@ A. Also, B includes attestations with attesting power ``5251``. Then A receives the fees and 10 tez (the ``BAKING_REWARD_FIXED_PORTION``) as a reward for producing the block's payload. Concerning the bonus, given that ``CONSENSUS_COMMITTEE_SIZE = 7000``, the minimum required validator slots is ``4667``, and there are ``2333 = 7000 - 4667`` additional validator slots. -Therefore B receives the bonus ``(5251 - 4667) * 0.001428 = 0.833952`` tez. (Note +Therefore B receives the bonus ``(5251 - 4667) * 0.001143 = 0.667512`` tez. (Note that B only included attestations corresponding to 584 = 5251 - 4667 additional validator slots, about a quarter of the maximum 2333 extra attestations it could have theoretically included.) Finally, consider some -delegate C, whose active stake at some cycle is 5% of the total stake. Note that -his expected number of validator slots for that cycle is ``5/100 * 8192 * 7000 = -2,867,200`` slots. Assume also that the attesting power of C's attestations -included during that cycle has been ``2,123,456`` slots. Given that this number is -bigger than the minimum required (``2,867,200 * 2 / 3``), it receives an attesting -reward of ``2,867,200 * 0.000952 = 2729.5744`` tez for that cycle. +delegate C, whose active stake at some cycle is 1% of the total stake. Note that +his expected number of validator slots for that cycle is ``1/100 * 30720 * 7000 = +2,150,400`` slots. Assume also that the attesting power of C's attestations +included during that cycle has been ``1,987,456`` slots. Given that this number is +bigger than the minimum required (``2,150,400 * 2 / 3``), it receives an attesting +reward of ``2,150,400 * 0.000761 = 1636.4544`` tez for that cycle. .. _slashing_paris: @@ -378,10 +379,12 @@ its attesting rewards. If a validator double signs, that is, it double bakes (which means signing different blocks at the same level and same round) or it double (pre)attests (which means voting on two different proposals at the same level and round), a part of the frozen deposit is slashed. The slashed amount -for double baking and double (pre)attesting are fixed percentage of the frozen -deposit: ``PERCENTAGE_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_BAKING`` and -``PERCENTAGE_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_ATTESTATION``. -The payload producer that includes the misbehavior evidence is rewarded a +for double baking is a fixed percentage of the frozen deposit +``PERCENTAGE_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_BAKING``. For +double (pre)attestations, the formula is more complex, as it depends +on the number of attestation slots that participated in the +misbehavior; see :ref:`adaptive_slashing` for more details. +The payload producer that includes the misbehavior evidence will be rewarded a seventh of the slashed amount, which corresponds to ``1 / (GLOBAL_LIMIT_OF_STAKING_OVER_BAKING + 2)``. @@ -392,18 +395,14 @@ The evidence for double signing at a given level can be collected by any :ref:`accuser` and included as an *accusation* operation in a block for a period of ``MAX_SLASHING_PERIOD``. -If the recorded denunciation events in the previous and current cycle lead to -slashing over 51% of the deposits, it immediately forbids the delegate to -participate further in the consensus, either by baking or attesting. -At the end of the first cycle in which both the sum of slashing events of a -delegate over the last two cycles fall under the 51% threshold and its frozen -deposits are at least half of its consensus rights for the given cycle, the -delegate is allowed to participate again in the next cycle. +As soon as a delegate is denounced for any double signing, it is +immediately :ref:`forbidden` from both baking +and attesting for at least 2 cycles. -The actual slashing and denunciation rewarding happen at the end of the cycle in -which the denunciation has been included. +The actual slashing and denunciation rewarding happen at the end of +the last cycle of the slashing period of the misbehavior. -We note that selfish baking is not an issue in Tenderbake: say we are at round +Note that selfish baking is not an issue in Tenderbake: say we are at round ``r`` and the validator which is proposer at round ``r+1`` does not (pre)attest at round ``r`` in the hope that the block at round ``r`` is not agreed upon and its turn comes to propose at round ``r+1``. Under the assumption that the @@ -427,7 +426,7 @@ Consensus related protocol parameters * - ``CONSENSUS_THRESHOLD`` - ``ceil(2 * CONSENSUS_COMMITTEE_SIZE / 3)`` = 4667 * - ``MINIMAL_BLOCK_DELAY`` - - 10s + - 8s * - ``DELAY_INCREMENT_PER_ROUND`` - 5s * - ``MINIMAL_PARTICIPATION_RATIO`` @@ -438,14 +437,12 @@ Consensus related protocol parameters - 2 cycles * - ``PERCENTAGE_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_BAKING`` - 5% - * - ``PERCENTAGE_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_ATTESTATION`` - - 50% * - ``BAKING_REWARD_FIXED_PORTION`` - - 3.33 tez + - 2.67 tez * - ``BAKING_REWARD_BONUS_PER_SLOT`` - - ``bonus / (CONSENSUS_COMMITTEE_SIZE / 3)`` = 0.001429 tez + - ``bonus / (CONSENSUS_COMMITTEE_SIZE / 3)`` = 0.001143 tez * - ``ATTESTING_REWARD_PER_SLOT`` - - ``attesting_reward / CONSENSUS_COMMITTEE_SIZE`` = 0.000952 tez + - ``attesting_reward / CONSENSUS_COMMITTEE_SIZE`` = 0.000761 tez * - ``GLOBAL_LIMIT_OF_STAKING_OVER_BAKING`` - 5 -- GitLab From 633ed15e068cb28fedcedda046766d9502d6f5fb Mon Sep 17 00:00:00 2001 From: Diane Gallois-Wong Date: Fri, 3 May 2024 20:43:46 +0200 Subject: [PATCH 4/6] Doc/consensus: consensus balance -> overall balance --- docs/paris/consensus.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/paris/consensus.rst b/docs/paris/consensus.rst index 3351e5d7bc2d..add82239ba86 100644 --- a/docs/paris/consensus.rst +++ b/docs/paris/consensus.rst @@ -146,7 +146,7 @@ Validator selection: staking balance and active stake Validator selection is based on the staking balance of a delegate, as in Emmy*. Let us first (re)define these and related concepts. -- The *consensus balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the +- The *overall balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the balances of all accounts that have delegated to it. It must be at least ``MINIMAL_STAKE`` tez, otherwise the delegate cannot be selected as a validator. - The *active stake* of a delegate is the amount of tez with which @@ -171,7 +171,7 @@ not the other way around.): - ``delegated balance`` represents the total amount of tokens delegated or staked by others to a given delegate; it excludes the delegate's full balance; it is obtained with ``../context/delegates//delegated_balance`` -- ``consensus balance = full balance + delegated balance``; it is obtained with +- ``overall balance = full balance + delegated balance``; it is obtained with ``../context/delegates//staking_balance`` - ``full balance = spendable balance + staking balance``; it is obtained with ``../context/delegates//full_balance`` @@ -205,7 +205,7 @@ before updating the delegates' :ref:`activity status`. block*. Intuitively, the active stake is set to 10 times the delegate's staking balance, -without going beyond its consensus balance. +without going beyond its overall balance. More precisely, the active stake is: - the delegate's staking balance, @@ -225,7 +225,7 @@ during the last 5 cycles). :widths: 20 20 20 20 20 :header-rows: 1 - * - Consensus balance + * - Overall balance - Frozen deposit limit - Active stake - Staking balance @@ -255,7 +255,7 @@ We note in passing that this new schema basically solves the main problem of over-delegation: a delegate will not fail anymore to bake and attest because of an insufficient balance to pay the deposit. However, a delegate can still be over-delegated, and it will be -rewarded based on its active stake, not on its consensus balance. +rewarded based on its active stake, not on its overall balance. Economic Incentives ~~~~~~~~~~~~~~~~~~~ -- GitLab From f22613dfb6a0c2bc88bf98beb2ec92e81abc47de Mon Sep 17 00:00:00 2001 From: Julien Tesson Date: Mon, 6 May 2024 14:51:41 +0200 Subject: [PATCH 5/6] docs/paris: fix link to adaptive_slashing --- docs/paris/consensus.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/paris/consensus.rst b/docs/paris/consensus.rst index add82239ba86..3cc1b7bd0ed5 100644 --- a/docs/paris/consensus.rst +++ b/docs/paris/consensus.rst @@ -383,7 +383,7 @@ for double baking is a fixed percentage of the frozen deposit ``PERCENTAGE_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_BAKING``. For double (pre)attestations, the formula is more complex, as it depends on the number of attestation slots that participated in the -misbehavior; see :ref:`adaptive_slashing` for more details. +misbehavior; see :doc:`adaptive_slashing` for more details. The payload producer that includes the misbehavior evidence will be rewarded a seventh of the slashed amount, which corresponds to ``1 / (GLOBAL_LIMIT_OF_STAKING_OVER_BAKING + 2)``. -- GitLab From a8ba0bc3a6880dc76b8311e3a1f089bc07e44560 Mon Sep 17 00:00:00 2001 From: Lucas Randazzo Date: Mon, 13 May 2024 16:42:19 +0200 Subject: [PATCH 6/6] docs/paris: staking balance -> staked balance --- docs/paris/consensus.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/paris/consensus.rst b/docs/paris/consensus.rst index 3cc1b7bd0ed5..a8403b773a9f 100644 --- a/docs/paris/consensus.rst +++ b/docs/paris/consensus.rst @@ -140,10 +140,10 @@ should be taken at round 0, meaning that the time between blocks would be .. _active_stake_paris: -Validator selection: staking balance and active stake +Validator selection: staked balance and active stake ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Validator selection is based on the staking balance of a delegate, as in Emmy*. +Validator selection is based on the staked balance of a delegate, as in Emmy*. Let us first (re)define these and related concepts. - The *overall balance* of a delegate is its full balance (i.e. all the tokens owned by the delegate) plus the @@ -151,17 +151,17 @@ Let us first (re)define these and related concepts. It must be at least ``MINIMAL_STAKE`` tez, otherwise the delegate cannot be selected as a validator. - The *active stake* of a delegate is the amount of tez with which it participates in consensus. It is at most its maximal - staking balance. We explain below how it is computed. -- The *staking balance* represents the delegate's skin in the game: in - the case that the delegate behaves badly, its staking balance is - partly :ref:`slashed`. This staking balance must be + staked balance. We explain below how it is computed. +- The *staked balance* represents the delegate's skin in the game: in + the case that the delegate behaves badly, its staked balance is + partly :ref:`slashed`. This staked balance must be at least ``MINIMAL_FROZEN_STAKE`` tez, otherwise the delegate cannot be selected as a validator. Note that until the :ref:`activation of Adaptive Issuance and Staking`, the - staking balance is automatically updated at the end of each cycle to + staked balance is automatically updated at the end of each cycle to maximize the active stake. - The *spendable balance* of a delegate is its full balance - minus its staking balance. + minus its staked balance and unstaked frozen balance. We state next the RPCs which allow to retrieve these types of balances, and also some invariants about them (Note that these are just invariants, not definitions; for @@ -173,12 +173,12 @@ not the other way around.): with ``../context/delegates//delegated_balance`` - ``overall balance = full balance + delegated balance``; it is obtained with ``../context/delegates//staking_balance`` -- ``full balance = spendable balance + staking balance``; it is obtained with +- ``full balance = spendable balance + staked balance + unstaked frozen balance``; it is obtained with ``../context/delegates//full_balance`` -- ``staking balance`` is obtained with ``../context/delegates//frozen_deposits`` +- ``staked balance`` is obtained with ``../context/delegates//frozen_deposits`` - ``spendable balance`` is obtained with ``../context/contracts//balance`` -Until Adaptive Issuance, delegates can set an upper limit to their staking balance with the +Until Adaptive Issuance, delegates can set an upper limit to their staked balance with the command ``octez-client set deposits limit for to ``, and unset this limit with the command ``octez-client unset deposits limit for ``. These commands are implemented @@ -204,21 +204,21 @@ before updating the delegates' :ref:`activity status`. block* or *having a preattestation or attestation included in a final block*. -Intuitively, the active stake is set to 10 times the delegate's staking balance, +Intuitively, the active stake is set to 10 times the delegate's staked balance, without going beyond its overall balance. More precisely, the active stake is: -- the delegate's staking balance, -- its stakers' staking balance (up to a limit, see +- the delegate's staked balance, +- its stakers' staked balance (up to a limit, see :ref:`limit_of_staking_over_baking`), -- and the liquid delegated balance + the spendable balance, up to 9 times the delegate's staking balance. +- and the liquid delegated balance + the spendable balance, up to 9 times the delegate's staked balance. Before Adaptive Issuance, each part weighs equally when computing the baking and voting rights. After Adaptive Issuance, the frozen balances (non-liquid, non-spendable) are weighed for twice as much per tez as the liquid part. Let's take some examples. Say that the full balance of a delegate is ``1000`` tez. Then, without external staking, its theoretical maximum active stake is ``10000`` tez. The following table lists some scenarios before Adaptive Issuance (assuming for -simplicity no changes in the delegate's full and staking balances +simplicity no changes in the delegate's full and staked balances during the last 5 cycles). .. list-table:: @@ -228,7 +228,7 @@ during the last 5 cycles). * - Overall balance - Frozen deposit limit - Active stake - - Staking balance + - Staked balance - Spendable balance * - 9000 - -- -- GitLab