EIP-1482: Define a maximum block timestamp drift

Read the full text here

Abstract

Include an explicit definition of the acceptable timestamp drift in the protocol specification.

Motivation

There is a lack of clarity about how accurate timestamps in the block header must be. The yellow paper describes the timestamp as

A scalar value equal to the reasonable output of Unix’s time() at this block’s inception

This causes confusion about the safe use of the TIMESTAMP opcode (solidity’s block.timestamp or now ) in smart contract development.

Differing interpretations of ‘reasonable’ may create a risk of consenus failures.

Specification

The yellow paper should define a timestamp as:

A scalar value equal to the output of Unix’s time() at this block’s inception. For the purpose of block validation, it must be greater than the previous block’s timestamp, and no more than 15 seconds greater than system time.

Rationale

Both Geth and Parity reject blocks with timestamp more than 15 seconds in the future. This establishes a defacto standard, which should be made explicit in the reference specification.

3 Likes

I’m going further down the stack with this simple EIP than usual. I’d appreciate any feedback on it.

Am I expected to provide Test Cases at this stage? To what detail do they need to be specified?

It should be noted that the “no more than 15 seconds in the future” rule does not apply to ommers. Need to be careful we don’t imply it does when adding this to the YP.

Word on the street is that the Jello Paper is going to be the canonical reference going forward. What does it say?

I’ve got a work-in-progress PR to codify in the EIPs README where canonical representations / specifications live, and how this interacts with EIP expectations.

I think this EIP is useful AND that it might be more of a matter of a PR against the Jello Paper? Not sure!

All those “15 seconds” should be “15 minutes”, right?

No, per the source code it’s seconds:

I think this may be a useful as a clarification, and could be applied similarly to some of the other “retroactive” ones, e.g. EIP-2681 and EIP-3607.

I wonder what how this will change after the merge, @mkalinin?

1 Like