Fork-choice rule for dynamic stake protocols

[jsoares]

In Proof-of-Stake protocols with dynamic staking, participants can do stake updates: add, remove and confirm their committed stake. In a longest-chain protocol, this may lead to forks with two different committed stake amounts. Intuitively forks with higher committed stake should be preferred since there are more assets at stake.

Designing a fork choice rule for such protocols poses the following challenges:

• If the total committed stake counts in the weight of a fork, the protocol is vulnerable to:
  • “Stake Game Attacks”: the adversary could remove all of the sudden its stake from the honest chain while starting a private chain in which it will keep its stake. For a short-period of time, this means that the adversarial chain has more stake than the honest chain and the adversary could use this to increase its chance of attacking the system.
• If the total committed stake does not count, the protocol suffers from:
  • In the _honest vs malicious _setting “Stake Bleeding Attacks”: the adversary starts a private chain in which the honest committed stake will gradually be removed from the chain (as the adversary would skip confirmation of their stake in its private chain) to the point where the adversary controls more than 50% of the committed stake in this chain. The adversary will still maintain its stake in the honest chain, without contributing blocks such that the average number of blocks created in the honest chain will be less than those created in the adversarial chain.
  • In the rational setting “Stake Update Exclusion”: participants may have no incentive to include messages of other participants that want to “increase” their stake commitment (as this decreases their relative power and reward). This is even more problematic in some protocols, such as Filecoin, where participants must “confirm” their current stake periodically otherwise it will get removed. \

A direction is to use the fork choice rule similar as the one proposed by Ouroboros Genesis, however this fork choice rule does not incentivise miners to include other miners' stake confirmations nor addition (since power does not count in the chain’s weight), so “Stake Update Exclusion” is not solved.

Why is it important in Filecoin?

In Filecoin the weight function includes both the number of blocks and the total power committed to the chain (in terms of storage) hence is vulnerable, to some extent, to the attacks described above. Furthermore in Filecoin storage (i.e., power) must be periodically proved, hence Stake Bleeding and Stake Update Exclusion are all the more effective for an adversary.