diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 2816d8507a10144196ed090b71907cd39a868274..7dbc919a1bf1d3f8fd556c483c8aca4eae1897d1 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -366,7 +366,7 @@ maximum 2333 extra endorsements it could have theoretically included.) Finally, 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 * 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 +included during that cycle has been ``2,123,456`` slots. Given that this number is 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. @@ -380,7 +380,7 @@ validator does not reveal its nonce by the end of the cycle, it does not receive its endorsing 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)endorses (which means voting on two different proposals at the -same level and round), the frozen deposit is slashed. The slashed amount for double baking +same level and round), a part of the frozen deposit is slashed. The slashed amount for double baking is ``DOUBLE_BAKING_PUNISHMENT``. The slashed amount for double (pre)endorsing is a fixed percentage ``RATIO_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_ENDORSEMENT`` of the frozen deposit. The payload producer that includes the misbehavior diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 775025997911d0e75a0a19a3d3e3c5b1bd212fb7..86bb19c7a08ebcce611532c464548b52b2464ab6 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -575,7 +575,8 @@ the following WASM program in text format. (local.get $hello_length))))) This program can be compiled to the WASM binary format with -general-purpose tool like [WABT](https://github.com/WebAssembly/wabt). +general-purpose tool like +`WABT `_. :: diff --git a/docs/developer/protocol_environment_upgrade.rst b/docs/developer/protocol_environment_upgrade.rst index ef20886f8cc22a3a798921bf2a30ce8678eb310e..35736d8b10a6fbef02df18dc2e1c8ad909cf2758 100644 --- a/docs/developer/protocol_environment_upgrade.rst +++ b/docs/developer/protocol_environment_upgrade.rst @@ -105,6 +105,7 @@ And finally, bump environment version in ``src/proto_alpha/lib_protocol/TEZOS_PR For an example, check `the MR in which the environment V6 was activated `__. +Additionally, you have to update the documentation of protocol Alpha to reflect the fact that it now uses environment ``V``. For that, see meta-issue :gl:`#4155`, which explains all the necessary changes (don't worry, the changes are very limited). Making changes in the environment --------------------------------- diff --git a/docs/kathmandu/consensus.rst b/docs/kathmandu/consensus.rst index ef9e48cbfbaf74289fe5eac7331e6f49e1eb7505..fea11638d740b438b1832d4102da1757e152387f 100644 --- a/docs/kathmandu/consensus.rst +++ b/docs/kathmandu/consensus.rst @@ -371,7 +371,7 @@ maximum 2333 extra endorsements it could have theoretically included.) Finally, 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 * 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 +included during that cycle has been ``2,123,456`` slots. Given that this number is 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. @@ -386,7 +386,7 @@ validator does not reveal its nonce by the end of the cycle, it does not receive its endorsing 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)endorses (which means voting on two different proposals at the -same level and round), the frozen deposit is slashed. The slashed amount for double baking +same level and round), a part of the frozen deposit is slashed. The slashed amount for double baking is ``DOUBLE_BAKING_PUNISHMENT``. The slashed amount for double (pre)endorsing is a fixed percentage ``RATIO_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_ENDORSEMENT`` of the frozen deposit. The payload producer that includes the misbehavior diff --git a/docs/lima/consensus.rst b/docs/lima/consensus.rst index 48ceaf456918758a390e8bb777f0113762591899..502dcc23b7f55e4530fed0df898dc6663b558ae5 100644 --- a/docs/lima/consensus.rst +++ b/docs/lima/consensus.rst @@ -366,7 +366,7 @@ maximum 2333 extra endorsements it could have theoretically included.) Finally, 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 * 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 +included during that cycle has been ``2,123,456`` slots. Given that this number is 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. @@ -380,7 +380,7 @@ validator does not reveal its nonce by the end of the cycle, it does not receive its endorsing 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)endorses (which means voting on two different proposals at the -same level and round), the frozen deposit is slashed. The slashed amount for double baking +same level and round), a part of the frozen deposit is slashed. The slashed amount for double baking is ``DOUBLE_BAKING_PUNISHMENT``. The slashed amount for double (pre)endorsing is a fixed percentage ``RATIO_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_ENDORSEMENT`` of the frozen deposit. The payload producer that includes the misbehavior diff --git a/docs/user/sandbox.rst b/docs/user/sandbox.rst index 82afef2c5d9f7b360c33f69471781af3f916cdbb..2c9fb74969cefda7bd0083f4430cb4af42bbed23 100644 --- a/docs/user/sandbox.rst +++ b/docs/user/sandbox.rst @@ -56,7 +56,7 @@ preconfigured for communicating with the same-numbered node. When you bootstrap a new network, the network is initialized with a dummy economic protocol, called `genesis`. If you want to run the whole implemented protocol, ``init-sandboxed-client`` also defines an -alias ``tezos-activate-alpha``, that you need to execute once for +alias ``octez-activate-alpha``, that you need to execute once for activating the whole network. For instance: @@ -64,7 +64,7 @@ For instance: $ octez-client rpc get /chains/main/blocks/head/metadata "next_protocol": "Ps9mPmXaRzmzk35gbAYNCAw6UXdE2qoABTHbN2oEEc1qM7CwT9P" - $ tezos-activate-alpha + $ octez-activate-alpha Injected BMV9KnSPE1yw $ octez-client rpc get /chains/main/blocks/head/metadata "protocol": "Ps9mPmXaRzmzk35gbAYNCAw6UXdE2qoABTHbN2oEEc1qM7CwT9P" @@ -115,7 +115,7 @@ binary. Tune protocol Alpha parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The ``tezos-activate-alpha`` alias uses parameters from +The ``octez-activate-alpha`` alias uses parameters from ``src/proto_alpha/parameters/sandbox-parameters.json`` to activate protocol Alpha. It can be useful to tune these parameters when you need to debug something, for example, change the number of blocks per cycle, the time between diff --git a/src/lib_store/shared/store_events.ml b/src/lib_store/shared/store_events.ml index 02c3af17231a98b4be564a0dee9c44cf302c3c5f..ff91d1aed8dbef623dd606e04d79f84d48f20a7c 100644 --- a/src/lib_store/shared/store_events.ml +++ b/src/lib_store/shared/store_events.ml @@ -226,7 +226,7 @@ let context_gc_is_not_allowed = ~level:Warning ~name:"gc_is_not_allowed" ~msg: - "garbage collection is not fully enable on this data directory: context \ + "garbage collection is not fully enabled on this data directory: context \ cannot be garbage collected. Please read the documentation or import a \ snapshot to enable it" () diff --git a/src/lib_webassembly/runtime/input_buffer.mli b/src/lib_webassembly/runtime/input_buffer.mli index e07a2d57840af203404a0b9c1ccd13fcdc1920aa..ccfdce1991f864033475337d174888628f65d7e8 100644 --- a/src/lib_webassembly/runtime/input_buffer.mli +++ b/src/lib_webassembly/runtime/input_buffer.mli @@ -30,8 +30,6 @@ val num_elements : t -> Z.t (** [reset buffer] removes the current contents of the buffer. *) val reset : t -> unit -(* TODO: #3340 Note that op does not clean up the list. *) - (** [dequeue buffer] pops the current message from buffer and returns it. Note that the input buffer models a FIFO queue so the current message is the oldest in the queue. If the queue is empty it raises diff --git a/src/proto_alpha/bin_sc_rollup_node/state.mli b/src/proto_alpha/bin_sc_rollup_node/state.mli index 0e27e37dbaf8ad86e90805a46d853c1e4a67e73c..0b6e426bf6bd9f593859b00eebfdccc245fe153b 100644 --- a/src/proto_alpha/bin_sc_rollup_node/state.mli +++ b/src/proto_alpha/bin_sc_rollup_node/state.mli @@ -53,6 +53,6 @@ val hash_of_level : _ Store.t -> int32 -> Tezos_crypto.Block_hash.t Lwt.t val level_of_hash : _ Store.t -> Tezos_crypto.Block_hash.t -> int32 tzresult Lwt.t -(** [set_block_level_and_has store head] registers the correspondences +(** [set_block_level_and_hash store head] registers the correspondences [head.level |-> head.hash] and [head.hash |-> head.level] in the store. *) val set_block_level_and_hash : Store.rw -> Layer1.head -> unit Lwt.t diff --git a/src/proto_alpha/lib_protocol/test/helpers/dummy_zk_rollup.ml b/src/proto_alpha/lib_protocol/test/helpers/dummy_zk_rollup.ml index e6eb55c04cb9842f2c0d9ff765a5ee104ff4b033..085fcd9a70574073e21898671b2bd85a531d2a8d 100644 --- a/src/proto_alpha/lib_protocol/test/helpers/dummy_zk_rollup.ml +++ b/src/proto_alpha/lib_protocol/test/helpers/dummy_zk_rollup.ml @@ -346,10 +346,10 @@ end) : sig Plonk.Main_protocol.verifier_public_parameters * Plonk.Main_protocol.transcript - (** [craft_update state ~zk_rollup ?private_ops public_ops] will apply - first the [public_ops], then the [private_ops]. While doing so, - the public inputs for every circuit will be collected. A Plonk proof - of correctness of the application these operations is created. *) + (** [craft_update state ~zk_rollup ?private_ops ?exit_validities public_ops] + will apply first the [public_ops], then the [private_ops]. While doing so, + the public inputs for every circuit will be collected. A Plonk proof of + correctness of the application these operations is created. *) val craft_update : Zk_rollup.State.t -> zk_rollup:Zk_rollup.t ->