Updated and simplified info on Smart Rollups #163
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
timothymcmackin
force-pushed
the
architecture-overview
branch
from
14caf45 to
528b833
Compare
timothymcmackin
force-pushed
the
architecture-overview-smart-rollups
branch
from
4ef850c to
a3ce162
Compare
timothymcmackin
changed the title
timothymcmackin
force-pushed
the
architecture-overview-smart-rollups
branch
from
04f11d0 to
95da4d8
Compare
timothymcmackin
force-pushed
the
architecture-overview-smart-rollups
branch
from
95da4d8 to
5241a07
Compare
timothymcmackin
force-pushed
the
architecture-overview-smart-rollups
branch
from
6785b93 to
331c29a
Compare
docs/architecture/accounts.md
Outdated
| @@ -11,11 +11,11 @@ Tezos uses these types of accounts: | |||
| These accounts have addresses that start with "tz1", "tz2", "tz3" or "tz4." | |||
| Any wallet application or the Octez command-line tool can create implicit accounts. | |||
|
|
|||
| - Smart contract accounts (also known as _originated accounts_) store immutable code, mutable storage, tez (ꜩ), and tickets. | |||
| - Smart contract accounts (a type of _originated account_) store immutable code, mutable storage, tez (ꜩ), and tickets. | |||
There was a problem hiding this comment.
this implies that there are other types of originated accounts, which I don't think is true?
There was a problem hiding this comment.
Are Smart Rollup accounts not originated accounts?
There was a problem hiding this comment.
As told in a different thread, I don't think they are. If we want to reclassify them as accounts, we have to discuss this in a documentation venue (e.g. EffortDoc).
There was a problem hiding this comment.
I'm removing changes to this file from this PR and I'm working on clarifying accounts and addresses in this pr: #252
docs/architecture/smart-rollups.mdx
Outdated
| ## Examples | ||
| Smart Rollups play a crucial part in providing high scalability on Tezos. | ||
| They handle transactions and logic in a separate environment that doesn't need to follow all of the same rules as the main Tezos network. | ||
| For this reason, they are not subject to the same block delays and data space constraints as the main Tezos network. |
There was a problem hiding this comment.
This is also a bit misleading.
Rollups by themselves are still subject to the same block delays of the L1 network. In order to be processed, data that allows to retrieve L2 transactions (either directly or by using a Data availability solution, see below) must be posted to the rollup inbox on the L1.
Data space constraints require a data availability solution which is separate from rollups. Smart rollups, however, integrate with two data availability solutions: the Data Availability Layer (DAL) and Data Availability Committees (DACs), the latter via a mechanism called the reveal data channel.
There was a problem hiding this comment.
How about "They handle logic in a separate environment that can run transactions at a much higher rate and can use larger amounts of data than the main Tezos network."
docs/architecture/smart-rollups.mdx
Outdated
| For examples of Smart Rollups, see this repository: https://gitlab.com/tezos/kernel-gallery. | ||
| The transactions and logic that Smart Rollups run is called _layer 2_ to differentiate it from the main network, which is called _layer 1_. | ||
|
|
||
| The compiled code of a Smart Rollup must be provided publicly, so that anyone can run a Smart Rollup node to execute that code and verify that other nodes are running it correctly, just like anyone can run nodes, bakers, and accusers on layer 1. |
There was a problem hiding this comment.
In practice, because of the space constraints on the L1, only a small kernel (the installer kernel) is used to originate a rollup. This code is public as it is stored on the L1. The first action of the installer kernel is that of installing a larger kernel, whose code is imported using the reveal data channel. The blockchain itself does not guarantee the availability of this data, and instead it is the responsibility of the originator of the rollup to make it available to rollup operators.
There was a problem hiding this comment.
I think the installer kernel and kernel are too detailed for this intro, so I changed this sentence to:
Anyone can run a node based on a Smart Rollup to execute its code and verify that other nodes are running it correctly, just like anyone can run nodes, bakers, and accusers on layer 1.
docs/architecture/smart-rollups.mdx
Outdated
| The transactions and logic that Smart Rollups run is called _layer 2_ to differentiate it from the main network, which is called _layer 1_. | ||
|
|
||
| The compiled code of a Smart Rollup must be provided publicly, so that anyone can run a Smart Rollup node to execute that code and verify that other nodes are running it correctly, just like anyone can run nodes, bakers, and accusers on layer 1. | ||
| This code, called the _kernel_, must behave in a deterministic manner and according to a given semantics, which guarantees that results are reproducible by any rollup node with the same kernel. |
There was a problem hiding this comment.
Deterministic execution is ensured by the reference PVM, so it is virtually impossible to write a kernel that behaves non-deterministically
There was a problem hiding this comment.
Changed to:
This code, called the kernel, runs in a deterministic manner...
docs/architecture/smart-rollups.mdx
Outdated
|
|
||
| - Smart Rollups allow you to run large amounts of processing and manipulate large amounts of data that would be too slow or expensive to run on layer 1. | ||
|
|
||
| - Smart Rollups are not constrained to the layer 1 block baking rate and therefore can run far more transactions per second than layer 1. |
There was a problem hiding this comment.
This is not entirely true. Without a "sequencer", a rollup receives input by following L1 blocks and hence are subject to the same baking rate.
There was a problem hiding this comment.
But they can run a lot of logic in between blocks, so they aren't constrained by putting every transaction into a block. Is there a way to explain how/why L2 nodes can run "far more TPS" or should I simplify this to say "Smart Rollups can run far more transactions per second..."?
There was a problem hiding this comment.
Changed to "Smart Rollups can run far more transactions per second than layer 1."
Co-authored-by: NicNomadic <[email protected]>
Co-authored-by: NicNomadic <[email protected]>
Simplified info on Smart Rollups to what makes sense for Tezos developers on docs.tezos.com. Preview: https://docs-staging-git-architecture-overview-smart-rollups-trili-tech.vercel.app/architecture/smart-rollups
The PR includes this new diagram: https://lucid.app/documents/embedded/3953825e-e5aa-43bb-bc43-701bb0ac3b73#