Note – my intention with the original PeerDAS post (as inspired by discussions with Dankrad) was to find a way to mix relay-type-entities (named consistently available super-full nodes or “DAS providers”) naturally into the p2p
I think it’s a powerful design to consider what the network looks like with assumptions around super-full nodes (a set that is likely a super-set of relays), but doesn’t tightly integrate the current “relay” further into the workflow. That is, a node could whitelist super-full nodes, bias toward sampling from them, etc, with huge gains without elevating them to a particular network function with hyper specific messages
Obviously, this leaves efficiencies on the table – such as relays streaming samples to each other.
See DAS Providers in my original post.
Why the sidecar? Is this to ensure that a node that receives the sidecar+header can immediately begin successful queries? Whereas if they only sample their set of relays, there might be a race condition – i.e. querying prior to that relay receiving the samples? And with the sidecar, they have at least 1 of N that can immediately respond?