Integration of DAL with SCORU

# Integration of DAL with SCORU Considering the new DAC proposition, we can rethink a bit the current design of DAL for the interaction with SCORU. The aim is to: - Simplify the L1 refutation game - Give more freedom to the kernel to import DAL data - It relies on features that are desired for SCORU - Implement a mechanism similar to DAC enabling to share code with DAC if the design is validated The design ensures the following invariant > We do not want more messages on L1 than we absolutely need By not adding more data on the L1 than the current design of DAL. ## Open commitments: A generalization of pre-image revelation An innovative emerged recently following the discussions around the DAC proposition. Independently from the inbox input of the rollup, the rollup with DAC can request pre-image values to a certain "hash". The refutation game must be able to prove that the pre-image is indeed the one requested by looking at his "hash". This idea can be extended in the case of DAL. ## Integration of the DAL on top of Open commitments The design proposed in this document for DAL is the following. The kernel can request at any moment a page of the DAL. A page is uniquely defined as a `3`-uples $(l,s_i,p_i)$ where $l$ is the level, $s_i$ is the slot index, and $p_i$ is the page index. At any moment, a rollup can decide to be in a state $\mathrm{Wait\_for\_page}(l,s_i,p_i)$. It expects to be fed with: - $\mathrm{Page}(\mathrm{data})$ if the slot $s_i$ at level $l$ was confirmed by the $L_1$ - $\mathrm{No\_data}$ otherwise This creates a new import tick. Consequently, the refutation game must be modified. On the $L_1$ side: - At the end of each level, we register in a skip list, all the slot headers confirmed at that level. A cell of the skip list can be $(l,s_i,s_h)$ where $l$ is the current level, $s_i$ the slot index and $s_h$ is the slot header (aka the Kate commitment). Only the last cell of the skip list is stored into the $L_1$ context. However, to produce the proof all the cells must be stored by the rollup node. For the refutation game, there are two cases. ### Proving confirmed pages - When the rollup state is $\mathrm{Wait\_for\_page}$, we aim to provide of the proof that needs to be provided to the PVM. This proof is a `3`-uples $(d,inc,sh)$` simply some data $d$ (as a list of bytes) and the slot headers associated. - The verification part is two-folds. Given a page as $(l,s_i,p_i)$ and the data $d$ which corresponds to the given page (of a reasonable size to hold in an $L_1$ Tezos operation): 1. The $L_1$ computes the cell of the skip list`(l,s_i,s_h)` and uses the inclusion proof $inc$ to check that this cell is part of the skip list (i.e. the slot was confirmed). The level $l$ must be before the commitment level. 2. We use the cryptographic function $\mathrm{verify_page}$ to check that $\mathrm{verify\_page(d,p_i,s_h) = true}$ ### Proving a page is not confirmed - In the case where the PVM is in state $\mathrm{Wait\_for\_page}$ but the page associated cannot be provided (the slot is not confirmed/does not exist), the proof is $(l_1,s_{i_1},s_{h_1},l_2,s_{i_2},s_{h_2}, inc)$ - Given a page as $(l,s_i,p_i)$, the verification part is as follows: 1. The $L_1$ computes the two cells $(l_1,s_{i_1},s_{h_1})$ and $(l_2,s_{i_2},s_{h_2})$. Then, uses the inclusion proof $inc$, to check that those both cells belong to the skip list, and that they are consecutive cells (similarly to what is done right now for cross-level proofs for the inbox). Then it checks that $(l_1,s_{i_1}) < (l,s_i) < (l_2, s_{i_2})$ (as a lexicographic ordering). The level $l$ must be before the commitment level. *Note: A particular case must be implemented when we are at the beginning or at the end of the skip list. Technically, this can be avoided by allows ensuring the first cell and the last cells are respectively lower and larger than any refutable pages for the current commitment level.* ## Discussions points ### Rollup node interactions with the kernel With this design, nor the $L_1$, nor the rollup node knows the slot indices the kernel will request. While this is not an issue with respect to safety or the security of the rollup, in practice it can be an issue to reach a high throughput. Indeed, the date of the DAL must be downloaded and can take some time. This could be prevented if the rollup node could communicate with the kernel so that the latter can tell to the rollup node the slot indices to track. ### Reorganisation We must ensure this design is resilient to re-organisations. This is probably the case, but we must think about it.