chainlocks: Implement Multi-Quorum ChainLocks #4016
Conversation
|
Interesting... So today because the height is committed to the randomization to choose the quorum to sign on a CLSIG essentially you have 1/N chance of achieving the next chainlock, which would end up causing the chain to have to progress from that locked chain, however they would again only have 1/N chance of progressing with a subsequent chainlock. This would add a M of N threshold to require majority of nodes within all the quorums in the chainlock quorum to agree on the state of the chain tip right? Since the llmq400_60 is 240/400 and there are 4 quorums active at any time(just like your new llmq_test) it would effectively require 3/4 quorums to agree on a chainlock for it to succeed (75% threshold to achieve majority) |
@sidhujag tl;dr: it's a tweak of the usual CLSIG creation process to let other quorums vote too. Each quorum would produce its own CLSIG though, so there is another step on top of it to check that majority of CLSIGs ( |
UdjinM6
force-pushed
the
multi_stage_cl
branch
2 times, most recently
from
1732e01 to
6bbcc56
Compare
UdjinM6
force-pushed
the
multi_stage_cl
branch
from
eb3f5e2 to
b7af2b8
Compare
UdjinM6
force-pushed
the
multi_stage_cl
branch
8 times, most recently
from
d8ad0e2 to
c4735c6
Compare
UdjinM6
force-pushed
the
multi_stage_cl
branch
5 times, most recently
from
46adf03 to
fa365e1
Compare
UdjinM6
force-pushed
the
multi_stage_cl
branch
3 times, most recently
from
914fd6b to
670e7e3
Compare
UdjinM6
force-pushed
the
multi_stage_cl
branch
3 times, most recently
from
9e9fa1c to
8886ff2
Compare
…re clsigs when it makes sense A malicious quorum can sign a clsig with some (random) hash and some future height. This will basically disable clsig logic for all heights up to that future one without actually locking the chain. Note that the best known clsig with a known block is not affected by the issue, no conflicts below that block are allowed. Using the best clsig with a known block instead of a pure best clsig (with no known blocks) fixes the issue. tests: See if a fake clsig can stop us from creating/relaying/accepting new legit clsigs test: Just some python styling
and keepOldConnections to 5, respectively
Specifically: - Queue quorums instead of signing at the same time - Wait for the "previous" quorum to sign first (for some time) - Look deeper and sign anyway if "previous" quorums are silent - Prefer signing the same tip as the "previous" quorum did if there is a choice
…nedHeight` relationship and make `TrySignChainTip` thread-safe
Update the hash when needed
|
This pull request has conflicts, please rebase. |
3 participants
This PR is a Proof of Concept for the Multi-Quorum ChainLocks idea. To be merged after corresponding DIP8 modifications only.
The main idea is to let all active ChainLock quorums create new CLSIG messages at every block and to require the majority of these quorums to vote for the same hash to actually lock the chain. Unlike in current system, having a malicious quorum will no longer be enough to disrupt ChainLocks (see tests as an example where 3 honest quorums override the "fake" ChainLock produced by a malicious quorum).
The new mode is activated by setting
SPORK_19_CHAINLOCKS_ENABLEDto1. This PR changes CLSIG structure, bumps protocol version to70220, introduces new rpcgetchainlocks, deprecatesgetbestchainlock(as less functional and more confusing in new mode), tweaks test quorum params and related tests accordingly. Please see individual commits.Based on #3978 atm.