Multiple updates regarding LLMQs (#42)

* Add description of new LLMQ merkle roots to DIP4

* Rename deletedMNcount -> deletedMNsCount

* Add quorumType to parameter description and DIP6 P2P messages

* Remove quorumMinMemberAge from parameter description

This was never implemented

* Rename badVotesThreshold -> quorumDkgBadVotesThreshold

* Update testing LLMQ type to LLMQ_5_60

* Better describe active LLMQs in DIP6 and DIP7

* Bump CbTx version

* Handle review comments
This commit is contained in:
Alexander Block 2019-04-29 14:20:26 +02:00 committed by thephez
parent 60ade37fee
commit 745adcee3f
4 changed files with 75 additions and 10 deletions

View file

@ -43,7 +43,7 @@ More data could have been potentially added the same way as defined in BIP34, ho
The Coinbase Transactions will become a special transaction (DIP2) to the network. We abbreviate this transaction as CbTx. Miners must calculate the correct values for each field of the CbTx while all other nodes must verify correctness of these fields. If a node receives a block with an invalid CbTx, it must reject the block.
This DIP proposes adding 2 fields to the CbTx. These are the “height” and “merkleRootMNList” fields. Future DIPs might add additional fields to the CbTx.
This DIP proposes adding multiple fields to the CbTx. Future DIPs might add additional fields to the CbTx.
The special transaction type used for Coinbase Transactions is 5.
@ -55,6 +55,12 @@ The transaction consists of the following data in the payload area:
| height | uint32_t | 4 | Height of the block |
| merkleRootMNList | uint256 | 32 | Merkle root of the masternode list |
Starting with version >= 2, the following fields are added:
| Field | Type | Size | Description |
| ----- | ---- | ---- | ----------- |
| merkleRootQuorums | uint256 | 32 | Merkle root of currently active LLMQs |
### Height in CbTx and deprecation of BIP34
The CbTx contains the “height” field. It acts as a guaranteed variance in the CbTx so that each blocks CbTx gets a different hash. This is meant as a replacement for the height value currently found in the coinbase input (BIP34). With the deployment of this DIP, BIP34 becomes obsolete for new blocks and nodes should not enforce the presence of the block height in the coinbase input's “scriptSig” anymore.
@ -88,6 +94,23 @@ A SML entry consists of the following fields:
| keyIDVoting | CKeyID | 20 | The public key hash used for voting. |
| isValid | bool | 1 | True if a masternode is not PoSe-banned |
### Calculating the merkle root of the active LLMQs
The CbTx contains the “merkleRootQuorums” field. This is the merkle root of all the hashes of the final quorum commitments
of all active LLMQ sets.
To calculate the merkle root:
1. Collect all final commitments from all LLMQs which are in the active set at the given block height. All LLMQ types need
to be collected.
2. Calculate the hash of all these commitments and collect the hashes in a list.
3. Sort this list in ascending order by the previously calculated hash.
4. Calculate the merkle root from this list of hashes in the same way it is done when calculating the merkle root of the block transactions.
Please refer to [DIP6 - Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md) for more details on LLMQs
and final commitments. The final commitment referred to multiple times in this DIP is the `qfcommit` message found in
DIP6.
## Requesting the masternode lists
The P2P message `GETMNLISTDIFF` is introduced to request a full masternode list or an update to a previously requested masternode list. It expects a serialized object with the following structure as arguments:
@ -113,11 +136,21 @@ The `MNLISTDIFF` message contains a serialized object with the following structu
| merkleFlagsCount | compactSize uint | 1-9 | Number of Merkle flag bytes |
| merkleFlags | uint8_t[] | variable | Merkle flag bits, packed per 8 in a byte, least significant bit first |
| cbTx | CTransaction | variable | The fully serialized coinbase transaction of blockHash |
| deletedMNcount | compactSize uint | 1-9 | Number of ProRegTx hashes which were deleted after baseBlockHash |
| deletedMNsCount | compactSize uint | 1-9 | Number of ProRegTx hashes which were deleted after baseBlockHash |
| deletedMNs | uint256[] | variable | A list of ProRegTx hashes for masternode which were deleted after baseBlockHash |
| mnCount | compactSize uint | 1-9 | Number of SML entries which were added or updated since baseBlockHash |
| mnList | SMLEntry[] | variable | The list of SML entries which were added or updated since baseBlockHash |
Starting with protocol version 70214, the following fields are added to the `MNLISTDIFF` message.
| Field | Type | Size | Description |
| --- | --- | --- | --- |
| deletedQuorumsCount | compactSize uint | 1-9 | Number of LLMQs which were deleted from the active set after baseBlockHash |
| deletedQuorums | (uint8_t+uint256)[] | variable | A list of LLMQ type and quorum hashes for LLMQs which were deleted after baseBlockHash |
| newQuorumsCount | compactSize uint | 1-9 | Number of new LLMQs which were added to the active set since baseBlockHash |
| newQuorums | qfcommit[] | variable | The list of LLMQ commitments for the LLMQs which were added since baseBlockHash |
## Tracking/Updating and verifying masternode lists based on MNLISTDIFF
With DIP3, each block in the chain might result in a different masternode list. SPV clients are required to keep track of these multiple masternode lists so they can properly verify quorum related messages when the lists change. Very old masternode lists can be pruned as it is very unlikely that they are necessary.
@ -132,6 +165,23 @@ To achieve this, It is suggested to first request a full masternode list from an
6. Calculate the hash of “cbTx” and verify existence of this transaction in the block specified by “blockHash”. To do this, use the already received block header and the fields “totalTransactions”, “merkleHashes” and “merkleFlags” from the `MNLISTDIFF` message and perform a merkle verification the same way as done when a “MERKLEBLOCK” message is received. If the verification fails, abort the process and ask for diffs from another node.
7. Store the resulting validated masternode list identified by “blockHash”
## Tracking/Updating and verifying the active LLMQ sets based on MNLISTDIFF
With the introduction of version 2 CbTx special transactions, a merkle root for the currently active LLMQ sets was added
to the coinbase. This merkle root allows (SPV) clients to maintain the active LLMQ sets without the full chain.
It is suggested to couple the house-/bookkeeping of active LLMQ sets with the masternode list bookkeeping described in
the previous section and perform the following additional steps:
1. Create a copy of the active LLMQ sets which were given at "baseBlockHash". If “baseBlockHash” is all-zero, empty sets must be used.
2. Delete all entries found in "deletedQuorums" from the corresponding active LLMQ sets.
3. Verify each final commitment found in "newQuorums", by the same rules found in [DIP6 - Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md).
If any final commitment is invalid, abort the process and ask for diffs from another node.
4. Add the LLMQ defined by the final commitments found in "newQuorums" to the corresponsing active LLMQ sets.
5. Calculate the merkle root of the active LLMQ sets by following the “Calculating the merkle root of the active LLMQs” section
6. Compare the calculated merkle root with what is found in “cbTx”. If it does not match, abort the process and ask for diffs from another node.
7. Store the new active LLMQ sets the same way the masternode list is stored.
## Copyright
Copyright (c) 2018 Dash Core Team. [Licensed under the MIT License](https://opensource.org/licenses/MIT)