From d50b29139892251ff6e5bca67a53d1d1a53da7f7 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 4 Oct 2023 11:27:42 +0200 Subject: [PATCH 1/2] doc: move failing_noop to blocks_ops.rst --- docs/alpha/blocks_ops.rst | 30 +++++++++++++++++++++++------- docs/user/various.rst | 20 -------------------- 2 files changed, 23 insertions(+), 27 deletions(-) diff --git a/docs/alpha/blocks_ops.rst b/docs/alpha/blocks_ops.rst index 43bf2249a36e..bf6dfa2c46a9 100644 --- a/docs/alpha/blocks_ops.rst +++ b/docs/alpha/blocks_ops.rst @@ -32,18 +32,14 @@ operations`. This order also specifies the of each of these classes. Consensus operations are considered the highest priority ones, and manager operations the lowest. -The current protocol implementation enforces the following invariant: +As an exception, the :ref:`failing_noop` is currently the only operation not associated to any class. + +Overall, the current protocol implementation enforces the following invariant: - each kind of operation belongs to *at most one* validation pass; - operations whose kind does not belong to any validation pass cannot be :ref:`applied`. -.. FIXME tezos/tezos#3915: - - Failing noops don't fit within any of the validation passes - below. We need to change the structure a bit to be able to list - them here. - In the sequel, we describe the different classes of operations, and the different kinds of operations belonging to each class. @@ -259,3 +255,23 @@ Batches satisfy the following properties: atomically: all its operations are executed sequentially, without interleaving other operations. Either all the operations in the batch succeed, or none is applied. + +.. _failing_noop: + +Failing_noop operation +~~~~~~~~~~~~~~~~~~~~~~ + +Starting with protocol 009 a ``Failing_noop`` operation is added. This operation +is not executable in the protocol and will always fail when injected. It allows +to sign an arbitrary string that cannot be misinterpreted in the protocol. + +The client has commands to sign a message with a given key or to check that +message has been signed by a given key. These commands create a ``failing_noop`` +operation from the message that is being signed or checked. + +:: + + octez-client sign message "hello world" for + + octez-client check that message "hello world" was signed by to + produce diff --git a/docs/user/various.rst b/docs/user/various.rst index 8b00b41767e5..8175e23ef74b 100644 --- a/docs/user/various.rst +++ b/docs/user/various.rst @@ -64,23 +64,3 @@ indicates a recommended course of action. +-------------+----------------------------------------------------------------------------------+------------------------------------------------------------------+ | 255 | like 127 but an error and an error occurred during exit (e.g., ``kill -9``) | check output/logs, clean-up leftover files | +-------------+----------------------------------------------------------------------------------+------------------------------------------------------------------+ - -.. _failing_noop: - -Failing_noop operation ----------------------- - -Starting with protocol 009 a ``Failing_noop`` operation is added. This operation -is not executable in the protocol and will always fail when injected. It allows -to sign an arbitrary string that cannot be misinterpreted in the protocol. - -The client has commands to sign a message with a given key or to check that -message has been signed by a given key. These commands create a ``failing_noop`` -operation from the message that is being signed or checked. - -:: - - octez-client sign message "hello world" for - - octez-client check that message "hello world" was signed by to - produce -- GitLab From 5aee14fe5aa55ab1fb6377f1d1bdd1846cd0e95f Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 4 Oct 2023 16:45:37 +0200 Subject: [PATCH 2/2] doc: improve explanations of Failing_noop, including its precise semantics --- docs/alpha/blocks_ops.rst | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/docs/alpha/blocks_ops.rst b/docs/alpha/blocks_ops.rst index bf6dfa2c46a9..dda150522791 100644 --- a/docs/alpha/blocks_ops.rst +++ b/docs/alpha/blocks_ops.rst @@ -32,13 +32,7 @@ operations`. This order also specifies the of each of these classes. Consensus operations are considered the highest priority ones, and manager operations the lowest. -As an exception, the :ref:`failing_noop` is currently the only operation not associated to any class. - -Overall, the current protocol implementation enforces the following invariant: - -- each kind of operation belongs to *at most one* validation pass; -- operations whose kind does not belong to any validation pass cannot - be :ref:`applied`. +Each kind of operation belongs to exactly one validation pass, except for the :ref:`failing_noop` which belongs to no validation pass and therefore cannot be :ref:`applied`. In the sequel, we describe the different classes of operations, and the different kinds of operations belonging to each class. @@ -261,12 +255,15 @@ Batches satisfy the following properties: Failing_noop operation ~~~~~~~~~~~~~~~~~~~~~~ -Starting with protocol 009 a ``Failing_noop`` operation is added. This operation -is not executable in the protocol and will always fail when injected. It allows -to sign an arbitrary string that cannot be misinterpreted in the protocol. +The ``Failing_noop`` operation is not executable in the protocol: + +- it can only be validated in :ref:`mempool mode `, by the :doc:`prevalidator component <../shell/prevalidation>`; +- consequently, this operation cannot be :ref:`applied `, and in fact will never be included into a block. + +Rather, the ``Failing_noop`` operation allows +to sign an arbitrary string, without introducing an operation that could be misinterpreted in the protocol. -The client has commands to sign a message with a given key or to check that -message has been signed by a given key. These commands create a ``failing_noop`` +The Octez client provides commands to sign and verify the signature of input messages by a given key. These commands create a ``failing_noop`` operation from the message that is being signed or checked. :: -- GitLab