diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index bdbf588d40167afe192dc89b564c0a8c4f0ee543..5af72504f61c46d4a16c99bf914ec4950e4b67a9 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -196,7 +196,7 @@ proposer (that is, the one that signs and injects the block): that's always true for blocks at round 0; however, in case of re-proposals this is not necessarily the case (see the algorithm description above). -Fees are given to the payload producer immediately, that is, they are +Fees are allocated to the payload producer's available balance immediately, that is, they are already reflected in the blockchain state obtained after applying the injected block. @@ -216,24 +216,24 @@ the included attestations represent. The bonus is also distributed immediately. The attesting rewards are distributed at the end of the cycle. -The attesting reward may be received even if not all of the validator's attestations are included in a block and is proportional to the validator's active stake (in other words, to its *expected* number of validator slots, and not its actual number of slots). +Attesting rewards may be received even if not all of the validator's attestations are included in the cycle's blocks and is proportional to the validator's active stake (in other words, to its *expected* number of validator slots, and not its actual number of slots). However, two conditions must be met: -- the validator has revealed its nonce, and +- the validator has revealed its nonces, and - the validator has been present during the cycle. Not giving rewards in case of missing revelations is not new as it is :ref:`adapted` from Emmy*. The second condition is new. We say that a delegate is *present* during a cycle if the attesting power (that is, the number of validator slots at the -corresponding level) of all the attestations included by the delegate during the +corresponding level) of all the delegate's attestations included during the cycle represents at least ``MINIMAL_PARTICIPATION_RATIO`` of the delegate's expected number of 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, before Adaptive Issuance, we first fix the total reward per +Regarding the concrete values for rewards, before :doc:`adaptive_issuance`, we first fix the total reward per level, call it ``total_rewards``, to ``80 / blocks_per_minute`` 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. +Assuming ``blocks_per_minute = 7.5``, ``total_rewards`` is 10.67 tez. With :doc:`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`` @@ -279,7 +279,7 @@ Slashing ^^^^^^^^ Like in Emmy*, not revealing nonces and double signing are punishable. If a -validator does not reveal its nonce by the end of the cycle, it does not receive +validator does not reveal its nonces by the end of the cycle, it does not receive 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 diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 42a76dbc80b86550a3f38b54b88d2253a4e75651..67245d0727e058453dc3eb6ed44c96880d2ca23e 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -29,9 +29,8 @@ Subsidy At every block in the chain, a small amount of tez is minted and credited to the CPMM contract, and the CPMM's ``%default`` entrypoint is called to update the ``xtz_pool`` balance in its storage. The amount that is minted and sent to 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. +CPMM contract for each block is a protocol constant (``LIQUIDITY_BAKING_SUBSIDY``), defining a fixed target rate of 5 tez/minute. +One can easily compute the value of the per block subsidy by taking into account the minimal block time, under the assumption that all blocks are produced at round 0. 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``. @@ -53,12 +52,12 @@ the subsidy, and ``Pass`` to abstain. ``e[n+1] = (1999 * e[n] // 2000)`` if the flag is set to ``On``. When computing ``e[n+1]``, the division is rounded toward ``1_000_000_000``. -If at any block ``e[n] >= 1_000_000_000`` then it means that an +If at any block ``e[n] >= LIQUIDITY_BAKING_EMA_THRESHOLD`` (currently ``1_000_000_000``) then it means that an exponential moving average with a window size on the order of two thousand non-abstaining blocks has had roughly at least a half of the blocks demanding the end of the subsidy. If that is the case, the subsidy is halted but can be reactivated if for some later block -``e[n] < 1_000_000_000``. +``e[n] < LIQUIDITY_BAKING_EMA_THRESHOLD``. For indicative purposes, if among the non-abstaining blocks a fraction ``f`` of blocks use it to request ending the subsidy, the threshold is diff --git a/docs/alpha/staking.rst b/docs/alpha/staking.rst index bc64aa1cfddca32ca969066d88ddd86f63d215bf..e253897df1e505c1616653196b2731a228f2e1ae 100644 --- a/docs/alpha/staking.rst +++ b/docs/alpha/staking.rst @@ -85,7 +85,7 @@ parameters: default value is 1. This parameter determines the fraction of the 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 +- ``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 diff --git a/docs/index.rst b/docs/index.rst index 2ebdf41f70670e62d4ab73276744407752f286a0..4c4a9eff8ec972a8c7497463d27f5952eaf1bff1 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -204,7 +204,6 @@ Platform developers are also provided reference materials for internal APIs of O :hidden: releases/releases - releases/version-20 releases/version-21 releases/history diff --git a/docs/releases/history.rst b/docs/releases/history.rst index 6a898586f239bc833e8c0b06ceac190736079e1c..8609f76548443eb5d15a56fb8b5860b492f97402 100644 --- a/docs/releases/history.rst +++ b/docs/releases/history.rst @@ -7,6 +7,11 @@ The following pages describe the former Octez releases in reverse chronological All the releases N.x sharing a same major version number N are grouped under a same page, named after the more recent release in that series. +.. toctree:: + :maxdepth: 2 + + version-20 + .. toctree:: :maxdepth: 2 diff --git a/docs/releases/version-21.rst b/docs/releases/version-21.rst index 33fef10998a95f83fc7ff296ec370ef02e5b02e8..6db999d459c51e93f077d539b8fdadf349fa4afc 100644 --- a/docs/releases/version-21.rst +++ b/docs/releases/version-21.rst @@ -104,6 +104,23 @@ Octez v21.0 introduces several UX improvements to the :doc:`logging infrastructu Please see the `Changelog`_ for further information and other optimizations. +Minimal hardware specifications +------------------------------- + +Our benchmarks suggest the following *minimal* specs for Octez node and baker operators: + +- 3 CPU cores: 2 needed by the node and 1 needed by the baker (arm64 or amd64/x86-64) +- 8GB of RAM + 8GB of swap (or 16GB of RAM) +- 100GB SSD storage (or similar I/O performance) +- A low-latency reliable internet connection + +This configuration has been tested for running an Octez node in :doc:`rolling history mode <../user/history_modes>`. +Other more specific uses may need adequate configurations. +For instance: + +- running a node in full or archive mode requires extra storage space; +- bakers participating to the DAL should consult `this article `__. + Update Instructions -------------------