Vbot@bench context

.gitlab-ci.yml

@@ -118,6 +118,11 @@ unit:crypto:
   script:
     - dune build @src/lib_crypto/runtest
 
+unit:stdlib_unix:
+  <<: *test_definition
+  script:
+    - dune build @src/lib_stdlib_unix/runtest
+
 unit:protocol_environment:
   <<: *test_definition
   script:
@@ -133,6 +138,11 @@ unit:shell:
   script:
     - dune build @src/lib_shell/runtest
 
+unit:protocol_compiler:
+  <<: *test_definition
+  script:
+    - dune build @src/lib_protocol_compiler/runtest
+
 unit:src/bin_client:
   <<: *test_definition
   script:

CHANGES.md

@@ -1,3 +1,12 @@
+# Version 7.3
+
+- Fixed a case where the number of open file descriptors was not correctly limited.
+  This could result in the node crashing due to being out of file descriptors.
+
+- Set a limit to the length of some incoming messages which previously did not have one.
+
+- Fixed some value encodings which were missing cases.
+
 # Version 7.2
 
 - Fixed an error that could cause baking to fail when validating some smart contracts.

docs/doc_gen/node_helpers.ml

@@ -46,6 +46,7 @@ let with_node f =
         user_activated_upgrades = [];
         user_activated_protocol_overrides = [];
         patch_context = None;
+        data_dir = dir;
         store_root = dir / "store";
         context_root = dir / "context";
         protocol_root = dir / "protocol";

docs/releases/version-7.rst

@@ -1,6 +1,6 @@
 .. _version-7:
 
-Version 7.2
+Version 7.3
 ===========
 
 Version 7.0 notably introduces the multinetwork node.
@@ -12,18 +12,20 @@ Version 7.2 fixes an issue that could cause baking to fail when validating some
 smart contracts, and fixes how arguments are passed by the tezos-docker-manager.sh
 script when using Docker images.
 
+Version 7.3 fixes a couple of security issues.
+
 Update Instructions
 -------------------
 
 To update from sources::
 
   git fetch
-  git checkout v7.2
+  git checkout v7.3
   make build-deps
   eval $(opam env)
   make
 
-If you are using Docker instead, use the ``v7.2`` Docker images of Tezos.
+If you are using Docker instead, use the ``v7.3`` Docker images of Tezos.
 
 New Versioning Scheme
 ---------------------
@@ -44,7 +46,7 @@ Additionnally, we provide a ``latest-release`` branch which will always
 be equal to the latest release. Release candidates are not considered
 to be releases in this sense, so ``latest-release`` will never
 point to a release candidate. In other words, ``latest-release`` points
-to the latest stable release. Currently, it thus points to version 7.2.
+to the latest stable release. Currently, it thus points to version 7.3.
 
 If you are used to the ``mainnet`` and ``mainnet-staging`` branches,
 you can consider release candidates to be the new ``mainnet-staging``
@@ -54,8 +56,8 @@ branch.
 Note for Remote Signer Users
 ----------------------------
 
-Note for users of ``tezos-signer``: the 7.0 (or 7.1, or 7.2) client, baker, endorser
-and accuser need the 7.0 signer (or 7.1, or 7.2) to work. They are in particular not
+Note for users of ``tezos-signer``: the 7.0 (or above) client, baker, endorser
+and accuser need the 7.0 signer (or above) to work. They are in particular not
 compatible with the ``mainnet`` version of ``tezos-signer``. So remember to
 update your remote signer too!
 
@@ -77,6 +79,16 @@ this script has been renamed ``tezos-docker-manager.sh``. The ``alphanet.sh``
 script is still available in the Docker image for the auto-update mechanism.
 See :ref:`howtoget` for more information.
 
+Changelog — Version 7.3
+-----------------------
+
+- Fixed a case where the number of open file descriptors was not correctly limited.
+  This could result in the node crashing due to being out of file descriptors.
+
+- Set a limit to the length of some incoming messages which previously did not have one.
+
+- Fixed some value encodings which were missing cases.
+
 Changelog — Version 7.2
 -----------------------
 

docs/user/key-management.rst

@@ -31,25 +31,19 @@ Tezos Wallet app
 ~~~~~~~~~~~~~~~~
 
 Now on the client we can import the keys (make sure the device is
-in the Tezos Wallet app):
-
-::
+in the Tezos Wallet app)::
 
    ./tezos-client list connected ledgers
 
 You can follow the instructions to import the ledger private key and
 you can choose between the root or a derived address.
-We can confirm the addition by listing known addresses.
-
-::
+We can confirm the addition by listing known addresses::
 
    ./tezos-client import secret key my_ledger ledger://tz1XXXXXXXXXX
    ./tezos-client list known addresses
 
 Optional: we can check that our ledger signs correctly using the
-following command and confirming on the device:
-
-::
+following command and confirming on the device::
 
    tezos-client show ledger path ledger://tz1XXXXXXXXXX
 
@@ -72,13 +66,13 @@ only to bake for increasing levels.
 This prevents signing blocks at levels below the latest
 block signed.
 
-If you have tried the app on some network (Zeronet, Mainnet,...) and want to use it on another
-network you might need to reset this level with the command:
-
-::
+If you have tried the app on some network (Zeronet, Mainnet,...) and want to
+use it on another network you might need to reset this level with the command::
 
-   tezos-client set ledger high watermark for ledger://tz1XXXXXXXXXX to 0
+   tezos-client setup ledger to bake for my_ledger
 
+More details can be found on the `Tezos Ledger app
+<https://github.com/obsidiansystems/ledger-app-tezos>`_.
 
 .. _signer:
 
@@ -195,8 +189,6 @@ We strongly advice you to first **make a backup** and then
 transfer your tokens to a new pair of keys imported from a ledger (see
 :ref:`ledger`).
 
-Check the balance with:
-
-::
+Check the balance with::
 
     tezos-client get balance for alice

docs/user/mockup.rst

@@ -176,21 +176,44 @@ You can now edit the files ``bootstrap-accounts.json`` and
      --protocol-constants protocol-constants.json \
      --bootstrap-accounts bootstrap-accounts.json
 
+Setting protocol constants for the mockup mode
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Let's look at the contents of the ``protocol-constants.json`` file as produced
+by the ``config init mockup`` of ``config show mockup`` commands. The following
+was generated using the Carthage protocol:
+
+.. code-block:: JSON
+
+   { "hard_gas_limit_per_operation": "1040000",
+     "hard_gas_limit_per_block": "10400000",
+     "hard_storage_limit_per_operation": "60000",
+     "cost_per_byte": "1000",
+     "chain_id": "NetXynUjJNZm7wi",
+     "initial_timestamp": "1970-01-01T00:00:00Z" }
+
+By modifying the two first fields, a user can easily create a mockup environment
+with bumped up (or down) gas limits and storage limit. A invariant should be
+that the gas limit per block should be greater or equal to the gas limit per
+operation.  The ``cost_per_byte`` is used to compute the amount of tokens to be
+burnt proportionally to the fresh storage consumed by the execution of an
+operation.  The ``chain_id`` is used to prevent replay of operations between
+chains.  You can pick a chain id for your mockup environment using the following
+command: 
 
-Chain id
-~~~~~~~~
+::
 
-The `chain id` is one particular chain parameter that is also accessible from
-the command line at mockup creation.
+   $ tezos-client compute chain id from seed <string>
 
-For that, you need to use the `chain-id-seed` command-line switch, which will in
-turn initialize a valid `chain id`. The mockup creation command now becomes
+For instance, the following command:
 
 ::
 
-    tezos-client --protocol ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK \
-      --base-dir /tmp/mockup create mockup --chain-id-seed myseed
+   $ tezos-client compute chain id from seed strudel
+
+yields the chain id ``NetXwWbjfCqBTLV``.
 
 
-Among the response output to this command, there is a valid chain id
-`Chain id is NetXi1dwBfm6F4Y` initialized from your input.
+The last field,  ``initial_timestamp``, is the creation time of the first block
+of the chain. This date string follows the ISO-8601 standard format, which be
+generated by `date --iso-8601=seconds`.

instructions.md

@@ -0,0 +1,14 @@
+This is a mirror of vbot@bench_context on nomadic's remote.
+Here are the instructions :
+
+- Retrieve the data-dirs located at `data/ioana` on comanche ({full,archive}_store_BLAktkWruUqXNgHAiR7kLh4dMP96mGmQANDGagdHAsTXfqgvfiR_933914.tar.gz) and their md5 checks;
+- Also, copy the blocks you'll validate locally using the patched baker (/data/ioana/blocks_above_933913 on comanche);
+- Extract the data-dir somewhere, this will be your bench's initial state;
+- Checkout vbot@bench_context on nomadic's remote;
+- Generate a p2p identity in the data-dir: `./tezos-node identity generate --data-dir <data-dir>` (this can be your real "ready-to-use" initial state backup);
+- Start a node with no connections : `./tezos-node run --rpc-addr :8732 --no-bootstrap-peers --connections 0 --data-dir <data-dir>`;
+- Start the baker : `./tezos-baker-006-PsCARTHA run with local node <data-dir> <path_to/blocks_above_933913>`.
+
+This should simulate 2 RO (node + baker) and 1 RW (validator process) allowing you to bench. I also logged in the baker the time spent trying to validate the next block.
+
+A short explanation of the fake baker: instead of producing blocks out of the blue, the fake baker reads already produced blocks on mainnet (in the provided file), try to simulate the operations as it would have done if it was normally producing blocks (thus using the RO instance), and inject it to the node that will also validate it in its RW instance.

src/bin_client/main_admin.ml

@@ -38,8 +38,4 @@ let select_commands _ _ =
          Client_rpc_commands.commands;
          Client_event_logging_commands.commands () ])
 
-let () =
-  Client_main_run.run
-    ~log:(Log.fatal_error "%s")
-    (module Client_config)
-    ~select_commands
+let () = Client_main_run.run (module Client_config) ~select_commands

src/bin_client/main_client.ml

@@ -159,8 +159,4 @@ let select_commands ctxt {chain; block; protocol; _} =
   @ Mockup_commands.commands ()
   @ commands_for_version
 
-let () =
-  Client_main_run.run
-    ~log:(Log.fatal_error "%s")
-    (module Client_config)
-    ~select_commands
+let () = Client_main_run.run (module Client_config) ~select_commands

src/bin_node/main.ml

@@ -31,11 +31,6 @@ let () =
     prerr_endline "Non-64 bit architectures are not supported." ;
     exit 1 )
 
-let () =
-  let log s = Node_logging.fatal_error "%s" s in
-  Lwt_exit.exit_on ~log Sys.sigint ;
-  Lwt_exit.exit_on ~log Sys.sigterm
-
 let () =
   if Filename.basename Sys.argv.(0) = Updater.compiler_name then (
     try
@@ -48,7 +43,20 @@ let () =
 
 let () =
   if Filename.basename Sys.argv.(0) = "tezos-validator" then (
-    try Stdlib.exit (Lwt_main.run @@ Validator.main ())
+    try
+      let is_valid_directory =
+        Array.length Sys.argv = 3
+        && Sys.argv.(1) = "--socket-dir"
+        && Sys.file_exists Sys.argv.(2)
+        && Sys.is_directory Sys.argv.(2)
+      in
+      if not is_valid_directory then
+        invalid_arg
+          "Invalid arguments provided for the validator: expected \
+           'tezos-validator --socket-dir <dir>'." ;
+      Stdlib.exit
+        ( Lwt_main.run @@ Lwt_exit.wrap_and_forward
+        @@ Validator.main ~socket_dir:Sys.argv.(2) () )
     with exn ->
       Format.eprintf "%a\n%!" Opterrors.report_error exn ;
       Stdlib.exit 1 )