3 ms·

A trust assumption of PoS (Proof of Stake) is that >66% of the stake is honest. If you violate this trust assumption then yes PoS breaks. This is a similar trus

A trust assumption of PoS (Proof of Stake) is that >66% of the stake is honest. If you violate this trust assumption then yes PoS breaks. This is a similar trust assumption to requiring that 51% of the mining power in PoW (Proof of Work) is not malicious. This risk can be mitigated: 1. The network should halt if a fork is detected. A fork with more than 66% of the stake behaving maliciously means a fundamental trust assumption of the network has been violated. Stop everything! Let humans figure out what is going on. I'm not saying every PoS system WILL halt under these circumstances, but as a countermeasure they SHOULD be designed to halt and value safety over partition resilience. Thus, an attacker forking a PoS must never allow parties to see either side of the fork. If a party notices a fork occurs, they will halt and can't be double spent against. 2. Following from 1, how do you prevent parties from communicating and discovering that a fork is occurring? Are you a tier-1 ISP and can control all internet traffic? You can defend against such attacks by making it very hard to hide the presence of a fork via redundant communication mechanisms. For instance the Bitcoin blockchain is broadcasted via satellite, a PoS blockchain could do that as well. 3. Additionally you can require that stakers lock their stake for long periods of time e.g., 6 months. This means that if an attacker wants to perform this attack and truly have nothing at stake they must cause a fork in the chain before the 6-months ago mark. Parties who are up to date with the latest chain are not vulnerable since they have already accepted the consensus history of chain. New parties who are syncing for the first time would be vulnerable, however clients could be programmed to have hardcoded 6th month checkpoints or clients could check block explorers and halt if a fork is detected.

yanmaani 5y ago
> This is a similar trust assumption to requiring that 51% of the mining power in PoW (Proof of Work) is not malicious. Yeah, but you're glossing over an important detail: It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked. In PoW, I only need to trust the miners of today to tell me the truth about what happened today. In PoS, I need that, plus the miners of yesterday, plus the miners of a year ago, plus ..., in perpetuity. > New parties who are syncing for the first time would be vulnerable, however clients could be programmed to have hardcoded 6th month checkpoints or clients could check block explorers and halt if a fork is detected. Right, maybe you can elaborate on this. Is checking block explorers a decentralized or trustless solution to, well, anything?
- mattalex 5y ago
  > It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked. In PoW, I only need to trust the miners of today to tell me the truth about what happened today. I don't quite get that. As far as I understand it the "nothing at stake" problem works by a malicious party inducing a fork, one of which they double-spend in. Since it's in the best interest for everyone else to mine both forks, you can force your double-spend fork to become the longest chain by only validating the double-spend fork. This means you have to trust that nobody part of your current chain has double-spent in this way. But isn't this the same as in PoW where you have to trust that nobody has launched a 51% attack to disrupt the network in the past? Also, can't you just prevent people from mining all forks? I.e. for becoming a validator you have to deposit X as a security beforehand and you can only earn at most X via staking (so it is in the history before you can attack with nothing at stake). If it is recognised that you mine on more than one fork at a time, you lose the security deposit you gave before the fork. X goes to the person who found the fork, incentivising that the mallicious fork is identified on all forks (miners on competing forks are incentivised to look at all forks and quickly add the mallicious fork detection for their own benefit). If you want to retrieve your security and money earned, you have to announce this on all forks (you immediatly seize to be a validator). You are only allowed to retrieve the funds, if it is confirmed on all forks, or the forks are sufficiently behind the longest chain. This allows everybody ample time to look for dual-fork work and also incentivizes rapid solution of forks.
  - comex 5y ago
    > If it is recognised that you mine on more than one fork at a time, you lose the security deposit you gave before the fork. Yes, modern proof-of-stake algorithms work this way. The caveat is that at some point (on the order of months later) the security deposit is refunded, and at that point you can lie about the past without consequence. But this is a limited attack: you can only successfully lie to someone who has been offline since you were a staker, or else they would already have a record of the real successor chain (which now has a new set of stakers, who themselves still have their security deposit deposited).
    - 5y ago
xorcist 5y ago
> Stop everything! Let humans figure out what is going on. What does this mean in practice? Who are these humans? When can the network get going again? Would a consensus rule change be part of it, and what type of changes would be allowed in that situation? It sounds hard to manage this type of maintenance breaks in a trustless way. Surely consensus rule changes during outages should not be handled any differently than changes when under normal operations. > clients could be programmed to have hardcoded 6th month checkpoints Who signs these checkpoints? Once you have established the trust required for checkpointing the entire blockchain regularly, wouldn't it be much easier to checkpoint every block instead and in an instant do away with all the hard problems of blockchain networks?
- EthanHeilman 5y ago
  > What does this mean in practice? Who are these humans? When can the network get going again? Would a consensus rule change be part of it, and what type of changes would be allowed in that situation? We have a bunch of examples of this happening in practice. The humans are usually a mix of the developers, parties important to consensus (miners, stakers) and big ecosystem players. > It sounds hard to manage this type of maintenance breaks in a trustless way. When solving a problem that violates your core security assumption you are only longer in the world of security definitions. It doesn't really make sense to talk about "trustlessness". If the protocol is busted, you need to find a solution and get enough people on board with that solution that you can upgrade the protocol. > Once you have established the trust required for checkpointing the entire blockchain regularly, wouldn't it be much easier to checkpoint every block instead and in an instant do away with all the hard problems of blockchain networks? The checkpoints aren't trusted for safety but instead for availability. Instead you should think of them like alarms that "something has gone horribly horribly wrong, stop everything, don't transact, don't move, don't touch anything, pull the ebrake." tl;dr Much like the fuse box in your house, my view is that checkpoints should turn safety failures (electrical fires) into availability failures (electricity is shut off).

yanmaani 5y ago

> This is a similar trust assumption to requiring that 51% of the mining power in PoW (Proof of Work) is not malicious. Yeah, but you're glossing over an important detail: It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked. In PoW, I only need to trust the miners of today to tell me the truth about what happened today. In PoS, I need that, plus the miners of yesterday, plus the miners of a year ago, plus ..., in perpetuity. > New parties who are syncing for the first time would be vulnerable, however clients could be programmed to have hardcoded 6th month checkpoints or clients could check block explorers and halt if a fork is detected. Right, maybe you can elaborate on this. Is checking block explorers a decentralized or trustless solution to, well, anything?

mattalex 5y ago
> It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked. In PoW, I only need to trust the miners of today to tell me the truth about what happened today. I don't quite get that. As far as I understand it the "nothing at stake" problem works by a malicious party inducing a fork, one of which they double-spend in. Since it's in the best interest for everyone else to mine both forks, you can force your double-spend fork to become the longest chain by only validating the double-spend fork. This means you have to trust that nobody part of your current chain has double-spent in this way. But isn't this the same as in PoW where you have to trust that nobody has launched a 51% attack to disrupt the network in the past? Also, can't you just prevent people from mining all forks? I.e. for becoming a validator you have to deposit X as a security beforehand and you can only earn at most X via staking (so it is in the history before you can attack with nothing at stake). If it is recognised that you mine on more than one fork at a time, you lose the security deposit you gave before the fork. X goes to the person who found the fork, incentivising that the mallicious fork is identified on all forks (miners on competing forks are incentivised to look at all forks and quickly add the mallicious fork detection for their own benefit). If you want to retrieve your security and money earned, you have to announce this on all forks (you immediatly seize to be a validator). You are only allowed to retrieve the funds, if it is confirmed on all forks, or the forks are sufficiently behind the longest chain. This allows everybody ample time to look for dual-fork work and also incentivizes rapid solution of forks.
- comex 5y ago
  > If it is recognised that you mine on more than one fork at a time, you lose the security deposit you gave before the fork. Yes, modern proof-of-stake algorithms work this way. The caveat is that at some point (on the order of months later) the security deposit is refunded, and at that point you can lie about the past without consequence. But this is a limited attack: you can only successfully lie to someone who has been offline since you were a staker, or else they would already have a record of the real successor chain (which now has a new set of stakers, who themselves still have their security deposit deposited).
  - 5y ago

xorcist 5y ago

> Stop everything! Let humans figure out what is going on. What does this mean in practice? Who are these humans? When can the network get going again? Would a consensus rule change be part of it, and what type of changes would be allowed in that situation? It sounds hard to manage this type of maintenance breaks in a trustless way. Surely consensus rule changes during outages should not be handled any differently than changes when under normal operations. > clients could be programmed to have hardcoded 6th month checkpoints Who signs these checkpoints? Once you have established the trust required for checkpointing the entire blockchain regularly, wouldn't it be much easier to checkpoint every block instead and in an instant do away with all the hard problems of blockchain networks?

EthanHeilman 5y ago
> What does this mean in practice? Who are these humans? When can the network get going again? Would a consensus rule change be part of it, and what type of changes would be allowed in that situation? We have a bunch of examples of this happening in practice. The humans are usually a mix of the developers, parties important to consensus (miners, stakers) and big ecosystem players. > It sounds hard to manage this type of maintenance breaks in a trustless way. When solving a problem that violates your core security assumption you are only longer in the world of security definitions. It doesn't really make sense to talk about "trustlessness". If the protocol is busted, you need to find a solution and get enough people on board with that solution that you can upgrade the protocol. > Once you have established the trust required for checkpointing the entire blockchain regularly, wouldn't it be much easier to checkpoint every block instead and in an instant do away with all the hard problems of blockchain networks? The checkpoints aren't trusted for safety but instead for availability. Instead you should think of them like alarms that "something has gone horribly horribly wrong, stop everything, don't transact, don't move, don't touch anything, pull the ebrake." tl;dr Much like the fuse box in your house, my view is that checkpoints should turn safety failures (electrical fires) into availability failures (electricity is shut off).