How Ethereum is dependent of well synced computer time
Hi, I was wondering how important is a fine synced time on an ethereum node. Are we talking about a maximum of a second delay to be able to interact with other nodes or is it more about micro or miliseconds or even nanoseconds? We mostly rely on NTP servers to have this time. NTP servers rely on atomic clocks. Atomic clocks are centralised. I see a spof here. If the maximum time shift is not so low, couldn't we find a more decentralised way to have the right time? Thanks.
Posted Feb 14, 2018, 7:36 AM UTC
47
Using time in networking protocols is a horrible idea!
Ethereum uses time in it's discovery protocol.
Ok, with that out of my system :D...
The reason Ethereum uses time is to prevent node impersonations when changing IP addresses. Suppose your node advertises itself to the network, finds peers, everybody is happy. An hour later your ISP changes your IP. No problem, you just advertise your new IP.
An attacker comes along however, who saved your old UDP advertisement packets, and re-injects them into the network. The network all of a sudden sees two (digitally signed!) advertisements from the same node for different IPs.
Currently this is solved by timestamping each discovery packet. If the timestamp is too old (15 sec), it is discarded as a "replay attack". This means however that if your node is more than 15 seconds shifted, you can't discover nodes because everyone just considers you an attacker ;P
We're trying to get rid of this limitation in the next version of the discovery protocol. But that's a fairly low priority undertaking.
The second place where Ethereum uses time in the protocols are for block imports. Each block has a timestamp, and nodes reject blocks that are too far in the future (15 sec I think).
The rationale behind this is that the PoW difficulty is based on time (i.e. how long did finding the next block take? if too long, lower the difficulty). Without a limit on the future timestamps, miners could just create blocks that are days apart from each other, slashing the difficulty and thus allowing them to find blocks like crazy.
In either case, as long as your node is within this +-15 second window from the rest of the network, you should be fine.
Ok. Thank you very much for this clear answer. So I guess that if the accepted shift is within 15s, we don't really need an atomic clock precision. So could we imagine a decentralised time network based on simple quartz clocks that any node owner could feed in order to be free of the atomic clock time servers? My concern is that if one would like to shut down Ethereum, it would only need to hack a few time servers. I know there are other spof like isp internet connections, but we already heard about mesh networks and things like that but I never read anything about time decentralisation. I admit this is not a priority, that was juste one of my morning shower thought ;)
No. Decentralized networks need consensus on an accepted value, but the value doesn't actually need to be correct. This is why centralized time exists in the first place, it's a paradigm that needs to be authoritative.
That's not at all correct. Your desktop/laptop keeps it's own time via RTC on the motherboard. That's sufficient to stay within the +/-15 seconds. To update the system time, you can set it manually in the BIOS, or you can let your OS allow you to change it or set it automatically. This is where your computer potentially gets its time from some NTP server - which again, is more than good enough for +/- 15 sec.
Atomic clocks are far far down the line in terms of where "actual time" comes from. Shutting them down would't really impact much at all for a very long time, and even then I don't think we'd see significant skew as new NTP servers came online to replace old ones.
If shutting down atomic timer servers was an actual problem, Ethereum would be the least of your worries.
Thanks for the details!
You would need to hack a lot of time servers to have a wide effect. Time servers are set up in a hierarchical fashion - if you take out all the servers at stratum 0 (i.e. the root of the system), all of the servers at stratum 1 would continue working, albeit without the benefit of atomic-precision updates.
Successfully attacking Ethereum in this way would also break HTTPS so I suspect the problem would be fixed relatively quickly.
Interesting idea. A GPS-backed clock would be sufficient for Ethereum's purpose, and you can run one of those on a Raspberry Pi.
Thanks!
Really great explanation. Thank you for everything you do for the Ethereum community!