-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multi: Add batched cfilter fetching messages #3211
Conversation
3b94d59
to
5a7ccf2
Compare
5a7ccf2
to
ebac834
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it took so long to review this. I totally let it fall through the cracks.
I've reviewed the first commit and this is looking super nice overall! I really appreciate the effort put into make it easy to review and also determining all the worst case scenarios and adding tests to exercise them.
I figured I'd push the review thus far so you can start addressing the various (minor) points.
Also, please rebase this to the latest master. I've done it locally for testing, but needs to be done on the PR too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review for the second commit "wire: Add msgs to get batch of cfilters".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review for the third commit "blockchain: Add function to locate multiple cfilters".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review complete. Really nice job overall. Avoiding the calls to gcs.FromBytesV2
on all of the filters will save quite a few allocs which will not only be a lot faster, but it'll put less pressure on the serving nodes as well.
This will be helpful in determining the max number of cfilters to return in a future batched getcfilter message. This will also nail down the maximum size of the filter based on the constants used throughout the project, such that if any of them changes, causing the max cfilter size to change, a test will break indicating the need to review any code paths that assume a max cfilter size.
Thank you for the review! I believe I addressed all the review items. |
Reviewed all the updates and they look good. The only thing remaining is my latest comment and then I'll get this merged. 💯 |
This adds the getcfsv2 and cfiltersv2 messages. These messages are intended to allow nodes in the P2P network to request and receive a batch of version 2 committed filters that span multiple sequential blocks in a chain. These messages are intended to be used when syncing SPV clients, which require requesting all committed filters on the current main chain and currently use a large number of getcfilter/cfilter messages. One of the critical issues in the design for these messages is the MaxCFiltersV2PerBatch constant, which establishes an upper bound on the max number of cfilters requested and replied. The current value of this constant was decided based on the max block size for all of the currently deployed networks, the max possible filter size for transactions in such a block and the max P2P message size. A runtime check is added to ensure any changes to the constants that were involved in deciding this number trigger a panic so that this bound is verified and, if needed, a new protocol version is introduced to update it. This check is meant to guard against inadvertedly changing the assumptions that went into establishing this bound without reviewing it.
This function will be used to reply to the recently introduced getcfsv2 P2P message. The LocateCFiltersV2 function fetches a batch of cfilters from the database and encodes it in a wire.CFiltersV2 message, ready to be sent to remote peers.
This adds the appropriate processing to the peer and server structs to respond to the recently introduced getcfsv2 message. It also bumps the peer and server max supported protocol versions to version 10 (BatchedCFiltersV2Version). This message queries the chain for a batch of committed filters spanning a set of sequential blocks and will be used by SPV clients to fetch committed filters during their initial sync process.
Close #3206
This adds the getcfsv2/cfiltersv2 set of messages, intended to be used by SPV clients to fetch batches of version 2 committed filters during their initial sync process.
Summary of changes: