Parallelize BLS signature verification

[Giulio2002]

💎 Issue

As of now, Prysm is processing BLS signatures without any parallelization, this makes it slow on initial-sync and BLS signatures are the main bottlenecks for Consensus Layer clients.

Background

I understand that optimizing initial sync is not a priority because of weak subjectivity, but still i think it would not be an ugly addition to the mix, as i believe it would strongly diminish initial sync time by a non-significant degree.

Description

What i would do, is the following:

• Accumulating bigger block batches (500-2000 blocks vs 64), with multiple p2p requests
• When accumulating the set, instead of slap it in a linear function, slap it into multiple goroutines/jobs with a worker function.
• Send each block over the workers with a channel and process the signature accordingly, to then send them back through a subsequent goroutine

[nisdas]

This is already done here: https://github.com/prysmaticlabs/prysm/blob/develop/crypto/bls/blst/signature.go#L254 https://github.com/supranational/blst/blob/master/bindings/go/blst.go#L512

Signature verification is multi-threaded right now. If you desire to have a larger batch limit then you can specify --block-batch-limit . The reason we do not specify too high a batch size is because it breaks rate limits among other peers.

[Giulio2002]

is BLS Signature Aggregate verification multi-threaded under the hood? I thought aggregation verification ()is not based on multi-threading but rather on some BLS properties (not a mathematician myself lol). anyway 64 blocks is not enough for any significant improvement with multi-threading, what i meant was not increase the raw amount of blocks we request but rather, accumulate these batches in one big batch we keep internally and once we surpass a certain threshold, aggregate them and verify them at once.

[prestonvanloon]

anyway 64 blocks is not enough for any significant improvement with multi-threading

Could you provide a benchmark to suggest a better number?

[Giulio2002]

can try doing this

[nisdas]

anyway 64 blocks is not enough for any significant improvement with multi-threading, what i meant was not increase the raw amount of blocks we request but rather, accumulate these batches in one big batch we keep internally and once we surpass a certain threshold, aggregate them and verify them at once.

If you that look at the method under the hood that is exactly what it does. 64 blocks != 64 signatures , there are diminishing returns to having bigger batches simply for the fact that aggregates are heavier in mainnet currently. A block contains many different signature sets to verify : -> Proposer Signature -> Randao Signature -> Sync Contribution Signature -> Aggregate Signatures

The last set of signatures take by far the longest to verify. There are a maximum of 128 aggregates in a block, so you would have to verify a total of 131 signatures per block. With 64 blocks this comes out to 8384 signatures per batch. Having a larger batch will have a limited improvement as the only gain would be in final exponentiation. We would still have to aggregate all public keys for each aggregate before we can verify a single aggregate signature. Now, you can repeat this step for all the other 127 aggregate signatures, and the time to aggregate the pubkeys would be non-trivial. A larger batch wouldn't improve the time taken for these other steps.

[rauljordan]

hi @Giulio2002 does this answer your questions? Let us know if we can still help with anything. If so, we can re-open