Skip to content

Latest commit

 

History

History
124 lines (97 loc) · 5.38 KB

dip-0031.md

File metadata and controls

124 lines (97 loc) · 5.38 KB
  DIP: 0031
  Title: Platform Proof of Service
  Chain: Core
  Author(s): Ivan Shumkov, Pasta
  Special-Thanks:
  Comments-Summary: No comments yet.
  Status: Proposed
  Type: Standard
  Created: 2024-09-12
  License: MIT License

Table of Contents

Abstract

Core will introduce a new P2P message platformban, which, when properly signed and received by any masternode type, will result in the node voting against the targeted evonode in all future DKG sessions until that targeted evonode has been successfully banned. Platform will initiate this ban process by passing relevant information to Core using RPC.

Motivation

To ensure that evonodes provide service on Dash Platform and that non-functioning evonodes do not participate in the Platform validator set, Platform needs a way to exclude faulty evonodes from future Platform validator sets / quorums. Since these nodes are not properly providing service, they should be proof-of-service (PoSe) banned. This DIP outlines a method for Platform to securely notify Core that a node should be banned.

Prior Work

PlatformBan P2P Message

Core will introduce a new P2P message, which will facilitate the PoSe banning of nodes identified as not providing proper service on Platform. This P2P message will be broadcast via the inventory system and introduced in Protocol Version 70236.

Field Type Size(bytes) Description
protxHash uint256 32 The protxHash of the evonode being banned
signedHeight int32_t 4 The height at which this message was signed by the platform quorum
quorumHash uint256 32 The quorumHash of the quorum which signed the message
signature byte[] 96 The BLS signature over the message, by the quorum identified by quorumHash

Note: this P2P message intentionally excludes an internal version; instead, it is versioned via the Protocol Version.

Validation

When received, a node must validate the message. It should do this by:

  1. Check if the node is synced
    • Penalty: skip validation of message, do not forward, do not mark as received in inventory
  2. Validate the protxHash is in the masternodeList
    • Penalty: small P2P penalty (1), as the evonode may have very recently been removed
  3. Validate the protxHash is associated with an evonode and not a regular masternode
    • Penalty: Ban node, P2P penalty (100)
  4. Validate the signedHeight is within [TipHeight - 576, TipHeight]
    • Penalty: small P2P penalty (1) if signedHeight is inside the range [TipHeight - 576 - 5, TipHeight + 5]. The node might incorrectly think it is synced, or blocks might be arriving quickly enough that a previously valid message is no longer valid.
    • Penalty: medium P2P penalty (10) if signedHeight is outside the mentioned ranges.
  5. Validate the quorumHash, with quorum type equal to the platform quorum, exists at the signedHeight
    • Penalty: Ban node, P2P penalty (100)
  6. Validate the blsSignature is valid for the quorumHash over the protxHash and signedHeight
    • Penalty: Ban node, P2P penalty (100)

The inventory system should mark the message as received unless validation case 1 fails.

Processing

Once validation succeeds, Core shall adjust an internal PlatformPoSeBan flag from false to true. This flag should be stored on disk and persisted across restarts.

Effect

During subsequent DKG sessions, all masternode types should voteBad against members marked as PlatformPoSeBanned. If, during the DKG session, quorumDkgBadVotesThreshold (as defined by DIP-6) members vote to indicate a member is bad, it will be prevented from participating in the quorum, resulting in a PoSe penalty bump and potentially a PoSe Ban. The flag PlatformPoSeBanned must be set to false when an evonode is revived in the deterministic masternode list (DML).

Signing Process

This should follow the LLMQ signing protocol as described in DIP-7. The LLMQ type authorized to sign this shall be the consensus.llmqTypePlatform. On mainnet this is LLMQ_100_67 and on testnet this is LLMQ_25_67. The signing session parameters are:

DIP-7 parameter Value
Request ID SHA256(SHA256("PlatformPoSeBan", protxHash, signedHeight))
Message hash SHA256(SHA256(protxHash, signedHeight))

Ban RPC command

A node should accept and validate all of the information as described in the Validation section via a new RPC command. Then, the node shall bundle this information into the platformban P2P message and add it to the inventory system.

Copyright

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