-
Notifications
You must be signed in to change notification settings - Fork 37.7k
p2p: Fill reconciliation sets and request reconciliation (Erlay) #26283
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
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
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.
Just few comments as a first parse on the post-#23443 commits.
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.
First code-review parse, left some minor comments.
4afeac2
to
cacf08d
Compare
cacf08d
to
441a4f3
Compare
b0c1c43
to
913c2cb
Compare
180052c
to
80dc9c4
Compare
Still have to review a couple of comments, especially the fuzzing suggested by @dergoegge |
The pre-mutexed version is useful for external calls, while the regular version will be used internally.
They will be used later on.
b509e9a
to
863a334
Compare
This PR is good for review. Fuzzing will come in a separate PR. |
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.
will review again pr from scratch
const Consensus::Params& consensusParams = m_chainparams.GetConsensus(); | ||
|
||
const auto current_time{GetTime<std::chrono::microseconds>()}; | ||
|
||
// We must look into the reconciliation queue early. Since the queue applies to all peers, |
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.
note the call to IsPeerNextToReconcileWith
is before MaybeDiscourageAndDisconnect
. if a peer is misbehaving and candidate for disconnection, maybe we should disconnect first and let the reconciliation slot be used by another peer
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.
This would make a difference only once, which is fine for (lower-risk) outbound peers I think.
The problem with latter IsPeerNextToReconcileWith
is that the queue won't be queried. Say, a peer finds a way to exploit MaybeDiscourageAndDisconnect
(say in combination with something else) — so that it always returns, but never disconnects. In that case the peer will be stuck at the front of the queue forever.
I don't think what i described is currently possible (fDisconnect only can go from false to true), but I'm afraid it might be in the future.
Transactions eligible for reconciliation are added to the reconciliation sets. For the remaining txs, low-fanout is used.
For a subset of reconciling peers we announce transactions via low fanout. We need to set lower intervals for that to achieve lower relay latency. Note that for privacy reasons the ratio between inbound and outbound delays matter more than the actual delays.
When we're finalizing negotiation, we should add the peers for which we will initiate reconciliations to the queue.
863a334
to
3637986
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.
left a test nit, feel free to ignore
When the time comes for the peer, we send a reconciliation request with the parameters which will help the peer to construct a (hopefully) sufficient reconciliation sketch for us. We will then use that sketch to find missing transactions.
3637986
to
b518d26
Compare
I decided to split this off into #28765. |
See #28765
First, this PR enables keeping track of per-peer reconciliation sets, containing those transactions which we intend to exchange efficiently. The remaining transactions are announced via flooding, as usual.
Second, this PR enables periodically initiating a reconciliation round via a new p2p message.
Erlay Project Tracking: #28646