statement-store: allow light clients to specify topic affinity#11329
Conversation
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
| /// Maximum number of bits allowed in a bloom filter received from the network. | ||
| /// Derived from [`MAX_STATEMENT_NOTIFICATION_SIZE`] so the affinity filter can never exceed the | ||
| /// protocol's notification budget. 1 MiB = 8_388_608 bits. | ||
| const MAX_BLOOM_BITS: usize = MAX_STATEMENT_NOTIFICATION_SIZE as usize * 8; |
There was a problem hiding this comment.
nit: We unlikely ever encounter a 1 MiB filter, but should this also account for the v2 envelope size and other data sent on the wire?
There was a problem hiding this comment.
Actually, may be set a way lower cap on the filter size? For example, Bitcoin caps a transaction Bloom filter size to 36 kB: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
Given the false positive rate of 1% and 10000 topics (which is already a lot), we only need a 12 kB filter.
There was a problem hiding this comment.
Actually, realized that 10k topics for a chat of 1m daily users is not enough :D
There was a problem hiding this comment.
Edit: 1m users should be irrelevant to a single client/filter, if I am not mistaking something.
There was a problem hiding this comment.
1m users should be irrelevant to a single client/filter, if I am not mistaking something.
No it is not irelevant, the number bits is related to the total number of topics in the system, not just the ones a client subscribes to, because if the system has 10M topics that get check against your filter then 1% means you still get 100K topics(which is not what you want), so you would have to have a lower FP rate let's say 0.001% and that automatically translate in more bits.
Description
Add explicit topic affinity support to the statement protocol, allowing nodes to advertise at P2P level which statement topics they're interested in. When a peer's affinity changes, relevant statements are re-sent.
The topic affinity is specified as a BloomFilter, all statements that match the filter are forwarded to new peers.
Currently, this is meant to be used by light clients like smoldot to receive only the statements they are interested in. In the future, this can also be used by statement store full nodes, but some other changes will also be needed.
Changes
TODO