Crown Masternode and Sytemnode Proof of Stake Consensus System [MNPoS]

Technical specifications for Crown MNPoS

The following is a detailed technical description of the Crown MNPoS consensus system. It explains the context of development, ellaborates on the solutions given to all detected conventional Proof of Stake vulnerabilities, and gives an overview of the system and its terminology. If you have any questions, please do not hesitate to join the Crown GitLab/social networks and ask them!

Crown MNPoS solves detected vulnerabilities in other PoS systems and ascends Masternodes and Systemnodes to consensus kings.

a) History

b) Traditional Proof of Stake Attack Vectors and Mitigation

1) Long Range

2) Nothing at Stake

3) Stake Grinding

4) Overcrowding / Undercrowding

5) Masternode Set Disagreement

c) Masternode Proof of Stake Consensus System Overview and Terminology

a) History

The Crown Masternode Proof of Stake system was commissioned in Summer 2018 and delivered in Spring 2019 in the Crown v0.13.0 ("Jade") release. It was designed to overcome known attack vectors in existing Proof of Stake consensus mechanisms, and to provide a unique cold staking solution.

b) Traditional Proof of Stake Attack Vectors and Mitigation

5 specific attack vectors were identified and mitigation techniques developed. Additionally, during development the much publicised "fake stake" attack vectors were addressed.

1. Long Range

Description

An attacker overtakes the main chain by producing a competing chain using past staking balances. For example, assume an attacker has a moderately large stake in the network then exchanges their stake for another cryptocurrency (or for fiat). They no longer have a stake in the network at the most recent block but their past stake is still viable from the perspective of some older blocks. This attacker may collude with other attackers who've followed the same steps until they reach 51% of the supply at that point in time. Now they have the ability to quickly generate a fork by forging previous time stamps until the height of the fork is equal to the height of the main chain. This can be done in such a way that the trust scores of the two chains are very close. Without additional safeguards, honest nodes would not be able to differentiate between the honest chain and the attacker's chain, thus potentially forcing a reorg.

Solution

A maximum reorganization depth completely mitigates long range attacks on online validating nodes. The issue still exists for inactive nodes who are re-syncing with the network and new nodes who are syncing for the first time. A fixed checkpointing system is used to prevent syncing nodes from syncing with the attacker's chain. This is done by either directly encoding checkpoints into the source code (long interval checkpointing) or broadcasting checkpoints from a trusted source (short interval checkpointing). Although these solutions may introduce other issues, they do drastically reduce the likelihood of a long range attack.

2. Nothing at Stake

Description

A distinction must be made between honest, rationally self interested, and malicious nodes. Honest nodes will always align their actions with what is best for the network. Rationally self interested nodes don't aim to compromise the network but their self interest may lead them in that direction if the incentive structure facilitates it. A malicious node's only goal is to compromise the network. Now imagine a chain with multiple competing forks. No node can be sure which fork will ultimately win, so in order to improve their expected value the rationally self interested nodes stake on every fork. This is an issue for two core reasons: 1. it can cause uncontrollable forking because the network can't reach a consensus on what the main chain is and 2. the stake threshold an attacker needs to launch a 51% attack is reduced because the rationally self interested nodes will effectively assist in the attack by staking on the attacker's chain.

Solution

The double-block protection mechanism allows for the cancellation of the top block for double stakes. This partially mitigates the risk of the nothing at stake attack being successful. Additionally, the rationally self interested nodes may have an incentive to stake on as many chains as possible to increase returns but they also have an incentive to help the network reach consensus in a timely manner. Otherwise, they run the risk of losing their entire deposit due to the dysfunctional network. When considering these positive factors, the likelihood of the nothing at stake problem occurring in reality is very low from both an economic and technical standpoint.

3. Stake Grinding

Description

Also known as a pre-computation attack. If there is no context based entropy included in the target calculation then the staker can calculate the future target values that their stake will produce. With this information the staker now has no incentive to remain online before they expect to successfully stake a block. This reduces the quantity of active verifying nodes and thus reduces the security of the network. If the nodes were unable to determine when they would successfully stake then they would have to remain online consistently. Another attack that is based on this same principle is pre-computing the outcome of different events and using the results of those computations to determine how to increase the likelihood of staking consecutive blocks. The act of computing all the possible outcomes is called Stake Grinding and essentially reduces proof of stake consensus to bitcoin's original proof of work consensus that proof of stake was meant to replace.

Solution

The process of including chain based entropy into the target hash calculation is known as stake modification. The more the stake modifier can obfuscate future target hashes, the more difficult it becomes to successfully launch a stake grinding attack. Different stake modification schemes provide different degrees of obfuscation so it's crucial to use the best one available. The most advanced stake modification schemes include deterministic sampling of entropy from previous blocks within the modifier interval and change significantly from block to block. This makes pre-computation attacks unfeasible for any realistic amount of computing power.

4. Overcrowding/Undercrowding

Description

In order for a node to be able to successfully stake a block they must provide the proof pointer to their most recent masternode or systemnode reward transaction. The proof pointer is only valid if the payment occurred at most some minimum number of blocks earlier in the chain. This proof pointer interval can be exploited under certain circumstances if not designed with enough flexibility. If the number of active masternodes increases substantially over time then the proportion of them who are able to stake may decrease. This essentially reduces the size of the validator node set and opens up the opportunity for an attacker who holds less than 51% stake in the network to launch an attack. This attack vector is called overcrowding.

It's also possible to have the opposite problem of a substantial decrease in active masternodes. Consider a masternode that goes offline immediately after their most recent masternode payment. They are still eligible to stake for some amount of time after they go offline. From an incentive structure point of view, it's important that a large proportion of the nodes staking are active masternodes. Otherwise, a node can act as a masternode for a short amount of time (until they receive their first reward) because there aren't many masternodes in the queue. Then, they deactivate the masternode but are able to continue staking for a long period of time. This attack vector is called undercrowding.

Solution

This issue necessitates a dynamic but deterministically generated proof pointer interval based on the network's current knowledge of the masternode set size. Because it requires knowledge of the masternode set size, this model assumes some minimum threshold of consistency across the network in terms of what each node perceives to be the active masternode set. To fulfil this requirement a large sampling interval can be chosen to determine the distribution of masternode rewards for specific public keys. This information can be used to construct the likely size of the set in a deterministic way. The size can then be used to update the proof pointer interval every n blocks.

5. Masternode Set Disagreement

Description

The issue of disagreeing on the state of the masternode set here is similar to the causes behind the overcrowding problem; except in this case it isn't just the size of the set that's important, it's also the ordering of masternodes within the queue. The order of the queue determines which masternode will receive a reward next, and any newly proposed block that does not include the correct masternode reward will be rejected by the network. This works as intended the majority of the time but if there's significant disagreement on the queue ordering then this validation requirement can cause uncontrollable forking. A hard fork is a good example of a situation that can lead to disagreement on the queue ordering and the composition of the masternode set.

Solution

The spork system can be utilized to temporarily change consensus rules during especially contentious periods on the network. Spork 8 in the existing spork system (MASTERNODE_PAYMENT_ENFORCEMENT) can be used to disable checks on the masternode payments included in blocks. This would eliminate the issue of uncontrollable forking. The problem is that if an attacker were able to stake many blocks during this period of disabled masternode payment enforcement, they can significantly influence the masternode reward distribution. The distribution is used to deterministically calculate the proof pointer interval so the attacker would be able to manipulate the future behaviour of the network. A couple of different strategies can be employed to mitigate this. One option is to reduce the amount of time the spork is disabled as much as possible so that an attacker wouldn't be able to cause a noticeable change in distribution. If this isn't possible then protocol level solutions need to be implemented. For example, a larger sampling interval would reduce the attacker's impact, but this may produce unwanted externalities under certain conditions. Another approach is to mark newly created blocks and ignore them in future sampling processes.

c) Crown Masternode Proof of Stake Consensus System Overview

The proof of stake consensus system for Crown allows both masternodes and systemnodes to create new blocks and add them to the blockchain. Users do not need to run hot wallets to participate in the staking process.