21 - LLMQ DKG Data Sharing#

  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#