From 37409f659b37fefd2e13e07009adc254aa82b9c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Proust?= Date: Fri, 4 Mar 2022 10:46:12 +0100 Subject: [PATCH 01/10] Lwtreslib: fix plurals in implementation documentation --- src/lib_lwt_result_stdlib/bare/structs/list.ml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/lib_lwt_result_stdlib/bare/structs/list.ml b/src/lib_lwt_result_stdlib/bare/structs/list.ml index 73b0aaaeac9e..9407d8a2f298 100644 --- a/src/lib_lwt_result_stdlib/bare/structs/list.ml +++ b/src/lib_lwt_result_stdlib/bare/structs/list.ml @@ -39,8 +39,8 @@ let traverse f xs = with variations for when [f] takes more than one parameter, when the matching is slightly different, and so on. Whatever the variation, the - patterns remain: one recursive function immediately shadowed by a - non-recursive function which only handles the first element. + pattern remains: one recursive function immediately shadowed by a + non-recursive function which only handles the head of the list. This is necessary because the application of [f] to the head of the list [x] is not on the right-hand side of an Lwt bind. As such, the call [f x] is not -- GitLab From 63b867d94bb6664d39bed763935d95cdecb9e00e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Proust?= Date: Fri, 4 Mar 2022 10:46:40 +0100 Subject: [PATCH 02/10] Everywhere: fix some comment indentation issues --- .../bare/structs/list.ml | 18 ++++++------- src/lib_store/consistency.ml | 2 +- tezt/manual_tests/migration_voting.ml | 26 +++++++++---------- 3 files changed, 23 insertions(+), 23 deletions(-) diff --git a/src/lib_lwt_result_stdlib/bare/structs/list.ml b/src/lib_lwt_result_stdlib/bare/structs/list.ml index 9407d8a2f298..0c618aab1a98 100644 --- a/src/lib_lwt_result_stdlib/bare/structs/list.ml +++ b/src/lib_lwt_result_stdlib/bare/structs/list.ml @@ -23,19 +23,19 @@ (* *) (*****************************************************************************) -(* A note about the implementation of recursive Lwt and Lwt-result functions: +(* A note about the implementation of recursive Lwt and Lwt-result functions: [_s] and [_es] functions are implemented following this pattern: -{[ -let rec traverse f xs = - | [] -> .. - | x :: xs -> .. f x .. traverse xs .. + {[ + let rec traverse f xs = + | [] -> .. + | x :: xs -> .. f x .. traverse xs .. -let traverse f xs = - | [] -> .. - | x :: xs -> .. Lwt.apply f x .. traverse xs .. -]} + let traverse f xs = + | [] -> .. + | x :: xs -> .. Lwt.apply f x .. traverse xs .. + ]} with variations for when [f] takes more than one parameter, when the matching is slightly different, and so on. Whatever the variation, the diff --git a/src/lib_store/consistency.ml b/src/lib_store/consistency.ml index 76b8206b5c09..3c41fa55c669 100644 --- a/src/lib_store/consistency.ml +++ b/src/lib_store/consistency.ml @@ -632,7 +632,7 @@ let fix_savepoint_and_caboose ?history_mode chain_dir block_store head genesis = by setting it to the lowest block with metadata which is higher that the last allowed fork level of the current head (and <= head_level). - Assumptions: + Assumptions: - head is valid, - savepoint is valid, - block store is valid and available. *) diff --git a/tezt/manual_tests/migration_voting.ml b/tezt/manual_tests/migration_voting.ml index 5b60660b51ba..907681ad4d50 100644 --- a/tezt/manual_tests/migration_voting.ml +++ b/tezt/manual_tests/migration_voting.ml @@ -25,19 +25,19 @@ (*****************************************************************************) (* Example of the relevant fields from metadata: - "level_info": { - "level": 1404929, - "level_position": 1404928, - "cycle": 343, - "cycle_position": 0, - "expected_commitment": false }, - "voting_period_info": { - "voting_period": { - "index": 44, - "kind": "cooldown", - "start_position": 1404927 }, - "position": 1, - "remaining": 40958 } + "level_info": { + "level": 1404929, + "level_position": 1404928, + "cycle": 343, + "cycle_position": 0, + "expected_commitment": false }, + "voting_period_info": { + "voting_period": { + "index": 44, + "kind": "cooldown", + "start_position": 1404927 }, + "position": 1, + "remaining": 40958 } *) let check_voting_period_invariants ~blocks_per_voting_period ~blocks_per_cycle -- GitLab From fef803e79728dc0939b491c191d44aa7a514909a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Germ=C3=A1n=20Delbianco?= Date: Fri, 11 Mar 2022 17:46:37 +0000 Subject: [PATCH 03/10] doc: clarify we no longer ship endorser daemons Add a NB clarifying there is no endorsers for protos Ithaca2 and Alpha for v12. --- docs/releases/version-12.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/releases/version-12.rst b/docs/releases/version-12.rst index 526783081b7f..fcabe8224dec 100644 --- a/docs/releases/version-12.rst +++ b/docs/releases/version-12.rst @@ -40,6 +40,13 @@ To update from sources:: If you are using Docker instead, use the ``v12.2`` Docker images of Tezos. +**NB** The `Ithaca2 <../protocols/012_ithaca.html>`_ protocol adopts +the new `Tenderbake <../protocols/tenderbake.html#daemons>`_ consensus +algorithm, which no longer requires a separate *endorser* daemon. This +functionality is now integrated into the *baker* daemons: +``tezos-baker-012-Psithaca`` for Ithaca2 and, respectively, +``tezos-baker-alpha`` for `protocol Alpha <../protocols/alpha.html>`_. + Changelog --------- -- GitLab From d95b8d83dc394faea5d96ae28eeed9a1dc72dec1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Germ=C3=A1n=20Delbianco?= Date: Fri, 11 Mar 2022 19:23:01 +0100 Subject: [PATCH 04/10] doc: clean up :: in time measurement ppx entry Fix syntax for code blocks which was rendering double colons in some places. --- docs/developer/time_measurement_ppx.rst | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/docs/developer/time_measurement_ppx.rst b/docs/developer/time_measurement_ppx.rst index 52854999f445..4177bcd2c51a 100644 --- a/docs/developer/time_measurement_ppx.rst +++ b/docs/developer/time_measurement_ppx.rst @@ -134,11 +134,15 @@ This is useful to prevent our code from embedding benchmarking tooling in production by mistake: If no backend is specified for the compilation, added attributes will just be ignored by the OCaml compiler and that's it! -We can now compile our ready-to-benchmark code::: +We can now compile our ready-to-benchmark code: + +.. code-block:: dune build --instrument-with tezos-time-measurement -We can then run the executable::: +We can then run the executable: + +.. code-block:: ./my_program.exe @@ -187,6 +191,8 @@ Instrumenting the tezos-node executable --------------------------------------- A helper has been added in the ``Makefile``, so you just need to run the following -command to instrument the node during the compilation::: +command to instrument the node during the compilation: + +.. code-block:: - ./make enable-time-measurement + ./make enable-time-measurement -- GitLab From 01886641de2ddf0cd199c7f7cc88a1eee620d998 Mon Sep 17 00:00:00 2001 From: Lacramioara Astefanoaei Date: Mon, 14 Mar 2022 09:09:32 +0100 Subject: [PATCH 05/10] doc: change 8000 in 7000 and update calculations --- docs/alpha/consensus.rst | 26 +++++++++++++------------- docs/ithaca/consensus.rst | 28 ++++++++++++++-------------- 2 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 372619ee218f..ea3f163139a6 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -337,25 +337,25 @@ The bonus per additional endorsement slot is in turn ``bonus / ``CONSENSUS_COMMITTEE_SIZE / 3`` validator slots corresponding to the additional endorsements included in a block). The rewards per endorsement slot are ``endorsing_rewards / CONSENSUS_COMMITTEE_SIZE``. -Assuming ``CONSENSUS_COMMITTEE_SIZE = 8000``, we obtain a bonus per slot of -``10 / (8000 / 3) = 0.00375`` tez and an endorsing -rewards per slot of ``20 / 8000 = 0.0025`` tez. +Assuming ``CONSENSUS_COMMITTEE_SIZE = 7000``, we obtain a bonus per slot of +``10 / (7000 / 3) = 0.004286`` tez and an endorsing +rewards per slot of ``20 / 7000 = 0.002857`` tez. Let's take an example. Say a block has round 1, is proposed by delegate B, and contains the payload from round 0 produced by delegate -A. Also, B includes endorsements with endorsing power ``6000``. Then A receives +A. Also, B includes endorsements with endorsing power ``5251``. Then A receives the fees and 10 tez (the ``BAKING_REWARD_FIXED_PORTION``) as a reward for -producing the block's payload. For simpler calculations, let's assume -``CONSENSUS_COMMITTEE_SIZE = 8000``. Concerning the bonus, the minimum required validator slots is ``5334``, and there are ``2666 = 8000 - 5334`` additional validator slots. -Therefore B receives the bonus ``(6000 - 5334) * 0.00375 = 2.4975`` tez. (Note -that B only included endorsements corresponding to 666 additional validator slots, about a quarter of the -maximum 2666 extra endorsements it could have theoretically included.) Finally, consider some +producing the block's payload. Concerning the bonus, given that +``CONSENSUS_COMMITTEE_SIZE = 7000``, the minimum required validator slots is ``4667``, and there are ``2333 = 7000 - 4667`` additional validator slots. +Therefore B receives the bonus ``(5251 - 4667) * 0.004286 = 2.503`` tez. (Note +that B only included endorsements corresponding to 584 = 5251 - 4667 additional validator slots, about a quarter of the +maximum 2333 extra endorsements it could have theoretically included.) Finally, consider some delegate C, whose active stake at some cycle is 5% of the total stake. Note that -his expected number of validator slots for that cycle is ``5/100 * 8192 * 8000 = -3,276,800`` slots. Assume also that the endorsing power of C's endorsements +his expected number of validator slots for that cycle is ``5/100 * 8192 * 7000 = +2,867,200`` slots. Assume also that the endorsing power of C's endorsements included during that cycle has been ``3,123,456`` slots. Given that this number is -bigger than the minimum required (``3,276,800 * 2 / 3``), it receives an endorsing -reward of ``3,276,800 * 0.0025 = 8192`` tez for that cycle. +bigger than the minimum required (``2,867,200 * 2 / 3``), it receives an endorsing +reward of ``2,867,200 * 0.002857 = 8191.59`` tez for that cycle. .. _slashing_alpha: diff --git a/docs/ithaca/consensus.rst b/docs/ithaca/consensus.rst index a60d3eda98d8..94603241ed60 100644 --- a/docs/ithaca/consensus.rst +++ b/docs/ithaca/consensus.rst @@ -342,25 +342,25 @@ The bonus per additional endorsement slot is in turn ``bonus / ``CONSENSUS_COMMITTEE_SIZE / 3`` validator slots corresponding to the additional endorsements included in a block). The rewards per endorsement slot are ``endorsing_rewards / CONSENSUS_COMMITTEE_SIZE``. -Assuming ``CONSENSUS_COMMITTEE_SIZE = 8000``, we obtain a bonus per slot of -``10 / (8000 / 3) = 0.00375`` tez and an endorsing -rewards per slot of ``20 / 8000 = 0.0025`` tez. +Assuming ``CONSENSUS_COMMITTEE_SIZE = 7000``, we obtain a bonus per slot of +``10 / (7000 / 3) = 0.004286`` tez and an endorsing +rewards per slot of ``20 / 7000 = 0.002857`` tez. Let's take an example. Say a block has round 1, is proposed by delegate B, and contains the payload from round 0 produced by delegate -A. Also, B includes endorsements with endorsing power ``6000``. Then A receives +A. Also, B includes endorsements with endorsing power ``5251``. Then A receives the fees and 10 tez (the ``BAKING_REWARD_FIXED_PORTION``) as a reward for -producing the block's payload. For simpler calculations, let's assume -``CONSENSUS_COMMITTEE_SIZE = 8000``. Concerning the bonus, the minimum required validator slots is ``5334``, and there are ``2666 = 8000 - 5334`` additional validator slots. -Therefore B receives the bonus ``(6000 - 5334) * 0.00375 = 2.4975`` tez. (Note -that B only included endorsements corresponding to 666 additional validator slots, about a quarter of the -maximum 2666 extra endorsements it could have theoretically included.) Finally, consider some +producing the block's payload. Concerning the bonus, given that +``CONSENSUS_COMMITTEE_SIZE = 7000``, the minimum required validator slots is ``4667``, and there are ``2333 = 7000 - 4667`` additional validator slots. +Therefore B receives the bonus ``(5251 - 4667) * 0.004286 = 2.503`` tez. (Note +that B only included endorsements corresponding to 584 = 5251 - 4667 additional validator slots, about a quarter of the +maximum 2333 extra endorsements it could have theoretically included.) Finally, consider some delegate C, whose active stake at some cycle is 5% of the total stake. Note that -his expected number of validator slots for that cycle is ``5/100 * 8192 * 8000 = -3,276,800`` slots. Assume also that the endorsing power of C's endorsements +his expected number of validator slots for that cycle is ``5/100 * 8192 * 7000 = +2,867,200`` slots. Assume also that the endorsing power of C's endorsements included during that cycle has been ``3,123,456`` slots. Given that this number is -bigger than the minimum required (``3,276,800 * 2 / 3``), it receives an endorsing -reward of ``3,276,800 * 0.0025 = 8192`` tez for that cycle. +bigger than the minimum required (``2,867,200 * 2 / 3``), it receives an endorsing +reward of ``2,867,200 * 0.002857 = 8191.59`` tez for that cycle. .. _slashing_ithaca: @@ -403,7 +403,7 @@ Consensus related protocol parameters * - ``CONSENSUS_COMMITTEE_SIZE`` - 7000 * - ``CONSENSUS_THRESHOLD`` - - ``ceil(2 * CONSENSUS_COMMITTEE_SIZE / 3)`` + - ``ceil(2 * CONSENSUS_COMMITTEE_SIZE / 3)`` = 4667 * - ``MINIMAL_BLOCK_DELAY`` - 30s * - ``DELAY_INCREMENT_PER_ROUND`` -- GitLab From d59789fdb6160beaee8ce2f198ff5bb6e747df5e Mon Sep 17 00:00:00 2001 From: Lacramioara Astefanoaei Date: Tue, 15 Mar 2022 10:02:52 +0100 Subject: [PATCH 06/10] doc: fix typos in protocols/tenderbake.rst --- docs/protocols/tenderbake.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/protocols/tenderbake.rst b/docs/protocols/tenderbake.rst index 4a7aec7aac68..ef352650fd1e 100644 --- a/docs/protocols/tenderbake.rst +++ b/docs/protocols/tenderbake.rst @@ -26,7 +26,7 @@ delegates that participate in consensus at a given level are called :ref:`validators` in Tenderbake and validator rights in Tenderbake are similar to endorsing rights in Emmy*. Baking rights are deduced from endorsing rights: the baker at round ``r`` is the -validator that has endorsing slot ``r``. +validator that owns the endorsing slot ``r``. Operations ~~~~~~~~~~ @@ -254,7 +254,7 @@ Signer The signer's messages were of the form ```` and are now of the form ````, where -the magic byte has changes from ``0x01`` for blocks and ``0x02`` for +the magic byte has changed from ``0x01`` for blocks and ``0x02`` for endorsements, to ``0x11`` for blocks, ``0x12`` for preendorsements, ``0x13`` for endorsements. -- GitLab From d7afeb2b5719762b97a0898506c4fd39a9dfde60 Mon Sep 17 00:00:00 2001 From: Arvid Jakobsson Date: Thu, 17 Mar 2022 11:15:46 +0100 Subject: [PATCH 07/10] Docs/Proto: Extend the documentation of Michelson type size --- src/proto_alpha/lib_protocol/constants_repr.mli | 7 ++++++- src/proto_alpha/lib_protocol/script_typed_ir.ml | 5 +++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/proto_alpha/lib_protocol/constants_repr.mli b/src/proto_alpha/lib_protocol/constants_repr.mli index 0a9160a7840c..41a5cf7ff61d 100644 --- a/src/proto_alpha/lib_protocol/constants_repr.mli +++ b/src/proto_alpha/lib_protocol/constants_repr.mli @@ -46,7 +46,7 @@ val max_operation_data_length : int number by finding the largest possible contract in terms of number of nodes. The number of nodes is constrained by the current "max_operation_data_length" (32768) to be ~10,000 ( - see "largest_flat_contract.tz" in the tezt suite for the largest + see "large_flat_contract.tz" in the tezt suite for the largest contract with constants that can be originated). As a first approximation, we set the node size limit to 5 times this amount. *) val max_micheline_node_count : int @@ -65,6 +65,11 @@ val max_micheline_bytes_limit : int in [Script_ir_translator]. *) val max_allowed_global_constant_depth : int +(** A global size limit on the size of Michelson types. + + The size of a type is the number of nodes in its AST + representation. See [Script_typed_ir.TYPE_SIZE]. + *) val michelson_maximum_type_size : int type fixed diff --git a/src/proto_alpha/lib_protocol/script_typed_ir.ml b/src/proto_alpha/lib_protocol/script_typed_ir.ml index 35e736a0f32e..cb9b0ab5f7c1 100644 --- a/src/proto_alpha/lib_protocol/script_typed_ir.ml +++ b/src/proto_alpha/lib_protocol/script_typed_ir.ml @@ -226,6 +226,11 @@ module type TYPE_SIZE = sig It allows keeping type metadata and types non-private. + The size of a type is the number of nodes in its AST + representation. In other words, the size of a type is 1 plus the size of + its arguments. For instance, the size of [Unit] is 1 and the size of + [Pair ty1 ty2] is [1] plus the size of [ty1] and [ty2]. + This module is here because we want three levels of visibility over this code: - inside this submodule, we have [type 'a t = int] -- GitLab From 04b137a9a610ec66c34ca367edc8b75defc1687f Mon Sep 17 00:00:00 2001 From: Arvid Jakobsson Date: Fri, 25 Mar 2022 10:35:23 +0100 Subject: [PATCH 08/10] docs: set language for literal json and ocaml includes --- docs/developer/guidelines.rst | 2 ++ docs/user/node-configuration.rst | 1 + 2 files changed, 3 insertions(+) diff --git a/docs/developer/guidelines.rst b/docs/developer/guidelines.rst index 54e8a630aa15..98f49f67fa98 100644 --- a/docs/developer/guidelines.rst +++ b/docs/developer/guidelines.rst @@ -9,6 +9,8 @@ License The Tezos software is distributed under the MIT license. Every OCaml source file should start with a header comment instantiating the following template (use appropriate comment syntax for other languages): .. literalinclude:: LICENSE.ml + :language: ocaml + Note that: diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index 8871c4fdd00d..e9b177da224a 100644 --- a/docs/user/node-configuration.rst +++ b/docs/user/node-configuration.rst @@ -266,6 +266,7 @@ hard-coded in :src:`src/lib_rpc_http/RPC_server.ml` (remember to replace actually listening on): .. literalinclude:: default-acl.json + :language: json The endpoints specifically required for baking can be found in :src:`vendors/flextesa-lib/tezos_node.ml`. -- GitLab From 79dd304e67ef7284a3b02909b37fff92ccdcc617 Mon Sep 17 00:00:00 2001 From: Arvid Jakobsson Date: Fri, 25 Mar 2022 10:39:34 +0100 Subject: [PATCH 09/10] docs: ignore CHANGES-dev.rst and developer/metrics.csv --- docs/.gitignore | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/.gitignore b/docs/.gitignore index 9eabfea324e4..b6ed58b75939 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -15,4 +15,5 @@ tezos-client.html /api/errors.rst /shell/p2p_api.rst /user/default-acl.json -/CHANGES.rst +/CHANGES-dev.rst +/developer/metrics.csv -- GitLab From c2f2077a7c67bef99b72ce39d8799f9816e4e9b2 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 25 Mar 2022 23:50:35 +0100 Subject: [PATCH 10/10] doc: point to zcash instructions in howtouse --- docs/introduction/howtouse.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 88426ada0a3d..c841242b0212 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -123,6 +123,11 @@ connect to the network:: tezos-node identity generate +.. note:: + + If the node prompts you to install the Zcash parameter file, follow + the :ref`corresponding instructions `. + The identity comprises a pair of cryptographic keys that nodes use to encrypt messages sent to each other, and an antispam-PoW stamp proving that enough computing power has been -- GitLab