Assuming that there's 64 commitees in per slot and in each commitee of each slot, there's 16 aggregators, this results in the 1024 aggregator messages shared per slot. The reason for this is that if each commitee has 16 aggregators, they will share their aggregated message which will be of count 16, but since there's 64 committees, then we have 64*16 = 1024.

So in slot, each validator can receive up to max 1024 aggregated "Attestation". I have the following 2 questions.

  1. How does validators that receive this aggregation verify its contents ? My opinion is as follows: It looks at aggregation_bits and figures out which validators are included in there. Then loops through the indexes(taken from aggregation_bits) and from global validator set, it fetches the pub keys for those validators. Then uses these pub keys and aggregated signature to verify that these validators actually did sign that specific data. Would this be correct ?
  2. Since each commitee has 16 aggregators, there'll be 16 aggregated message broadcasted. It's highly possible that not all 16 aggregators will have the same "AttestationData" in there even though they were sent from the same commitee(while it should have the same attestationData, assume that they don't). So what does the node do at the verification step ? it has 16 aggregated messages from the same commitee, but different results. Not only that, there're 64 committes in the same slot, so 64*16 = 1024 aggregated results, which don't have to match each other(normally it would if all were honest and there was no propagation delay) but if they don't, how does node that verifies them decide which one of those is the better "attestationData" that it can remember/store in its state such as for the next propose block(in case he is a proposer), he puts it in the block ? I hope I made sense. Haven't even found a code of this in none of the documentations.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.