DAL support

The support for the DAL within the economic protocol relies on two operations:

  1. DAL_publish_commitment: a manager operation, allowing anyone to publish a DAL commitment

  2. attestation: the existing consensus operation, allowing bakers to attach a DAL payload attesting the data seen on the DAL P2P network

DAL publish commitment

DAL_publish_commitment is a manager operation that can be issued by a user wishing to publish data onto the DAL. The payload of this operation consists in the following fields:

  • Slot index: Identifies the specific slot for which the data is being published. It is an integer between 0 and number_of_slots - 1.

  • Commitment: The KZG commitment over the data.

  • Commitment proof: A proof that the commitment commits over data that does not exceed the size slot_size.

Users can create and manage these commitments and proofs through the DAL node using these RPCs:

  • To create a commitment: POST /commitment

  • To retrieve a commitment’s proof: GET /commitments/<commitment>/proof

Concurrent operations

If a block contains a valid DAL_publish_commitment operation, any subsequent operations of the same kind within the same block (and the same slot index) will be recognized as valid but will fail during execution. They still incur transaction fees. More details about this can be found in the validator documentation.


Currently, the fees are estimated based on the execution cost of this operation alone. There are no additional charges related to the bandwidth required for bakers to download data from the DAL for this commitment. However, this might be subject to changes in the future.

DAL attestation payloads

The attestation operation includes an optional field dal_content. This field allows attesters participating to the DAL to announce whether they were able to successfully download the shards assigned to them. Concretely, this field is a bitset reflecting the status of each slot. The size of the bitset corresponds to the total number of slots. A value of 1 indicates successful retrieval of all assigned shards by the baker for that slot, while 0 indicates an unsuccessful attempt. The least significant bit corresponds to the smallest slot index.

Attestation timing

When a commitment is published at a certain level, say level PL, the corresponding DAL payloads are expected to be included in the attestations contained in the block at level PL + attestation_lag.

Block metadata

In the block’s metadata, there is a specific field for the DAL. This field reflects the availability of slots based on the DAL payloads received. It is a bitfield with one bit per slot (its format is the same as the attestation payload of the attestation operation). The bit is set to 1 if the slot is declared available. The smallest slot index corresponds to the least significant bit. To consider a slot as available, there must be a minimum number of shards, as defined by the availability_threshold parameter, marked as available by the attesters for that slot (e.g. if the number of shards is 2048 and the availability threshold is 50%, then 1024 shards are required).

Therefore, for data committed (published) at level L, the slot’s availability is determined by the metadata of the block at level L + attestation_lag. Consequently, a smart rollup can only utilize this data from level L + attestation_lag + 1 onward.

Smart rollups integration

The DAL is integrated with smart rollups so that kernels can request pages from the DAL via the reveal data channel. A smart rollup can fetch any page from the DAL node if the commitment respects some conditions:

  • The commitment should have been published after the rollup origination (this constraint will be leveraged so that the kernel can request any commitment in the past)

  • The commitment should not have been published in a level in the future after the level of the next commitment of the state (at most 30 levels in the future). This constraint might be leveraged thanks to the internal messages Start of Level and End of Level (abbreviated as SOL and EOL), which allow the kernel to track the L1 level, so that the kernel cannot request a page for a commitment published after the current L1 level.

If the kernel requests a page that does not satisfy the mentioned conditions, then the rollup node must answer with an empty page indicating there is no data. Similarly, if the kernel requests for a commitment that was not attested, the rollup node must also provide an empty page. As a consequence, if a kernel requests a page for a commitment for which its availability is still unknown, the rollup node cannot answer and will have to wait for the availability status to be confirmed by the L1.

Moreover, the rollup kernel has access to the protocol constants so that the same kernel code can be used on different test networks.