4 ms·
The article does not even mention long range attacks in which large portions of the block chain are rewritten. This is made extremely hard in Bitcoin through p
by Barrera 4y ago
The article does not even mention long range attacks in which large portions of the block chain are rewritten.
This is made extremely hard in Bitcoin through proof-of-work. To rewrite history you must re-do all of the work, which means you burn enough real-world energy to work faster than the entire rest of the network (aka majority hash rate attack). It's allowed, but expensive.
In PoS, there was never any work, so you can just rewrite history.
Every time the subject of Ethereum's move to PoS comes up, it seems this issue is there. The solutions mutate into a head-spinning kaleidoscope of different guises, all rabbit holes in their own maddening way and suspicious on that basis alone.
That this lengthy piece doesn't even mention long range attacks speaks volumes.
- 0xfoobar 4y agoArticle author here. Supermajority attestations and block finalization, as well as withdrawal queues, prevent long-range attacks. To attempt to reorg a finalized block (blocks are generally finalized after 6 minutes) you have to commit to losing 1/3 of total staked ether, currently several billion dollars. The only participants who can equivocate (vote for two blocks at the same height) are active validators so there is significant economic value at risk to pursue such an attack.
- naveen99 4y agoWasn’t there a recent attack on solana/ solend, where the attacker was willing to lose more than 30% for the chance to cash out and crash solend at the same time ?
- 0xfoobar 4y agoThe Solend drama was at the app-layer rather than the protocol-layer. Solana also runs PoS but its variant is a bit more handwavy and weaker imo, slashing rules are applied in a post-hoc human decision-making process rather than clear rules enshrined within the protocol.
- camjohnson26 4y agoTheoretically, if somebody forked the Ethereum PoS blockchain and faked timestamps to catch up to the real chain’s height, would there be any way to know which was the original other than community agreement? Seems like PoW makes it impossible since duplicating the original chain is prohibitively expensive. Not challenging the solution, just genuinely curious in how PoS works.
- 0xfoobar 4y agoGreat question, it's not timestamps but attestations (signed validator votes for pairs of checkpoint blocks) that determines the canonical chain head. This fork choice rule, known as LMD-GHOST, is different from PoW which has a "greatest difficulty" rule for determining the canonical chain. There is some element of bootstrapping who the original validator set was, known as "weak subjectivity". There's a great post from Vitalik exploring this further at https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...
- camjohnson26 4y agoAwesome, thanks!
- codechicago277 4y agoThat you’re getting downvoted speaks to the poor quality of discussion on this thread. To me this is the core issue with PoS. I don’t know enough about it to say if the Ethereum devs have solved it or not, but this is a much more interesting topic than misguided comparisons of PoS to crony capitalism, which is just uninformed.
- dlubarov 4y agoThere's no solution that will give PoS the same objectivity PoW enjoys, but PoS (with slashing and exit delays) is secure against long forks under a weakly subjective model. Vitalik has a pretty good post about it: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov... Essentially, the solution is to ignore forks whose lengths exceed the exit delay, since such forks can be created without a slashing risk. The main issue is that new nodes need to start with a (somewhat recent) trusted checkpoint. This does open up some attack surface that doesn't exist in PoW, though in my view it's not much of an issue. If I want to be extra careful, I can always ask several sources for a checkpoint and make sure they match.