From c852f76fcb68d62ad27b88848087253dde3a5348 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 23 Oct 2024 16:58:42 +0200 Subject: [PATCH 1/4] doc: add hw specs to v21 release page --- docs/releases/version-21.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/releases/version-21.rst b/docs/releases/version-21.rst index 33fef10998a9..6db999d459c5 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 ------------------- -- GitLab From 8bb401597548c3d38f554036770cd4e074417748 Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Thu, 7 Nov 2024 11:08:52 +0100 Subject: [PATCH 2/4] Doc/Alpha: slight rephrasings on the consensus page MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Germán Delbianco --- docs/alpha/consensus.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index bdbf588d4016..5af72504f61c 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 -- GitLab From 7bffc4d94e6fe98418b92a6f912f1a7755d1bc9c Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Tue, 12 Nov 2024 10:23:44 +0100 Subject: [PATCH 3/4] doc: rephrase amount of LB/block, add const LIQUIDITY_BAKING_EMA_THRESHOLD --- docs/alpha/liquidity_baking.rst | 9 ++++----- docs/alpha/staking.rst | 2 +- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 42a76dbc80b8..67245d0727e0 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 bc64aa1cfddc..e253897df1e5 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 -- GitLab From cadaaa5d10459c1d4ebf1d2f853d2db8be32249b Mon Sep 17 00:00:00 2001 From: Killian Delarue Date: Thu, 14 Nov 2024 16:52:56 +0100 Subject: [PATCH 4/4] Docs, Releases: Move [version-20] to history --- docs/index.rst | 1 - docs/releases/history.rst | 5 +++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/index.rst b/docs/index.rst index 2ebdf41f7067..4c4a9eff8ec9 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 6a898586f239..8609f7654844 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 -- GitLab