# Data-Availibility Layer The Data-Availibility Layer (DAL) is a decentralize data-base for Tezos. The use-case for such a data-base are the rollups solutions provided on Tezos: Smart-rollups and Epoxy. Such a decentralised data-base would allow to discharge the current Layer 1 that contains rollup operations. Using such a decentralised database, it is possible to reach 1 million of TPS in a decentralised way. The current alternative being the DAC project (Data-availibility Committee) which provides also a storage solution but backed only by a committee. With data posted off-chain, we can jeopardize the refutability of rollups. Indeed, the refutability of rollups relies crucially on the fact that any honest player can get those data. When those data are on the Layer 1, it is sufficient to track the Layer 1. When data are posted on the DAL, the Layer 1 should be able to attest whether those data where indeed published on the DAL. This is what is called **data-availibility**. :::info The *data availiblity* only guarantees that the data where published at least once. It says nothing with respect to the availibility of the data over the time. In the litterature, we may find also *data-availibility sampling*. The word *sampling* refers to a feature that allows to guarantee the availibility of the data for some amount of time which is fixed. In general, such amount of time depends on the use-case. For smart-rollups, it would be probably around two weeks. ::: # Retrospective of 2022 In 2022, we started to explore solutions to implement a data-availibility layer for Tezos. In particular: - We have integrated the DAL to the economic protocol (behind a feature flag) - We have integrated the DAL with the Smart-rollups - We have integrated the DAL cryptographic primitives to the Tezos codebase - We have started the implementation of a DAL node. A binary similar to the `octez-node` for the DAL. - We have explored a P2P protocol for the DAL The integration with Smart-rollups relies on the Reveal data channel. This allowed us to remove this idea of rollup subscription to the DAL. The integration of the DAL with the economic protocol relies on some parameters. The design of the DAL is resilient to changing values of this parameters (even though this is not fully supported yet). Regarding the P2P protocol for the DAL, the experimentation shows that it is possible to support the bandwith required for the DAL. However, we lack of confidence for reliability. ## The DAL in 2023 The current target is to release the DAL for 2023. The main development axis are: - Propose a design for the P2P protocol and test it - Validate the design of the DAL using E2E tests - Consolidate our P2P layer - Branch the P2P protocol to the DAL node - Make the DAL node resiliant to changes of parameters :::info Note that this plan is all about "data-availibility" and consequently, we do not propose to implement the *sampling* yet, even though we plan to add it in the future. ::: ```mermaid graph TD subgraph "End to end tests for the DAL node" a1[The endorser emits<br>DAL attestations<br>1 week] --> a3[Fully automated test<br>for the DAL without P2P<br>1 weeks] a2[Write Tezt tests<br>where everything<br>is automated except<br>the endorser<br>1 week] --> a3 a3 --> a4[Automated tests<br>with mainnet parameters<br>1 week] end subgraph "Run numerous machines" b1[Have an infrastruture<br>to run numerous machines<br> ?? weeks] end subgraph "End to end tests at large scale" a4 --> c1[Run end-to-end tests on a larger scale<br> ?? weeks] b1 --> c1 end subgraph "Consolidate P2P" d1[Extensively test<br>the connection protocol<br> 6 weeks] d2[Being able to<br>deactivate<br>the maintenance<br> 2 weeks] end subgraph "Gossipsub" e1[Implement a<br>prototype of gossiupsub<br> 3 weeks] e2[Write a design document<br> 4 weeks] e1 --> e3[Branch gossipsub on top of Octez-p2p<br> 2 week] e2 --> e3 d2 --> e3 end subgraph "Gossipsub" e1 --> f1[Test extensively gossiupsub] b1 --> f1 end subgraph "P2P/DAL node" b1 --> g1[Branch the DAL node on Gossipsub<br> 2 week] f1 --> g1 end ```