-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Implement "concentrated recovery" of LLMQ signatures #3389
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
Implement "concentrated recovery" of LLMQ signatures #3389
Conversation
|
Will review tonight or tomorrow |
| .signingActiveQuorumCount = 4, // four days worth of LLMQs | ||
|
|
||
| .keepOldConnections = 5, | ||
| .recoveryMembers = 100, |
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.
Was the number of .recoveryMembers chosen arbitrarily? I noticed the smaller quorums use a higher percent of the overall LLMQ size.
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.
Yeah...mostly arbitrary. I chose the numbers in an absolute way because there wouldn't be a good percentage that would work well on all LLMQ types.
PastaPastaPasta
left a comment
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.
Concept ACK, don't see any problems. utACK
Instead of propagating all sig shares to all LLMQ members, this will now make all members send their individual sig share to a single member, which is then responsible for the recovery and propagation of the recovered signature. This process is repeated by all members every second for another target/recovering member, until a recovered signature appears.
8a6082d to
76b6614
Compare
UdjinM6
left a comment
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.
A couple more nits, otherwise looks good.
(test failures seems to be random/unrelated, fails on develop too...)
Co-Authored-By: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-Authored-By: UdjinM6 <UdjinM6@users.noreply.github.com>
UdjinM6
left a comment
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.
utACK
Implement "concentrated recovery" of LLMQ signatures
Implement "concentrated recovery" of LLMQ signatures
a85b450 Merge pull request dashpay#3399 from codablock/pr_speedups2 (Alexander Block) 136f900 cherry-pick dashpay#2833 (Alexander Block) d942439 Merge pull request dashpay#3389 from codablock/pr_concentrated_recovery (Alexander Block) 36790d2 cherry pick dashpay#3368 (Author Alexander Block) dac01a9 cherry-pick dashpay#2780 (Alexander Block) 39d0ed9 cherry-pick dashpay#3367 (Alexander Block) 5084bbf Allow re-signing of IS locks when performing retroactive signing (dashpay#3219) (Alexander Block) 802c006 Only track last seen time instead of first and last seen time (dashpay#3165) (Alexander Block) 479b64b Avoid propagating InstantSend related old recovered sigs (dashpay#3145) (Alexander Block) 27fa2af cherry-pick dashpay#3117 (Pasta) cf138e0 cherry-pick dashpay#3097 (Pasta) 23b140e Introduce getbestchainlock rpc and fix llmq-is-cl-conflicts.py (dashpay#3094) (UdjinM6) Pull request description: as usual each commit backports a different PR ACKs for top commit: a85b450 Duddino: utACK a85b450 Liquid369: uTACK a85b450 Fuzzbawls: ACK a85b450 Tree-SHA512: e9024d180888d8a6cc300ba9df74fc15929e3ade1773e5d312bd8cc93f6c9fd3898c5bf2d14672abf4faba576575c33936708e6e1dfd01a393479d264d3f2c57
Implement "concentrated recovery" of LLMQ signatures
This implements "concentrated recovery" (I'm happy for suggestions of better names...).
In the current system, signature shares are propagated to all LLMQ members, until one of them has enough shares collected to recover the signature. Until this recovered signature is propagated in the LLMQ, all members will keep propagating shares and verifying each one. This causes quite some load on the LLMQ, which will be avoided with the new system.
The new system sends all shares to only a single deterministically selected node, so that this node can recover the signature and propagate the recovered signature. This way only the recovered signature needs to be propagated and verified by all members. After sending the share to this single node, each member waits for one second and repeats sending it to another deterministically selected member. This process is repeated until a recovered signature is finally created and propagated.
The new system is activated with the previously added spork21.
My assumption with this change is that it can reduce the load on a LLMQ by a factor of up to 40x-50x.