From e2a60e97f65e84fb2cc97a80f2cbbac147b0bc23 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 3 May 2024 16:39:46 +0200 Subject: [PATCH 1/6] fix section structure --- docs/alpha/smart_rollups.rst | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index add886dc6d14..3cf804bedf6a 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -8,6 +8,9 @@ documentation, we will generally refer to the rollup under consideration as the Layer 2 on top of the Tezos blockchain, considered as the Layer 1. +Overview +^^^^^^^^ + Rollups are a permissionless scaling solution for the Tezos blockchain. Indeed, anyone can originate and operate one or more rollups, allowing to increase the throughput of the Tezos blockchain, @@ -25,6 +28,9 @@ punish someone who has published an invalid claim. Therefore, thanks to the refutation mechanism, a single honest participant is enough to guarantee that the input messages are correctly interpreted. +Kernel +^^^^^^ + In the Tezos protocol, the subsystem of smart rollups is generic with respect to the syntax and the semantics of the input messages. More precisely, the originator of a smart rollup provides a program named a @@ -49,8 +55,8 @@ use case though: they are fully programmable, hence their names, smart optimistic rollups, as they are very close to smart contracts in terms of expressiveness. -Overview --------- +User roles +^^^^^^^^^^ Just like smart contracts, smart rollups are decentralized software components. However, contrary to smart contracts that are processed @@ -344,7 +350,7 @@ logic, an outbox message can only be executed when the associated commitment has been cemented (see :doc:`../shell/smart_rollup_node`). Glossary --------- +^^^^^^^^ #. **PVM**: A Proof-generating Virtual Machine is a reference implementation for a device on top of which a smart rollup can be -- GitLab From 74596155f6fea1c8ea33173a6013335480af7b66 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 6 May 2024 11:01:35 +0200 Subject: [PATCH 2/6] doc: rename (rollup) staker to committer --- docs/alpha/smart_rollups.rst | 38 ++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 3cf804bedf6a..37c7b8cc3ebc 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -179,7 +179,7 @@ A smart rollup is characterized by: - the Michelson type of the entrypoint used by Layer 1 smart contracts to send internal messages to it, and - an optional list of addresses used as a white-list of allowed -stakers (see :ref:`private_rollups_alpha`). +committers (see :ref:`private_rollups_alpha`). All these characteristics are provided when originating a new smart rollup. @@ -234,11 +234,15 @@ is only one honest commitment. In other words, if two distinct commitments are published for the same commitment period, one of them must be wrong. -Notice that, to publish a commitment, an operator must provide a -deposit of 10,000 tez. For this reason, the operator is said to be a -**staker**. Several users can stake on the same commitment. When a -staker *S* publishes a new commitment based on a commitment that *S* is staking -on, *S* does not have to provide a new deposit: the deposit also +An operator publishing a commitment is called a **committer**. +Notice that, to publish a commitment, the operator must provide a +deposit of 10,000 tez. For this reason, the committer is sometimes called a +(smart rollup) *staker*. However, to avoid confusion with the notion of +:ref:`staker ` in Layer 1, we will prefer using the term "committer" in this documentation. + +Several committers can publish (and thus stake on) the same commitment. When a +committer *C* publishes a new commitment based on a commitment that *C* +has published, *C* does not have to provide a new deposit: the deposit also applies to this new commitment. There is no need to synchronize between operators: if two honest @@ -282,7 +286,7 @@ By construction, only one view of the rollup state is valid (as the PVM is deterministic). When two concurrent branches exist in the commitment tree, the cementation process is stopped at the first fork in the tree. To unfreeze the cementation process, a **refutation -game** must be started between *two concurrent stakers* of these +game** must be started between *two concurrent committers* of these branches. Refutation games are automatically played by rollup nodes to defend their stakes: honest participants are guaranteed to win these games. Therefore, an honest participant should not have to worry about @@ -291,19 +295,19 @@ new commitments to be published on top of the disputed commitments. A refutation game is decomposed into two main steps: a dissection mechanism and a final conflict resolution phase. During the first -phase, the two stakers exchange hashes about intermediate states of +phase, the two committers exchange hashes about intermediate states of the rollups in a way that allows them to converge to the very first tick on which they disagree. The exact number of hashes exchanged at a -given step is PVM-dependent. During the final phase, the stakers must +given step is PVM-dependent. During the final phase, the committers must provide a proof that they correctly interpreted this conflicting tick. The Layer 1 PVM then determines whether these proofs are valid. There -are only two possible outcomes: either one of the stakers, that we dub *S* in the sequel, has provided -a valid proof, then *S* wins the game, and is rewarded with half of the -opponent's deposit (the other half being burnt); or, both stakers have +are only two possible outcomes: either one of the committers, that we dub *C* in the sequel, has provided +a valid proof, then *C* wins the game, and is rewarded with half of the +opponent's deposit (the other half being burnt); or, both committers have provided an invalid proof and they both lose their deposit. In the end, at most one stake will be kept in the commitment tree. When a -commitment has no more stake on it (because all stakers have lost the +commitment has no more stake on it (because all committers have lost the related refutation games), it is removed from the tree. An honest player *H* must therefore play as many refutation games as there are stakes on the commitments in conflict with *H*'s own commitment. @@ -317,7 +321,7 @@ two players can last at most 2 weeks. There is no timeout for starting a refutation game after having published a concurrent commitment. However, assuming the existence of an honest participant *H*, then *H* will start the refutation game with all -concurrent stakers to avoid the rollup getting stuck. +concurrent committers to avoid the rollup getting stuck. .. _private_rollups_alpha: @@ -327,7 +331,7 @@ Private rollups A **private** Smart Rollup guarantees that private data cannot be leaked by any means, whereas in a public rollup, one can force a rollup to leak part of the data by starting a refutation game. This is -achieved by restricting the set of allowed stakers using a +achieved by restricting the set of allowed committers using a *whitelist*. With that restriction, only addresses on the whitelist can publish commitments and therefore participate in a refutation game. @@ -377,8 +381,8 @@ Glossary #. **Refutation period**: When the first commitment for a commitment period is published, a refutation period of two weeks starts to allow this commitment to be challenged. -#. **Staker**: A user account that has made a deposit on a +#. **Committer**: A user account that has published and has made a deposit on a commitment. #. **Refutation game**: A process by which the Tezos protocol solves - a conflict between two stakers. + a conflict between two committers. -- GitLab From 2771108f821e2b3abb8d350535dfc5c83a2cc96e Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 6 May 2024 11:32:43 +0200 Subject: [PATCH 3/6] doc: make local glossary self-contained --- docs/alpha/smart_rollups.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 37c7b8cc3ebc..7703d9d7a972 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -373,11 +373,19 @@ Glossary cemented (hence, at least two weeks after the actual execution of the operation). +#. **Commitment**: a claim that the interpretation of all inbox messages + published during a given period, and applied on the state of + a parent commitment, led to a given new state by performing a given + number of execution steps of the PVM. + #. **Commitment period**: A period of roughly 15 minutes (currently 112 blocks) during which all inbox messages must be processed by the rollup node state to compute a commitment. A commitment must be published for each commitment period. +#. **Rollup node**: a daemon required for deploying and operating smart rollups. + The rollup node is responsible for making the rollup progress by publishing commitments and by playing refutation games. + #. **Refutation period**: When the first commitment for a commitment period is published, a refutation period of two weeks starts to allow this commitment to be challenged. -- GitLab From 0e9dea87467cc60b902512c2586d58f78cf7b638 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 6 May 2024 15:21:07 +0200 Subject: [PATCH 4/6] doc: qualify some terms before globalizing them --- docs/alpha/smart_rollups.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 7703d9d7a972..0b6c9e991ae1 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -363,34 +363,34 @@ Glossary of rollups. The PVM is able to produce proofs enforcing this truth. This ability is used during the final step of refutation games. -#. **Inbox**: A sequence of messages from the Layer 1 to smart rollups. +#. **Rollup Inbox**: A sequence of messages from the Layer 1 to smart rollups. The contents of the inbox are determined by the consensus of the Tezos protocol. -#. **Outbox**: A sequence of messages from a smart rollup to the Layer 1. +#. **Rollup Outbox**: A sequence of messages from a smart rollup to the Layer 1. Messages are smart contract calls, potentially containing tickets. - These calls can be triggered only when the related commitment is + These calls can be triggered only when the related rollup commitment is cemented (hence, at least two weeks after the actual execution of the operation). -#. **Commitment**: a claim that the interpretation of all inbox messages +#. **Rollup Commitment**: a claim that the interpretation of all rollup inbox messages published during a given period, and applied on the state of - a parent commitment, led to a given new state by performing a given + a parent rollup commitment, led to a given new state by performing a given number of execution steps of the PVM. -#. **Commitment period**: A period of roughly 15 minutes (currently 112 blocks) during which all inbox +#. **Commitment period**: A period of roughly 15 minutes (currently 112 blocks) during which all rollup inbox messages must be processed by the rollup node state to compute a - commitment. A commitment must be published for each commitment + rollup commitment. A commitment must be published for each commitment period. #. **Rollup node**: a daemon required for deploying and operating smart rollups. The rollup node is responsible for making the rollup progress by publishing commitments and by playing refutation games. -#. **Refutation period**: When the first commitment for a commitment period is published, a refutation +#. **Refutation period**: When the first rollup commitment for a commitment period is published, a refutation period of two weeks starts to allow this commitment to be challenged. -#. **Committer**: A user account that has published and has made a deposit on a +#. **Rollup Committer**: A user account that has published and has made a deposit on a commitment. #. **Refutation game**: A process by which the Tezos protocol solves - a conflict between two committers. + a conflict between two rollup committers. -- GitLab From 8f36160aec42b0ed94563b41cbc848ddce0c3978 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 6 May 2024 17:14:37 +0200 Subject: [PATCH 5/6] doc: merge rollup glossary into main glossary --- docs/alpha/glossary.rst | 68 ++++++++++++++++++++++++++++++------ docs/alpha/smart_rollups.rst | 54 ++++------------------------ 2 files changed, 63 insertions(+), 59 deletions(-) diff --git a/docs/alpha/glossary.rst b/docs/alpha/glossary.rst index 964bf118a0d6..7b8ab32a5db1 100644 --- a/docs/alpha/glossary.rst +++ b/docs/alpha/glossary.rst @@ -246,13 +246,10 @@ _`Layer 1` _`Layer 2` Layer 2 (L2) includes sidechains, rollups, payment channels, etc. that batch their transactions and - write to the `layer 1`_ chain. By processing transactions on layer 2 networks, + write to the `Layer 1`_ chain. By processing transactions on layer 2 networks, greater scalability in speed and throughput can be achieved by the ecosystem overall, since the number of transactions - the layer 1 can process directly is limited. By cementing transactions from a L2 to L1, - the security of the L1 chain backs those operations. In Tezos there are a number of layer 2 solutions, - including :doc:`Smart Optimistic Rollups `, - validity or ZK-Rollups `Epoxy `_ , - zkChannels, and sidechains such as `Deku `_. + the Layer 1 can process directly is limited. By cementing transactions from a L2 to L1, + the security of the L1 chain backs those operations. Currently, Layer 2 solutions on Tezos are built as `smart rollup`_\ s. _`Michelson` The built-in language used by a `smart contract`_. @@ -278,6 +275,58 @@ _`Origination` A manager operation_ whose purpose is to create -- that is, to deploy -- a `smart contract`_ on the Tezos blockchain. +_`PVM` + A PVM (Proof-generating Virtual Machine) is a reference + implementation for a device on top of which a `smart rollup`_ can be + executed. This reference implementation is part of the `economic + protocol`_ and is the unique source of truth regarding the semantics + of rollups. The PVM is able to produce proofs enforcing this truth. + This ability is used during the final step of a `refutation game`_. + +_`Refutation game` + A process by which the `economic protocol`_ solves a conflict between two + `rollup committer`_\ s. + Note that the refutation mechanism used in Tezos `smart rollup`_\ s corresponds to the notion of `fraud proofs `__ used in other blockchain/Layer 2 ecosystems. + +_`Refutation period` + When the first `rollup commitment`_ for a `rollup commitment period`_ is published, a refutation + period of two weeks starts to allow this commitment to be challenged. + +_`Roll` + deprecated; see `minimal stake`_. + +_`Rollup commitment` + A claim that the interpretation of all `rollup inbox`_ messages + published during a given period, and applied on the state of + a parent rollup commitment, led to a given new state by performing a given + number of execution steps of the `PVM`_. + +_`Rollup commitment period` + A period of roughly 15 minutes during which all `rollup inbox`_ + messages must be processed by the `rollup node`_ state to compute a + `rollup commitment`_. A commitment must be published for each commitment + period. + +_`Rollup committer` + A `user account`_ that has published and made a deposit on a + `rollup commitment`_. + +_`Rollup inbox` + A sequence of messages from the Layer 1 to all the `smart rollup`_\ s. + The contents of the inbox are determined by the consensus of the + `economic protocol`_. + +_`Rollup node` + A daemon required for deploying and operating `smart rollup`_\ s. + The rollup node is responsible for making the rollup progress by publishing `rollup commitment`_\ s and by playing `refutation game`_\ s. + +_`Rollup outbox` + A sequence of messages from a `smart rollup`_ to the Layer 1. + Messages are `smart contract`_ calls, potentially containing tickets. + These calls can be triggered only when the related `rollup commitment`_ is + cemented (hence, at least two weeks after the actual execution of + the operation). + .. _def_round_alpha: _`Round` @@ -288,9 +337,6 @@ _`Round` the round's corresponding time span. Baking_ outside of one's designated round results in an invalid block_. -_`Roll` - deprecated; see `minimal stake`_. - _`Smart contract` Account_ which is associated to a Michelson_ script. They are created with an @@ -298,8 +344,8 @@ _`Smart contract` originated accounts. The address of a smart contract always starts with the letters ``KT1``. -_`Smart Optimistic Rollups` - Smart optimistic rollups constitute a `layer 2`_ solution that can be used to deploy either a general-purpose polyvalent layer 2 blockchain +_`Smart Rollup` + Smart rollups constitute a `Layer 2`_ solution that can be used to deploy either a general-purpose polyvalent Layer 2 blockchain (e.g., an EVM-compatible one), or an application-specific DApp. See :doc:`smart_rollups`. diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 0b6c9e991ae1..00851be17ae5 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -11,7 +11,7 @@ considered as the Layer 1. Overview ^^^^^^^^ -Rollups are a permissionless scaling solution for the Tezos +Smart rollups are a permissionless scaling solution for the Tezos blockchain. Indeed, anyone can originate and operate one or more rollups, allowing to increase the throughput of the Tezos blockchain, (almost) arbitrarily. @@ -28,8 +28,8 @@ punish someone who has published an invalid claim. Therefore, thanks to the refutation mechanism, a single honest participant is enough to guarantee that the input messages are correctly interpreted. -Kernel -^^^^^^ +Rollup kernel +^^^^^^^^^^^^^ In the Tezos protocol, the subsystem of smart rollups is generic with respect to the syntax and the semantics of the input messages. More @@ -235,10 +235,10 @@ commitments are published for the same commitment period, one of them must be wrong. An operator publishing a commitment is called a **committer**. -Notice that, to publish a commitment, the operator must provide a +Notice that, in order to publish a commitment, the operator must freeze a deposit of 10,000 tez. For this reason, the committer is sometimes called a -(smart rollup) *staker*. However, to avoid confusion with the notion of -:ref:`staker ` in Layer 1, we will prefer using the term "committer" in this documentation. +(smart rollup) *staker*. However, in order to avoid confusion with the +:ref:`staker ` role in Tezos Layer 1's Proof-of-Stake mechanism, we prefer to use the term "committer" throughout this documentation. Several committers can publish (and thus stake on) the same commitment. When a committer *C* publishes a new commitment based on a commitment that *C* @@ -352,45 +352,3 @@ own access control list logic to add and remove addresses. Also, it is important to remember that because of the refutation logic, an outbox message can only be executed when the associated commitment has been cemented (see :doc:`../shell/smart_rollup_node`). - -Glossary -^^^^^^^^ - -#. **PVM**: A Proof-generating Virtual Machine is a reference - implementation for a device on top of which a smart rollup can be - executed. This reference implementation is part of the Tezos - protocol and is the unique source of truth regarding the semantics - of rollups. The PVM is able to produce proofs enforcing this truth. - This ability is used during the final step of refutation games. - -#. **Rollup Inbox**: A sequence of messages from the Layer 1 to smart rollups. - The contents of the inbox are determined by the consensus of the - Tezos protocol. - -#. **Rollup Outbox**: A sequence of messages from a smart rollup to the Layer 1. - Messages are smart contract calls, potentially containing tickets. - These calls can be triggered only when the related rollup commitment is - cemented (hence, at least two weeks after the actual execution of - the operation). - -#. **Rollup Commitment**: a claim that the interpretation of all rollup inbox messages - published during a given period, and applied on the state of - a parent rollup commitment, led to a given new state by performing a given - number of execution steps of the PVM. - -#. **Commitment period**: A period of roughly 15 minutes (currently 112 blocks) during which all rollup inbox - messages must be processed by the rollup node state to compute a - rollup commitment. A commitment must be published for each commitment - period. - -#. **Rollup node**: a daemon required for deploying and operating smart rollups. - The rollup node is responsible for making the rollup progress by publishing commitments and by playing refutation games. - -#. **Refutation period**: When the first rollup commitment for a commitment period is published, a refutation - period of two weeks starts to allow this commitment to be challenged. - -#. **Rollup Committer**: A user account that has published and has made a deposit on a - commitment. - -#. **Refutation game**: A process by which the Tezos protocol solves - a conflict between two rollup committers. -- GitLab From 6998b3cce35e56133c50ec1466168851083c3588 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 10 Jun 2024 16:31:33 +0200 Subject: [PATCH 6/6] doc: backport changes to Paris --- docs/paris/glossary.rst | 68 +++++++++++++++++++++++++----- docs/paris/smart_rollups.rst | 80 +++++++++++++----------------------- 2 files changed, 85 insertions(+), 63 deletions(-) diff --git a/docs/paris/glossary.rst b/docs/paris/glossary.rst index c7664c99b3c2..c1d8fa3f373f 100644 --- a/docs/paris/glossary.rst +++ b/docs/paris/glossary.rst @@ -259,13 +259,10 @@ _`Layer 1` _`Layer 2` Layer 2 (L2) includes sidechains, rollups, payment channels, etc. that batch their transactions and - write to the `layer 1`_ chain. By processing transactions on layer 2 networks, + write to the `Layer 1`_ chain. By processing transactions on layer 2 networks, greater scalability in speed and throughput can be achieved by the ecosystem overall, since the number of transactions - the layer 1 can process directly is limited. By cementing transactions from a L2 to L1, - the security of the L1 chain backs those operations. In Tezos there are a number of layer 2 solutions, - including :doc:`Smart Optimistic Rollups `, - validity or ZK-Rollups `Epoxy `_ , - zkChannels, and sidechains such as `Deku `_. + the Layer 1 can process directly is limited. By cementing transactions from a L2 to L1, + the security of the L1 chain backs those operations. Currently, Layer 2 solutions on Tezos are built as `smart rollup`_\ s. _`Michelson` The built-in language used by a `smart contract`_. @@ -293,6 +290,58 @@ _`Origination` A manager operation_ whose purpose is to create -- that is, to deploy -- a `smart contract`_ on the Tezos blockchain. +_`PVM` + A PVM (Proof-generating Virtual Machine) is a reference + implementation for a device on top of which a `smart rollup`_ can be + executed. This reference implementation is part of the `economic + protocol`_ and is the unique source of truth regarding the semantics + of rollups. The PVM is able to produce proofs enforcing this truth. + This ability is used during the final step of a `refutation game`_. + +_`Refutation game` + A process by which the `economic protocol`_ solves a conflict between two + `rollup committer`_\ s. + Note that the refutation mechanism used in Tezos `smart rollup`_\ s corresponds to the notion of `fraud proofs `__ used in other blockchain/Layer 2 ecosystems. + +_`Refutation period` + When the first `rollup commitment`_ for a `rollup commitment period`_ is published, a refutation + period of two weeks starts to allow this commitment to be challenged. + +_`Roll` + deprecated; see `minimal stake`_. + +_`Rollup commitment` + A claim that the interpretation of all `rollup inbox`_ messages + published during a given period, and applied on the state of + a parent rollup commitment, led to a given new state by performing a given + number of execution steps of the `PVM`_. + +_`Rollup commitment period` + A period of roughly 15 minutes during which all `rollup inbox`_ + messages must be processed by the `rollup node`_ state to compute a + `rollup commitment`_. A commitment must be published for each commitment + period. + +_`Rollup committer` + An `implicit account`_ that has published and made a deposit on a + `rollup commitment`_. + +_`Rollup inbox` + A sequence of messages from the Layer 1 to all the `smart rollup`_\ s. + The contents of the inbox are determined by the consensus of the + `economic protocol`_. + +_`Rollup node` + A daemon required for deploying and operating `smart rollup`_\ s. + The rollup node is responsible for making the rollup progress by publishing `rollup commitment`_\ s and by playing `refutation game`_\ s. + +_`Rollup outbox` + A sequence of messages from a `smart rollup`_ to the Layer 1. + Messages are `smart contract`_ calls, potentially containing tickets. + These calls can be triggered only when the related `rollup commitment`_ is + cemented (hence, at least two weeks after the actual execution of + the operation). + .. _def_round: .. _def_round_paris: @@ -304,9 +353,6 @@ _`Round` the round's corresponding time span. Baking_ outside of one's designated round results in an invalid block_. -_`Roll` - deprecated; see `minimal stake`_. - _`Smart contract` Account_ which is associated to a Michelson_ script. They are created with an @@ -314,8 +360,8 @@ _`Smart contract` originated accounts. The address of a smart contract always starts with the letters ``KT1``. -_`Smart Optimistic Rollups` - Smart optimistic rollups constitute a `layer 2`_ solution that can be used to deploy either a general-purpose polyvalent layer 2 blockchain +_`Smart Rollup` + Smart rollups constitute a `Layer 2`_ solution that can be used to deploy either a general-purpose polyvalent Layer 2 blockchain (e.g., an EVM-compatible one), or an application-specific DApp. See :doc:`smart_rollups`. diff --git a/docs/paris/smart_rollups.rst b/docs/paris/smart_rollups.rst index 2100835a07a7..cf6c67571b82 100644 --- a/docs/paris/smart_rollups.rst +++ b/docs/paris/smart_rollups.rst @@ -8,7 +8,10 @@ documentation, we will generally refer to the rollup under consideration as the Layer 2 on top of the Tezos blockchain, considered as the Layer 1. -Rollups are a permissionless scaling solution for the Tezos +Overview +^^^^^^^^ + +Smart rollups are a permissionless scaling solution for the Tezos blockchain. Indeed, anyone can originate and operate one or more rollups, allowing to increase the throughput of the Tezos blockchain, (almost) arbitrarily. @@ -25,6 +28,9 @@ punish someone who has published an invalid claim. Therefore, thanks to the refutation mechanism, a single honest participant is enough to guarantee that the input messages are correctly interpreted. +Rollup kernel +^^^^^^^^^^^^^ + In the Tezos protocol, the subsystem of smart rollups is generic with respect to the syntax and the semantics of the input messages. More precisely, the originator of a smart rollup provides a program named a @@ -49,8 +55,8 @@ use case though: they are fully programmable, hence their names, smart optimistic rollups, as they are very close to smart contracts in terms of expressiveness. -Overview --------- +User roles +^^^^^^^^^^ Just like smart contracts, smart rollups are decentralized software components. However, contrary to smart contracts that are processed @@ -174,7 +180,7 @@ A smart rollup is characterized by: - the Michelson type of the entrypoint used by Layer 1 smart contracts to send internal messages to it, and - an optional list of addresses used as a white-list of allowed -stakers (see :ref:`private_rollups_paris`). +committers (see :ref:`private_rollups_paris`). All these characteristics are provided when originating a new smart rollup. @@ -229,11 +235,15 @@ is only one honest commitment. In other words, if two distinct commitments are published for the same commitment period, one of them must be wrong. -Notice that, to publish a commitment, an operator must provide a -deposit of 10,000 tez. For this reason, the operator is said to be a -**staker**. Several users can stake on the same commitment. When a -staker *S* publishes a new commitment based on a commitment that *S* is staking -on, *S* does not have to provide a new deposit: the deposit also +An operator publishing a commitment is called a **committer**. +Notice that, in order to publish a commitment, the operator must freeze a +deposit of 10,000 tez. For this reason, the committer is sometimes called a +(smart rollup) *staker*. However, in order to avoid confusion with the +:ref:`staker ` role in Tezos Layer 1's Proof-of-Stake mechanism, we prefer to use the term "committer" throughout this documentation. + +Several committers can publish (and thus stake on) the same commitment. When a +committer *C* publishes a new commitment based on a commitment that *C* +has published, *C* does not have to provide a new deposit: the deposit also applies to this new commitment. There is no need to synchronize between operators: if two honest @@ -277,7 +287,7 @@ By construction, only one view of the rollup state is valid (as the PVM is deterministic). When two concurrent branches exist in the commitment tree, the cementation process is stopped at the first fork in the tree. To unfreeze the cementation process, a **refutation -game** must be started between *two concurrent stakers* of these +game** must be started between *two concurrent committers* of these branches. Refutation games are automatically played by rollup nodes to defend their stakes: honest participants are guaranteed to win these games. Therefore, an honest participant should not have to worry about @@ -286,19 +296,19 @@ new commitments to be published on top of the disputed commitments. A refutation game is decomposed into two main steps: a dissection mechanism and a final conflict resolution phase. During the first -phase, the two stakers exchange hashes about intermediate states of +phase, the two committers exchange hashes about intermediate states of the rollups in a way that allows them to converge to the very first tick on which they disagree. The exact number of hashes exchanged at a -given step is PVM-dependent. During the final phase, the stakers must +given step is PVM-dependent. During the final phase, the committers must provide a proof that they correctly interpreted this conflicting tick. The Layer 1 PVM then determines whether these proofs are valid. There -are only two possible outcomes: either one of the stakers, that we dub *S* in the sequel, has provided -a valid proof, then *S* wins the game, and is rewarded with half of the -opponent's deposit (the other half being burnt); or, both stakers have +are only two possible outcomes: either one of the committers, that we dub *C* in the sequel, has provided +a valid proof, then *C* wins the game, and is rewarded with half of the +opponent's deposit (the other half being burnt); or, both committers have provided an invalid proof and they both lose their deposit. In the end, at most one stake will be kept in the commitment tree. When a -commitment has no more stake on it (because all stakers have lost the +commitment has no more stake on it (because all committers have lost the related refutation games), it is removed from the tree. An honest player *H* must therefore play as many refutation games as there are stakes on the commitments in conflict with *H*'s own commitment. @@ -312,7 +322,7 @@ two players can last at most 2 weeks. There is no timeout for starting a refutation game after having published a concurrent commitment. However, assuming the existence of an honest participant *H*, then *H* will start the refutation game with all -concurrent stakers to avoid the rollup getting stuck. +concurrent committers to avoid the rollup getting stuck. .. _private_rollups: .. _private_rollups_paris: @@ -323,7 +333,7 @@ Private rollups A **private** Smart Rollup guarantees that private data cannot be leaked by any means, whereas in a public rollup, one can force a rollup to leak part of the data by starting a refutation game. This is -achieved by restricting the set of allowed stakers using a +achieved by restricting the set of allowed committers using a *whitelist*. With that restriction, only addresses on the whitelist can publish commitments and therefore participate in a refutation game. @@ -344,37 +354,3 @@ own access control list logic to add and remove addresses. Also, it is important to remember that because of the refutation logic, an outbox message can only be executed when the associated commitment has been cemented (see :doc:`../shell/smart_rollup_node`). - -Glossary --------- - -#. **PVM**: A Proof-generating Virtual Machine is a reference - implementation for a device on top of which a smart rollup can be - executed. This reference implementation is part of the Tezos - protocol and is the unique source of truth regarding the semantics - of rollups. The PVM is able to produce proofs enforcing this truth. - This ability is used during the final step of refutation games. - -#. **Inbox**: A sequence of messages from the Layer 1 to smart rollups. - The contents of the inbox are determined by the consensus of the - Tezos protocol. - -#. **Outbox**: A sequence of messages from a smart rollup to the Layer 1. - Messages are smart contract calls, potentially containing tickets. - These calls can be triggered only when the related commitment is - cemented (hence, at least two weeks after the actual execution of - the operation). - -#. **Commitment period**: A period of roughly 15 minutes (currently 90 blocks) during which all inbox - messages must be processed by the rollup node state to compute a - commitment. A commitment must be published for each commitment - period. - -#. **Refutation period**: When the first commitment for a commitment period is published, a refutation - period of two weeks starts to allow this commitment to be challenged. - -#. **Staker**: An implicit account that has made a deposit on a - commitment. - -#. **Refutation game**: A process by which the Tezos protocol solves - a conflict between two stakers. -- GitLab