To me it looks like libalpm just iterates through all packages one by one to check signatures. On my machine (8 core ryzen laptop, SSD, 32G RAM) this is CPU-bound, using only a single core at 100%. I think it might be worthwhile to parallelize this: Spawn $NCPUS worker threads that fetch packages to verify from a queue. AFAICT pacman always uses gpgme for signature checking, which seems to support multi-threading. Right after downloading all of that data should still be in RAM caches anyway so this is unlikely to cause a disk bottleneck even on machines with slower disks. I guess speed-up of the signature verification step would be roughly $NCPUS times. As multicore CPUs with six or more cores are fairly common today, for most people that would be 5-10 x.

With the new parallel connections downloader, downloading a lot of updates now has become really fast even on my home Wifi. Installation is also fast, since I use a fast SSD. Apart from post-install hooks, the only thing that currently feels slow about pacman is this signature verification step at maybe 10-20 seconds.

Besides simply parallelizing this step, another option would be to roll the actual signature verification into the download loop. When downloads are bandwidth-constrained (instead of CPU bound for *very* fast connections), pacman could already call gpgme_op_verify right after downloading, and simply cache gpgme_op_verify_result for later. This way, pacman would already do all the cryptographic heavy lifting (computing hashes and checking signatures) while waiting for the network, and later in the actual "signature verification" step would only have to check whether the keys of the already validate signatures are trusted.