I’ve some technical questions on danksharding and validation committees.
From this publish on two-slot proposer-builder separation: https://ethresear.ch/t/two-slot-proposer-builder-separation/10980, danksharding is supposed to be a two-slot course of, that means (if I’ve understood it appropriately) it can take two 8-second slots for the entire build-propose-verify-append course of to be accomplished.
With PBS, after the intermediate block deadline, we see the remaining ‘N-1 committees’ attest to the block physique. My first questions:
Is the committee measurement right here nonetheless the identical as that meant instantly post-Merge, i.e. 128 validators, or one thing else?
What’s N right here? The entire validator set out there divided by 128?
These N-1 committees attest to the block physique tying as much as the block header. However do additionally they confirm for information availability and transaction validity (i.e. test for validity proofs within the case of ZKRs, or elevate fraud proofs within the case of ORs)?
My subsequent questions relate to this report: https://members.delphidigital.io/reviews/the-hitchhikers-guide-to-ethereum, and particularly, this picture from it:
(Picture taken from part titled ‘Danksharding – Sincere Majority Validation’.)
My further questions from the picture:
4. 1/32 of the entire validator set is assigned to attest to the information availability of the block in every slot, as there are 32 slots in an epoch. However with PBS, the block cycle now ought to take two slots! So is that this incorrect? Or ought to it’s one thing like 1/16 testifying each two slots?
5. Is ‘1/32 of the validator set’ meant to be the identical because the ‘N-1 committees’, and these information availability checks occurs similtaneously that course of? Or is that this information availability verification a separate course of with completely different teams of validators that occurs after the ‘N-1 committee’ attestation?
6. Does the ‘1/32 of the validator set’ additionally attest to the transaction validity of every block?
7. Later in the identical report it is acknowledged that it is meant for the opposite full nodes (i.e. these not within the validation set) to do their very own personal information availability sampling. If that’s the case, will they **additionally** be doing their very own transaction validity verifications? This can be trivial for validity proofs, however I anticipate it could be fairly onerous for fraud proofs. How would this work in apply?