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?
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.
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.
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.
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.
- 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
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!
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.
PoS is, as usual, vulnerable to attacks like grinding, and you can only paper over this.