Consider increasing number of attnets

[djrtwo]

One strategy to help mitigate the load of attestations on nodes is to actually split committees across multiple subnets.

For example -- split each committee across two subnets, thus doubling the total subnets from 64 to 128 in which the lower half of the committee is assigned to a different subnet than the upper half of the committee (ensuring aggregatability of each half). In such a design, you'd still need to assign the same number of target aggregators per subnet (rather than per committee), so the total load on the global aggregate attestation subnet would be 2x. Given that attnets load increases linearly with size of validator set while aggregate subnet has remained stable, the trade-off to put more load on the aggregate subnet is likely acceptable.

Note, the above is just an example parametrization, you could even do a partial overlap, where you do 1.5x subnets per committee where some are split and some are not (evening out the disjoint load over many repeated epochs).

The obvious issue/downside with such a design is that without sufficient nodes on the network, you might either reduce the number of nodes per subnet to dangerous levels or you need to increase the attnets backbone subscription count to counteract it, which would still put a similar load on nodes albeit potentially helping by creating different meshes/paths.

If we had 10x the number of nodes on the network, I think such a strategy would be a no-brainer. Given our current node counts, it's unclear if this is a worthwhile path. That said, I've been sitting on this idea for a while and wanted to make sure others were aware given all of the validator-load discussions.

[ppopth]

The reason that we don't want to increase the number of committees together with the number of subnets is because we don't want to do hard-fork, right?

If the hard-fork is not the issue, I think increasing the number of committees and subnets (which, in turn, will reduce the size of the committee) probably makes more sense than distributing the members of the committees across the subnets.

That is, setting MAX_COMMITTEES_PER_SLOT and ATTESTATION_SUBNET_COUNT to be 128 looks quite cleaner. You can just change the configurations rather than designing the p2p network.

In addition, I guess that the only reason we have committees is that we want to mitigate the load on the network, so doing multiple subnets per committee sounds like solving the problem that's already solved.

[djrtwo]

That would be a more straightforward way to do so, but would have one side effect -- it would double the total number of messages that have to be included on chain, as yuo wouldn't get the final aggregatability of the two halves of a committee. Not a death sentence, but then you'd want to consider things such as MAX_ATTESTATIONS

Given the way this affects subnet message validity, you'd have to do it at a specific coordination point (e.g. activate at a particular epoch), regardless of if you just target network values or get into the consensus values

[ppopth]

it would double the total number of messages that have to be included on chain, as yuo wouldn't get the final aggregatability of the two halves of a committee

That makes sense.

Another question. Who will be the ones who aggregate the two halves? the block proposers, right?

[djrtwo]

Yes, the block proposer would do any final aggregation. Note that block proposers already do some of this work to try to optimize any disparate attestations (both semi-aggregates and singles they may have seen) when packing a block