# 31 - Platform Proof of Service

<pre>
  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
</pre>

# Table of Contents

* [Abstract](#abstract)
* [Motivation](#motivation)
* [Prior Work](#prior-work)
* [PlatformBan P2P Message](#platformban-p2p-message)
* [Validation](#validation)
* [Processing](#processing)
* [Effect](#effect)
* [Signing Process](#signing-process)
* [Ban RPC command](#ban-rpc-command)
* [Copyright](#copyright)

## 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

* [DIP-0006: Long-Living Masternode
  Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md)  
* [DIP-0007: LLMQ Signing Requests /
  Sessions](https://github.com/dashpay/dips/blob/master/dip-0007.md)

## 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](https://github.com/dashpay/dips/blob/master/dip-0006.md)) 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](https://github.com/dashpay/dips/blob/master/dip-0003.md#updating-service-features-from-operator-proupservtx)
in the deterministic masternode list (DML).

## Signing Process

This should follow the LLMQ signing protocol as described in
[DIP-7](https://github.com/dashpay/dips/blob/master/dip-0007.md). 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](#validation) 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](https://opensource.org/licenses/MIT)