Time Based Upgrade Transitions

[shemnon]

A process to specify network upgrades relative to a point in time instead of a fixed block number.

In brief change the fork process so that that network upgrades would activate at the second “round thousand” of blocks after a specific time on the network, as reported in the blockheader. Why the second round thousand? In case the first round thousand is within an ommer re-org and to keep miners from playing too many games lying about the block time.

[holiman]

This is ambiguous, since and I'm wondering if there's some typo...?
Because if the timestamp of N is on TRANSITION_TIME, then the timestamp of N-1 cannot also be on TRANSITION TIME. So as I read it, we can totally skip the second bullet?

[shemnon]

I'll tighten up the wording on the second bullet point. "the block" of the second bullet point needs to be a Transition Eligible Block. So point 2 is looking at block n where (n % 1000) == 0 and point 3 is looking at block n - TRANSISION_INCREMENT and hence ((n - TRANSITION_INCREMENT) % 1000 == 0)

[carver]

I'm very in favor of finding a way to fork on timestamp 👍

The biggest con to this particular approach is losing the ability to look at a single header to decide which rules (VM) should be applied to its execution. Block-number-forking is conceptually clear, and lends itself to an API we're happy with in Trinity: get_vm(header). It would be a shame to lose that, especially when there might still be other options.

As far as I know, the two main concerns about direct timestamp forking are:

1. It opens new uncle validation edge cases
2. Some risk that miners will have a new incentive to manipulate timestamp away from current "true" time

So let's at least check if we can directly address these, first.

For example, maybe adding a rule that "uncles must have a timestamp older than the header that includes them" would get us most of the way there. (So we don't have to deal with uncles on a future fork when the including header is on an old fork). Also, we probably need to formalize that we only validate uncle PoW, and according to the rules of the uncle header's VM.

Also, some more analysis about miner incentives and timestamp-tweaking capabilities seems worthwhile, but my intuition is that the small-time gaming that might happen is not catastrophic. Any significant deviation would require a majority coalition of miners, as far as I can tell.

[shemnon]

@carver can you copy your comment to the discussion-to thread at https://ethereum-magicians.org/t/time-based-upgrade-transitions/3902 please?

[Souptacular]

@shemnon Do you want this merged?

[vbuterin]

I would propose reducing the lookback from 1024 to 256 or less. The reason is that the 1024 lookback implicitly adds the last 1024 blocks of history into the state, increasing the data that clients are required to hold; this could lead to edge cases for clients that haven't synced history yet. A lookback of 256 has no such risk, because the last 256 blocks are already required to be accessible to the BLOCKHASH opcode.

[MicahZoltu]

This looks good for getting merged as a draft aside from the extraneous comments (new policy is to remove them).

[MicahZoltu]

Suggested change

<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->

[MicahZoltu]

This seems unnecessarily complex. The specific block number choice is pretty arbitrary in all cases, and having a different strategy for mainnet and testnet seems like a waste of engineering effort for what is essentially the color of the boathouse being different in mainnet and testnets.

[MicahZoltu]

Suggested change

	<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->

[MicahZoltu]

Suggested change

	## Test Cases
	<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
	> To be completed once Eligible for Inclusion

This isn't currently a required suggestion, consider just leaving it out.

[MicahZoltu]

Suggested change

	## Test Cases
	<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
	> To be completed once Eligible for Inclusion
	## Test Cases
	TBD

Alternatively, if you want to leave it in so you don't forget that is fine as well, just remove the comment.

[MicahZoltu]

Suggested change

	## Implementation
	<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
	> To be completed once Eligible for Inclusion

Suggested change

	## Implementation
	<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
	> To be completed once Eligible for Inclusion
	## Implementation
	TBD

Same comment as above.

[MicahZoltu]

Suggested change

<!--All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->

[shemnon]

@shemnon Do you want this merged?

I no longer participate in the EIP process.

[MicahZoltu]

I no longer participate in the EIP process.

I'm interpreting this statement to mean that the Author no longer wishes to pursue this EIP and I'll close the PR. @shemnon please re-open this PR if I have misunderstood your meaning! If someone else wishes to pursue this specification, just create a new PR with yourself as the author and a new EIP number (usually the PR number).