Skip to content

Latest commit

 

History

History
139 lines (105 loc) · 7.71 KB

dip-0021.md

File metadata and controls

139 lines (105 loc) · 7.71 KB
Raw
  DIP: 0021
  Title: LLMQ DKG Data Sharing
  Author(s): dustinface
  Special-Thanks:
  Comments-Summary: No comments yet.
  Status: Proposed
  Type: Standard
  Created: 2021-03-08
  License: MIT License

Table of Contents

  1. Abstract
  2. Motivation
  3. Prior Work
  4. Specification
  5. Processing and Usage
  6. Reference Implementation
  7. Copyright

Abstract

This document introduces two new P2P messages called QGETDATA and QDATA. The QGETDATA message allows masternodes to request QDATA messages containing various data payloads, such as quorum verification vectors or distributed key generation (DKG) contributions, from members of a Long Living Masternode Quorum (LLMQ).

Motivation

There are the following two problems which can be solved with the proposed P2P messages:

  1. In Tenderdash a validator-set is represented by an LLMQ. In order to change the validator-set from LLMQx to LLMQy, LLMQx must include all required data (including public key shares) of LLMQy in the Tenderdash block which proposes/executes the validator-set rotation. This means that for validator-set rotation in Tenderdash to work, all members of LLMQx must have the quorum verification vector of LLMQy (which currently isn’t the case) so they can calculate the public key shares for all LLMQy members.
  2. If a member of LLMQx needs to reindex or wipe the data directory (e.g. due to unexpected issues during an upgrade or unexpected file corruption), it currently loses all the information it requires to participate in LLMQx signing sessions. This information includes the quorum verification vector and its own DKG secret key share. Currently there is no mechanism for masternodes to recover this data from other members.

Prior work

Specification

Two new messages are defined: QGETDATA and QDATA. The two new P2P messages will only be available for masternodes, must be ignored by non-masternode connections and must be rate limited to prevent potential DoS attacks. Masternodes will only be allowed to request DKG data with QGETDATA from each member once every 5 minutes.

Any incorrect usage of these messages should result in a connection ban score increase of:

  • 10 - For duplicate/invalid/malformed messages
  • 25 - For exceeding the rate limit threshold

These messages will be available upon activation of protocol version 70219.

P2P - QGETDATA

The QGETDATA message is used to request a QDATA message from another masternode. The following table defines its available parameters:

Payload description

Field Type Size Description
quorumType uint8 1 byte Type of the quorum to request data from.
quorumHash uint256 32 bytes Hash of the quorum to request data from.
dataMask uint16 2 bytes Defines which data to request, see Available data flags.
protxHash uint256 32 bytes (Optional) Protx hash. See 0x0002 in Available data flags.

Where quorumHash and quorumType define from which quorum the data defined by dataMask gets requested.

P2P - QDATA

The QDATA message is the response to QGETDATA messages. It should be ignored and result in a small ban-score increase if it has not been requested. The following table describes its possible payload:

Payload description

Field Type Size Description
quorumType uint8 1 byte Type of the quorum the data is about.
quorumHash uint256 32 bytes Hash of the quorum the data is about.
dataMask uint16 2 bytes See Available data flags. This value should be equal to the dataMask value of the requesting QGETDATA message.
protxHash uint256 32 bytes This is the protx hash of the member which can decrypt the data in data_0002. Included if 0x0002 is set in dataMask.
error uint8 1 byte See Possible error codes
data_0001 BLSVerificationVector Variable Included if 0x0001 is set in dataMask. See Available data flags.
data_0002 std::vector<CBLSIESEncryptedObject<CBLSSecretKey>> Variable Included if 0x0002 is set in dataMask. See Available data flags.

Available data flags

Flag Description Response
0x0001 Request the quorum verification vector of the LLMQ. The quorum verification vector of the LLMQ.

Type: std::vector<CBLSPublicKey>

Size: <quorum_threshold> * 48 bytes

Max. size: ~16,320 bytes
0x0002 Request all encrypted DKG contributions directed to the member with the protx hash provided in the protxHash field. Set of secret keys encrypted with the operator key of the requesting masternode.

Type: std::vector<CBLSIESEncryptedObject<CBLSSecretKey>>

Size: <valid_member_count> * 112 bytes

Max. Size: 44,800 bytes

Possible error codes

Value Name Description
0x00 NONE No error, this value indicates the QGETDATA request was processed successfully.
0x01 QUORUM_TYPE_INVALID The quorum type provided in the quorumType field is invalid.
0x02 QUORUM_BLOCK_NOT_FOUND The hash provided in the quorumHash field wasn’t found in the active chain.
0x03 QUORUM_NOT_FOUND The quorum (combination of quorumType and quorumHash) wasn’t found in the active chain.
0x04 MASTERNODE_IS_NO_MEMBER The masternode with the protx-hash provided in the protxHash field is not a valid member of the requested quorum.
0x05 QUORUM_VERIFICATION_VECTOR_MISSING The quorum verification vector for the requested quorum is missing on the node servicing the request.
0x06 ENCRYPTED_CONTRIBUTIONS_MISSING The encrypted DKG contributions for the requested member are missing on the node servicing the request.

Processing and usage

For each QDATA message received, the receiving masternode must validate and store the related data. The following table shows the steps required depending on the dataType received:

dataType Validate and process the data Usage
0x0001 Calculate the hash of the received quorum verification vector. The calculated hash must match quorumvvecHash from the mined commitment of the LLMQ the data has been requested for. Mainly used to make the quorum verification vector of other LLMQs available on platform validators. Another use case is described in “Usage” of the flag 0x0002 below.
0x0002 Decrypt all the contributions with the operator key, aggregate them to the secret key share and make sure its public key matches the public key share calculated with the quorum verification vector for the masternode’s protxHash. This can be wrapped into a workflow where a masternode which is a member of one or more quorums has lost its LLMQ DKG data. By requesting 0x0002 it can recover its secret key share. When combined with 0x0001, it can recover itself as a valid member of the LLMQ by just asking other LLMQ-Members for the required data after a re-sync/re-index.

Reference implementation

Copyright

Copyright (c) 2021 Dash Core Group, Inc. Licensed under the MIT License