diff --git a/docs/.gitignore b/docs/.gitignore index 9eabfea324e4c9b30e97ba9c3295247d47f36150..b6ed58b759392fe475f663682043d85f69ca1671 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 diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 372619ee218ffc354a9040a2b075af2999494206..ea3f163139a69380e8d23c08fad2b9d5e28fdd72 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/developer/guidelines.rst b/docs/developer/guidelines.rst index 54e8a630aa156702fa9d121d5f7dcad4ceb450ee..98f49f67fa98dcf6a222a74ef0c26a9e58579e43 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/developer/time_measurement_ppx.rst b/docs/developer/time_measurement_ppx.rst index 52854999f445f7e6b07b7053722c9cb6563832e4..4177bcd2c51aca414035011d2b3855a41a1573de 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 diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 88426ada0a3d135023aec6fd60b603554290aebf..c841242b0212af297c2a7164282b1495c25251ca 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 diff --git a/docs/ithaca/consensus.rst b/docs/ithaca/consensus.rst index a60d3eda98d83fa2cfbcba3f5aa6578d7160d004..94603241ed60534684cdfe6cdb9bfc3c1808c50d 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`` diff --git a/docs/protocols/tenderbake.rst b/docs/protocols/tenderbake.rst index 4a7aec7aac680b97800f4fc13459f3555c82f9bb..ef352650fd1e6c2f186ef892845142904516f871 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. diff --git a/docs/releases/version-12.rst b/docs/releases/version-12.rst index 526783081b7f5556c65741f5b50835a97ac42f8b..fcabe8224dec988e47ba0f7703e47959d9fdf245 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 --------- diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index 8871c4fdd00df1e6c0fbac22967ab245bb390c36..e9b177da224ae35cb4ed12a1d1e808ca8ed91e8d 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`. diff --git a/src/lib_lwt_result_stdlib/bare/structs/list.ml b/src/lib_lwt_result_stdlib/bare/structs/list.ml index 73b0aaaeac9ecfb52e7a372601ebbeab4b2fe20e..0c618aab1a98e97a8ca30674f730ffb5ef274312 100644 --- a/src/lib_lwt_result_stdlib/bare/structs/list.ml +++ b/src/lib_lwt_result_stdlib/bare/structs/list.ml @@ -23,24 +23,24 @@ (* *) (*****************************************************************************) -(* 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 - 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 diff --git a/src/lib_store/consistency.ml b/src/lib_store/consistency.ml index 76b8206b5c09e87e462b6d0be092803bd00e63c1..3c41fa55c6695e514b3b2039981edda1501f66fc 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/src/proto_alpha/lib_protocol/constants_repr.mli b/src/proto_alpha/lib_protocol/constants_repr.mli index 0a9160a7840c6cceda158a9c601f52dad6a18181..41a5cf7ff61de4a097d0bc58cfa1f4e585277340 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 35e736a0f32ec547feb04a2a2199fb7a02354342..cb9b0ab5f7c1347dc2aefb2f4baefd91923d99b1 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] diff --git a/tezt/manual_tests/migration_voting.ml b/tezt/manual_tests/migration_voting.ml index 5b60660b51ba027684a49c4df3696fd149416d10..907681ad4d50fb6e98ecbbbd2d3ae51a5d2b6cf5 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