As I understand, fast sync has all the security guarantees of a full sync, but is faster. Is that correct? If so, why isn't fast sync the default?
- Fast sync indeed has one additional weakness compared to full sync. As long as an attacker can keep you isolated from the main chain (e.g. infect your router), it may construct an arbitrary state that your node will believe (details in https://github.com/ethereum/go-ethereum/pull/1889, Weakness section). This is the reason why fast sync is only a one shot sync mechanism: people will likely verify that they are indeed up to date and correctly when they initially sync, but probably will assume nothing's wrong afterwards. It's hard and expensive to trick fast sync, but given "enough" trials, you could eventually do it. By disabling fast sync after the initial one we're making it impossible to mount a realistic attack against it.
- Fast sync does not retain past transition data (e.g. what an account held half a year ago), only a relatively fresh view of the network (last 8-10 hours) when it finishes, (from which point it will act as a full node). Because of this, if we would enable by default then it would be bad for block explorers.
However, hopefully Geth 1.5 will have state pruning implemented, with which we're going to make the "archive" and "full" node separation. Then archive nodes will have pruning and fast sync off, whereas full nodes will have pruning and fast sync on. At least this is the plan :)
Thanks for this answer. As I understand without
--fastthe amount of disk space required today is ~10GB. Given
--fastdoes not retain past transition data how much disk space does
--fastrequire today? Mar 7, 2016 at 12:02
Didn't measure recently, but around 1.3GB. Mar 7, 2016 at 15:31
Is geth --fast safe to use? Yes or no?– VesaMay 17, 2016 at 3:22
@Vesa If you want a simplified answer, Yes: "By disabling fast sync after the initial one we're making it impossible to mount a realistic attack against it."– eth ♦May 17, 2016 at 4:06
Actually I want a correct answer, not a simple answer. If yes or no doesn't apply, then n/a (not applicable) would be the correct answer. I don't want to take any risks here. If geth --fast is not safe, then do not simplify the answer but instead say n/a or no.– VesaMay 21, 2016 at 1:39