From 500bcb0d73857eb485a452d7a42d4c02a30e8a8d Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Thu, 1 Dec 2022 10:35:33 +0100 Subject: [PATCH 01/12] Doc: fix typo in liquidity_baking.rst --- docs/alpha/liquidity_baking.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 6685c0fe8c8a..83cc6fb84996 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -46,7 +46,7 @@ the subsidy, and ``Pass`` to abstain. ``e[n+1] = e[n]`` if the flag is set to ``Pass``. ``e[n+1] = (1999 * e[n] // 2000) + 1_000_000`` if the flag is set to ``Off``. ``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```. +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 exponential moving average with a window size on the order of two -- GitLab From 8a08ca5cc5a10dbdcf3a49b3a6d359b40a2aa894 Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Thu, 1 Dec 2022 10:41:38 +0100 Subject: [PATCH 02/12] Docs/LB: use capital letter when starting sentence --- docs/alpha/liquidity_baking.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst index 83cc6fb84996..be16b56338d8 100644 --- a/docs/alpha/liquidity_baking.rst +++ b/docs/alpha/liquidity_baking.rst @@ -10,7 +10,7 @@ During activation of Granada protocol, a constant product market making (CPMM) M .. warning:: - while the CPMM and LQT contract originations provide an ``Origination_result``, the LQT contract contains two big maps not included in a `lazy_storage_diff` field. Indexers and other tooling may need manual updates to include these. + While the CPMM and LQT contract originations provide an ``Origination_result``, the LQT contract contains two big maps not included in a `lazy_storage_diff` field. Indexers and other tooling may need manual updates to include these. The CPMM maintains a balance of ``a`` tez and ``b`` `tzBTC `_, where tzBTC is the `FA1.2 token `_ found at address ``KT1PWx2mnDueood7fEmfbBDKx1D9BAnnXitn``. The smart contract accepts deposits of ``da`` tez and returns ``db`` tzBTC (or vice versa) where the invariant ``(a + da * (1 - f - n)) * (b - db) = a b`` is preserved, and ``f`` and ``n`` are a fee and burn, set at 0.1% each. Calculations are done with precision of 1000, rounding down on division. -- GitLab From e8f0f5087be4891244b7dd332847bba48f0dcc14 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 2 Dec 2022 15:50:52 +0100 Subject: [PATCH 03/12] doc: mention combining remote signer with Ledger --- docs/user/key-management.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 7fcad5e88af8..5276e0846c6c 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -20,12 +20,13 @@ The solutions provided to strengthen the security of the default key management + sign user operations (e.g. transfers) interactively on the wallet + automatically sign baking operations, such as (pre-)endorsements, more securely. -- If you don't have a hardware wallet: +- If you don't have a hardware wallet, the option ``--encrypted`` of the client offers a first protection for storing your keys. - + The option ``--encrypted`` of the client offers a first protection for storing your keys. - + A separate signer daemon allows to decouple the client and baker from the signing process. - In particular, this allows executing a remote signer, placed on a different machine than the client and/or the baker, perhaps less exposed to attacks. - As the keys only need to be accessible to the signer, they can also benefit from the lesser exposure. +- A separate signer daemon allows to decouple the client and baker from the signing process. + + In particular, this allows executing the signer remotely (that is, on a different machine than the client and/or the baker), perhaps less exposed to attacks. + + As the keys only need to be accessible to the signer, they can also benefit from the lesser exposure. Even better (and recommended), a remote signer can be combined with a hardware wallet connected to the same machine as the signer. These solutions are detailed in the rest of this page. -- GitLab From 1fb3d4d7025c35038593e3b40e41473f6a2db64c Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 2 Dec 2022 18:00:18 +0100 Subject: [PATCH 04/12] doc: refutation period serves to challenge/dispute commits --- docs/alpha/smart_rollups.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index b63479931e2a..50a58c4c5440 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -1271,7 +1271,7 @@ Glossary #. **Refutation period**: At the end of each commitment period, a period of two weeks starts to allow any commitment related to - this commitment period to be published. + this commitment period to be challenged. #. **Staker**: An implicit account that has made a deposit on a commitment. -- GitLab From b72f00fd04186235f225c0f6002694a67dc02104 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 2 Dec 2022 18:01:37 +0100 Subject: [PATCH 05/12] doc: this file/value is removed before kernel_run --- docs/alpha/smart_rollups.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 50a58c4c5440..6d82c7ce6dd5 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -694,7 +694,7 @@ the next inbox are being loaded. The inputs that were not consumed by kernel from yielding by writing arbitrary data under the path ``/kernel/env/reboot`` in its durable storage. In such a case (known as reboot), ``kernel_run`` is called again, without dropping unread -inputs. This value is removed between each call of ``kernel_run``, +inputs. The value at ``/kernel/env/reboot`` is removed between each call of ``kernel_run``, and the ``kernel_run`` function can postpone yielding at most 1,000 reboots for each Tezos level. -- GitLab From a292a46b2de7cba99abcb6f3118458b006a3ef86 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 8 Dec 2022 11:36:43 +0100 Subject: [PATCH 06/12] doc: remove endorser and emphasis only first occurrence of Octez --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1a61e5b5c5a5..e40130bb607c 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ available at https://tezos.gitlab.io/. ## The Tezos software This repository hosts **Octez**, an implementation of the Tezos blockchain. -**Octez** provides a node, a client, a baker, an endorser, an accuser, and other tools, distributed with the Tezos economic protocols of Mainnet for convenience. +Octez provides a node, a client, a baker, an accuser, and other tools, distributed with the Tezos economic protocols of Mainnet for convenience. In more detail, this git repository contains: - the source code, in directory src/ -- GitLab From c7fb31383ae73392be333fb1b54a1280311cc04a Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Tue, 13 Dec 2022 12:04:16 +0100 Subject: [PATCH 07/12] Docs/Shell: fix typo --- docs/shell/prevalidation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/shell/prevalidation.rst b/docs/shell/prevalidation.rst index a98382e6000a..aaa26e3ccaae 100644 --- a/docs/shell/prevalidation.rst +++ b/docs/shell/prevalidation.rst @@ -57,7 +57,7 @@ the operation and already accepted operations, not taking into account the state of the ledger. Starting from Octez version 12.0, the ``precheck`` filter can be used -instead of ``applying_operation`` to classify operations, as follows: +instead of ``apply_operation`` to classify operations, as follows: If ``precheck`` cannot decide the classification of an operation, the prevalidator uses ``apply_operation`` instead. If an operation passes the ``precheck`` filter, or otherwise it has been successfully -- GitLab From ad8bc2ed16671ea944a23ef3977e159e18ff15ca Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 15 Dec 2022 11:48:26 +0100 Subject: [PATCH 08/12] doc: mention that compiling sources is now a pre-requisite for doc build --- docs/README.rst | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/README.rst b/docs/README.rst index 8ee14ff16e40..56bfb4b8e709 100644 --- a/docs/README.rst +++ b/docs/README.rst @@ -36,8 +36,13 @@ To build the documentation locally, you need to install the Python package manager `Poetry `_. For instructions on how to obtain Python and Poetry, see :doc:`the installation instructions for the python testing -framework`. Once this is done, you can -do: +framework`. + +Another pre-requisite for building the documentation is making sure that the Octez sources on your branch are compiled, because part of the documentation is generated by Octez executables. +This involves executing ``make`` in the parent directory (the repository root). +If this step results in errors, you usually have to restart the :ref:`compiling procedure ` from ``make clean`` onwards. + +Once this is done, you can do: .. code-block:: bash -- GitLab From 719c4ebd708a2b6a2302857a821c50bbf49195fa Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 21 Dec 2022 14:50:47 +0100 Subject: [PATCH 09/12] doc: instantiate alpha API links to other protocols --- docs/Makefile | 4 +++- docs/alpha/token_management.rst | 3 +-- docs/alpha/validation.rst | 4 ++-- docs/lima/token_management.rst | 3 +-- docs/mumbai/blocks_ops.rst | 2 +- docs/mumbai/protocol_overview.rst | 4 ++-- docs/mumbai/token_management.rst | 3 +-- docs/mumbai/validation.rst | 7 +------ scripts/snapshot_alpha.sh | 2 ++ 9 files changed, 14 insertions(+), 18 deletions(-) diff --git a/docs/Makefile b/docs/Makefile index 49fc830233db..a34fb10d2a7d 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -1,3 +1,5 @@ +# TODO #2170: search for old/preceding protocol name AND number, and adapt + # You can set these variables from the command line. SPHINXOPTS = -j auto -aE -n -W --keep-going SPHINXBUILD = poetry run sphinx-build @@ -71,7 +73,7 @@ odoc-lite: docexes rm -rf $(TMPDOCDIR)/ mkdir -p $(TMPDOCDIR)/ rsync --recursive --links --perms \ - --include="src/proto_014*" --include="src/proto_015*" \ + --include="src/proto_015*" --include="src/proto_016*" \ --exclude="src/proto_0*" \ ../src ../tezt ../vendors ../dune ../dune-project $(TMPDOCDIR)/ # FIXME: https://gitlab.com/tezos/tezos/-/issues/2971 diff --git a/docs/alpha/token_management.rst b/docs/alpha/token_management.rst index 4f6348b43973..c6f73a6539ff 100644 --- a/docs/alpha/token_management.rst +++ b/docs/alpha/token_management.rst @@ -6,7 +6,7 @@ This page describes the reporting of tokens transfers in block metadata, as a se Overview ~~~~~~~~ -Minting, transferring or burning tokens is handled by the `Token `_ module. +Minting, transferring or burning tokens is handled by the :package-api:`Token ` module. The module provides functions (``Token.transfer`` and ``Token.transfer_n``) to transfer tokens from one, respectively from more accounts, to another account. Balance updates found in block metadata are generated by these functions as a trace of the token movements having taken place. @@ -203,4 +203,3 @@ For example, for an amount of ``100`` mutez in rewards not distributed due to in "change": "100", ...} ] Double signing evidence rewards and nonce revelation rewards are analogous to endorsing rewards, except that the source accounts used are ``"double signing evidence rewards"`` and ``"nonce revelation rewards"``. - diff --git a/docs/alpha/validation.rst b/docs/alpha/validation.rst index 0d11724be1f2..be828c88c56f 100644 --- a/docs/alpha/validation.rst +++ b/docs/alpha/validation.rst @@ -53,8 +53,8 @@ state-passing machine where: .. TODO #4155: When creating a new environment, update references to V in the - paragraph below. - + paragraph below (only in the doc for Alpha!). + However, the *concrete* API exported from the Tezos economic protocol does not implement this business logic *monolithically*, as described above, but it rather presents a more fine-grained API. The rationale diff --git a/docs/lima/token_management.rst b/docs/lima/token_management.rst index 4f6348b43973..e1a4b639745b 100644 --- a/docs/lima/token_management.rst +++ b/docs/lima/token_management.rst @@ -6,7 +6,7 @@ This page describes the reporting of tokens transfers in block metadata, as a se Overview ~~~~~~~~ -Minting, transferring or burning tokens is handled by the `Token `_ module. +Minting, transferring or burning tokens is handled by the :package-api:`Token ` module. The module provides functions (``Token.transfer`` and ``Token.transfer_n``) to transfer tokens from one, respectively from more accounts, to another account. Balance updates found in block metadata are generated by these functions as a trace of the token movements having taken place. @@ -203,4 +203,3 @@ For example, for an amount of ``100`` mutez in rewards not distributed due to in "change": "100", ...} ] Double signing evidence rewards and nonce revelation rewards are analogous to endorsing rewards, except that the source accounts used are ``"double signing evidence rewards"`` and ``"nonce revelation rewards"``. - diff --git a/docs/mumbai/blocks_ops.rst b/docs/mumbai/blocks_ops.rst index f832a40e2b15..d989935c6e6d 100644 --- a/docs/mumbai/blocks_ops.rst +++ b/docs/mumbai/blocks_ops.rst @@ -14,7 +14,7 @@ those available to end-users on Tezos Mainnet. The complete list of operations, including those corresponding to features in development or available only on test networks, is given in the :package-api:`OCaml Documentation -`. +`. .. _validation_passes_mumbai: diff --git a/docs/mumbai/protocol_overview.rst b/docs/mumbai/protocol_overview.rst index 4e849f8b02d9..5e3ee038dc62 100644 --- a/docs/mumbai/protocol_overview.rst +++ b/docs/mumbai/protocol_overview.rst @@ -158,10 +158,10 @@ The *list* of protocol constants can be found in the OCaml APIs: - fixed protocol constants are defined in the module :package-api:`Constants_repr - ` + ` - parametric constants are defined in the module :package-api:`Constants_parametric_repr - ` + ` The *values* of protocol constants in any given protocol can be found using specific RPC calls: diff --git a/docs/mumbai/token_management.rst b/docs/mumbai/token_management.rst index 4f6348b43973..7f5aeaf1b19f 100644 --- a/docs/mumbai/token_management.rst +++ b/docs/mumbai/token_management.rst @@ -6,7 +6,7 @@ This page describes the reporting of tokens transfers in block metadata, as a se Overview ~~~~~~~~ -Minting, transferring or burning tokens is handled by the `Token `_ module. +Minting, transferring or burning tokens is handled by the :package-api:`Token ` module. The module provides functions (``Token.transfer`` and ``Token.transfer_n``) to transfer tokens from one, respectively from more accounts, to another account. Balance updates found in block metadata are generated by these functions as a trace of the token movements having taken place. @@ -203,4 +203,3 @@ For example, for an amount of ``100`` mutez in rewards not distributed due to in "change": "100", ...} ] Double signing evidence rewards and nonce revelation rewards are analogous to endorsing rewards, except that the source accounts used are ``"double signing evidence rewards"`` and ``"nonce revelation rewards"``. - diff --git a/docs/mumbai/validation.rst b/docs/mumbai/validation.rst index e36525ae4fe9..9908925b0aff 100644 --- a/docs/mumbai/validation.rst +++ b/docs/mumbai/validation.rst @@ -50,11 +50,6 @@ state-passing machine where: on (i.e., it should call) *apply_operation* to validate and apply each operation in the block, and compute intermediate states. -.. TODO #4155: - - When creating a new environment, update references to V in the - paragraph below. - However, the *concrete* API exported from the Tezos economic protocol does not implement this business logic *monolithically*, as described above, but it rather presents a more fine-grained API. The rationale @@ -71,7 +66,7 @@ specified by the :package-api:`Protocol module in the :doc:`protocol environment<../shell/protocol_environment>` ``V8``, and it is implemented by this protocol in the -:package-api:`Main` +:package-api:`Main` module. The rest of this document is organized as follows: we first describe diff --git a/scripts/snapshot_alpha.sh b/scripts/snapshot_alpha.sh index de23fead6a42..8c1890d26246 100755 --- a/scripts/snapshot_alpha.sh +++ b/scripts/snapshot_alpha.sh @@ -93,6 +93,8 @@ echo "Fixing versioned links in docs" cd docs/${label} sed -i.old -e s/_alpha:/_${label}:/g \ -e s,src/proto_alpha,src/proto_${version}_${short_hash},g \ + -e s,tezos-protocol-alpha/,tezos-protocol-${version}-${short_hash}/,g \ + -e s,raw_protocol_alpha/,raw_protocol_${version}_${short_hash}/,g \ -e s/_alpha\>/_${label}\>/g \ -e s/_alpha\`/_${label}\`/g \ -e s/-alpha.html/-${label}.html/g \ -- GitLab From 8c2aceb6f13d4e6275dcb2624ead91fd5c464e7c Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Fri, 23 Dec 2022 14:31:25 +0100 Subject: [PATCH 10/12] Doc: rename TOKENS_PER_ROLL to MINIMAL_STAKE --- docs/alpha/consensus.rst | 2 +- docs/alpha/proof_of_stake.rst | 6 +++--- docs/lima/consensus.rst | 2 +- docs/lima/proof_of_stake.rst | 6 +++--- docs/mumbai/consensus.rst | 2 +- docs/mumbai/proof_of_stake.rst | 6 +++--- 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 795c312eaa5e..629f1ab4f459 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -149,7 +149,7 @@ balance*. 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 balances of all accounts that have delegated to it. - It must be at least ``TOKENS_PER_ROLL`` tez, otherwise the delegate cannot be selected as a validator. + 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. diff --git a/docs/alpha/proof_of_stake.rst b/docs/alpha/proof_of_stake.rst index 5c48e204f943..1dc55ebe1b99 100644 --- a/docs/alpha/proof_of_stake.rst +++ b/docs/alpha/proof_of_stake.rst @@ -45,7 +45,7 @@ proportional to their *delegated stake* -- that is, the balance of all the accounts that delegate to it, including the balance of the delegate itself. To participate in consensus or in governance, a delegate needs to have at least a minimal stake, which is given by the -``TOKENS_PER_ROLL`` :ref:`protocol constant +``MINIMAL_STAKE`` :ref:`protocol constant `. Delegates place security deposits that may be forfeited in case they do not @@ -115,7 +115,7 @@ At the end of cycle ``n-1-PRESERVED_CYCLES``, the snapshot for cycle PRNG having as seed the :ref:`random seed` for cycle ``n``. -Only the stake of active delegates with the minimal stake of ``TOKENS_PER_ROLL`` is snapshot. +Only the stake of active delegates with the minimal stake of ``MINIMAL_STAKE`` is snapshot. .. _rights_alpha: @@ -164,7 +164,7 @@ Proof-of-stake parameters - 16384 blocks * - ``PRESERVED_CYCLES`` - 5 cycles - * - ``TOKENS_PER_ROLL`` + * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``BLOCKS_PER_STAKE_SNAPSHOT`` - 1024 blocks diff --git a/docs/lima/consensus.rst b/docs/lima/consensus.rst index 5a04bbf7267f..25c6a6050c4e 100644 --- a/docs/lima/consensus.rst +++ b/docs/lima/consensus.rst @@ -154,7 +154,7 @@ balance*. 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 balances of all accounts that have delegated to it. - It must be at least ``TOKENS_PER_ROLL`` tez, otherwise the delegate cannot be selected as a validator. + 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. diff --git a/docs/lima/proof_of_stake.rst b/docs/lima/proof_of_stake.rst index 9b591c034370..9c53ad9097d9 100644 --- a/docs/lima/proof_of_stake.rst +++ b/docs/lima/proof_of_stake.rst @@ -42,7 +42,7 @@ proportional with their delegated stake, which includes the balances of all the accounts that delegate to it, and also the balance of the delegate itself. To participate in consensus or in governance, a delegate needs to have at least a minimal stake, which is given by the -``TOKENS_PER_ROLL`` :ref:`protocol constant +``MINIMAL_STAKE`` :ref:`protocol constant `. Delegates place security deposits that may be forfeited in case they do not @@ -105,7 +105,7 @@ At the end of cycle ``n-1-PRESERVED_CYCLES``, the snapshot for cycle PRNG having as seed the :ref:`random seed` for cycle ``n``. -Only the stake of active delegates with the minimal stake of ``TOKENS_PER_ROLL`` is snapshot. +Only the stake of active delegates with the minimal stake of ``MINIMAL_STAKE`` is snapshot. .. _rights: .. _rights_lima: @@ -155,7 +155,7 @@ Proof-of-stake parameters - 8192 blocks * - ``PRESERVED_CYCLES`` - 5 cycles - * - ``TOKENS_PER_ROLL`` + * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``BLOCKS_PER_STAKE_SNAPSHOT`` - 512 blocks diff --git a/docs/mumbai/consensus.rst b/docs/mumbai/consensus.rst index f5a2d3d6c8c6..e5b38d9e5f65 100644 --- a/docs/mumbai/consensus.rst +++ b/docs/mumbai/consensus.rst @@ -149,7 +149,7 @@ balance*. 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 balances of all accounts that have delegated to it. - It must be at least ``TOKENS_PER_ROLL`` tez, otherwise the delegate cannot be selected as a validator. + 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. diff --git a/docs/mumbai/proof_of_stake.rst b/docs/mumbai/proof_of_stake.rst index 613079004f73..a40935876a46 100644 --- a/docs/mumbai/proof_of_stake.rst +++ b/docs/mumbai/proof_of_stake.rst @@ -43,7 +43,7 @@ proportional with their delegated stake, which includes the balances of all the accounts that delegate to it, and also the balance of the delegate itself. To participate in consensus or in governance, a delegate needs to have at least a minimal stake, which is given by the -``TOKENS_PER_ROLL`` :ref:`protocol constant +``MINIMAL_STAKE`` :ref:`protocol constant `. Delegates place security deposits that may be forfeited in case they do not @@ -103,7 +103,7 @@ At the end of cycle ``n-1-PRESERVED_CYCLES``, the snapshot for cycle PRNG having as seed the :ref:`random seed` for cycle ``n``. -Only the stake of active delegates with the minimal stake of ``TOKENS_PER_ROLL`` is snapshot. +Only the stake of active delegates with the minimal stake of ``MINIMAL_STAKE`` is snapshot. .. _rights_mumbai: @@ -152,7 +152,7 @@ Proof-of-stake parameters - 16384 blocks * - ``PRESERVED_CYCLES`` - 5 cycles - * - ``TOKENS_PER_ROLL`` + * - ``MINIMAL_STAKE`` - 6,000 ꜩ * - ``BLOCKS_PER_STAKE_SNAPSHOT`` - 1024 blocks -- GitLab From db0fdc6d07e085e1b025a1bacc44e49fad51ce05 Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Fri, 23 Dec 2022 14:50:00 +0100 Subject: [PATCH 11/12] Docs: make cosmetic changes in key-management --- docs/user/key-management.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 5276e0846c6c..ceb0becbadba 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -267,12 +267,12 @@ Consensus Key .. note:: - Consensus key is available starting with the Tezos L protocol. + The "consensus key" feature is available starting with the Tezos :doc:`Lima<../protocols/015_lima>` protocol. By default, the baker's key, also called manager key, is used to sign in the consensus protocol, i.e. signing blocks while baking, and signing consensus operations (preendorsements and endorsements). -A delegate may elect instead to choose a dedicated key: the consensus key. It can then be changed without redelegation. +A delegate may elect instead to choose a dedicated key: the *consensus key*. It can then be changed without redelegation. It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems (KMS) where the private key is @@ -299,7 +299,7 @@ The command to update the consensus key is:: tezos-client set consensus key for to consensus -The update becomes active after `PRESERVED_CYCLES + 1` cycles. We therefore distinguish +The update becomes active after ``PRESERVED_CYCLES + 1`` cycles. We therefore distinguish the active consensus key and the pending consensus keys. The active consensus key is by default the delegate’s manager key, which cannot change. @@ -325,7 +325,7 @@ The delegate will seamlessly keep baking when the transition happens:: Draining a Manager's Account With its Consensus Key ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This operation immediately transfers all the spendable balance of the `baker_pkh`’s implicit account into the `destination_pkh` implicit account:: +This operation immediately transfers all the spendable balance of the ``baker_pkh``’s implicit account into the ``destination_pkh`` implicit account:: tezos-client drain delegate to with @@ -334,9 +334,9 @@ If the destination is the consensus key account, this can be simplified to:: tezos-client drain delegate to The active consensus key is the signer for this operation, therefore the private key associated to the consensus key must be available -in the wallet of the client typing the command. The delegate's private key needs not be present. +in the wallet of the client typing the command. The delegate's private key does not need to be present. -`drain delegate` has no effect on the frozen balance. +The drain operation has no effect on the frozen balance. A fixed fraction of the drained delegate’s spendable balance is transferred as fees to the baker that includes the operation, i.e. the maximum between 1 tez or 1% of the spendable balance. -- GitLab From 408fc459119dd5d32feb94039c55ef739df17a64 Mon Sep 17 00:00:00 2001 From: Eugen Zalinescu Date: Fri, 23 Dec 2022 18:08:45 +0100 Subject: [PATCH 12/12] Proto: fix incorrect doc-string --- src/proto_alpha/lib_protocol/contract_storage.mli | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/proto_alpha/lib_protocol/contract_storage.mli b/src/proto_alpha/lib_protocol/contract_storage.mli index 23c062aad53b..55720b9e0d71 100644 --- a/src/proto_alpha/lib_protocol/contract_storage.mli +++ b/src/proto_alpha/lib_protocol/contract_storage.mli @@ -58,7 +58,7 @@ type error += val allocated : Raw_context.t -> Contract_repr.t -> bool Lwt.t (** [exists ctxt contract] returns [true] if and only if either the - contract is originated or it is (implicit and) "allocated". *) + contract is implicit or it is (originated and) {!allocated}. *) val exists : Raw_context.t -> Contract_repr.t -> bool Lwt.t (** [must_exist ctxt contract] fails with the [Non_existing_contract] error if -- GitLab