Traditional Proof of Stake Attack Vectors and

Mitigation

Long Range Stake Grinding

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 resyncing 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). Athough these solutions may introduce other
issues, they do drastically reduce the likelihood of a long range attack.
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.
Description: Also known as a precomputation 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 precomputing 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 precomputation
attacks unfeasible for any realistic amount of computing power.

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 occuring in reality is very low from both an economic and technical standpoint.
 Crown Proof of Stake Vulnerabilities and
Mitigations
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 occured 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 veiw, 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 fulfill 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.
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
behavior 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.