Guide - masternode sync

- Added details including the schedule at which various sync-related
actions occur
This commit is contained in:
thephez 2017-11-06 11:13:09 -05:00
parent 1314d4c28e
commit 3e238c858c

View file

@ -669,7 +669,53 @@ treated as misbehaving and have its ban score increased.
Dash Core performs masternode synchronization as required, but it can be started Dash Core performs masternode synchronization as required, but it can be started
manually by issuing the `mnsync reset` RPC command. manually by issuing the `mnsync reset` RPC command.
*Masternode Sync Data Flow* There are several conditions that restart the sync process:
* More than 60 minutes have passed since the last activation
* A failure occurred during the last sync attempt (after a 1 minute cooldown before sync restarts)
#### Masternode Sync Status
There are several status values used to track masternode synchronization. They
are used in both `ssc` messages and the `mnsync` RPC.
| **Value** | **Status** | **Description** |
| -1 | `MASTERNODE_SYNC_FAILED` | Synchronization failed |
| 0 | `MASTERNODE_SYNC_INITIAL` | Synchronization just started, was reset recently, or is still in IBD |
| 1 | `MASTERNODE_SYNC_WAITING` | Synchronization pending - waiting after initial to check for more headers/blocks |
| 2 | `MASTERNODE_SYNC_LIST` | Synchronizing masternode list |
| 3 | `MASTERNODE_SYNC_MNW` | Synchronizing masternode payments |
| 4 | `MASTERNODE_SYNC_GOVERNANCE` | Synchronizing governance objects |
| 999 | `MASTERNODE_SYNC_FINISHED` | Synchronization finished |
#### Masternode Sync Schedule
The following tables detail the timing of various functions used to keep the
masternodes in sync with each other. This information is derived from
`ThreadCheckPrivateSend` in `src/privatesend.cpp`.
| **Period (seconds)** | **Action** | **Description** |
| 6 | MN Sync | Synchronizes sporks, masternode list, masternode payments, and governance objects |
The following actions only run when the masternode sync is past `MASTERNODE_SYNC_WAITING` status
| **Period (seconds)** | **Action** | **Description** |
| 1 | MN Check | Check the state of each masternode that is still funded and not banned. The action occurs once per second, but individual masternodes are only checked at most every 5 seconds (only a subset of masternodes are checked each time it runs) |
| 60 | Process MN Connections | Disconnects some masternodes |
| 60 | MN Check/Remove | Remove spent masternodes and check the state of inactive ones |
| 60 | MN Payment Check/Remove | Remove old masternode payment votes/blocks |
| 60 | InstantSend Check/Remove | Remove expired/orphaned/invalid InstantSend candidates and votes |
| 300 | Full verification | Verify masternodes via direct requests (`mnv` messages). Note time constraints in the Developer Reference section |
| 300 | Maintenance | Check/remove/reprocess governance objects |
| 600 | Manage State | Sends masternode pings (`mnp` message). Also sends initial masternode broadcast (`mnb` message) for local masternodes. |
#### Masternode Sync Data Flow
The following tables details the exchanged of P2P messages during masternode
synchronization.
| **Syncing Node Message** | **Direction** | **Masternode Response** | **Description** | | **Syncing Node Message** | **Direction** | **Masternode Response** | **Description** |
| **1. Sporks** | | | | | **1. Sporks** | | | |