Implement 100 Member LLMQ to be used by Dash Platform
Benefits of implementing a new LLMQ
Quorum size is 100 instead of 50 so:
- Better protection from DoS
- Lower possibility of having more than ⅓ low latency or offline nodes.
- More secured consensus, much harder to achieve majority for malicious nodes
Validation workload distributed more evenly among network
Do not disturb IS lock process by utilizing the same LLMQ
LLMQ Parameters
type
4
name
llmq_100_67
size
100
This should hit the balance between performance and security for the launch of Dash platform. If we succeed to significantly reduce the block time by consensus optimisations we will reconsider the quorum size. The desire to raise the validator set’s size stems from both concerns with DDos protection and work load distribution.
minSize
90
threshold
Maybe better to set it to 67 to be BFT compatible (>=67/<33). Or we could stick with the normal LLMQ thresholds of 60 (>=60/<=40).
dkgInterval
24
The number of blocks between two DKG sessions. If set to 576 for example, a new DKG session will start once per day. This depends on how quick we want to have new validator quorums form. Probably should be 24 like with IS quorums for simplicity.
dkgPhaseBlocks
2
Number of blocks a single DKG phase is active. It must be high enough to allow all members to exchange all required messages. It must also be high enough to take block time variances into account. Minimum seems to be 2.
dkgMiningWindowStart
10 (not defined by platform team)
dkgMiningWindowEnd
18 (not defined by platform team)
dkgBadVotesThreshold
80
Important for PoSe. Threshold for votes on bad members. If >=dkgBadVotesThreshold members have voted on another member to be bad, that member is also considered bad locally. Should be between 75% - 85%. So maybe 80 would be a good number.
signingActiveQuorumCount
24
keepOldConnections
I'm not really sure about this value (and it wasn't defined by platform team) so we need to figure out what a proper value would be. llmq_50_60 is 25, llmq_400_60 is 5
recoveryMembers
50 (not defined by platform team)
I'm also not really sure about this value...
Activation
I believe this will need to be activated via a BIP9 style hard fork
Implement 100 Member LLMQ to be used by Dash Platform
Benefits of implementing a new LLMQ
Quorum size is 100 instead of 50 so:
Validation workload distributed more evenly among network
Do not disturb IS lock process by utilizing the same LLMQ
LLMQ Parameters
type
4
name
llmq_100_67
size
100
This should hit the balance between performance and security for the launch of Dash platform. If we succeed to significantly reduce the block time by consensus optimisations we will reconsider the quorum size. The desire to raise the validator set’s size stems from both concerns with DDos protection and work load distribution.
minSize
90
threshold
Maybe better to set it to 67 to be BFT compatible (>=67/<33). Or we could stick with the normal LLMQ thresholds of 60 (>=60/<=40).
dkgInterval
24
The number of blocks between two DKG sessions. If set to 576 for example, a new DKG session will start once per day. This depends on how quick we want to have new validator quorums form. Probably should be 24 like with IS quorums for simplicity.
dkgPhaseBlocks
2
Number of blocks a single DKG phase is active. It must be high enough to allow all members to exchange all required messages. It must also be high enough to take block time variances into account. Minimum seems to be 2.
dkgMiningWindowStart
10 (not defined by platform team)
dkgMiningWindowEnd
18 (not defined by platform team)
dkgBadVotesThreshold
80
Important for PoSe. Threshold for votes on bad members. If >=dkgBadVotesThreshold members have voted on another member to be bad, that member is also considered bad locally. Should be between 75% - 85%. So maybe 80 would be a good number.
signingActiveQuorumCount
24
keepOldConnections
I'm not really sure about this value (and it wasn't defined by platform team) so we need to figure out what a proper value would be. llmq_50_60 is 25, llmq_400_60 is 5
recoveryMembers
50 (not defined by platform team)
I'm also not really sure about this value...
Activation
I believe this will need to be activated via a BIP9 style hard fork