flipchan
commented
6 days ago Also, as someone who ran an Avalanche validator for two years, I can say that I slept much better at night than I would have validating a platform that uses slashing
Slashing makes sure bad actors/validators are punished, as a consumer you want to pick trusted validator providers. Slashing is necessary for having a Byzantine fault tolerance PoS network. Encouraging good actors and getting rid of the malicious once.
Finally, I'm curious, if this first deployment cannot support "a large number of validators," how many can it support?
Depends on how the active validator set is implemented in this new system. Since the PoS consensus code is not live I guess we have to wait to see the hardcoded limit of the amount of active interest earning validators is not written in stone yet. (I would assume)
Looks great overall, and I appreciate the need to limit scoping and set expectations which this document does very well.
I have heard before the statement that PoS "enables bridges" and as far as I understand, the argument is that with a PoW chain, you never achieve finality, and because of the unending possibility of reorgs, bridging is not possible. Though I've heard this from a number of people I respect, personally I do not buy it. In PoW, with each mined block, it becomes exponentially more unlikely that a reorg will happen, and though it's true, that chance never reaches zero, it approaches zero rapidly and to a point that in real-world financial systems, eventually bridging benefit vastly outweighs any tiny reorg risk that remains. There's plenty of real-world evidence for this being true, including the Bitcoin-Avalanche bridge. (True, Zcash has much less hashing power than Bitcoin, but this just means you need to wait longer before reaching the risk vs. benefit finality that you desire.) For this reason, I'd say that it "increases bridging speed and efficiency" instead, which is most definitely true!
I saw a few mentions of slashing in the google doc, and it's a feature of many PoS platforms. I'll just point out here that Avalanche does not implement slashing (you simply lose your reward, but staked funds are not at risk), and this has been working well for four years. Also, as someone who ran an Avalanche validator for two years, I can say that I slept much better at night than I would have validating a platform that uses slashing. These good night's of sleep need to be balanced with the damage that a rouge validator could do, and what deterrents they would need to choose not to go rogue. Is slashing even enough?
Finally, I'm curious, if this first deployment cannot support "a large number of validators," how many can it support?
Overall looks great, and I'm really excited to see this moving forward. It will help the red·bridge project out a lot, creating a much better UX experience for its users.