## Peer Sampling safety concern

There is a concern regarding Peer Sampling safety if we want to get back to this approach for DAS instead of Subnet Sampling approach in the present EIP-7594 version or next DAS iterations.

- How our draft sampling algorithm (Teku PeerDas) worked for sampling a single column:
- check local storage
- if none found, ask existing peers from the corresponding subnet
- if none found, try finding other peers in the corresponding subnet

- Attack:
- Make few adversarial nodes to custody all subnets
- Develop a 'peer-sampling' Req/Resp pattern: when a peer wants to sample and not back-fill its custody
- Response to any 'peer-sampling' query
- Don't response to other requests, don't broadcast samples to gossip subnets
- **False positive** result:
- DA peer sampling succeeds for everyone
- Data is not actually available
- Attack is possible for either block proposer or an adversary who managed to eclipse block proposer node

- From that perspective Peer Sampling only ensures that data _was_ available (was not withheld)
- Enough samples was revealed for the network to restore the data
- _but_ samples retrieved are disposed and are not available to be found and queried

- How subnet sampling is different
- Sampled columns are *stored and available* for download
- In the corner case with 8 samples and 4 columns custody this is not applicable for those columns which are sampled but not stored in custody
- Sampled columns are *propagated* further via Pubsub