5 ms·

Honest question - if you get deterministic finality in a day (#8), then how can you attack the chain with a "long-range" fork (#5). Doesn't #8 solve #5?

ChadNauseam 4y ago
The answer as I understand it, is that anyone who's continuously running a node won't be confused by such a fork, but someone who just joined the network has no way of telling which fork is the true one. Put another way, if you know the true chain at time T, you also know it at time T+1. But if you're just joining the network, or you went offline for a bit, that means you don't know which chain is the true one and need some outside-of-protocol way of determining which fork to trust.
- clemensley 4y ago
  What can users do to get certainty over which one is the correct fork? In POW you can check the POW. Is there a trustless solution for this in POS? Or is the only solution essentially to ask around and hope that people aren't lying to you?
  - DennisP 4y ago
    In practice, it's the same as with Bitcoin: you have to get the correct, current software. It's just that the software will include a block hash from a few months back. You might argue that Bitcoin is defined as the chain with the most hashpower, period. That would remove all subjectivity from Bitcoin, but it would mean that a 51% attacker could arbitrarily change the rules and steal people's funds. That's not how it actually works; a 51% attacker still has to follow the rules of the protocol for their blocks to be accepted by the non-mining nodes, and that means there's social consensus on the correct software to run the protocol.
    - Geee 4y ago
      That's not how it works. Hashpower decides the canonical chain, not the rules of the system. Hashpower makes sure that the blockchain can't be rewritten. Hashpower can't change the rules of the system, because those blocks would be invalid and rejected by the network. There's no consensus needed on which rules to use. Everyone can use whichever rules they want, by using different versions of the software. Different rules define a different currency, like euro or dollar. Using the best currency with the best rules is just a game theoretic focal point. Everyone chooses to use the best version of the software, because they assume that everyone else does so too, even in the absence of communication. There is no "correct, current" software in Bitcoin, because it would be a single point of failure. There's no objective protection against long-range attacks in PoS, because there's no hashpower to prove the canonical chain. It requires the provider of the "correct, current" software to decide which chain is the right one.
      - ETH_start 4y ago
        >>Hashpower decides the canonical chain, not the rules of the system. No, hash power and the rules decide it. If you have invalid signatures in your blocks, it doesn't matter how much hashpower your fork has, it won't be accepted as canonical by other forks.
        ETH_start 4y ago
        *by other nodes
    - polyomino 4y ago
      51% attacks can not arbitrarily change the rules nor can they steal funds. They can double spend or prevent finality. Nodes enforce the rules of the network by rejecting blocks they deem invalid.
  - baby 4y ago
    It’s the same as with Bitcoin: - wait a bit to make sure that you can talk to different people on the network and see what each of them see - check checkpoints on twitter or websites like etherscan (are they seeing the same thing I’m seeing?) In projects like Mina, since you do not download the history of the chain (there’s a single zero knowledge proof of a few kB that covers the whole history) you must rely on a marker for “chain quality “ to differentiate potential forks. Note that there was also some research on how to get signal from the transactions you see that you’re on the correct fork (from some ex colleagues working on libra): https://eprint.iacr.org/2019/1440.pdf https://eprint.iacr.org/2019/1440.pdf
    - hanselot 4y ago
narush 4y ago
If you're running a node, and it finalizes a block, that means your node will refuse to ever revert that block. A long-range attack is when a validator withdrawals their stake, waits the withdrawal period (e.g. the 6 month delay delay mentions above), and then creates a fake chain starting from before they withdrew their staked eth. Because in the "real" history (e.g. the ones that most nodes have seen over the past 6 months) the validator doesn't have Eth locked up still, there's no way to punish them. Thus, these long range attacks get very cheap (you could even imagine someone who pays validators for old keys -- aka, you don't even need to be a validator yourself). These two facts together mean that PoS blockchains require some "weak subjectivity" - which pretty much means when you download and start syncing your node, you need to know a "finalized" block hash from the past 6 months (or within the withdrawal delay). This ensures you won't get tricked by a cheap long-range attack. In practice, I don't think this will be much of a problem - clients can just do a new release with a new block has every few months for new users!
- 3np 4y ago
  There must be some part of the attack I am missing here. Let's say I'm an attacker and I do this. But now none of the subsequent blocks on the original chain will validate anymore because of hashes mismatching. I could of course validate new blocks but 6months+ of blocks from only one or a small number of validators (depending on how much validator capital one can amass for the attack) is going to be pretty obvious. Unless the attacker can get a significant percentage of validators part of the attack, I can' see it work out in practice.
  - baby 4y ago
    What do you mean by obvious? Your crypto client is a computer and unless you go and check what it is connected to this will be opaque to you (and so not obvious).
Geee 4y ago
Long-range fork is possible if network participants are manipulated or forced to switch to another fork. In practice, the correct fork is communicated from entities who control the majority stake, such as exchanges. In the case of network disruptions, there might be multiple valid forks, and choosing the correct one is arbitrary, because there isn't one. There's no objective consensus similar to proof-of-work.
- baby 4y ago
  It sounds like there is if you wait for the deterministic finality
baby 4y ago
By the way I was under the impression that Ethereum will still have forks, and thus probabilistic finality
- DennisP 4y ago
  Ethereum's PoS is really two consensus algorithms. The first converges rapidly but has probabilistic finality. The second has true finality, in the sense that a finalized block can't be reverted without destroying a large percentage of total stake, but it takes a while before that finality kicks in.
wyager 4y ago
Because they don't actually have "deterministic finality" in any meaningful sense. It's not possible. PoS is, as usual, vulnerable to attacks like grinding, and you can only paper over this.
- djbusby 4y ago
  Can you link more details on this? (am n00b, genuine curiosity)

ChadNauseam 4y ago

The answer as I understand it, is that anyone who's continuously running a node won't be confused by such a fork, but someone who just joined the network has no way of telling which fork is the true one. Put another way, if you know the true chain at time T, you also know it at time T+1. But if you're just joining the network, or you went offline for a bit, that means you don't know which chain is the true one and need some outside-of-protocol way of determining which fork to trust.

clemensley 4y ago
What can users do to get certainty over which one is the correct fork? In POW you can check the POW. Is there a trustless solution for this in POS? Or is the only solution essentially to ask around and hope that people aren't lying to you?
- DennisP 4y ago
  In practice, it's the same as with Bitcoin: you have to get the correct, current software. It's just that the software will include a block hash from a few months back. You might argue that Bitcoin is defined as the chain with the most hashpower, period. That would remove all subjectivity from Bitcoin, but it would mean that a 51% attacker could arbitrarily change the rules and steal people's funds. That's not how it actually works; a 51% attacker still has to follow the rules of the protocol for their blocks to be accepted by the non-mining nodes, and that means there's social consensus on the correct software to run the protocol.
  - Geee 4y ago
    That's not how it works. Hashpower decides the canonical chain, not the rules of the system. Hashpower makes sure that the blockchain can't be rewritten. Hashpower can't change the rules of the system, because those blocks would be invalid and rejected by the network. There's no consensus needed on which rules to use. Everyone can use whichever rules they want, by using different versions of the software. Different rules define a different currency, like euro or dollar. Using the best currency with the best rules is just a game theoretic focal point. Everyone chooses to use the best version of the software, because they assume that everyone else does so too, even in the absence of communication. There is no "correct, current" software in Bitcoin, because it would be a single point of failure. There's no objective protection against long-range attacks in PoS, because there's no hashpower to prove the canonical chain. It requires the provider of the "correct, current" software to decide which chain is the right one.
    - ETH_start 4y ago
      >>Hashpower decides the canonical chain, not the rules of the system. No, hash power and the rules decide it. If you have invalid signatures in your blocks, it doesn't matter how much hashpower your fork has, it won't be accepted as canonical by other forks.
      - ETH_start 4y ago
        *by other nodes
  - polyomino 4y ago
    51% attacks can not arbitrarily change the rules nor can they steal funds. They can double spend or prevent finality. Nodes enforce the rules of the network by rejecting blocks they deem invalid.
- baby 4y ago
  It’s the same as with Bitcoin: - wait a bit to make sure that you can talk to different people on the network and see what each of them see - check checkpoints on twitter or websites like etherscan (are they seeing the same thing I’m seeing?) In projects like Mina, since you do not download the history of the chain (there’s a single zero knowledge proof of a few kB that covers the whole history) you must rely on a marker for “chain quality “ to differentiate potential forks. Note that there was also some research on how to get signal from the transactions you see that you’re on the correct fork (from some ex colleagues working on libra): https://eprint.iacr.org/2019/1440.pdf https://eprint.iacr.org/2019/1440.pdf
  - hanselot 4y ago

narush 4y ago

If you're running a node, and it finalizes a block, that means your node will refuse to ever revert that block. A long-range attack is when a validator withdrawals their stake, waits the withdrawal period (e.g. the 6 month delay delay mentions above), and then creates a fake chain starting from before they withdrew their staked eth. Because in the "real" history (e.g. the ones that most nodes have seen over the past 6 months) the validator doesn't have Eth locked up still, there's no way to punish them. Thus, these long range attacks get very cheap (you could even imagine someone who pays validators for old keys -- aka, you don't even need to be a validator yourself). These two facts together mean that PoS blockchains require some "weak subjectivity" - which pretty much means when you download and start syncing your node, you need to know a "finalized" block hash from the past 6 months (or within the withdrawal delay). This ensures you won't get tricked by a cheap long-range attack. In practice, I don't think this will be much of a problem - clients can just do a new release with a new block has every few months for new users!

3np 4y ago
There must be some part of the attack I am missing here. Let's say I'm an attacker and I do this. But now none of the subsequent blocks on the original chain will validate anymore because of hashes mismatching. I could of course validate new blocks but 6months+ of blocks from only one or a small number of validators (depending on how much validator capital one can amass for the attack) is going to be pretty obvious. Unless the attacker can get a significant percentage of validators part of the attack, I can' see it work out in practice.
- baby 4y ago
  What do you mean by obvious? Your crypto client is a computer and unless you go and check what it is connected to this will be opaque to you (and so not obvious).

Geee 4y ago

Long-range fork is possible if network participants are manipulated or forced to switch to another fork. In practice, the correct fork is communicated from entities who control the majority stake, such as exchanges. In the case of network disruptions, there might be multiple valid forks, and choosing the correct one is arbitrary, because there isn't one. There's no objective consensus similar to proof-of-work.

baby 4y ago
It sounds like there is if you wait for the deterministic finality

baby 4y ago

By the way I was under the impression that Ethereum will still have forks, and thus probabilistic finality

DennisP 4y ago
Ethereum's PoS is really two consensus algorithms. The first converges rapidly but has probabilistic finality. The second has true finality, in the sense that a finalized block can't be reverted without destroying a large percentage of total stake, but it takes a while before that finality kicks in.

wyager 4y ago

Because they don't actually have "deterministic finality" in any meaningful sense. It's not possible. PoS is, as usual, vulnerable to attacks like grinding, and you can only paper over this.

djbusby 4y ago
Can you link more details on this? (am n00b, genuine curiosity)