diff --git a/docs/Makefile b/docs/Makefile index b626b3ad276594aa7064ce0c810b4cf52285a2a9..fec7318382711f53dc350729e2805e90ab63e401 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -53,14 +53,11 @@ html: octez-gen docexes-gen @../octez-baker-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ %/octez-accuser.html: @../octez-accuser-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ -%/octez-smart-rollup-node.html: - @../octez-smart-rollup-node-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@ manuals: \ $(PROTOCOLS:%=%/octez-client.html) \ $(PROTOCOLS:%=%/octez-baker.html) \ - $(PROTOCOLS:%=%/octez-accuser.html) \ - $(PROTOCOLS:%=%/octez-smart-rollup-node.html) + $(PROTOCOLS:%=%/octez-accuser.html) # generic @../octez-admin-client man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/octez-admin-client.html @../octez-signer man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/octez-signer.html @@ -124,8 +121,8 @@ redirectcheck: # - on the active protocol using its numeric name (not the "active" symlink) # - on each other protocol including alpha, also checking label defs (option -l) xrefscheck: - $(CHECKXREFS) paris $(CHECKXREFS) oxford + $(CHECKXREFS) -l paris $(CHECKXREFS) -l alpha installcheck: diff --git a/docs/alpha/cli-commands.rst b/docs/alpha/cli-commands.rst index 420008c547f5b10b6dd00e33c9f1913914963ff8..38bf04030e044dd26cea8df498849fee55762c96 100644 --- a/docs/alpha/cli-commands.rst +++ b/docs/alpha/cli-commands.rst @@ -39,9 +39,3 @@ Accuser manual .. raw:: html :file: octez-accuser.html - -Smart rollup node manual -======================== - -.. raw:: html - :file: octez-smart-rollup-node.html diff --git a/docs/api/openapi.rst b/docs/api/openapi.rst index 4e8776b0d701d6e651d4e820b5bc9ff9fa351c42..4d7263651b6f6b6419745f091a00834c918d3870 100644 --- a/docs/api/openapi.rst +++ b/docs/api/openapi.rst @@ -103,7 +103,7 @@ Oxford RPCs The OpenAPI specifications for the RPCs of the smart rollup node for the Oxford (``Proxford``) protocol can be found at: -- `oxford-smart-rollup-node-openapi.json (version 19.1) +- `oxford-smart-rollup-node-openapi.json (version 19.2) `_ - `oxford-smart-rollup-node-openapi.json (version 20.0~rc1) diff --git a/docs/index.rst b/docs/index.rst index a2da105e929b97220a9aa7fb164fc88228baa813..660c9c9ac33f98a50832999df9731a995f89615c 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -25,10 +25,10 @@ capability. This means that, unlike other blockchains like Bitcoin or Ethereum, Tezos comes to consensus not only about the state of its ledger, but also about how the protocol and the nodes should adapt and upgrade. -This is a fundamental design choice, allowing Tezos to be seamlessly upgradable and continuosly evolving. +This is a fundamental design choice, allowing Tezos to be seamlessly upgradable and continuously evolving. Due to this feature, Tezos is built to last, and always stay at the leading edge of blockchain technology. -To learn more about Tezos, the `Tezos documentation `__. +To learn more about Tezos, see . To learn more about how Octez & the protocol fit into Tezos and its ecosystem, see :doc:`introduction/tezos`. @@ -40,9 +40,9 @@ To learn more about how Octez & the protocol fit into Tezos and its ecosystem, s Getting started
-**Newcomer to Octez?** Start participating to Tezos using Octez! +**Newcomer to Octez?** Start participating in Tezos using Octez! -Start participating to Tezos by following the ``Introduction`` section in the documentation menu. +Start participating in Tezos by following the ``Introduction`` section in the documentation menu. These tutorials explain: diff --git a/docs/oxford/cli-commands.rst b/docs/oxford/cli-commands.rst index 4ff974257a9c81b01490909075b5064cf9c3364a..72682756c8f790d001f72b66dbf34da65a06c3f8 100644 --- a/docs/oxford/cli-commands.rst +++ b/docs/oxford/cli-commands.rst @@ -42,9 +42,3 @@ Accuser manual .. raw:: html :file: octez-accuser.html - -Smart rollup node manual -======================== - -.. raw:: html - :file: octez-smart-rollup-node.html diff --git a/docs/paris/cli-commands.rst b/docs/paris/cli-commands.rst index fdfc9319ba01a0047b5f728627f4274217dd8ddf..e759afd11657d2fa8f40b46c452773b91930e70e 100644 --- a/docs/paris/cli-commands.rst +++ b/docs/paris/cli-commands.rst @@ -39,9 +39,3 @@ Accuser manual .. raw:: html :file: octez-accuser.html - -Smart rollup node manual -======================== - -.. raw:: html - :file: octez-smart-rollup-node.html diff --git a/docs/releases/version-19.rst b/docs/releases/version-19.rst index f4348f59012942b677fc556f443d284a594417a6..152299d06e25c9d0ccbf424c8b172a79b790dbdb 100644 --- a/docs/releases/version-19.rst +++ b/docs/releases/version-19.rst @@ -70,7 +70,7 @@ The keys in the Smart Rollup client use the same format as the Octez client. They can be imported with ``octez-client import secret key ``, or by merging the key files between the ``octez-client`` base directory and the ``smart-rollup-client-`` base directory. -The Smart Rollup node now allows multiple :ref:`batcher keys `. Setting multiple +The Smart Rollup node now allows :ref:`multiple batcher keys `. Setting multiple keys for the batching purpose allows to inject multiple operations of the same kind per block by the rollup node. diff --git a/docs/shell/smart_rollup_node.rst b/docs/shell/smart_rollup_node.rst index dec66d33542f136170fdb23ade6d6f8eb2fba803..31226dec7486ce410e0f12d7ba40ecf430da0c85 100644 --- a/docs/shell/smart_rollup_node.rst +++ b/docs/shell/smart_rollup_node.rst @@ -194,8 +194,6 @@ First, we need to decide on a mode the rollup node will run: rollup node will accept transactions in its queue and batch them on the Layer 1. -.. _rollup_batcher: - #. ``batcher`` means that the rollup node will accept transactions in its queue and batch them on the Layer 1. In this mode, the rollup node follows the Layer 1 chain, but it does not update its state @@ -248,27 +246,26 @@ The table below summarises the modes and their associated purposes: +-------------+------------+----------+------------+------------+------------------+ | | Operating | Batching | Cementing | Recovering | Executing_outbox | +=============+============+==========+============+============+==================+ -| Operator | Yes | Yes | Yes | No | Yes[^1]_ | +| Operator | Yes | Yes | Yes | No | Yes [#f1]_ | +-------------+------------+----------+------------+------------+------------------+ -| Maintenance | Yes | No | Yes | No | Yes[^1]_ | +| Maintenance | Yes | No | Yes | No | Yes [#f1]_ | +-------------+------------+----------+------------+------------+------------------+ -| Bailout | Yes[^2]_ | No | Yes | Yes | No | +| Bailout | Yes [#f2]_ | No | Yes | Yes | No | +-------------+------------+----------+------------+------------+------------------+ -| Accuser | Yes [^3]_ | No | No | No | No | +| Accuser | Yes [#f3]_ | No | No | No | No | +-------------+------------+----------+------------+------------+------------------+ | Batcher | No | Yes | No | No | No | +-------------+------------+----------+------------+------------+------------------+ | Observer | No | No | No | No | No | +-------------+------------+----------+------------+------------+------------------+ -.. [^1] If and only it's a private rollup. In that case, only the +.. [#f1] If and only it's a private rollup. In that case, only the whitelist update outbox message are injected. -.. [^2] A rollup node in bailout mode won't publish any new commitments but only +.. [#f2] A rollup node in bailout mode won't publish any new commitments but only defends the one published by the operator if they are refuted. -.. [^3] An accuser node will publish commitments only when it detects +.. [#f3] An accuser node will publish commitments only when it detects conflicts; for such cases it must make a deposit of 10,000 tez. - Then to run the rollup node, use the following command: .. code:: sh @@ -304,14 +301,15 @@ capping the number of L2 messages that the rollup node's batcher purpose can inject per block to the maximum size of one L1 operation's maximal size (e.g., 32kb on mainnet). +.. _rollup_batcher_keys: + To bypass that limitation and inject multiple ``smart_rollup_add_messages`` L1 operations within a single L1 block, it is possible to provide multiple keys for the batcher purpose of a rollup node. At each block, the rollup node will use as many keys as possible to inject a corresponding number of queued L2 messages into -the L1 rollup inbox[^1]. - -[^1]: The order of the batches of L2 messages is not guaranteed to be +the L1 rollup inbox. +The order of the batches of L2 messages is not guaranteed to be preserved by the rollup node nor by the octez node mempool. The way to provide multiple batcher keys on the command line is: