package tezos-protocol-014-PtKathma
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=7062cd57addd452852598a2214ade393130efa087b99068d53713bdf912b3680
sha512=08e4091144a03ce3c107fb91a66501bd8b65ca3278917c455a2eaac6df3e108ade63f6ab8340a4bb152d60f404326e464d0ec95d26cafe8e82f870465d24a5fc
doc/tezos-protocol-014-PtKathma.raw/Tezos_raw_protocol_014_PtKathma/Tx_rollup_l2_batch/index.html
Module Tezos_raw_protocol_014_PtKathma.Tx_rollup_l2_batchSource
This module introduces the batches of transactions that the layer-2 (1) reads from its inboxes (see Tx_rollup_message_repr.t.Batch), and (2) interprets off-chain.
One of the main concerns of the transaction rollups is to provide a high-throughput to its participants. That is, transaction rollups are expected to be able to process a significant number of operations “per second.”
Putting aside the computational power required by the rollup node, the main limit to the throughput of a transaction rollup is the number of operations that can fit in a Tezos block. As such, the number of bytes that are necessary to store the batches is of key importance.
To estimate the theoretical maximum throughput of the transaction rollups as a feature, we can use the following methodology:
- Determine the number of bytes that can be allocated to layer-2 batches in a Tezos block, under the hypothesis that only layer-2 batch submissions and the consensus-related operations are included in said block. Ideally, this needs to take into account the limitation of the size of a layer-2 batch imposed by the layer-1 protocol, and the size of the signature that comes with an individual batch.
- Divide this number by the average size of a layer-2 operation, this gives an estimate of the maximum layer-2 operations per block.
- Divide again the result by the average time (in seconds) between two Tezos blocks; the result is the theoretical maximum number of operations per second the transaction rollups allow to process.
That is, there is three parameters that decide the throughput of transaction rollups, and the average size of an operation is the only one under the control of the layer-2 implementation. Henceforth, both the definitions of types of this module and the implementation of their encodings have been carefully crafted in order to allow for compact batches.
type signer = | Bls_pk of Tezos_protocol_environment_014_PtKathma.Bls_signature.pk(*A signer identified by a BLS public key.
*)| L2_addr of Tx_rollup_l2_address.t(*A signer identified by a layer-2 address. Each such adress is in turn identified with a BLS public key.
*)
Represents the signer of an layer-2 operation. This is either a BLS public key or a layer-2 address index, whose metadata in turn contains a corresponding BLS public. key
Layer-2 Batches Definitions
The operations are versioned, to let the possibility to propose new features in future iterations of the protocol.
Versioning
To pave the road towards being able to update the semantics of the transaction rollups without having to interfere with the rejection mechanism, we preemptively back the notion of semantics versioning into the definition of a layer-2 batch.
val encoding :
(Indexable.unknown, Indexable.unknown) t
Tezos_protocol_environment_014_PtKathma.Data_encoding.tAn encoding for t that uses a specialized, space-efficient encoding for the list of transactions.