2

One thing I don't understand about the Ethereum protocol is how timestamps work. If I, as miner, have a reason to fiddle with timestamps (such as adding a few minutes to decrease the mining difficulty) I simply produce a block with a timestamp which is a few minutes larger than the current UNIX time.

I suppose that this is not possible, but I don't understand how this is enforced. Does the network simply not allow blocks which have a drift time which is too large compared to the current time? Or is there some kind of protocol in place which disencourages miners to create invalid timestamps?

Improve this question

1 Answer 1

Reset to default
2

While all the nodes operate on their local time (i.e. the local time of the computer they are being run on) large differences in time between nodes are not allowed. If you are really out of sync with an NTP server, you will experience problems with syncing blocks, consensus, etc. So while not strictly enforced, it is necessary to have accurate local time.

As for the attack you are describing, Ethereum has some checks in place:

  • In PoW (Ethash) your block will be accepted if you are 15 seconds ahead (or less). If you are trying to propagate a block with a stale timestamp, the block will be instantly rejected.
var (
...
allowedFutureBlockTime    = 15 * time.Second
...
)
...
if header.Time > uint64(time.Now().Add(allowedFutureBlockTime).Unix()) {
    return consensus.ErrFutureBlock
}
...
...
if header.Time <= parent.Time {
    return errZeroBlockTime
}
  • In PoA (Clique) nodes don't get any leeway to propagate "blocks from the future".
// Don't waste time checking blocks from the future
if header.Time > uint64(time.Now().Unix()) {
    return consensus.ErrFutureBlock
}

So to summarise: you are absolutely right about the network not allowing blocks that have a delta in time that is too large.

Edit. Clarification from comments: it's really all about the majority of clients (the 51%). If the majority of clients disable dagger-hashimoto (PoW) block verification you can propagate bogus blocks, etc. So it's essential for clients to operate on the same protocol - this ensures consensus between all of them.

Improve this answer
6
  • 1
    True, but this is an implementation in the client. I cannot try to create bogus blocks because I do not have enough mining power, but the mined blocks have no "decentralized level" of enforcement of the timing - it is just that clients are expected to have this implementation, but if the majority of the clients throw this requirement out of the window we can start seeing bogus timestamps while we cannot see bogus blocks regarding their contents which are unrelated to timestamps (due to PoW).
    – JBrouwer
    Commented May 15, 2019 at 20:31
  • 1
    "if the majority of the clients throw this requirement out of the window we can start seeing bogus timestamps while we cannot see bogus blocks regarding their contents which are unrelated to timestamps (due to PoW)" If your client throws this requirement out the window, then it will accept blocks with arbitrary timestamps. Similarly, if your client decides it doesn't care about PoW being correct, then you can see "bogus blocks" in that regard. There's no difference between the two requirements. They're both checked by each node, and a node will refuse to accept invalid blocks.
    – user19510
    Commented May 15, 2019 at 21:45
  • 1
    Hmm yes this is a good point. So basically these timestamps are enforced on the network because a miner can assume that >50% of the nodes do not accept bogus timestamps. Hence their bogus block does not get accepted by the majority of nodes so they can never payout their mining income @smarx ?
    – JBrouwer
    Commented May 15, 2019 at 23:10
  • 1
    @IvanAndrusenko I think the main point I learned from here is that in the end it is about the majority of clients accepting blocks which follow a certain protocol. Could you add something like that to your answer? I think more people will think about it this way. The only thing that is odd is that you can essentially verify everything on the chain that no one has tampered with it - except that you cannot check if all nodes have behaved "right" in the past regarding these timestamps because there is no way to actually verify if it was that time at that point.
    – JBrouwer
    Commented May 15, 2019 at 23:12
  • 1
    You can verify the timestamps. The rule enforced by clients about timestamps is how far they are from the timestamp of the previous block. You can verify that whenever you want.
    – user19510
    Commented May 15, 2019 at 23:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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