diff --git a/docs/alpha/adaptive-slashing-new.jpeg b/docs/alpha/adaptive-slashing-new.jpeg new file mode 100644 index 0000000000000000000000000000000000000000..54fec4c6c23ba516245740ab8d6ee788daefac1a Binary files /dev/null and b/docs/alpha/adaptive-slashing-new.jpeg differ diff --git a/docs/alpha/adaptive_issuance.rst b/docs/alpha/adaptive_issuance.rst index 60b4061411125e8d7ca918a3714af7f5e581879b..831e73bb66808fcad2b44c7724b4327004b22d3b 100644 --- a/docs/alpha/adaptive_issuance.rst +++ b/docs/alpha/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_alpha: @@ -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_alpha: @@ -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,11 +471,11 @@ the same name introduced for :ref:`user accounts `. This approach was chosen to minimize the work required by wallets, custodians, exchanges, and other parties to support the functionality. -**NB** Until :ref:`feature -activation `: 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 -user accounts can become stakers. In other words, smart contracts +*user accounts* can become stakers. In other words, smart contracts cannot stake funds (they can of course still delegate them). .. _staking_policy_configuration_alpha: @@ -586,16 +596,17 @@ unfinalizable unstake request for token staked with the old delegate. .. _feature_activation_alpha: -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 diff --git a/docs/alpha/adaptive_slashing.rst b/docs/alpha/adaptive_slashing.rst new file mode 100644 index 0000000000000000000000000000000000000000..bb801509e0ddc43ab67b3b4c1d509b94c971d41f --- /dev/null +++ b/docs/alpha/adaptive_slashing.rst @@ -0,0 +1,160 @@ +================= +Adaptive Slashing +================= + + +Overview +======== + +In Oxford2, each instance of a baker's misconduct results in the +slashing of a fixed percentage of their staked funds. However, this +approach does not distinguish between innocent mistakes and deliberate +attacks. The rule conservatively punishes every misconduct with strong +penalties. The rationale for this model is its simplicity and the +observation that the cost of avoiding these mistakes is low anyway. +Nonetheless, it overlooks the impact of double signing of attestations +on the entire block committee, treating all cases uniformly and +ignoring collusion among bakers. + +To better reflect this distinction, the Paris protocol +adjusts the amount of slashing based on the fraction of +double-attestation in a single block. A low fraction of misconduct +incurs moderate penalties, while a high fraction of misconduct is +deemed to be critical and faces more serious repercussions. + +This document presents the definition of an :ref:`adaptive slashing +function` implementing this idea, as well as a +:ref:`new forbidden period`. + +.. _adaptive_slashing_fn_alpha: + +Adaptive Slashing Function +========================== + +.. _adaptive_slashing_informal_alpha: + +Informal presentation +--------------------- + +For a given block, we call “fraction of double-attestations” the ratio +between the total weight of attestations for which a valid +denunciation has been included and the total weight of possible +attestations in a block. + +The shape of the slashing function for double attestations is the +following: + +.. figure:: adaptive-slashing-new.jpeg + + ++------------------------------------------+----------------------------------------+ +| f: fraction of double attestations | S: slashing ratio | ++==========================================+========================================+ +| 1.00% | 0.09% | ++------------------------------------------+----------------------------------------+ +| 5.00% | 2.25% | ++------------------------------------------+----------------------------------------+ +| 10.00% | 9.00% | ++------------------------------------------+----------------------------------------+ +| 20.00% | 36.00% | ++------------------------------------------+----------------------------------------+ +| 23.57% | 50.00% | ++------------------------------------------+----------------------------------------+ +| 33.34% | 100.00% | ++------------------------------------------+----------------------------------------+ +| 100.00% | | ++------------------------------------------+----------------------------------------+ + +Instead of using a constant function as in Oxford2, we propose to use +a convex function that saturates at 100% when a critical fraction of +doubled attestations are issued. Accidental double attestations are +unlikely to cause a large amount of slashing to be applied, but +concerted attacks result in severe penalties. + +\ **Remark 1.** Even though the baker does not attest to a weight +exactly equivalent to its staked funds at each block, the slashing +function is applied to bakers’ total staked funds for simplicity. + +\ **Remark 2.** As in Oxford2, slashing happens at the end of each +cycle. Since the denunciation period for a block ranges over its cycle +and the next one, a baker can be punished for misbehaving during the +previous cycle, not only the one that has just ended. + +\ **Remark 3.** If a baker wants to get back their at-stake funds, it +takes more than 2 cycles to complete the unstaking process. This +ensures that the baker can't decrease their at-stake funds after being +denunciated and before facing penalties. + +.. _formal_adaptive_slashing_alpha: + +A formal definition of slashing function for double-attestations +---------------------------------------------------------------- + +* :math:`\mathcal{W}` denotes the maximal possible *weight* of + attestations in a block, that is, the fixed number of available + :ref:`slots` in any block. It is also known as + :ref:`CONSENSUS_COMMITTEE_SIZE`. + +* :math:`f(B)` is the *fraction of double attestations* for block + :math:`B`, that is, the ratio of the total weight of double + attestations in :math:`B`, over :math:`\mathcal{W}`. + +* :math:`T` is the *threshold* for the fraction of double attestations + to be considered critical. A typical value for :math:`T` is + :math:`{1 \over 3} \mathcal{W}`, which is the difference between + :math:`\mathcal{W}` and the + :ref:`CONSENSUS_THRESHOLD` which is set to + :math:`{2 \over 3} \mathcal{W}`. + +We define :math:`S(B)` the percentage of slashed funds for all +misbehaving bakers at the block :math:`B` as follows: + +:math:`S(B) = \text{min} (100\%, {1 \over T^2} \cdot f(B)^2 \cdot 100\%)` + +Then, the percentage of slashed funds :math:`S(b,C)` for a baker +:math:`b` at the end of the cycle :math:`C` is defined as follows: + +:math:`S(b, C) = \text{min} (100\%, \sum_{(b, B) \in C} S(B))` + +where :math:`(b, B) \in C` means that: + +* the double attestation by baker :math:`b` of block :math:`B` has + been denounced before the end of cycle :math:`C`, and + +* :math:`C` is the last cycle of the denunciation period for + :math:`B`. + +.. _new_forbidden_period_alpha: + +A new definition for the forbidden period +========================================= + +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. + +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. diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index f6a9726ada6294524a455c9cf542f30662109621..8ad945a6da94ab124ff56c143302d6068b910ffc 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -140,48 +140,49 @@ should be taken at round 0, meaning that the time between blocks would be .. _active_stake_alpha: -Validator selection: staking balance, active stake, and frozen deposits ------------------------------------------------------------------------ +Validator selection: staked 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 staked 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 *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 - it participates in consensus. It is at most its - 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_alpha`). - 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. + it participates in consensus. It is at most its maximal + 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 + 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 the frozen deposits. + 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 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 +- ``overall 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 + staked balance + unstaked frozen balance``; it is obtained with ``../context/delegates//full_balance`` -- ``frozen deposit`` is obtained with ``../context/delegates//frozen_deposits`` +- ``staked 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 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 -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 staked balance, +without going beyond its overall 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 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 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 its theoretical maximum staking balance is -``10000`` tez. The following table lists some scenarios (assuming for -simplicity no changes in the delegate's full and staking balances -during the last 8 cycles). +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 staked balances +during the last 5 cycles). .. list-table:: :widths: 20 20 20 20 20 :header-rows: 1 - * - Staking balance + * - Overall balance - Frozen deposit limit - Active stake - - Frozen deposit + - Staked 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 overall 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_alpha: @@ -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 :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)``. @@ -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 @@ -468,7 +467,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`` @@ -479,14 +478,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 diff --git a/docs/alpha/protocol.rst b/docs/alpha/protocol.rst index da493586f242f61eb909b15f040579e180c7a31e..080d9f0023d5b71856716283d123e7f7c491f65e 100644 --- a/docs/alpha/protocol.rst +++ b/docs/alpha/protocol.rst @@ -117,6 +117,11 @@ Sapling, etc), and some details about its implementation. adaptive_issuance +.. toctree:: + :maxdepth: 2 + + adaptive_slashing + .. toctree:: :maxdepth: 2