feat(bloom): aggregate bloom filters

[sistemd]

This PR adds code for aggregate bloom filters. It doesn't do anything useful with the code, but under a conditional flag it will compare the results obtained from aggregate bloom filters with results obtained from regular bloom filters to ensure that the implementation is correct.

The bit matrix is implemented manually because somehow it's 10x faster this way than using the bitvec crate and also it's extremely simple. I have a hunch that we could get even more improvements if we used u32 instead of u8 to back the bit matrix. But this can be done later.

The next PR will implement storing these aggregate filters in the DB, and then the final PR will implement actually using them from the RPC calls (and finally reaping the benefits).

[sistemd]

I have a hunch that we could get even more improvements if we used u32 instead of u8 to back the bit matrix. But this can be done later.

However, the problem with this is that we still store/load Vec<u8> from the DB, and converting that to Vec<u32> safely requires copying. So it may actually turn out to be slower.

[CHr15F0x]

I have a hunch that we could get even more improvements if we used u32 instead of u8 to back the bit matrix. But this can be done later.

However, the problem with this is that we still store/load Vec<u8> from the DB, and converting that to Vec<u32> safely requires copying. So it may actually turn out to be slower.

• If the copying happens only once it shouldn't have any impact.
• You could even try usize to match the word width.

[sistemd]

You could even try usize to match the word width.

Good idea!

[CHr15F0x]

nit: I guess the correct mathematical wording would be transposition.

Suggested change

	/// rotated by 90 degrees.
	/// rotated by 90 degrees (transposed).

[CHr15F0x]

LGTM 🙇

I'm curious to see how it boosts some really slow event queries in the rpc 👀 .