Proof-of-Stake, Private Keys Attacks and Unforgeable Costliness the Unsung Hero
In my previous article, I discussed how PoS is less resilient than PoW in dealing with worst-case scenarios.
In this article, I want to expand on worst-case scenario #3: private keys attacks.
There are 2 types of private keys attacks: old private keys attack & current private keys attack.
- Old private keys attack
Earlier versions of PoS typically employ a fixed validator set. This means that users who sold their stakes at some point in the past can still participate in the validation process (in PoS validating is equivalent to block-minting) in the future. This is a huge loophole since there’s a lot of money to be made for anyone who gets a hold of these outdated keys (by rewriting history), while there is zero downside. This is also known as the nothing-at-stake problem.
To address this issue, newer versions of PoS use dynamic validator sets and/or checkpoints. The idea is to revoke the right of past stake holders to participate in future validation.
However, even with these measures in place, PoS protocols can’t completely make the problem go away. Two types of nodes are still particularly vulnerable:
a) New nodes who just joined the network
b) Long-dormant nodes
Since these nodes either start with a blank memory or have a huge gap in their memory, they would have trouble detecting that some stake holders already sold their coins on the “real” chain when they weren’t online.
Some PoS proponents will be quick to point out that similar problem exists for new nodes in PoW, so it’s an acceptable problem.
This argument is highly misleading. While it’s true that new users in a PoW system do need to trust someone, in order to download the correct version of the software & to bootstrap peers, the trust doesn’t extend to choosing which chain is valid.
Second & much more importantly, once the PoW node software has been downloaded, it’s reasonably safe for the PoW node operator to turn off the node for an arbitrary amount of time. Past the bootstrapping stage, PoW is highly permission-less: nodes can come & go whenever they like. The only exception to this is in the event of hard forks, which require the node operators to repeat the bootstrapping process (another reason hard forks should be used very judiciously & avoided if possible).
In contrast, a PoS node operator, even with the correct software downloaded, will regularly need to reach out to trusted third parties to ensure he stays on the canonical chain. The fear of losing contact with the main network & getting tricked onto the wrong chain will continue for eternity, possibly long after the trusted third parties cease to exist! This marks a significant degradation in security.
All PoS protocols suffer from this fundamental problem.
2. Current private keys attack
In the second type of attack, the keys are current. Which means that neither dynamic validator sets nor checkpoints would help. (In fact, automatic checkpoints would exacerbate the problem by making unresolved splits permanent.)
How it works: an attacker who gains access to private keys that control at least 1/3 of the coin supply [1], will easily be able to create two equally valid blocks of the same height, with neither block appearing more “correct” to the rest of the network (effectively creating a chain split). This is already a deal breaker for the majority of PoS protocols, since they are forced to halt operation if the 2/3+ honest majority threshold is not met. No block can be “finalized” for any given round. The PoS chain will stop dead in its track.
(The ability to guarantee continued operation is known as the “liveness” property).
A closer look at a few PoS implementations:
i) Tendermint:
Tendermint acknowledges the above shortcoming and concedes that in the event of the protocol getting stuck, users have to go out-of-band to reach consensus:
“A subset of the validators through external means should coordinate to sign a reorg-proposal that chooses a fork.”
The honesty is laudable, but I wholeheartedly disagree that this “solution” is a solution at all. Increased reliance on manual human intervention means that the protocol is less scalable & more easily corruptible. It is far from the kind of robustness that we should aim for in designing critical, infrastructure-level software. This is fundamentally a problem of mindset as I discussed in my previous article.
ii) Casper
Casper can also get stuck if an adversary controls 1/3+ of the stake.
Casper introduces the problematic concept of “inactivity leak”, where nodes get penalized for the mere crime of going offline. Whether you’re intentionally going offline to cause harm or not, it doesn’t matter. This is a super perverse rule because a) it introduces a new vulnerability where an attacker can DDOS honest validators into going offline & cause them to lose money and b) it potentially discourages nodes from staking for fear of losing money. This has a negative impact on overall security, since staking participation is extremely critical to PoS (more on this below).
iii) DFINITY
In DFINITY a block needs to be “notarized” (read: confirmed) twice before it can be finalized. An adversary with 1/3+ stake could also stop blocks from being notarized & freeze the protocol.
There are a few things worth pointing out in DFINITY.
DFINITY introduces a mechanism that tries to emulate the “weight” property of a PoW chain (so that it can resolve chain splits), but without the backing energy. It randomly assigns a “rank” to each validator in a round, via something called a “random beacon”. The “weight” of each block is equal to the rank of the validator that created it. Simply put, DFINITY’s idea of weight is based on nothing but randomness (and everyone agreeing on the same randomness).
Leaving aside the issue of whether the “random beacon” can truly be implemented securely & in a decentralized way, intuitively, this is a flawed idea.
A digital block has no real weight. All a block is is a bunch of 0’s and 1’s. If it costs nothing to produce, it will cost nothing to forge or reproduce. The thing that makes the weight of a PoW block real is that there is a direct, provable linkage between the block hash & the energy spent mining that block. (For more on this, check out my article on PoW).
A DFINITY block’s weight, on the other hand, is subjective & therefore can be manipulated. This make-believe weight would become meaningless if a) nodes ever disagree on the randomness, or b) the source of randomness malfunctions (e.g.: failure to notarize blocks would cause the random beacon to stop).
Overall, DFINITY security might actually be worse than Tendermint and Casper. The “Threshold Group”, while a cool idea, represents only a subset of all active validators (k < N). Since the subsets are picked randomly, adversarial nodes could easily be over-represented in some subsets (and under-represented in others). An adversary who controls 1/3 of the validator set could have more than 1/3 participation in a subset. The attacker could further improve his odds by “grinding” identities until he gets the participation ratio he desires. (He only needs to control some threshold groups, not all.)
Stake participation
So far in this analysis we have assumed that the worst-case here is an attacker gaining control over 1/3+ of the total coin supply, which is hard but not impossible. But in reality, the requirement for the attacker is much lower since the attacker only needs 1/3+ of the active stake.
It’s extremely unlikely that all coin holders will participate in the process of staking & validating. Let’s say the rate of participation is 50%, then the attacker only needs 1/6 of the coin supply in order to cause conflicting blocks/checkpoints, instead of 1/3. If the rate of participation is 25%, the attacker only needs 1/12. This is quite alarming because as stated, wealth distributions follow power laws. A handful of the richest stake holders could easily control 1/12 of the coin supply.
Low rate of participation in staking is probably the greatest threat facing PoS protocols.
Another issue that exacerbates the current-keys-theft problem is PoS connectivity requirement: validators are required to keep their staking keys online in order to sign transactions. The fact that these keys are always connected to the network means that they are a lot more vulnerable to being hacked or stolen. It doesn’t matter if these staking keys directly control the funds behind the stakes or not: those who gain control over the majority of these staking keys (that belong to the active validator set) will gain control over the minted blocks [3].
Unforgeable costliness: the unsung hero
Taking a step back, let’s break down the secret behind Bitcoin’s breakthrough innovation. There are three key ingredients:
- Randomness
- “Unforgeable costliness”
- Incentives
(1) and (2) are aspects of PoW mining. While (3) is embedded in the consensus code.
(1) falls into the realm of computer science & cryptography, while (3) falls into the realm of economics & Game Theory.
(2), on the other hand, does not neatly fit into any discipline. The mental models required to understand (2) and why (2) matters, come from a combination of different disciplines such as archeology, evolutionary psychology, economics and even physics [2].
Possibly due to this under-studied nature of (2), many have dismissed it & massively underestimated its significance. PoS protocol designers frequently make this mistake, and consider only (1) and (3) in their designs.
This is evident with DFINITY’s obsession with randomness. DFINITY researchers think randomness is the key to solving everything.
Ethereum Casper, on the other hand, is obsessed with incentives, going as far as coining a meaningless term: “cryptoeconomics”. Ethereum researchers think clever designs of incentives is the key to solving everything.
The old saying “to a hammer, everything is a nail” is fitting in the PoS protocol design space.
The reality is, unforgeable costliness might arguably be THE most important component powering Bitcoin. Without unforgeable costliness, there’s nothing new & disruptive about Bitcoin.
In summary, private keys attacks present a serious problem for PoS protocols. Losing majority control in PoW (hash rate) is bad, but does not mean the system will fail completely. Whereas losing majority control in PoS (stake) strips the system totally naked & defenseless.
[1]: The ratio 1/3 comes from the well-researched area of traditional BFT systems (which PoS protocols are a subset of). Traditional BFT systems fail to work when 1/3 or more nodes are faulty. The term BFT is derived from the Byzantine Generals’ Problem, which was defined by Lamport, Pease, and Shostak in 1982.
[2]: Read Nick Szabo’s essay on the Origins of Money to understand the importance of unforgeable costliness.
[3]: Thanks @datavetaren for pointing out this issue.
