diff --git a/docs/alpha/adaptive_issuance.rst b/docs/alpha/adaptive_issuance.rst index a11537153768c5ad57887f98ceeb682cf8d421fa..54c06afe7bbe5b7f4f5f89b42a05e422a0af3ab3 100644 --- a/docs/alpha/adaptive_issuance.rst +++ b/docs/alpha/adaptive_issuance.rst @@ -19,7 +19,6 @@ :math:`\newcommand\tw{\Sigma_w}` :math:`\newcommand\rw[2]{\F{reward_{#1}}{#2}}` :math:`\newcommand\tip[2]{\F{tip_{#1}}{#2}}` -:math:`\newcommand\lbs[1]{\F{subsidy_{LB}}{#1}}` :math:`\newcommand\exp[1]{\F{exp}{#1}}` :math:`\newcommand{\vdf}{\mathit{VDF}}` @@ -28,7 +27,7 @@ Adaptive Issuance and Staking ============================= -This document describes Adaptive Issuance and Staking, two new features experimented in the Alpha protocol (referred hereafter as the Adaptive-Issuance/Staking proposal), which together constitute a major evolution of Tezos’ :doc:`Proof-of-Stake mechanism `. +This document describes Adaptive Issuance and Staking, two new features (referred hereafter as the Adaptive-Issuance/Staking proposal) which together constitute a major evolution of Tezos’ :doc:`Proof-of-Stake mechanism `. .. note:: @@ -60,8 +59,7 @@ constants. The Adaptive-Issuance/Staking proposal introduces the possibility to activate Adaptive Issuance: a mechanism where the amount of -*regularly* issued tez (participation rewards and the LB subsidy, if -active) depends on the global **staked funds ratio** – that is, the +participation rewards depends 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*. @@ -69,7 +67,7 @@ to encourage participants to stake and produce blocks, but *no more*. At the end of each blockchain :ref:`cycle `, the regular issuance is adjusted, to nudge the staked funds ratio towards a protocol-defined target (set at 50% in the Adaptive-Issuance/Staking proposal). Participation rewards -and the LB subsidy are recomputed to match that budget. When the staked +are recomputed to match that budget. When the staked funds ratio decreases and diverges from the target, emission rates increase, incentivizing participants to stake funds to re-approach the target. Conversely, incentives decrease as the ratio increases beyond @@ -79,7 +77,7 @@ Adaptive issuance rate ---------------------- The :ref:`adaptive issuance rate ` determines, at the end -of cycle :math:`\IL{c}`, the issuance for cycle :math:`\IL{c + 5}`. The +of cycle :math:`\IL{c}`, the issuance for cycle :math:`\IL{c + 3}`. The adaptive issuance rate is the sum of a :ref:`static rate ` and a :ref:`dynamic rate `. The final result is clipped to ensure nominal emissions remain within :math:`\IL{[\minR,\ \maxR]}` (set @@ -179,26 +177,26 @@ the adaptive issuance rate is kept within :math:`\IL{[\minR,\ \maxR]}` bounds. Finally, as mentioned before, the nominal adaptive issuance rate [1]_ -for a cycle :math:`\IL{c + 5}` is defined as the sum of the static rate +for a cycle :math:`\IL{c + 3}` is defined as the sum of the static rate and the dynamic rate, clipped to stay within 0.05% – 5% range. .. _adaptive_rate_alpha: \ **ADAPTIVE ISSUANCE RATE**\    Let :math:`\F{f}{c}` be the staked funds ratio at the end of cycle :math:`\IL{c}`, the **adaptive issuance -rate** for cycle :math:`\IL{c+5}` is defined as: +rate** for cycle :math:`\IL{c+3}` is defined as: .. math:: - \adr{c + 5} = \clip{\dyn{c} + \static{\F{f}{c}}}{\minR}{\maxR} + \adr{c + 3} = \clip{\dyn{c} + \static{\F{f}{c}}}{\minR}{\maxR} .. _adaptive_rewards_alpha: Adaptive rewards ---------------- -Before adaptive issuance activation, participation rewards and -the LB subsidy are fixed values defined by protocol constants. With the +Before adaptive issuance activation, participation rewards +are fixed values defined by protocol constants. With the proposed mechanism, the :ref:`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 @@ -206,30 +204,29 @@ rewards, in proportion to their relative :ref:`weights `. \ **ADAPTIVE ISSUANCE PER BLOCK**\    Let :math:`\supply{c}` be the total supply at the end of cycle :math:`\IL{c}`, the **maximal issuance per -block** for cycle :math:`\IL{c+5}` is defined as: +block** for cycle :math:`\IL{c+3}` is defined as: .. math:: - \isb{c + 5} = \frac{\adr{c + 5}}{2102400} \tmult \supply{c} + \isb{c + 3} = \frac{\adr{c + 3}}{3153600} \tmult \supply{c} -Where 2102400 = -:math:`\IL{\frac{365 \tmult 24 \tmult 60 \tmult 60}{15}}` is the maximal -number of blocks produced in a year, given a minimal block time of 15 +Where 3153600 = +:math:`\IL{\frac{365 \tmult 24 \tmult 60 \tmult 60}{10}}` is the maximal +number of blocks produced in a year, given a minimal block time of 10 seconds. .. _reward_weights_alpha: \ **REWARD WEIGHTS**\    The Adaptive-Issuance/Staking proposal defines the weights for -participation rewards and the LB subsidy as: +participation rewards as: - Attestation (formerly, endorsing) rewards : 10,240. - Fixed baking reward: 5,120. - Bonus baking reward: 5,120. -- LB subsidy: 1,280. - Nonce revelation tip: 1. - VDF tip: 1. -The total sum of all weights is :math:`\tw` = 21762. The total issuance +The total sum of all weights is :math:`\tw` = 20482. The total issuance per block, :math:`\IL{\isb{c}}`, is distributed amongst the different rewards in proportion to their weight. @@ -272,30 +269,18 @@ being subject to the existing participation conditions. **Nonce and VDF revelation tips.** The rewards allocated to delegates for contributing to :ref:`random seed generation ` -(that is for, revealing nonce seeds and posting VDF proofs) are not paid +(that is, for revealing nonce seeds and posting VDF proofs) are not paid each block, but rather every 192 blocks. The adjusted formulas result: .. math:: \tip{\vdf}{c} = \tip{nr}{c} = 192 \tmult \frac{1}{\tw} \tmult \isb{c} -**Liquidity baking subsidy.** The :doc:`LB -subsidy ` per block is determined by the following formula: - -.. math:: - - \lbs{c} = \frac{1280}{\tw} \tmult \isb{c} - -Note that while the subsidy is issued **only if** the feature is on, its -weight is always counted in the computation of :math:`\IL{\tw}`. In -other words, the budget for the LB subsidy is always allocated, -regardless of whether it is issued or not. - The Adaptive-Issuance/Staking proposal implements a new `RPC endpoint `__, ``/issuance/expected_issuance``, which reports the precomputed values of -all participation rewards and the LB subsidy, for the cycle -corresponding to the queried block level, and the next 4 cycles. +all participation rewards, for the cycle +corresponding to the queried block level, and the next 3 cycles. .. _new_staking_alpha: @@ -309,7 +294,7 @@ complementary to the existing :ref:`delegate ` (also known as *baker*) and *delegator* roles. A staker must also be a *delegator* – that is, they must first choose a delegate. -When stakers **stake**\ funds towards a delegate’s **staking** +When stakers **stake** funds towards a delegate’s **staking** **balance**, the associated **baking** and **voting powers** accrue to that delegate. Similarly to how delegated funds work, staked funds remain within the staker’s account at all times. @@ -329,7 +314,7 @@ withdrawal delays – colloquially, they are "frozen". Stakers are slashed proportionally to their contribution to the delegate’s staking balance. To simplify slashing, double-baking penalties are now proportional to staked funds: instead of the previous -fixed sum of 640 tez they are now set to 10% of the delegate’s stake. +fixed sum of 640 tez they are now set to 5% of the delegate’s stake. Moreover, denunciation rewards (both for double-baking and double-attestations) are reduced from one half to one seventh of the slashed funds. The chosen value prevents adversarial delegates from @@ -340,10 +325,10 @@ stakers. policy ` by setting staking parameters which regulate whether they accept stakers (the default being to reject them), and if so, up to which fraction of their total staking balance. -They can also configure which proportion of the staking rewards is set -to accrue to their own staked balance versus their unfrozen, spendable -balance. As :ref:`participation rewards ` are paid to -the staked balance, and automatically shared between delegates and their +They can also configure which proportion of the staking rewards from other stakers is set +to accrue to their own staked balance instead. +As :ref:`participation rewards ` are +automatically shared between delegates and their stakers, delegates can use this parameter to collect an *edge* from the rewards attributable to their stakers. @@ -351,7 +336,7 @@ If and when the Adaptive-Issuance/Staking proposal activates, freezing and unfre 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 -7 cycles (cf. :ref:`Staked funds management `). +4 cycles (cf. :ref:`Staked funds management `). A new user interface is provided for delegates and stakers to interact with the mechanism. It is based on four *pseudo-operations*: ``stake``, @@ -379,8 +364,8 @@ parameters: - ``edge_of_baking_over_staking``: a ratio between 0 and 1, whose default value is 1. This parameter determines the fraction of the - rewards that accrue to the delegate’s liquid spendable balance – the - remainder accrues to frozen stakes. + rewards that accrue to the delegate's frozen deposit – the + remainder is shared among its stakers. - ``limit_of_staking_over_baking``: a non-negative number, denoting the maximum portion of external stake by stakers over the delegate’s own staked funds. It defaults to 0 – which entails that delegates do not @@ -404,7 +389,7 @@ or more conveniently:: **On overstaking and overdelegation.** Note that if a delegate’s ``limit_of_staking_over_baking`` is exceeded (that is, the delegate is -*overstaked*), the exceeding stake is automatically considered a +*overstaked*), the exceeding stake is automatically considered as *delegation* for the delegate’s baking and voting power calculation, but it does remain slashable. The new mechanism does not alter *overdelegation* (delegated funds beyond 9 times the delegate’s own @@ -453,7 +438,7 @@ or more conveniently:: octez-client unstake for The requested amount will be **unstaked** but will remain **frozen**. -After 7 cycles, unstaked frozen tokens are no longer considered at stake +After 4 cycles, unstaked frozen tokens are no longer considered at stake nor slashable. They are said then to be both **unstaked** and **finalizable**. @@ -468,10 +453,10 @@ or more conveniently:: octez-client finalize unstake for - In some circumstances, unstake and finalize can be done implicitly: any call - to ``stake`` or ``unstake`` will implicitly finalize all currently finalizable pending - unstake requests. Also, as we will see next, change of delegate triggers an - unstake operation. +In some circumstances, unstake and finalize can be done implicitly: any call +to ``stake`` or ``unstake`` will implicitly finalize all currently finalizable pending +unstake requests. Also, as we will see next, change of delegate triggers an +unstake operation. Change of delegate ------------------ @@ -499,7 +484,7 @@ In particular, the following changes will require additional approval from delegates via separate feature activation vote mechanism: - Adaptive issuance – including notably the changes to the computation - of consensus rewards and the LB subsidy. + of consensus rewards. - Ability for *delegators* to become *stakers* – until feature activation delegates continue to be the only participants who can **stake** funds. @@ -516,10 +501,10 @@ activation: derived from the frozen deposits at the end of the last cycle of Nairobi. - The changes in slashing penalties (double-baking penalties are set to - 10% of the staked funds) and denunciation rewards (they amount to one + 5% of the staked funds) and denunciation rewards (they amount to one seventh of slashed funds). - Changes to protocol constants. Note that this entails calculating - participation rewards and the LB subsidy using the weight-based + participation rewards using the weight-based formulas, but these are defined so that they match the previous values when :ref:`Adaptive Issuance ` is not active. @@ -541,7 +526,7 @@ mechanism: subsequent *Adoption* phase. - The *Voting* phase is driven by an Exponential moving average (EMA) whose *half-life* is 2 weeks. That is, it takes two weeks for the EMA - to raise from 0% to 50% assuming only **On**\ votes are cast. + to raise from 0% to 50% assuming only **On** votes are cast. - The target threshold is a supermajority of 80% of **On** votes over **On plus Off** votes. - There is no time limit or fixed duration for the Voting phase. It @@ -552,7 +537,7 @@ mechanism: - If the threshold is met, the Voting phase will complete at the end of the current cycle, and the Adoption phase will start at the beginning of the following cycle. -- The Adoption phase lasts 7 cycles. The beginning of the cycle +- The Adoption phase lasts 5 cycles. The beginning of the cycle following the end of the Adoption phase activates the guarded features. - There is **no automatic deactivation** of the guarded features once @@ -560,7 +545,7 @@ mechanism: counted towards an updated EMA, but without any further effect. **NB** In the implementation in the Adaptive-Issuance/Staking proposal, the issuance rate -is computed 5 cycles in advance. Thus, in the first 5 cycles where is +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. diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index d8385e72eae7f1c7bd62c1c31a5bfe5f2f4714fe..0de867612f932ccacbf2e4382224ed0c7f8cba81 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -32,8 +32,6 @@ CPMM contract, and the CPMM's ``%default`` entrypoint is called to update the CPMM contract is 1/16th of the rewards for a block of round 0 with all attestations; currently these rewards are 13.33 tez per block so the amount that is sent to the CPMM contract is 0.83 tez per block. -If the :ref:`adaptive issuance ` feature were to be activated, -the subsidy would be adjusted by the adaptive issuance coefficient. So the credits to the CPMM contract can be accounted for by indexers, they are included in block metadata as a balance update with a new constructor for ``update_origin``, ``Subsidy``. diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index 4d8cf890bf5ce0f1369e86d69f985ed038e5c999..d71d6563a330e2b0cd82179af081e1cfa7061927 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -64,7 +64,7 @@ transfer the delegate's free balance to an arbitrary account. In :doc:`relevant like ``/chains/main/blocks/head/helpers/baking_rights``, both the delegate's manager and consensus keys are listed. -On test-network only, if the :ref:`adaptive issuance ` +On test-network only, if the :ref:`adaptive issuance ` feature is activated, it grants delegators the ability to become 'stakers' by placing security deposits. These deposits would contribute to their delegate's stake and could be subject to slashing penalties if their delegate @@ -172,7 +172,7 @@ Proof-of-stake parameters * - ``BLOCKS_PER_CYCLE`` - 24576 blocks * - ``CONSENSUS_RIGHTS_DELAY`` - - 5 cycles + - 2 cycles * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``MINIMAL_FROZEN_STAKE`` @@ -189,7 +189,7 @@ found in the `whitepaper `_. -The adaptive issuance experimental feature :ref:`documentation `. +The adaptive issuance experimental feature :ref:`documentation `. Other presentations of the Tezos' proof-of-stake mechanism can be found in the diff --git a/docs/alpha/staked_funds_transitions.png b/docs/alpha/staked_funds_transitions.png index 46a3c022d1c49264f065115a16d69879f812907a..96a15d92c2c2480234c15a0b586a3a01ea3e2b3d 100644 Binary files a/docs/alpha/staked_funds_transitions.png and b/docs/alpha/staked_funds_transitions.png differ diff --git a/docs/oxford/adaptive_issuance.rst b/docs/oxford/adaptive_issuance.rst deleted file mode 100644 index fe4f1e14af57a1f2192e7b3b20c070a17ba38585..0000000000000000000000000000000000000000 --- a/docs/oxford/adaptive_issuance.rst +++ /dev/null @@ -1,581 +0,0 @@ -:math:`\newcommand\F[2]{\mathit{#1}\left(#2\right)}` -:math:`\newcommand{\minR}{\mathit{min_r}}` -:math:`\newcommand{\maxR}{\mathit{max_r}}` -:math:`\newcommand{\tmult}{\cdot}` -:math:`\newcommand\static[1]{\F{static}{#1}}` -:math:`\newcommand{\sfr}{\frac{1}{1600}}` :math:`\newcommand\tc{\tau_c}` -:math:`\newcommand\tr{\tau_r}` :math:`\newcommand\grf{\gamma}` -:math:`\newcommand\dyn[1]{\F{dyn}{#1}}` -:math:`\newcommand\sgn[1]{\F{sign}{#1}}` -:math:`\newcommand\dist[1]{\F{distance}{#1}}` -:math:`\newcommand\DTF{{\Delta t}}` -:math:`\newcommand\IL[1]{\normalsize{#1}}` -:math:`\newcommand\MX[2]{\F{max}{#1,#2}}` -:math:`\newcommand\adr[1]{\F{adaptive}{#1}}` -:math:`\newcommand\clip[3]{\F{clip}{#1,#2,#3}}` -:math:`\newcommand\supply[1]{\F{supply}{#1}}` -:math:`\newcommand\iss[1]{\F{issuance}{#1}}` -:math:`\newcommand\isb[1]{\F{issuance_{block}}{#1}}` -:math:`\newcommand\tw{\Sigma_w}` -:math:`\newcommand\rw[2]{\F{reward_{#1}}{#2}}` -:math:`\newcommand\tip[2]{\F{tip_{#1}}{#2}}` -:math:`\newcommand\lbs[1]{\F{subsidy_{LB}}{#1}}` -:math:`\newcommand\exp[1]{\F{exp}{#1}}` -:math:`\newcommand{\vdf}{\mathit{VDF}}` - - -============================= -Adaptive Issuance and Staking -============================= - -This document describes Adaptive Issuance and Staking, two new experimental features that can only be activated on testnets, (referred hereafter as the Adaptive-Issuance/Staking proposal), which together constitute a major evolution of Tezos’ :doc:`Proof-of-Stake mechanism `. - -.. note:: - - For operational details about the new staking mechanism and its configuration, see `a new staking mechanism tutorial `__. - -.. _adaptive_issuance: -.. _adaptive_issuance_oxford: - -Adaptive Issuance -================= - -Adaptive Issuance is a novel mechanism regulating tez issuance in Tezos. - -The :doc:`Tezos economic protocol <./protocol>` issues new -tez via: - -- Participation rewards: incentives given to delegates for - :doc:`participation in consensus ` - and random seed generation. -- The :doc:`Liquidity Baking (LB) subsidy `. -- Protocol "invoices": lump sums of tez issued and allocated during - protocol migration. - -Participation rewards and the LB subsidy are regularly issued by the -protocol, whereas the value and recipients of invoices are defined -discretionarily by the developers of a protocol proposal. -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 -*regularly* issued tez (participation rewards and the LB subsidy, if -active) depends 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*. - -At the end of each blockchain :ref:`cycle `, the -regular issuance is adjusted, to nudge the staked funds ratio towards a -protocol-defined target (set at 50% in the Adaptive-Issuance/Staking proposal). Participation rewards -and the LB subsidy are recomputed to match that budget. When the staked -funds ratio decreases and diverges from the target, emission rates -increase, incentivizing participants to stake funds to re-approach the -target. Conversely, incentives decrease as the ratio increases beyond -the target. - -Adaptive issuance rate ----------------------- - -The :ref:`adaptive issuance rate ` determines, at the end -of cycle :math:`\IL{c}`, the issuance for cycle :math:`\IL{c + 5}`. The -adaptive issuance rate is the sum of a :ref:`static rate ` -and a :ref:`dynamic rate `. The final result is clipped to -ensure nominal emissions remain within :math:`\IL{[\minR,\ \maxR]}` (set -to [0.05%, 5%] in the Adaptive-Issuance/Staking proposal) of the total supply. - -.. figure:: adaptive_rate.png - - Figure 1. Adaptive issuance rate as a function of the staked funds ratio f. - -Figure 1 plots the nominal issuance rate and the static rate as a -function of the staked ratio :math:`\IL{f}`. In the graph above, we -picked the value 0.0075 (or 0.75%) for the dynamic rate, but this is -just an example and that number varies dynamically over time. - -The **static rate** is a static mechanism, which approximates `a Dutch -auction `__ to compute a -nominal issuance rate as a function of the staked funds ratio for a -given cycle. Its value decreases as the staked funds ratio increases, -and *vice versa*. - -.. _static_rate: -.. _static_rate_oxford: - -\ **STATIC RATE**\    Let :math:`\IL{f}` be the staked funds ratio at -the end of cycle :math:`\IL{c}`. Then, the **static rate** is defined -as: - -.. math:: - - static(f)=\sfr \tmult \frac{1}{f^2} - -The choice of :math:`\IL{\sfr}` as a scaling factor ensures that the -curve takes reasonable values for plausible staking ratios. Moreover, -assuming Adaptive Issuance is activated with a dynamic ratio of 0, and -at current staked funds ratio (that is, ~7.5% of the total supply), this -factor allows for a smooth transition from current issuance rate -(~4.6%). - -The **dynamic reward rate** adjusts itself over time based on the -distance between the staked funds ratio :math:`\IL{f}` and the 50% (±2%) -target ratio (:math:`\IL{\tc}` and :math:`\IL{\tr}` parameters below), -increasing when :math:`\IL{f}` < 48% and decreasing when :math:`\IL{f}` -> 52%, provided the total issuance rate is not hitting its lower or -upper limit. - -.. _dynamic_rate: -.. _dynamic_rate_oxford: - -\ **DYNAMIC RATE**\    The **dynamic rate** :math:`\IL{\dyn{c}}` is -defined at the end of cycle :math:`\IL{c}` as: - -.. math:: - - & \dyn{c} =\ \dyn{c -1} + \sgn{\tc - \F{f}{c}} \tmult \grf \tmult \dist{\F{f}{c}} \tmult \DTF \\ - & \dyn{c_0} =\ 0 - -:math:`\IL{\dyn{c}}` is then clipped to -:math:`\IL{\left[ 0, \maxR - \static{\F{f}{c}}\right]}`, ensuring that -:math:`\IL{\static{\F{f}{c}} + \dyn{c} \leq \maxR}`. - -In this formula: - -- :math:`\IL{c_0}` is the first cycle where Adaptive Issuance is - active. - -- Given a cycle :math:`\IL{c}`, :math:`\IL{\F{f}{c}}` denotes the - **staked funds ratio** at the end of the cycle, and - :math:`\IL{\dyn{c}}` the value of the dynamic rate computed in that - cycle. - -- :math:`\IL{\tc}` = 0.5 and :math:`\IL{\tr}` = 0.02 denote, - respectively, the **target staked funds ratio** and the **radius** of - the interval centered on the target ratio. - -- :math:`\IL{\grf}` = 0.01, controls the speed at which the dynamic - rate adjusts. The value is set so that a one percentage point - deviation of the staked funds ratio changes the dynamic rate by 0.01 - percentage points per day. - -- :math:`\IL{\dist{\F{f}{c}} = \MX{0}{\left|\F{f}{c} - \tc \right| - \tr}}` - denotes the (*absolute*) distance between the staked funds ratio - :math:`\IL{\F{f}{c}}` and the interval - :math:`\IL{\left[ \tc - \tr, \tc + \tr \right]}`. - -- :math:`\IL{\DTF = \frac{16384 \tmult 15}{86400} = 2.8\overline{444}}`, - denotes the minimal duration (in days) of a Tezos cycle, assuming all - 16384 blocks in the cycle are produced at the minimal allowed time – - that is, every 15 seconds. - -- :math:`\IL{\sgn{\tc - \F{f}{c}} = 1}` if - :math:`\IL{\F{f}{c} \leq \tc}` and :math:`-1` otherwise, denotes the - sign of the distance between the target ratio :math:`\IL{\tc}` and - the staked funds ratio :math:`\IL{\F{f}{c}}`. - -In a nutshell, :math:`\IL{\dyn{c}}` increases and decreases by an amount -proportional to the distance between the target rate and the interval -:math:`\IL{\left[ \tc - \tr, \tc + \tr \right]}`, while ensuring that -the adaptive issuance rate is kept within :math:`\IL{[\minR,\ \maxR]}` -bounds. - -Finally, as mentioned before, the nominal adaptive issuance rate [1]_ -for a cycle :math:`\IL{c + 5}` is defined as the sum of the static rate -and the dynamic rate, clipped to stay within 0.05% – 5% range. - -.. _adaptive_rate: -.. _adaptive_rate_oxford: - -\ **ADAPTIVE ISSUANCE RATE**\    Let :math:`\F{f}{c}` be the staked -funds ratio at the end of cycle :math:`\IL{c}`, the **adaptive issuance -rate** for cycle :math:`\IL{c+5}` is defined as: - -.. math:: - - \adr{c + 5} = \clip{\dyn{c} + \static{\F{f}{c}}}{\minR}{\maxR} - -.. _adaptive_rewards: -.. _adaptive_rewards_oxford: - -Adaptive rewards ----------------- - -Before adaptive issuance activation, participation rewards and -the LB subsidy are fixed values defined by protocol constants. With the -proposed mechanism, the :ref:`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 `. - -\ **ADAPTIVE ISSUANCE PER BLOCK**\    Let :math:`\supply{c}` be the -total supply at the end of cycle :math:`\IL{c}`, the **maximal issuance per -block** for cycle :math:`\IL{c+5}` is defined as: - -.. math:: - - \isb{c + 5} = \frac{\adr{c + 5}}{2102400} \tmult \supply{c} - -Where 2102400 = -:math:`\IL{\frac{365 \tmult 24 \tmult 60 \tmult 60}{15}}` is the maximal -number of blocks produced in a year, given a minimal block time of 15 -seconds. - -.. _reward_weights: -.. _reward_weights_oxford: - -\ **REWARD WEIGHTS**\    The Adaptive-Issuance/Staking proposal defines the weights for -participation rewards and the LB subsidy as: - -- Attestation (formerly, endorsing) rewards : 10,240. -- Fixed baking reward: 5,120. -- Bonus baking reward: 5,120. -- LB subsidy: 1,280. -- Nonce revelation tip: 1. -- VDF tip: 1. - -The total sum of all weights is :math:`\tw` = 21762. The total issuance -per block, :math:`\IL{\isb{c}}`, is distributed amongst the different -rewards in proportion to their weight. - -**Consensus rewards.** Since the adoption of Tenderbake, Tezos protocols -before the Adaptive-Issuance/Staking proposal have rewarded delegates :doc:`for their participation in -consensus ` -with the following rewards per block: - -- A fixed **baking** reward, given to the delegate which produced the - *payload* of the block (i.e. choosing transactions, and other - non-consensus operations). -- A variable, baking **bonus** reward given to the delegate which - produced the block included in the chain. This bonus is given for - including attestations, if their combined attesting power exceeds the - minimal threshold (two thirds of total slots). -- A *collective* **attestation** reward, for attesting block proposals, - distributed at the end of the cycle to the delegates selected in the - consensus committees for that cycle, proportionnaly to their expected - participation. - -We refer to :doc:`the consensus page ` for -further insight on the pre-requisites and distribution of these rewards. -Here, we derive the new formulas which compute their values *per block* -for a cycle :math:`\IL{c}`: - -.. math:: - - & \rw{baking}{c} = \rw{bonus}{c} = \frac{5120}{\tw} \tmult \isb{c} - - & \rw{attestation}{c} = \frac{10240}{\tw} \tmult \isb{c} - -Note that these formulas change the value of available rewards, but not -why and how they are awarded. Hence, :math:`\IL{\rw{bonus}{c}}` still -denotes the maximal value for this reward: the actual reward issued -depends on the total number of attested slots in a block. Similarly, -:math:`\IL{\rw{attestation}{c}}` is also a maximal value per block, -as the basis for computing the share of selected delegate at the end of -the cycle, the actual allocation of the rewards -being subject to the existing participation conditions. - -**Nonce and VDF revelation tips.** The rewards allocated to delegates -for contributing to :ref:`random seed generation ` -(that is for, revealing nonce seeds and posting VDF proofs) are not paid -each block, but rather every 128 blocks. The adjusted formulas result: - -.. math:: - - \tip{\vdf}{c} = \tip{nr}{c} = 128 \tmult \frac{1}{\tw} \tmult \isb{c} - -**Liquidity baking subsidy.** The :doc:`LB -subsidy ` per block is determined by the following formula: - -.. math:: - - \lbs{c} = \frac{1280}{\tw} \tmult \isb{c} - -Note that while the subsidy is issued **only if** the feature is on, its -weight is always counted in the computation of :math:`\IL{\tw}`. In -other words, the budget for the LB subsidy is always allocated, -regardless of whether it is issued or not. - -The Adaptive-Issuance/Staking proposal implements a new `RPC -endpoint `__, -``/issuance/expected_issuance``, which reports the precomputed values of -all participation rewards and the LB subsidy, for the cycle -corresponding to the queried block level, and the next 4 cycles. - -.. _new_staking: -.. _new_staking_oxford: - -New Staking mechanism -===================== - -Staking is an evolution of the existing Tezos :doc:`Liquid Proof-of-Stake -mechanism `. It -introduces a new role for network participants, called **staker**, -complementary to the existing :ref:`delegate ` -(also known as *baker*) and *delegator* roles. A staker must also be a -*delegator* – that is, they must first choose a delegate. - -When stakers **stake**\ funds towards a delegate’s **staking** -**balance**, the associated **baking** and **voting powers** accrue to -that delegate. Similarly to how delegated funds work, staked funds -remain within the staker’s account at all times. - -Staked and delegated funds **have different weights** in the computation -of delegates’ baking and voting powers: staked funds (both external -stakes by stakers and the delegate’s own) count **twice** as much as -delegated funds. - -Unlike delegated funds, staked funds are considered to contribute to the -security deposit associated with their chosen delegate. Thus, they are -subject to :ref:`slashing ` if -the delegate misbehaves by :ref:`double-signing ` -block proposals or consensus operations, and are subject to the same -withdrawal delays – colloquially, they are "frozen". - -Stakers are slashed proportionally to their contribution to the -delegate’s staking balance. To simplify slashing, double-baking -penalties are now proportional to staked funds: instead of the previous -fixed sum of 640 tez they are now set to 10% of the delegate’s stake. -Moreover, denunciation rewards (both for double-baking and -double-attestations) are reduced from one half to one seventh of the -slashed funds. The chosen value prevents adversarial delegates from -abusing the slashing mechanism for profit at the expense of their -stakers. - -*Delegates* :ref:`configure their staking -policy ` by setting staking parameters -which regulate whether they accept stakers (the default being to reject -them), and if so, up to which fraction of their total staking balance. -They can also configure which proportion of the staking rewards is set -to accrue to their own staked balance versus their unfrozen, spendable -balance. As :ref:`participation rewards ` are paid to -the staked balance, and 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 -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 -7 cycles (cf. :ref:`Staked funds management `). - -A new user interface is provided for delegates and stakers to interact -with the mechanism. It is based on four *pseudo-operations*: ``stake``, -``unstake``, ``finalize_unstake``, and ``set_delegate_parameters``. -Pseudo-operations are self-transfers: a transfer operation where the -destination matches the source – each involving a special entry-point of -the same name introduced for :ref:`implicit 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 -*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 -cannot stake funds (they can of course still delegate them). - -.. _staking_policy_configuration: -.. _staking_policy_configuration_oxford: - -Staking policy configuration ----------------------------- - -*Delegates* can configure their staking policy by setting the following -parameters: - -- ``edge_of_baking_over_staking``: a ratio between 0 and 1, whose - default value is 1. This parameter determines the fraction of the - rewards that accrue to the delegate’s liquid spendable balance – the - remainder accrues to frozen stakes. -- ``limit_of_staking_over_baking``: a non-negative number, denoting the - maximum portion of external stake by stakers over the delegate’s own - staked funds. It defaults to 0 – which entails that delegates do not - accept external stakes by default. It is moreover capped by a global - constant, set to 5 in the Adaptive-Issuance/Staking proposal, which ensures the baker controls a - significant part of the stake. - -Delegates can modify these staking parameters at all times, using the -``set_delegate_parameters`` pseudo-operation: that is, by transferring 0 -tez to their own ``set_delegate_parameters`` entry-point. The chosen values for both -parameters need to be supplied. The new parameters are then applied -``PRESERVED_CYCLES`` (currently 5) cycles later. - -:: - - octez-client transfer 0 from to --entrypoint set_delegate_parameters --arg "Pair (Pair Unit)" - -or more conveniently:: - - octez-client set delegate parameters for --limit-of-staking-over-baking --edge-of-baking-over-staking - -**On overstaking and overdelegation.** Note that if a delegate’s -``limit_of_staking_over_baking`` is exceeded (that is, the delegate is -*overstaked*), the exceeding stake is automatically considered a -*delegation* for the delegate’s baking and voting power calculation, but -it does remain slashable. The new mechanism does not alter -*overdelegation* (delegated funds beyond 9 times the delegate’s own -stake) nor its consequence on voting and baking powers. That is, -overdelegated funds are not counted towards a delegate baking power, but -they do increase their voting power. - -.. _staked_funds_management: -.. _staked_funds_management_oxford: - -Staked funds management ------------------------ - -Stakers (and delegates) can use the ``stake``, ``unstake``, and -``finalize_unstake`` pseudo-operations to control their stakes. Figure -2 illustrates their effect on a staker’s funds. Note that -while these pseudo-operations change the *state* of the involved funds, -they remain otherwise within the staker’s account at all times. - -.. figure:: staked_funds_transitions.png - - Figure 2: staked funds management using pseudo-operations. - -To *stake* funds, a delegator uses the ``stake`` pseudo-operation, -transferring the chosen amount of **spendable** tez to their own -``stake`` entry-point. The **staked** tez will then be frozen and -contribute to their chosen delegate’s staking balance. Note that the -``stake`` pseudo-operation will fail if the sender account is not -*delegated*. - -:: - - octez-client transfer from to --entrypoint stake - -or more conveniently:: - - octez-client stake for - -To *unstake* funds, a staker first submits an unstake request with the -``unstake`` pseudo-operation. This is implemented by transferring the -chosen amount in tez to their ``unstake`` entry-point:: - - octez-client transfer from to --entrypoint unstake - -or more conveniently:: - - octez-client unstake for - -The requested amount will be **unstaked** but will remain **frozen**. -After 7 cycles, unstaked frozen tokens are no longer considered at stake -nor slashable. They are said then to be both **unstaked** and -**finalizable**. - -A staker can retrieve all unstaked and finalizable tokens at any time, -making them spendable again. This is done using the ``finalize_unstake`` -entrypoint -– that is, by transferring 0 tez to their -``finalize_unstake`` entry-point:: - - octez-client transfer 0 from to --entrypoint finalize_unstake - -or more conveniently:: - - octez-client finalize unstake for - - In some circumstances, unstake and finalize can be done implicitly: any call - to ``stake`` or ``unstake`` will implicitly finalize all currently finalizable pending - unstake requests. Also, as we will see next, change of delegate triggers an - unstake operation. - -Change of delegate ------------------- - -When a staker changes its delegate, the operation will trigger an implicit unstake -request for the full frozen deposit of the staker. - -As long as the unstake request is not finalized, the frozen tokens will continue -to be delegated to the old delegate, however the spending -balance of the account is accounted in the new delegate's stake. -It will not be possible to stake with the new delegate as long as there are -unfinalizable unstake request for token staked with the old delegate. - -.. _feature_activation: -.. _feature_activation_oxford: - -Feature activation vs protocol activation -========================================= - -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. - -In particular, the following changes will require additional approval -from delegates via separate feature activation vote mechanism: - -- Adaptive issuance – including notably the changes to the computation - of consensus rewards and the LB subsidy. -- Ability for *delegators* to become *stakers* – until feature - activation delegates continue to be the only participants who can - **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 - deposit freezing. On protocol activation, each delegate’s stake is - derived from the frozen deposits at the end of the last cycle of - Nairobi. -- The changes in slashing penalties (double-baking penalties are set to - 10% of the staked funds) and denunciation rewards (they amount to one - seventh of slashed funds). -- Changes to protocol constants. Note that this entails calculating - participation rewards and the LB subsidy using the weight-based - formulas, but these are defined so that they match the previous - values when :ref:`Adaptive Issuance ` is not active. - -Activation Vote ---------------- - -We highlight the following principles behind the feature activation vote -mechanism: - -- If and when the Adaptive-Issuance/Staking proposal activates, delegates can start voting for (**On**) - or against (**Off**) the feature activation of the changes listed - above in each block they bake. They can also abstain with a **Pass** - vote. -- These votes are cast by block-producing delegates, and are included - in block headers. -- Participation is not mandatory, defaulting to **Pass** in the absence - of signaling. -- The feature activation vote has two phases: a *Voting* phase and a - subsequent *Adoption* phase. -- The *Voting* phase is driven by an Exponential moving average (EMA) - whose *half-life* is 2 weeks. That is, it takes two weeks for the EMA - to raise from 0% to 50% assuming only **On**\ votes are cast. -- The target threshold is a supermajority of 80% of **On** votes over - **On plus Off** votes. -- There is no time limit or fixed duration for the Voting phase. It - continues as long as the threshold is not met. There is no *quorum* - either, the lack of participation (reified as **Pass** votes) is not - taken into account by the EMA, and hence only affects the time - required to reach the threshold. -- If the threshold is met, the Voting phase will complete at the end of - the current cycle, and the Adoption phase will start at the beginning - of the following cycle. -- The Adoption phase lasts 7 cycles. The beginning of the cycle - following the end of the Adoption phase activates the guarded - features. -- There is **no automatic deactivation** of the guarded features once - in (and after) the Adoption phase – subsequent votes continue to be - counted towards an updated EMA, but without any further effect. - -**NB** In the implementation in the Adaptive-Issuance/Staking proposal, the issuance rate -is computed 5 cycles in advance. Thus, in the first 5 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 - compounded at every cycle. diff --git a/docs/oxford/adaptive_rate.png b/docs/oxford/adaptive_rate.png deleted file mode 100644 index c404ad23a049658c4e923843e19e53c3c65298e5..0000000000000000000000000000000000000000 Binary files a/docs/oxford/adaptive_rate.png and /dev/null differ diff --git a/docs/oxford/liquidity_baking.rst b/docs/oxford/liquidity_baking.rst index 316905105c85bd2f1027251c364dfd0ae6bdba8c..20a4a3ae352f69279e7925685efd1c0ae9a0352c 100644 --- a/docs/oxford/liquidity_baking.rst +++ b/docs/oxford/liquidity_baking.rst @@ -32,8 +32,6 @@ CPMM contract, and the CPMM's ``%default`` entrypoint is called to update the CPMM contract is 1/16th of the rewards for a block of round 0 with all attestations; currently these rewards are 20 tez per block so the amount that is sent to the CPMM contract is 1.25 tez per block. -If the :ref:`adaptive issuance ` feature were to be activated, -the subsidy would be adjusted by the adaptive issuance coefficient. So the credits to the CPMM contract can be accounted for by indexers, they are included in block metadata as a balance update with a new constructor for ``update_origin``, ``Subsidy``. diff --git a/docs/oxford/proof_of_stake.rst b/docs/oxford/proof_of_stake.rst index be85d32487fbc242cb69140df5658d137ef7fb29..5097980927219e015cb8bc92a7dab57fcddba9c1 100644 --- a/docs/oxford/proof_of_stake.rst +++ b/docs/oxford/proof_of_stake.rst @@ -64,8 +64,8 @@ transfer the delegate's free balance to an arbitrary account. In :doc:`relevant like ``/chains/main/blocks/head/helpers/baking_rights``, both the delegate's manager and consensus keys are listed. -On test-network only, if the :ref:`adaptive issuance ` -feature is activated, it grants delegators the ability to become +On test-network only, if the adaptive issuance feature is activated, +it grants delegators the ability to become 'stakers' by placing security deposits. These deposits would contribute to their delegate's stake and could be subject to slashing penalties if their delegate misbehaves. The staking power of funds placed by stakers and delegates is twice @@ -194,8 +194,6 @@ found in the `whitepaper `_. -The adaptive issuance experimental feature :ref:`documentation `. - Other presentation of the Tezos' proof-of-stake mechanism can be found in the `Open Tezos entry `_. diff --git a/docs/oxford/protocol.rst b/docs/oxford/protocol.rst index c6a22a3de23785acd93f18e4f6fb71a65e6c90c5..8b582d40b0c3fa275b3a3263db321e0bab012240 100644 --- a/docs/oxford/protocol.rst +++ b/docs/oxford/protocol.rst @@ -106,8 +106,3 @@ Sapling, etc), and some details about its implementation. :maxdepth: 2 tickets - -.. toctree:: - :maxdepth: 2 - - adaptive_issuance diff --git a/docs/oxford/randomness_generation.rst b/docs/oxford/randomness_generation.rst index 95dbe1ba1420bc01bb416686f9e4879085942e5f..3c0f81c32796c3c13c4516e01ff585d5c7bd24be 100644 --- a/docs/oxford/randomness_generation.rst +++ b/docs/oxford/randomness_generation.rst @@ -115,8 +115,7 @@ bitstring is the hash of the concatenation of the previous bitstring with the iterated revealed nonce. A *nonce revelation* is an operation and multiple nonce revelations can thus be -included in a block. A reward ``SEED_NONCE_REVELATION_TIP``, :ref:`potentially adjusted -by the adaptive issuance coefficient `, is given for +included in a block. A reward ``SEED_NONCE_REVELATION_TIP`` is given for including a revelation. Revelations are free operations which do not compete with transactions for block space. Up to ``MAX_ANON_OPS_PER_BLOCK`` revelations, wallet activations and denunciations can be contained in any given block. @@ -137,9 +136,8 @@ solution: its value is set to be the hash of the RANDAO output and the VDF solution. -A *VDF revelation* is an operation. A reward ``SEED_NONCE_REVELATION_TIP``, -:ref:`potentially adjusted by the adaptive issuance coefficient -`, is given for the first correct VDF revelation, +A *VDF revelation* is an operation. A reward ``SEED_NONCE_REVELATION_TIP`` +is given for the first correct VDF revelation, subsequent VDF revelation operations being discarded. .. _rg_constants: diff --git a/docs/oxford/staked_funds_transitions.png b/docs/oxford/staked_funds_transitions.png deleted file mode 100644 index 46a3c022d1c49264f065115a16d69879f812907a..0000000000000000000000000000000000000000 Binary files a/docs/oxford/staked_funds_transitions.png and /dev/null differ diff --git a/docs/paris/adaptive_issuance.rst b/docs/paris/adaptive_issuance.rst index 34f5d2c50035e1e912e3de1bc79fdac615d0140a..8dae82ab5d3a7f49589618104e91ee492b901975 100644 --- a/docs/paris/adaptive_issuance.rst +++ b/docs/paris/adaptive_issuance.rst @@ -19,7 +19,6 @@ :math:`\newcommand\tw{\Sigma_w}` :math:`\newcommand\rw[2]{\F{reward_{#1}}{#2}}` :math:`\newcommand\tip[2]{\F{tip_{#1}}{#2}}` -:math:`\newcommand\lbs[1]{\F{subsidy_{LB}}{#1}}` :math:`\newcommand\exp[1]{\F{exp}{#1}}` :math:`\newcommand{\vdf}{\mathit{VDF}}` @@ -28,7 +27,7 @@ Adaptive Issuance and Staking ============================= -This document describes Adaptive Issuance and Staking, two new features experimented in the Alpha protocol (referred hereafter as the Adaptive-Issuance/Staking proposal), which together constitute a major evolution of Tezos’ :doc:`Proof-of-Stake mechanism `. +This document describes Adaptive Issuance and Staking, two new features (referred hereafter as the Adaptive-Issuance/Staking proposal) which together constitute a major evolution of Tezos’ :doc:`Proof-of-Stake mechanism `. .. note:: @@ -60,8 +59,7 @@ constants. The Adaptive-Issuance/Staking proposal introduces the possibility to activate Adaptive Issuance: a mechanism where the amount of -*regularly* issued tez (participation rewards and the LB subsidy, if -active) depends on the global **staked funds ratio** – that is, the +participation rewards depends 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*. @@ -69,7 +67,7 @@ to encourage participants to stake and produce blocks, but *no more*. At the end of each blockchain :ref:`cycle `, the regular issuance is adjusted, to nudge the staked funds ratio towards a protocol-defined target (set at 50% in the Adaptive-Issuance/Staking proposal). Participation rewards -and the LB subsidy are recomputed to match that budget. When the staked +are recomputed to match that budget. When the staked funds ratio decreases and diverges from the target, emission rates increase, incentivizing participants to stake funds to re-approach the target. Conversely, incentives decrease as the ratio increases beyond @@ -79,7 +77,7 @@ Adaptive issuance rate ---------------------- The :ref:`adaptive issuance rate ` determines, at the end -of cycle :math:`\IL{c}`, the issuance for cycle :math:`\IL{c + 5}`. The +of cycle :math:`\IL{c}`, the issuance for cycle :math:`\IL{c + 3}`. The adaptive issuance rate is the sum of a :ref:`static rate ` and a :ref:`dynamic rate `. The final result is clipped to ensure nominal emissions remain within :math:`\IL{[\minR,\ \maxR]}` (set @@ -179,26 +177,26 @@ the adaptive issuance rate is kept within :math:`\IL{[\minR,\ \maxR]}` bounds. Finally, as mentioned before, the nominal adaptive issuance rate [1]_ -for a cycle :math:`\IL{c + 5}` is defined as the sum of the static rate +for a cycle :math:`\IL{c + 3}` is defined as the sum of the static rate and the dynamic rate, clipped to stay within 0.05% – 5% range. .. _adaptive_rate_paris: \ **ADAPTIVE ISSUANCE RATE**\    Let :math:`\F{f}{c}` be the staked funds ratio at the end of cycle :math:`\IL{c}`, the **adaptive issuance -rate** for cycle :math:`\IL{c+5}` is defined as: +rate** for cycle :math:`\IL{c+3}` is defined as: .. math:: - \adr{c + 5} = \clip{\dyn{c} + \static{\F{f}{c}}}{\minR}{\maxR} + \adr{c + 3} = \clip{\dyn{c} + \static{\F{f}{c}}}{\minR}{\maxR} .. _adaptive_rewards_paris: Adaptive rewards ---------------- -Before adaptive issuance activation, participation rewards and -the LB subsidy are fixed values defined by protocol constants. With the +Before adaptive issuance activation, participation rewards +are fixed values defined by protocol constants. With the proposed mechanism, the :ref:`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 @@ -206,30 +204,29 @@ rewards, in proportion to their relative :ref:`weights `. \ **ADAPTIVE ISSUANCE PER BLOCK**\    Let :math:`\supply{c}` be the total supply at the end of cycle :math:`\IL{c}`, the **maximal issuance per -block** for cycle :math:`\IL{c+5}` is defined as: +block** for cycle :math:`\IL{c+3}` is defined as: .. math:: - \isb{c + 5} = \frac{\adr{c + 5}}{2102400} \tmult \supply{c} + \isb{c + 3} = \frac{\adr{c + 3}}{3153600} \tmult \supply{c} -Where 2102400 = -:math:`\IL{\frac{365 \tmult 24 \tmult 60 \tmult 60}{15}}` is the maximal -number of blocks produced in a year, given a minimal block time of 15 +Where 3153600 = +:math:`\IL{\frac{365 \tmult 24 \tmult 60 \tmult 60}{10}}` is the maximal +number of blocks produced in a year, given a minimal block time of 10 seconds. .. _reward_weights_paris: \ **REWARD WEIGHTS**\    The Adaptive-Issuance/Staking proposal defines the weights for -participation rewards and the LB subsidy as: +participation rewards as: - Attestation (formerly, endorsing) rewards : 10,240. - Fixed baking reward: 5,120. - Bonus baking reward: 5,120. -- LB subsidy: 1,280. - Nonce revelation tip: 1. - VDF tip: 1. -The total sum of all weights is :math:`\tw` = 21762. The total issuance +The total sum of all weights is :math:`\tw` = 20482. The total issuance per block, :math:`\IL{\isb{c}}`, is distributed amongst the different rewards in proportion to their weight. @@ -272,30 +269,18 @@ being subject to the existing participation conditions. **Nonce and VDF revelation tips.** The rewards allocated to delegates for contributing to :ref:`random seed generation ` -(that is for, revealing nonce seeds and posting VDF proofs) are not paid +(that is, for revealing nonce seeds and posting VDF proofs) are not paid each block, but rather every 192 blocks. The adjusted formulas result: .. math:: \tip{\vdf}{c} = \tip{nr}{c} = 192 \tmult \frac{1}{\tw} \tmult \isb{c} -**Liquidity baking subsidy.** The :doc:`LB -subsidy ` per block is determined by the following formula: - -.. math:: - - \lbs{c} = \frac{1280}{\tw} \tmult \isb{c} - -Note that while the subsidy is issued **only if** the feature is on, its -weight is always counted in the computation of :math:`\IL{\tw}`. In -other words, the budget for the LB subsidy is always allocated, -regardless of whether it is issued or not. - The Adaptive-Issuance/Staking proposal implements a new `RPC -endpoint `__, +endpoint `__, ``/issuance/expected_issuance``, which reports the precomputed values of -all participation rewards and the LB subsidy, for the cycle -corresponding to the queried block level, and the next 4 cycles. +all participation rewards, for the cycle +corresponding to the queried block level, and the next 3 cycles. .. _new_staking_paris: @@ -309,7 +294,7 @@ complementary to the existing :ref:`delegate ` (also known as *baker*) and *delegator* roles. A staker must also be a *delegator* – that is, they must first choose a delegate. -When stakers **stake**\ funds towards a delegate’s **staking** +When stakers **stake** funds towards a delegate’s **staking** **balance**, the associated **baking** and **voting powers** accrue to that delegate. Similarly to how delegated funds work, staked funds remain within the staker’s account at all times. @@ -329,7 +314,7 @@ withdrawal delays – colloquially, they are "frozen". Stakers are slashed proportionally to their contribution to the delegate’s staking balance. To simplify slashing, double-baking penalties are now proportional to staked funds: instead of the previous -fixed sum of 640 tez they are now set to 10% of the delegate’s stake. +fixed sum of 640 tez they are now set to 5% of the delegate’s stake. Moreover, denunciation rewards (both for double-baking and double-attestations) are reduced from one half to one seventh of the slashed funds. The chosen value prevents adversarial delegates from @@ -340,10 +325,10 @@ stakers. policy ` by setting staking parameters which regulate whether they accept stakers (the default being to reject them), and if so, up to which fraction of their total staking balance. -They can also configure which proportion of the staking rewards is set -to accrue to their own staked balance versus their unfrozen, spendable -balance. As :ref:`participation rewards ` are paid to -the staked balance, and automatically shared between delegates and their +They can also configure which proportion of the staking rewards from other stakers is set +to accrue to their own staked balance instead. +As :ref:`participation rewards ` are +automatically shared between delegates and their stakers, delegates can use this parameter to collect an *edge* from the rewards attributable to their stakers. @@ -351,7 +336,7 @@ If and when the Adaptive-Issuance/Staking proposal activates, freezing and unfre 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 -7 cycles (cf. :ref:`Staked funds management `). +4 cycles (cf. :ref:`Staked funds management `). A new user interface is provided for delegates and stakers to interact with the mechanism. It is based on four *pseudo-operations*: ``stake``, @@ -379,8 +364,8 @@ parameters: - ``edge_of_baking_over_staking``: a ratio between 0 and 1, whose default value is 1. This parameter determines the fraction of the - rewards that accrue to the delegate’s liquid spendable balance – the - remainder accrues to frozen stakes. + rewards that accrue to the delegate's frozen deposit – the + remainder is shared among its stakers. - ``limit_of_staking_over_baking``: a non-negative number, denoting the maximum portion of external stake by stakers over the delegate’s own staked funds. It defaults to 0 – which entails that delegates do not @@ -404,7 +389,7 @@ or more conveniently:: **On overstaking and overdelegation.** Note that if a delegate’s ``limit_of_staking_over_baking`` is exceeded (that is, the delegate is -*overstaked*), the exceeding stake is automatically considered a +*overstaked*), the exceeding stake is automatically considered as *delegation* for the delegate’s baking and voting power calculation, but it does remain slashable. The new mechanism does not alter *overdelegation* (delegated funds beyond 9 times the delegate’s own @@ -453,7 +438,7 @@ or more conveniently:: octez-client unstake for The requested amount will be **unstaked** but will remain **frozen**. -After 7 cycles, unstaked frozen tokens are no longer considered at stake +After 4 cycles, unstaked frozen tokens are no longer considered at stake nor slashable. They are said then to be both **unstaked** and **finalizable**. @@ -468,10 +453,10 @@ or more conveniently:: octez-client finalize unstake for - In some circumstances, unstake and finalize can be done implicitly: any call - to ``stake`` or ``unstake`` will implicitly finalize all currently finalizable pending - unstake requests. Also, as we will see next, change of delegate triggers an - unstake operation. +In some circumstances, unstake and finalize can be done implicitly: any call +to ``stake`` or ``unstake`` will implicitly finalize all currently finalizable pending +unstake requests. Also, as we will see next, change of delegate triggers an +unstake operation. Change of delegate ------------------ @@ -499,7 +484,7 @@ In particular, the following changes will require additional approval from delegates via separate feature activation vote mechanism: - Adaptive issuance – including notably the changes to the computation - of consensus rewards and the LB subsidy. + of consensus rewards. - Ability for *delegators* to become *stakers* – until feature activation delegates continue to be the only participants who can **stake** funds. @@ -516,10 +501,10 @@ activation: derived from the frozen deposits at the end of the last cycle of Nairobi. - The changes in slashing penalties (double-baking penalties are set to - 10% of the staked funds) and denunciation rewards (they amount to one + 5% of the staked funds) and denunciation rewards (they amount to one seventh of slashed funds). - Changes to protocol constants. Note that this entails calculating - participation rewards and the LB subsidy using the weight-based + participation rewards using the weight-based formulas, but these are defined so that they match the previous values when :ref:`Adaptive Issuance ` is not active. @@ -541,7 +526,7 @@ mechanism: subsequent *Adoption* phase. - The *Voting* phase is driven by an Exponential moving average (EMA) whose *half-life* is 2 weeks. That is, it takes two weeks for the EMA - to raise from 0% to 50% assuming only **On**\ votes are cast. + to raise from 0% to 50% assuming only **On** votes are cast. - The target threshold is a supermajority of 80% of **On** votes over **On plus Off** votes. - There is no time limit or fixed duration for the Voting phase. It @@ -552,7 +537,7 @@ mechanism: - If the threshold is met, the Voting phase will complete at the end of the current cycle, and the Adoption phase will start at the beginning of the following cycle. -- The Adoption phase lasts 7 cycles. The beginning of the cycle +- The Adoption phase lasts 5 cycles. The beginning of the cycle following the end of the Adoption phase activates the guarded features. - There is **no automatic deactivation** of the guarded features once @@ -560,7 +545,7 @@ mechanism: counted towards an updated EMA, but without any further effect. **NB** In the implementation in the Adaptive-Issuance/Staking proposal, the issuance rate -is computed 5 cycles in advance. Thus, in the first 5 cycles where is +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. diff --git a/docs/paris/liquidity_baking.rst b/docs/paris/liquidity_baking.rst index b52121a3abaacdf48cbfdfff026f432c9baf9121..bddf4082897b5a1e947121eaadcdf030e7e2f407 100644 --- a/docs/paris/liquidity_baking.rst +++ b/docs/paris/liquidity_baking.rst @@ -32,8 +32,6 @@ CPMM contract, and the CPMM's ``%default`` entrypoint is called to update the CPMM contract is 1/16th of the rewards for a block of round 0 with all attestations; currently these rewards are 13.33 tez per block so the amount that is sent to the CPMM contract is 0.83 tez per block. -If the :ref:`adaptive issuance ` feature were to be activated, -the subsidy would be adjusted by the adaptive issuance coefficient. So the credits to the CPMM contract can be accounted for by indexers, they are included in block metadata as a balance update with a new constructor for ``update_origin``, ``Subsidy``. diff --git a/docs/paris/proof_of_stake.rst b/docs/paris/proof_of_stake.rst index f77d062637b354de7942497081df048f72a2b448..ba60146072b8ba986babba6d9ead5fad0df2f199 100644 --- a/docs/paris/proof_of_stake.rst +++ b/docs/paris/proof_of_stake.rst @@ -64,7 +64,7 @@ transfer the delegate's free balance to an arbitrary account. In :doc:`relevant like ``/chains/main/blocks/head/helpers/baking_rights``, both the delegate's manager and consensus keys are listed. -On test-network only, if the :ref:`adaptive issuance ` +On test-network only, if the :ref:`adaptive issuance ` feature is activated, it grants delegators the ability to become 'stakers' by placing security deposits. These deposits would contribute to their delegate's stake and could be subject to slashing penalties if their delegate @@ -172,7 +172,7 @@ Proof-of-stake parameters * - ``BLOCKS_PER_CYCLE`` - 24576 blocks * - ``CONSENSUS_RIGHTS_DELAY`` - - 5 cycles + - 2 cycles * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``MINIMAL_FROZEN_STAKE`` @@ -189,7 +189,7 @@ found in the `whitepaper `_. -The adaptive issuance experimental feature :ref:`documentation `. +The adaptive issuance experimental feature :ref:`documentation `. Other presentations of the Tezos' proof-of-stake mechanism can be found in the diff --git a/docs/paris/staked_funds_transitions.png b/docs/paris/staked_funds_transitions.png index 46a3c022d1c49264f065115a16d69879f812907a..96a15d92c2c2480234c15a0b586a3a01ea3e2b3d 100644 Binary files a/docs/paris/staked_funds_transitions.png and b/docs/paris/staked_funds_transitions.png differ diff --git a/src/proto_alpha/lib_protocol/adaptive_issuance_services.ml b/src/proto_alpha/lib_protocol/adaptive_issuance_services.ml index 36885d778f81ff68882a743d5b66b408013df72f..59d1f473dc5c43fd14ab60991fd7a2ece17888ff 100644 --- a/src/proto_alpha/lib_protocol/adaptive_issuance_services.ml +++ b/src/proto_alpha/lib_protocol/adaptive_issuance_services.ml @@ -148,7 +148,7 @@ module S = struct RPC_service.get_service ~description: "Returns the expected issued tez for the provided block and the next \ - five cycles" + three cycles" ~query:RPC_query.empty ~output:(Data_encoding.list expected_rewards_encoding) RPC_path.(path / "expected_issuance")