Crypto NYC recently hosted a debate on Proof of Work vs. Proof of Stake. We got to hear about consensus mechanisms from Ethereum and Bitcoin developers Matt Corallo and Nate Rush. Matt is developer who has worked on Bitcoin Core since 2011. Nate is a researcher who contributes to the Correct-by-construction Casper codebase.
We covered a lot of ground in two hours. In this post, I’ll try to summarize the tradeoffs between PoS and PoW that they discussed that night. I should note that they didn’t discuss generic PoW vs PoS. Rather, they discussed specific consensus mechanisms: Bitcoin’s Consensus — also called Nakamoto Consensus – and Ethereum’s CBC Casper Proof of Stake proposal.
To start, let’s define the big three properties that we want a blockchain protocol to achieve:
Safety — We want our nodes to agree on one valid set of transactions.
Liveness — We want our nodes to make progress validating transactions without getting stuck.
Censorship resistance — We don’t want anyone to be able to censor transactions. Blockchains’ only advantages over databases are that they’re open and permissionless.
Blockchains can’t perfectly achieve all these things, because a majority of voters can lie, cheat and collude. That means we need to ask even more of our protocols:
No trusted 3rd party — We don’t want to rely on any single entity for safety, liveness or censorship resistance.
Decentralization — We don’t want our system to tend toward one entity who controls a majority of the stake/hashpower, because then they could compromise safety, liveness and censorship resistance.
Incentives — We can’t secure these open systems against an all-powerful attacker, but we can make attacks expensive and make following the protocol economically beneficial.
Resource use — We’d like to minimize the cost of real-world resources needed for security, like electricity and servers, if possible.
Disaster recovery — We want to be able to recover smoothly from a failure of safety, liveness or censorship resistance.
Simplicity — All else equal, a simpler protocol is easier to implement, reason about, and audit for flaws.
The debaters talked through the ways PoW and PoS approach these properties. I’ll try to summarize the points that they made.
Both protocols provide safety with voters approving valid transactions.
One difference is whether they have finality. Finality is when an observer can be sure that a transaction is confirmed by the network.
Proof of work blockchains only have probabilistic finality. A user can’t be sure that there’s not some heavier, true chain that they haven’t seen yet. The user can get probabilistic finality, by waiting for several blocks after their transaction. Each block makes it harder to replace their transaction with some other heavier chain. They can calculate how much it would cost to revert their transactions to figure out if any attacker might be worth it to someone.
Proof of stake does provide finality. Once the validators vote on a block, that block is final. This faster finality helps to build scalability layers like state channels or sharding.
Finality comes at a cost of some liveness for proof of stake. If there’s a network partition, every partition might lack the majority of votes needed to come to consensus. The network wouldn’t approve any transactions at all, losing liveness.
On the other hand, a proof of work chain will still be available during a network partition for some transactions. The transactions that can reach the miners on the heavier partition will make it into the blocks that will become the real chain after the partition is resolved.
Both protocols aim to be open enough for anyone to be able to use send transactions on the network.
One specific attack they discussed was an “eclipse attack”, where a node is cut off from the network by an attacker. The attacker can control all the information that flows to and from the node. In PoW, a miner would lose income while they were cut off. In proof of stake, an eclipsed staker would get their stake slashed for being offline. In both cases, though, the eclipsed node could figure out that something is wrong, because the apparent hashrate or apparent number of validators would be lower during the attack.
Both debaters compared their protocols to delegated proof of stake, which they noted as weak to censorship. A small number of publicly-known validators with nothing to at stake can easily censor transactions. Delegated validators are especially good targets for regulators.
Our debaters disagreed about which protocol would lead to more or less centralization in the long run.
Our proof of work debater, Matt, conceded that mining is quite centralized now, but claimed that mining will get better soon. There are more ASIC vendors coming to market, he expects to break up the current monopoly. Also, cheap power is becoming more fairly distributed as more cheap sources of power come online throughout the world and utilities kick miners off of artificially cheap sources of power.
Our debaters went back and forth on whether there are economies of scale to mining. Matt claimed that since the costs of electricity and cooling increase at the margin, smaller mining operations have cost advantages over larger ones. The PoS advocates pointed out that the existing mining operations have lower costs at scale.
The proof of stake advocate, Nate, claims that there are no economies of scale for PoS. One dollar is one dollar. Because the voting happens with virtual assets, there are few places to get operational advantages. The Matt responded by pointing out that capital tends to concentrate. Nate replied that they could, in the future, build progressive mechanisms into the protocol to flatten out the centralization of capital.
PoW and PoS have different approaches to incentives. Broadly, the proof of work incentives are simpler and the proof of stake ones are more complex.
In proof of work, there’s a separation of concerns. Miners have costs that are not denominated in cryptocurrency. Plus, the end users — holders — are not the same as miners. In proof of stake, the holders and validators are the same, so one has to consider the increased incentive attack surface. One shouldn’t assume that the large holders necessarily want to protect the safety and security of the network.
On the other hand, Proof of Stake’s mechanism gives a lot more room for incentive design. In Casper’s CBC proof of stake, validators have something to lose. If they attack the network, they stand to lose their stake, unlike in proof of work. In PoW, a 51% attack is free if it succeeds. In this sense, PoS’s additional incentives reduce the attack surface rather than increase it.
One problem, though, is that Proof of Stake’s incentives all live inside the system. Attacks can come from outside the system, too. For example, an attacker could steal or borrow a lot of Ether, short ETH/USD, stake the stolen Ether to attack safety or liveness, and make USD on their short. They can’t steal or borrow electricity in the same way.
Proof of work is famously energy intensive. Is PoS a way to secure the network without using so many real-world resources?
If proof of stake can offer all the secure guarantees covered here, it’s clearly better on the energy use front. PoS’s security would also be cheaper for users, because the cost of security can be paid out of the attacker’s stake instead of inflation and transaction fees.
Matt pushed back on the resource use, noting that it’s not as bad as it seems for CO2 emissions. Miners use cheap power, and most of the cheapest power today comes from non-fossil fuel sources: hydro, solar, geothermal and off-peak load.
If something goes wrong, like a contentious hard fork, how do the protocols recover?
Nate conceded that PoS needs a human-in-the-loop for security. When a user syncs their node, they need to start with a recent blockhash. “Recent” means no older than the length of the security deposit lockup, which will be four months in Casper. He says that this security assumption is ok, though, because even in PoW, the user needs to trust someone to download a safe client. They can get a recent hash from the same place they get their safe client.
A 51% attack on proof-of-work might require more human actions to escape the 51% attacker. The users might want to change their hash algorithm to brick the ASICs of the attacker, which would require developer and miner intervention. Further, that response only works once. After changing from the existing, ASIC-friendly hashing scheme to other scheme, there’s no more hashpower changes to escape from someone with a majority of the computing power.
The PoW response was that we should consider the second-order effects of easy forking. Would a system with easier forking make many chains and confuse users? Nate didn’t think that was likely, because there’s a strong network effect to join whichever chain is the “main” one.
One huge advantage for proof of work is that it’s simple. That makes it easier to reason about and develop.
Nate noted that consensus protocols have been getting simpler over time. PAXOS (1998) is more complicated than Tendermint (2014). Casper (now) is simpler still.
But even Casper has complex implementation details. Bugs are particularly dangerous for stakers because they can lose a lot of money from slashing. One way to mitigate that risk by letting small validators off the hook with partial slashing if they don’t cause a safety failure.
Of course, more complexity means more knobs to turn: having both rewards and punishments give more room for incentive design. That space should help in designing for censorship-resistance, lower resource use, and decentralization.
The last point is an important one. There’s still an unexplored universe of tradeoffs to make around consensus mechanisms. The most convincing way to answer these questions is to build the system. Run the experiment!