diff --git a/docs/010/consensus.rst b/docs/010/consensus.rst index 9c619867def7f589f193aa0ac349b476770b0c14..53fe408595df1f86ed95119b35f391ad81dd5ae7 100644 --- a/docs/010/consensus.rst +++ b/docs/010/consensus.rst @@ -323,7 +323,7 @@ Note that these parameters are part of the larger set of :ref:`protocol constant - ``ENDORSEMENT_SECURITY_DEPOSIT`` - 2.5 ꜩ -Since blocks are at least ``TIME_BETWEEN_BLOCKS[0]``, that is 30 seconds apart, +Since blocks are at least ``MINIMAL_BLOCK_DELAY``, that is 30 seconds apart, and since a cycle has ``BLOCKS_PER_CYCLE``, that is :ref:`8192 blocks`, a cycle lasts *at least* 2 days, 20 hours, and 16 minutes, and ``PRESERVED_CYCLES`` cycles, that is 5 cycles, last *at least* 14 diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 6f1d6e219fcf06f899112501d9a3b66ef818507d..b03e44feb3a328946514a8ea2653c404eb82fea8 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -319,7 +319,7 @@ Note that these parameters are part of the larger set of :ref:`protocol constant - ``ENDORSEMENT_SECURITY_DEPOSIT`` - 2.5 ꜩ -Since blocks are at least ``TIME_BETWEEN_BLOCKS[0]``, that is 30 seconds apart, +Since blocks are at least ``MINIMAL_BLOCK_DELAY``, that is 30 seconds apart, and since a cycle has ``BLOCKS_PER_CYCLE``, that is :ref:`8192 blocks`, a cycle lasts *at least* 2 days, 20 hours, and 16 minutes, and ``PRESERVED_CYCLES`` cycles, that is 5 cycles, last *at least* 14 diff --git a/docs/alpha/timelock.rst b/docs/alpha/timelock.rst index 7724081f02e21ce580b5ecfc580516ed25d9d3ad..1c4fca2e8c842a7dc450a93e81e110f43216e006 100644 --- a/docs/alpha/timelock.rst +++ b/docs/alpha/timelock.rst @@ -40,14 +40,14 @@ Either the author of the ciphertext produces a plaintext (and a proof of correct decryption) by providing a secret trapdoor (the factorization of an RSA modulus in our case). Otherwise a sequential computation can decrypt the ciphertext after a computation -requiring $T$ sequential operations (modular squaring in our case), -for some pre-determined constant :math:`T`. +requiring ``T`` sequential operations (modular squaring in our case), +for some pre-determined constant ``T``. -In addition, a proof of the correctness of the decryption can also be produced and checked in sub linear time ($\log T$ in our case). +In addition, a proof of the correctness of the decryption can also be produced and checked in sub linear time (``log T`` in our case). By experimentally measuring the time the sequential operation takes on available hardware using optimized implementation, we can estimate -a rough conversion (or a bound in our case) between the constant $T$ and +a rough conversion (or a bound in our case) between the constant ``T`` and wall clock time. We also note that the `VDF alliance `_ has been working on producing an ASIC for squaring in an RSA group to ensure a level playing field in terms of computational speed. @@ -83,7 +83,7 @@ Cryptographic principles Users first generate a RSA modulus and a symmetric encryption key. They use authenticated encryption to encrypt a packed Michelson value (an array of bytes computed with ``PACK``) and encrypt that encryption key using a timelock puzzle. -They then combine the RSA modulus, the timelocked symmetric key, the constant T +They then combine the RSA modulus, the timelocked symmetric key, the constant ``T`` and the encrypted value as a single value as well (called chest in our library in :src:`src/lib_crypto`). A proof of decryption can be the symmetric key itself. diff --git a/docs/developer/guidelines.rst b/docs/developer/guidelines.rst index 800ef833a93646f5572e6a46c21781a4cfd09427..b33f8cdd0d7d772886ffc3a56ebe17b9ca7e7bf9 100644 --- a/docs/developer/guidelines.rst +++ b/docs/developer/guidelines.rst @@ -356,7 +356,7 @@ to call it over a public network. If the answer is yes, you should probably consider adding the new endpoint to the ACL. If there are also risks related to calling the endpoint by a potentially malicious user, they should be weighed when making the decision too. There are no simple answers here. Remember that -all new endpoints are **blocked be default** unless explicitly added to the ACL. +all new endpoints are **blocked by default** unless explicitly added to the ACL. When changing an existing public RPC endpoint it is also important to consider, how does the change impact possible risks related to calling the endpoint. @@ -405,6 +405,7 @@ Notice that we use only one version number for both input and output of an RPC. .. _RPC-versioning-dev-adding-an-rpc: + How to Add a New Version to an RPC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -452,7 +453,7 @@ like the two examples below. .. code-block:: json - { + { "bar": { "baz": 10 } diff --git a/docs/developer/howto-freeze-protocols.rst b/docs/developer/howto-freeze-protocols.rst index 33503f162ac25dee09abd4747e50a40c2a9341c1..07f82c955e11ef4c69f4e4d531a16dc1139e5ecf 100644 --- a/docs/developer/howto-freeze-protocols.rst +++ b/docs/developer/howto-freeze-protocols.rst @@ -51,7 +51,7 @@ Remove Testnets From ``tezos-docker-manager.sh`` ------------------------------------------------ Mentions of the protocol's testnests should be removed from the script -:src:`script/ci/tezos-docker-manager.sh`. +:src:`scripts/tezos-docker-manager.sh`. Remove Testnet From ``bin_node`` -------------------------------- @@ -64,7 +64,7 @@ The protocol plugin registration module should be removed from :src:`src/bin_node/dune` and :src:`src/bin_node/tezos-node.opam`. Remove Protocol From Python Tests of Current Protocol -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +----------------------------------------------------- Tests ``test_voting_full.py`` and ``test_migration.py`` from the current protocol should be removed. Any mention of the protocol in @@ -102,4 +102,3 @@ In particular it should mention: - that the protocol's daemons were removed; - that the corresponding ``--network`` alias was removed. - diff --git a/docs/index.rst b/docs/index.rst index 91a05e7d0afd4f5c585d7a343629e9e31c8ab28f..16a2112d17c7c4bc0d29e3475f04e40336a95722 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -198,6 +198,7 @@ in the :ref:`introduction `. developer/error_monad developer/michelson_anti_patterns developer/entering_alpha + developer/howto-freeze-protocols developer/protocol_environment developer/protocol_environment_upgrade developer/event_logging_framework diff --git a/docs/scripts/check_proto_xrefs.py b/docs/scripts/check_proto_xrefs.py index 84694ba67847cf020d08562009baf7fe59a64de9..c307f30bc0fe130ce3c02af184eb61aea23b2c50 100755 --- a/docs/scripts/check_proto_xrefs.py +++ b/docs/scripts/check_proto_xrefs.py @@ -76,7 +76,7 @@ for file in glob.glob(f"{directory}/*.rst"): ref_pat = re.compile(r':ref:`([^`]+)`', flags=re.DOTALL) ref_lbl_desc_pat = re.compile(r'<(.+)>$') ref_file_pat = re.compile(r'[.](rst|html)$') -sphinx_id_pat = re.compile(r'[\w-]+') +sphinx_id_pat = re.compile(r'[\w.-]+') for file in glob.glob(f"{directory}/*.rst"): with open(file, mode="r", encoding="utf-8") as f: txt = f.read() # read all file contents diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index c077113bbdb43f153f25e3d30af9c5af67f497f6..3db86455c3cbd410dc11cbdabce71cae2448f499 100644 --- a/docs/user/node-configuration.rst +++ b/docs/user/node-configuration.rst @@ -192,7 +192,7 @@ is applied to the local host by default. :: - $ tezos-node run --rpc-addr localhost:8732 --rpc-addr 192.168.0.3:8732 + $ tezos-node run --rpc-addr localhost:8732 --rpc-addr 192.168.0.3:8732 In this example the RPC is available to both ``localhost`` and to the local network (assuming the node does have address ``192.168.0.3`` in that network). diff --git a/docs/user/versioning.rst b/docs/user/versioning.rst index 530f4423821b72908e622b605016f2252df8100e..a8c9d18a9123068b01511f646b6011016783a1d0 100644 --- a/docs/user/versioning.rst +++ b/docs/user/versioning.rst @@ -11,12 +11,13 @@ The whole Octez software is versioned by releases, see :doc:`../releases/release Protocol versions ----------------- -The Tezos economic protocol is versioned at a different pace, according to a :doc:`active/voting`, see :doc:`../protocols/naming`. +The Tezos economic protocol is versioned at a different pace, according to a :doc:`voting process <../active/voting>`, see :doc:`../protocols/naming`. Protocol environment versions ----------------------------- The economic protocol can interact with the rest of the Octez software through a sandboxed API called a protocol environment. When new features are needed by a proposed protocol, a new environment version is created, see `Protocol environment versions `__. +The new environment is delivered as part of a new Octez release. RPC Versioning @@ -79,4 +80,3 @@ For example:: The version 4 for RPC GET chains/main/mempool/pending_operations is deprecated and may be removed in the next major release of Octez. - diff --git a/scripts/b58_prefix/README.md b/scripts/b58_prefix/README.md index 9b0f3e1b5300fbea2dfd3ef55316f692cc387138..930236dc2f89b1a40fe3afbdff8534d15ecf4ed3 100644 --- a/scripts/b58_prefix/README.md +++ b/scripts/b58_prefix/README.md @@ -100,8 +100,8 @@ poetry install ``` # A tz1 address is generated from a fixed size hash of 20 characters. poetry run python b58_prefix.py --prefix tz1 --length 20 -# A block is generated from a fixed size hash of 20 characters. # Output: Base58 size: 36. Version bytes: [6, 161, 159] +# A block is generated from a fixed size hash of 32 characters. poetry run python b58_prefix.py --prefix B --length 32 # Output: Base58 size: 51. Version bytes: [1, 43] ```