5 ms·

There are a bunch of ways in which you're not exactly correct here. First, you're describing a very particular implementation of PoS. Not all PoS implementatio

There are a bunch of ways in which you're not exactly correct here. First, you're describing a very particular implementation of PoS. Not all PoS implementations include slashing. This isn't a mere technicality: the most popular implementation of PoS (as measured by market cap) is Cardano's and it doesn't include slashing. And not all PoS implementations involve randomly choosing a validator. The bigger problem here is that proof of stake is actually a misnomer because doesn't actually provide proof, period--it's a consensus algorithm, not a proof algorithm. That's fine if you're actively connected to a bunch of nodes, because you can resolve double spends by polling the network to find out the consensus. But if you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain. In PoS, there's no way to actually enforce the longer chain, because there's no cost to producing a longer chain. This is a problem which occurs in practice when nodes newly connect to a network or reconnect after a long absence. Slashing does nothing to address this issue. If I'm running a PoS validator node, I can stake coins, unstake them, and then spend the coins. Now I've got a free license to mine blocks without risk of slashing. I can mine blocks by simply validating blocks that say that I never unstaked. And I'm at no risk of slashing because I've already spent the coins: there's no balance to slash. You alluded to an attempted solution with "it is solved by randomly choosing which validator will create the next block according to an algorithm that all the nodes follow" but that doesn't work: a provable random function can choose a validator which creates artificial scarcity, but there has to be a fallback in case validators drop offline, otherwise a downed node would grind the entire chain to a halt as soon as it was chosen as a validator and doesn't validate a block when it's supposed to. The malicious validator can use this because there's no temporality stored on-chain: you just find a situation where your staking address is the fallback node and claim that the validators who were chosen by the random function validated late, and nobody can prove you wrong. This may sound suspicious, but in fact these fallbacks happen in practice. To create a believable chain after this, you have to create a situation where a lot of validators drop off and are replaced by nodes you control. This also looks suspicious, but again this also happens in practice: for example if AWS S3 US East VA goes down, there will be a huge number of validators that drop offline. Probably the most thorough explanation of this type of attack and the theory behind it can be found in On Stake and Consensus[1]. There's some debate on the importance of this attack--Vitalik Buterin calls this "weak subjectivity" and has written about it in length[2]. But to say he's not concerned about it would be inaccurate; he says, "actually implementing a proof of stake algorithm that is effective is proving to be surprisingly complex"[3]. That sentence was written in 2014 and Ethereum still does not rely on proof of stake in 2021--be assured that if in seven years Vitalik Buterin has not satisfactorily solved the problem, it's not trivial. I would caution anyone extolling the virtues of Proof of Stake from overstating their case--PoS is not a panacea and presents many challenges of its own. [1] https://download.wpsoftware.net/bitcoin/pos.pdf https://download.wpsoftware.net/bitcoin/pos.pdf [2] https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov... [3] https://blog.ethereum.org/2014/10/03/slasher-ghost-developments-proof-stake/ https://blog.ethereum.org/2014/10/03/slasher-ghost-developme...

skybrian 5y ago
How do you know you have the longest chain without having all the blocks? You need to reach consensus on which blocks exist, and you can't get that without talking to enough other nodes to be pretty sure you have enough blocks that a longer chain is unlikely. When there is a network split, nodes on one side of the split might think they have the longest chain and be wrong about it. Unless you know you have most of the computing power on your side of the network split, you can't really know which side has the longest chain until the network split is over. So no, Bitcoin doesn't avoid the need to achieve consensus.
- kerkeslager 5y ago
  Glad we've come to the conclusion that things I didn't say aren't true! What I actually said is, "[I]f you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain." You're correct that this isn't a proof of consensus.
  - skybrian 5y ago
    Fair enough. But looking at the longest chain you have (from the two nodes you can connect to) and assuming it's valid is not sufficient. You also need some reason to believe there isn't a longer chain out there. (In practice this is by waiting for a certain number of "confirmations.") Maybe that's assumed in "simply look at the longer chain" but I thought I'd point it out.
billytetrud 5y ago
> you're describing a very particular implementation of PoS. It's silly to say PoS doesn't work when what you really mean is that some badly designed PoS systems don't work. Slashing is a solution to a problem. It's honestly irrelevant if some PoS systems don't do slashing.
- kerkeslager 5y ago
  It's silly to respond to one particular claim in isolation, when I wrote a long post that addressed the limitations of slashing. Please don't respond to what I say out of context.

skybrian 5y ago

How do you know you have the longest chain without having all the blocks? You need to reach consensus on which blocks exist, and you can't get that without talking to enough other nodes to be pretty sure you have enough blocks that a longer chain is unlikely. When there is a network split, nodes on one side of the split might think they have the longest chain and be wrong about it. Unless you know you have most of the computing power on your side of the network split, you can't really know which side has the longest chain until the network split is over. So no, Bitcoin doesn't avoid the need to achieve consensus.

kerkeslager 5y ago
Glad we've come to the conclusion that things I didn't say aren't true! What I actually said is, "[I]f you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain." You're correct that this isn't a proof of consensus.
- skybrian 5y ago
  Fair enough. But looking at the longest chain you have (from the two nodes you can connect to) and assuming it's valid is not sufficient. You also need some reason to believe there isn't a longer chain out there. (In practice this is by waiting for a certain number of "confirmations.") Maybe that's assumed in "simply look at the longer chain" but I thought I'd point it out.

billytetrud 5y ago

> you're describing a very particular implementation of PoS. It's silly to say PoS doesn't work when what you really mean is that some badly designed PoS systems don't work. Slashing is a solution to a problem. It's honestly irrelevant if some PoS systems don't do slashing.

kerkeslager 5y ago
It's silly to respond to one particular claim in isolation, when I wrote a long post that addressed the limitations of slashing. Please don't respond to what I say out of context.