joshua/dips
1
0
Fork 0
mirror of https://github.com/seigler/dips synced 2025-07-27 01:36:14 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Describe new algo for quorum connections (#40)

Browse source
This commit is contained in:
UdjinM6 2019-02-19 17:04:24 +03:00 • committed by GitHub
parent 9e97430850
commit 60ade37fee
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

19
dip-0006.md
View file

@ -73,8 +73,6 @@ We will refer to these parameters and variables multiple times in the following
| quorumMinSize | Minimum number of valid members for quorum to be considered valid after the DKG has removed bad members. |
| quorumThreshold | The minimum number of threshold signature shares required to recover a threshold signature. It also influences the DKG as it is the minimum number of valid members to create a valid premature commitment and final commitment. This value should be at least 51% of the quorumSize. This is identical to the “m” in m-of-n. |
| quorumMinMemberAge | Minimum number of blocks a deterministic masternode must be confirmed on-chain before it is considered as a LLMQ member |
| quorumNeighborConnections | Number of connections to establish to neighbor nodes as described in “Intra-Quorum Communication” |
| quorumDiagonalConnections | Number of connections to establish to diagonal nodes as described in “Intra-Quorum Communication” |
| quorumDkgInterval | The number of blocks between two DKG sessions. If set to 576 for example, a new DKG session will start once per day. |
| quorumDkgPhaseBlocks | 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. |
| badVotesThreshold | Threshold for votes on bad members. If >=badVotesThreshold members have voted on another member to be bad, that member is also considered bad locally. |
@ -92,7 +90,7 @@ List of variables per DKG session:
The DKG and the signing sessions performed after LLMQ activation require many messages (up to one per phase and per member) to be propagated. Most of these messages are not of interest for nodes outside the LLMQ. Using full propagation (to all nodes) of all these messages would slow down the DKG and signing sessions dramatically. It would also impact the performance and stability of the whole network.
As a solution, we introduce the concept of “Intra-Quorum Communication”. Each LLMQ member is required to connect to a deterministically selected set of neighbor members and keep these connections open for the whole DKG and quorum lifetime. The way the required connections are determined ensures that there is always a path with low numbers of hops from each member to each other member. It also ensures that failure of individual members in the LLMQ does not result in total failure of the DKG and LLMQ.
As a solution, we introduce the concept of “Intra-Quorum Communication”. Each LLMQ member is required to connect to a deterministically selected set of members and keep these connections open for the whole DKG and quorum lifetime. The way the required connections are determined ensures that there is always a path with low numbers of hops from each member to each other member. It also ensures that failure of individual members in the LLMQ does not result in total failure of the DKG and LLMQ.
When messages need to be propagated to all other members, the members will then only push inventory items and messages to this deterministic set of connections. The other members will perform the same, until the message is propagated to the whole LLMQ.
@ -100,17 +98,14 @@ When messages need to be propagated to all other members, the members will then
Every member of the quorum has to build its own list of deterministic quorum connections. This is done the following way:
1. Build the deterministic list of quorum members (See Initialization Phase of the DKG protocol). “listSize” is the size of this list.
2. Loop through the list until the member finds itself in the list. The index at which it finds itself is called “i”.
3. Loop quorumNeighborConnections times, with “n” being the loop index. Calculate “c = (i + 1 + n) % listSize” for each loop iteration. If the resulting index does not equal to “i” (ourself), add the address of the masternode at index “c” to the set of deterministic connections.
4. Calculate “startIdx = (i + listSize / 2 - (quorumDiagonalConnections / 2) * quorumNeighborConnections) % listSize”.
5. Loop quorumDiagonalConnections times, with “n” being the loop index. Calculate “c = (startIdx + n * quorumNeighborConnections) % listSize” for each loop iteration. If the resulting index does not equal to “i” (ourself), add the address of the masternode at index “c” to the set of deterministic connections.
1. Build the deterministic list of quorum members (See Initialization Phase of the DKG protocol).
2. Loop through the list until the member finds itself in the list. The index at which it finds itself is called `i`.
3. Calculate indexes `(i+2^k)%n` where `k` is in the range `0..floor(log2(n-1))-1` and `n` is equal to the size of the list.
4. Add addresses of masternodes at indexes calculated at previous step to the set of deterministic connections.
When adding connections to the set of deterministic connections, duplicates should be ignored, meaning that every connection should exist only once in the set.
The result can be imagined as a circle of nodes.
The process can be imagined as a circle of nodes. In the first loop, each node connects to a few of his neighbors (e.g. the next 4 nodes). This gives good connectivity and low failure rates, but might result in slow propagation as distant nodes require more hops for each message. Thus, the second loop lets each node connect to a few distant nodes which are diagonal to itself on the circle. This builds shortcuts in the circle that allow for more parallel propagation and reduced failure rates.
![Building intra-quorum connections](dip-0006/intra-quorum-comm.png)
<p align="center"><img src="dip-0006/intra-quorum-comm.png" alt="Building intra-quorum connections" width="500"/></p>
Most messaging between members is performed using the inventory system of Dash. This means that members will first send INV messages to other members and respond to GETDATA messages. Some communication messages, however, will be directly sent (see [DIP007 - LLMQ Signing Requests/Sessions](https://github.com/dashpay/dips/blob/master/dip-0007.md)) to quorum members without using the inventory system.