docs(dip31): platform proof of service

README.md

@@ -44,6 +44,7 @@ Number | Layer | Title | Owner | Type | Status
 [28](dip-0028.md) | Consensus | Evolution Masternodes | Paul DeLucia, Odysseas Gabrielides, Łukasz Klimek, Ivan Shumkov, Samuel Westrich | Standard | Final
 [29](dip-0029.md) | Consensus | Randomness Beacon For LLMQ Selection | Virgile Bartolo | Standard | Proposed
 [30](dip-0030.md) | Consensus | Replay Attack Prevention and State Transition Nonces | Samuel Westrich | Standard | Proposed
+[31](dip-0031.md) | Consensus | Platform Proof of Service | Pasta | Standard | Proposed
 
 ## License
 

dip-0031.md

@@ -0,0 +1,121 @@
+<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 a
+masternode, will result in a masternode 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 `70235`.
+
+| 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 masternode associated with the protxHash is an evonode and not a regular masternode  
+   * Penalty: Ban node, P2P penalty (100)  
+4. Validate the signedHeight is valid and not too far in the past or future  
+   * Penalty: medium P2P penalty (10), it is possible we think we are synced, when we are not  
+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, masternodes 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
+
+Core shall expose a new RPC `platform ban`. This RPC shall have the format of: `platform ban
+protxHash signedHeight quorumHash blsSignature`. The RPC shall validate all of the information as
+described in the [Validation section](#validation). Then, Core 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)