13

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?

Improve this question

1 Answer 1

Reset to default
17

Two reasons:

  • 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 :)

Improve this answer
6
  • Thanks for this answer. As I understand without --fast the amount of disk space required today is ~10GB. Given --fast does not retain past transition data how much disk space does --fast require today?
    – Randomblue
    Mar 7, 2016 at 12:02
  • Didn't measure recently, but around 1.3GB.
    – Péter Szilágyi
    Mar 7, 2016 at 15:31
  • Is geth --fast safe to use? Yes or no?
    – Vesa
    May 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.
    – Vesa
    May 21, 2016 at 1:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.