diff --git a/docs/api/openapi.rst b/docs/api/openapi.rst index 09361d2c74efe342971b3ceb1c03d6e684e23e8d..6593602e70e7189fca82bd2f7aebccb6e95cfa02 100644 --- a/docs/api/openapi.rst +++ b/docs/api/openapi.rst @@ -50,7 +50,7 @@ Their OpenAPI specification can be found at: - `rpc-openapi.json (version 16.1) `_ -- `rpc-openapi-beta.json (version 17.0~beta1) `_ +- `rpc-openapi-beta.json (version 17.0~beta1) `_ .. TODO tezos/tezos#2170: add/remove section(s) diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index a7c27bf39c32bef9582371bb909eb757b8738be3..d2dbe2d87a1d19853ce06f33a0d33c6f12587dc7 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -22,6 +22,8 @@ After a successful compilation, you should have the following binaries: note that prior to v12 of Octez, there was also an endorser daemon ``octez-endorser-*``; - ``octez-signer``: a client to remotely sign operations or blocks (see :ref:`signer`); +- ``octez-smart-rollup-{client,node}-*``: executables for using and running a smart rollup as Layer 2 (see :doc:`../active/smart_rollups`) +- ``octez-smart-rollup-wasm-debugger``: debugger for smart rollup kernels (see :doc:`../active/smart_rollups`) - ``octez-proxy-server``: a readonly frontend to ``octez-node`` designed to lower the load of full nodes (see :doc:`../user/proxy-server`) - ``octez-codec``: a utility for documenting the data encodings and for performing data encoding/decoding (see `Codec`_) - ``octez-protocol-compiler``: a domain-specific compiler for Tezos protocols (see `Protocol compiler`_) diff --git a/docs/releases/version-17.rst b/docs/releases/version-17.rst index b03cba9295310c6d92b5351da27364ad7ff0c92f..62b8345033ccc29ffbe65fb9125444ec7e8ba1ea 100644 --- a/docs/releases/version-17.rst +++ b/docs/releases/version-17.rst @@ -3,7 +3,7 @@ Version 17.0~beta1 .. warning:: - For now, this is a `beta` version, it is not intended to be the stable version for Octez v17.0. Please use it only on testnets, such as `ghostnet` or `nairobinet`. + For now, this is a ``beta`` version, it is not intended to be the stable version for Octez v17.0. Please use it only on testnets, such as ghostnet or nairobinet. Please check :doc:`the release system documentation<./releases>` for more information. Version 17.0 contains a new version (V9) of the protocol environment, diff --git a/docs/shell/storage.rst b/docs/shell/storage.rst index 51425c59caf913dcfb3347a4ba5e38c745b7f9db..f2df7ce8fdf8fc93efa238583e31bc956b00c6e4 100644 --- a/docs/shell/storage.rst +++ b/docs/shell/storage.rst @@ -69,7 +69,7 @@ present but only the 10 most recent cemented cycles will have some metadata kept (see details at :ref:`History_mode_additional_cycles`). Older metadata is pruned. -Starting with Octez v15, the store also triggers *context pruning* when a cycle is completed, after finishing the store trimming and cementing. +Starting with Octez v15.0, the store also triggers *context pruning* when a cycle is completed, after finishing the store trimming and cementing. Thus, whenever pruning the metadata of a block, its context (ledger state associated to that block) is pruned as well. For the operational details of pruning, see :ref:`first_pruning`. diff --git a/docs/shell/the_big_picture.rst b/docs/shell/the_big_picture.rst index 76357d7b206e1295d2561a4589628169c7b51bb6..fc746d59688f557a1a38526f941d750667c64e5f 100644 --- a/docs/shell/the_big_picture.rst +++ b/docs/shell/the_big_picture.rst @@ -306,6 +306,8 @@ run them. The Final Executables ~~~~~~~~~~~~~~~~~~~~~ +The Octez executables are generated from packages such as the following ones (for the complete list of binaries, see :ref:`tezos_binaries`): + - :package:`octez-node` provides the node launcher binary ``octez-node``. All the algorithmic being implemented in the shell, this package only implements the node's CLI. It also diff --git a/docs/user/fa12.rst b/docs/user/fa12.rst index 9ca64adec111a35fc6333dbe321a193fc1a2edad..defe647c496ae11de15eed5632d29addeec3b564 100644 --- a/docs/user/fa12.rst +++ b/docs/user/fa12.rst @@ -25,7 +25,7 @@ supply. The Michelson interface is then described by the following entrypoints: Multiple implementations of such a standard exist within the ecosystem. For example, one is provided with the `TZIP-007 specification `_. -`Edukera `_ and +`Edukera `_ and `camlCase `_ both provide a contract that implements the standard, and both have been verified using the `Mi-Cho-Coq `_ framework (see related :gl:`merge diff --git a/docs/user/logging.rst b/docs/user/logging.rst index 568f0e1ac5f8b7698d210bb60c69a44a74dea662..8401ef34c21980a5305079d1a52679265b044648 100644 --- a/docs/user/logging.rst +++ b/docs/user/logging.rst @@ -1,13 +1,19 @@ Logging ======= -Logging features in Octez allow to monitor its execution and be informed in real -time about *events* of interest, such as errors, completion of certain steps, +Logging features in Octez allow to monitor the execution of Octez binaries, informing in real +time about events of interest, such as errors, completion of certain steps, etc. This is why various software components emit *events* throughout the codebase (see :doc:`../developer/event_logging_framework`), the logging framework dispatches them to an arbitrary number of (active) *sinks* which can filter print, store, or otherwise handle events. +The logging framework can be configured with environment variables, which specify how events are mapped to sinks. +Some Octez binaries provide additional configurations means. + +Events +------ + Events have: - a *name* @@ -202,9 +208,13 @@ where ```` is either ``no-section`` or Global Defaults --------------- +By default, the Octez binaries generate **user logs** as follows: + - ``lwt-log://`` sinks are activated by default and configured to output events of level at least ``Notice``. Their goal is the stdout logging. +The node additionally generates by default more detailed **internal logs** as follows: + - A file-descriptor-sink is activated to store logs from last seven days with an ``Info`` level. The path is ``/daily-logs/``. @@ -231,7 +241,7 @@ Environment Variables --------------------- The logging framework can be configured with environment variables -before starting the node. Those variables work on all the code using the +before starting an Octez executable (e.g., the node). Those variables work on all the code using the ``tezos-stdlib-unix`` library as long as ``Internal_event_unix.init`` is called; this should include *all* the regular ``octez-*`` binaries. @@ -268,6 +278,8 @@ environment variable, see :ref:`context_component`. Node-Specific Configuration --------------------------- +The node supports some additional means to configure logging, besides environment variables. + Configuration File ~~~~~~~~~~~~~~~~~~ @@ -311,8 +323,8 @@ events) this call adds a sink to suddenly start pretty-printing all octez-client rpc put /config/logging with \ '{ "active_sinks": [ "file-descriptor-path:///tmp/rpclogs?section-prefix=rpc:debug&format=pp&fresh=true" ] }' -Client and Baking Daemons -------------------------- +Client and baker configuration +------------------------------ For now, ``octez-client``, ``octez-{baker,accuser}-*``, etc. can only be configured using the environment variables. diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index 6eb3772ac6a5b12b55a6f0aa8d34dbed8547d0d4..4d96f40da52684aa0ee8978373d3fd5e937243c4 100644 --- a/docs/user/snapshots.rst +++ b/docs/user/snapshots.rst @@ -138,17 +138,17 @@ snapshot file name can be given as an additional argument. For example: .. note:: - If your node's current storage was created with Octez v13 (or - earlier), it is not compatible with the context pruning storage - layout, and therefore it is no longer possible to export a storage - snapshot. + If your node's current storage was created with Octez v13.0 (or + earlier versions), it is not compatible with the context pruning + storage layout, and therefore it is no longer possible to export a + storage snapshot. In order to benefit from recent storage features and optimizations, it is strongly recommended to restart your node with the latest Octez version and with a fresh, up-to-date storage -- either by importing a recent snapshot (that is, exported by an Octez node - version >= v13 and = v13.0), or by bootstrapping from scratch if this is not + possible. Rolling export ~~~~~~~~~~~~~~ diff --git a/src/proto_alpha/lib_protocol/script_interpreter.mli b/src/proto_alpha/lib_protocol/script_interpreter.mli index c491cceaae80e1327978b2d6c24bafb876d8ceb4..193a5c4d5b2aa10af9f007071807bef379bc5f22 100644 --- a/src/proto_alpha/lib_protocol/script_interpreter.mli +++ b/src/proto_alpha/lib_protocol/script_interpreter.mli @@ -78,7 +78,7 @@ type step_constants = Script_typed_ir.step_constants = { This will update the local storage of the contract [step_constants.self]. Other pieces of contextual information - ([sender], [payer], [amount], and [chaind_id]) are also passed in + ([sender], [payer], [amount], and [chain_id]) are also passed in [step_constant]. [internal] is [true] if and only if the execution happens within an