DAL committee

The DAL committee for a level

$l$ decides which attestor must attest the availibility of a shard

$s$ for all slot indices

$s_i$.

The property desired for this committee is that the number of shards assigned to an attestor should be proportional to its stake.

If an attestor is assigned to at least one shard, it should be able to attest whether the data is available or not. To do so, either we reuse the current attestion operation (formerly known as endorsement), or we use a new one.

• Question 1 : Should we implement another consensus operation dedicated for the attestations?

If we have a second operation:

Pros:

• An attestor always has the possibility to attest the data

Cons:

• More expensive to check (more check signatures, even though this could be mitigated if the attestor is also part of the Tenderbake committee)
• More bandwith on the network (how much?)

If we reuse the Tenderbake attestation:

Pros:

• More efficient

Cons:

• To ensure that all the attestors can attest the data-availibility, it means the DAL committee should be a "subset" of the Tenderbake committee.
• Given the current P2P design, if the DAL committe is a subet of the Tenderbake committee it may imply many connection switches which can slow down the DAL network.

Question 2: Assuming we do not add a new operation, can we relax the assumption of having the DAL committee as a subset of the Tenderbake committee? Implying that, by design, some shards cannot be attested? If so, what are the consequences of the model?

To propagate the shards over the P2P network, a peer must know what are the shards another peer wants or has. This is the notion of topic.

The current design plans for a topic to be a triple

$(level,slot\mathrm{\_}index,shard\mathrm{\_}index)$.

In practice, it means that the number of different topics can be

$2^{level+s_i+s{h}_j}$.

Question 3: What are the number of connection switches we can expect per level? What is the "time" to do a connection switch?

Ideas

Various ideas can be considered and already suggested above:

1. Implement DAL attestations separated from the Tenderbake attestations

2. Draw a DAL committee less often (for a full cycle for example? or with finer granularity). Without 1, what could be the consequences of this? How to draw a committee without compromising the model?

3. Use another notion of topics such as:

   ​​​​type profile =
   ​​​​| Endorser of public_key_hash
   ​​​​| Slot_index of slot_index
   ​​​​
   ​​​​
   ​​​​type topic = profile list (* Union of profiles *)
   ​​​​
   ​​​​
   

   Given a topic

   $t$, knowing the shards that must be tracked can be given by the
   $L1$. To know whether a slot producer covers all the shards, it can just maintain a set of attestor at each level. Is it better complexity-wise?

   This notion of topic sounds particularly relevant for the DAL node.

   Questions:

   • Does it leak more information than the current notion of topics?
   • Can it be implemented efficiently?
   • Can it be implemented on top of the P2P with PubSub?
     • the current proto for the p2p expects the following structure on topic sets
       1. fast membership test (topic \in topic_set)
       2. (approximate) iteration on the elements of a topic set

• Draw a Tenderbake committe every X levels

• Profile does not work with sampling.

• epoch permettrait d'avoir une granularité plus fine

• Souhaitons-nous avoir un epoch pour Tenderbake ?