Some meaningful changes in the PeerDAS design have been discussed, and agreed upon, at the interop: Do not use the tight fork-choice in the first iteration of PeerDAS Increase custody requirement and subnet count Introduce validator custody Take peer sampling completely out of the critical path of consensus In my opinion, they represent both a huge simplification and an increase in robustness of the design. Let's break down what these points mean and why that is the case. Trailing fork-choice instead of tight fork-choice

This post follows a previous one on the fork-choice of PeerDAS, incorporating changes stemming from the recent developments in the design of PeerDAS. Roles of peer sampling Peer sampling for full nodes: transaction confirmation The first role of peer sampling concerns full nodes, in particular the security of transaction confirmations. Still, we do not need to use peer sampling for the safe head rule, because this already relies on an honest majority assumption, which, if satisfied, would already guarantee availability. Instead, as far as transaction confirmation is concerned, we only need to use peer sampling to ensure availability of finalized checkpoints. Peer sampling for attesters: resistance to supermajority attacks As discussed in the interop update on PeerDAS, peer sampling is not necessary in order for consensus to function, as long as we have a sufficiently high custody requirement. In other words, as long as we have enough subnet sampling to ensure that at most a small percentage of the validators can ever vote for something unavailable. Still, peer sampling can play a role in improving a validator's response to supermajority attacks which invole the justification or finalization of an unavailable block. In such a situation, we would like to ensure two things: