package tezos-protocol-alpha
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=43723d096307603703a1a89ed1b2eb202b365f5e7824b96b0cbf813b343a6cf7
sha512=b2a637f2e965000d3d49ad85277ca24d6cb07a1a7cf2bc69d296d8b03ad78c3eaa8e21e94b9162e62c2e11649cd03bc845b2a3dafe623b91065df69d47dc8e4f
doc/tezos-protocol-alpha.raw/Tezos_raw_protocol_alpha/Tx_rollup_l2_batch/index.html
Module Tezos_raw_protocol_alpha.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_alpha.Bls.Public_key.t(*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_alpha.Data_encoding.tAn encoding for t that uses a specialized, space-efficient encoding for the list of transactions.