diff --git a/EIPS/eip-2456.md b/EIPS/eip-2456.md new file mode 100644 index 00000000000000..57f5af87f2a425 --- /dev/null +++ b/EIPS/eip-2456.md @@ -0,0 +1,166 @@ +--- +eip: 2456 +title: Time Based Upgrade Transitions +author: Danno Ferrin (@shemnon) +discussions-to: https://ethereum-magicians.org/t/time-based-upgrade-transitions/3902 +status: Draft +type: Standards Track +category: Core +created: 2020-01-02 +--- + +## Simple Summary + +A process to specify network upgrades relative to a point in time instead of a fixed block number. + +## Abstract + +Instead of assigning network upgrade transitions to occur on `TRANSITION_BLOCK` ahead of time a +`TRANSITION_TIME` is chosen. On the second "round" block after the `TRANSITION_TIME` occurs the +transition to the network upgrade will occur. Meta-EIPs will list the TIME and later be updated to +also include the historical BLOCK when the upgrade transitioned. + +## Motivation + + + +For the Muir Glacier and Istanbul upgrades there were a total of at least 4 times when the planned +upgrade occurred well away from the intended date. For Ropsten the Istanbul upgrade occurred earlier +because of the sudden addition of hashing power, and for Muir Glacier it happened much later because +of the removal of that hashing power. For Mainnet the Istanbul transition was days later and the +Muir Glacier transition was days sooner because of the unpredictable impact of the Difficulty Bomb. + +Such unpredictability is bad for node operators such as exchanges and block explorers. Particularly +an earlier fork may disrupt their maintenance plans. A much shorter window of unpredictability would +benefit node operators and developers monitoring the upgrade. + +## Specification + +A 'Transition Eligible Block' is defined as a block where the number of blocks preceding the block +is evenly divisible by the `TRANSITION_INCREMENT`, i.e. +`(block.number % TRANSITION_INCREMENT) == 0`. For Mainnet the `TRANSITION_INCREMENT` will be 1000. +For testnets a `TRANSITION_INCREMENT` of 1024 is recommended. + +A specific `TRANSITION_TIME` will be chosen for the network upgrade to activate. + +An upgrade will activate at a Transition Eligible Block if all of the following are true: + +- The upgrade has not activated already. +- The timestamp of the block is on or after the `TRANSITION_TIME`. +- The previous Transition Eligible Block was on or after the `TRANSITION_TIME`. + +Once activated the upgrade remains activated for all future blocks. + +If multiple upgrades would activate on a Transition Eligible Block all such transitions will +activate. Note that most network upgrades are defined as "previous upgrade + new rules" so the +effect may be that only the most recent network upgrade would appear to activate. + +After the upgrade transition completes the Hard Fork Coordinator will update the Meta-EIP to note +what the transition block was. Clients may incorporate this block into their genesis files as an aid +to synchronization. This transition block number is only advisory and the time base transition rules +have precedence. + +## Rationale + +Previously when determining upgrade transitions a specific block number was chosen. This number was +typically a multiple of 1000. For testnets a practice developed of making the numbers decimal +palindromes. Retaining the mainnet tradition is easy, but specifying a palindrome algorithm for +testnets seemed excessive. As a compromise round decimal numbers (ending in `000`) are proposed for +mainnet and round hexadecimal numbers (ending in `0x000`, `0x400`, `0x800`, or `0xc00`) is proposed +for testnets. + +The next concern was the reliability of the timestamp in the block header. The only rules enforced +for this by clients are from (a) always incrementing and (b) not being too far in the future. Only +the first rule produces a consensus error and clients can co-operate on the second rule. Apart from +these checks miners can lie about the time and manipulate it for their own ends. Because of the +incrementing timestamp rule it is expected that any gains would be short lived, and the timestamp is +not used in fork selection rules either, only in difficulty calculations. + +A related concern to miner manipulation would be chain reorganizations. If the transition were to +occur immediately then there is a chance one side of a reorganization would activate and the other +side would not. Hence the 1000-1999 block delay in the activation of the fork. It is not expected +that a chain reorganization would occur much past 100 blocks. In the +[Ethereum Classic 51% attack](https://blog.coinbase.com/ethereum-classic-etc-is-currently-being-51-attacked-33be13ce32de) +the longest reorganizations were less than 150 blocks, so a re-organization of over 1000 blocks is +not expected. + +The two eligible block activation process mirror's Casper's (and by extension Ethereum 2.0) block +finalization process. A block is first justified, and then finalized when another block that later +builds on that block is also justified. In this spec a transition occurs when the second Transition +Eligible Block past the transition time occurs. + +This delay of 1000 to 1999 blocks provides a small window where the transition block can be presumed +prior to it's actual arrival. It also has a smaller window of uncertainty around when it will +arrive, which is the principal motivating impact of this design. + +| Block Time | Mean Transition | Earliest Transition | Latest Transition | +| ---------- | --------------- | ------------------- | ----------------- | +| 13 seconds | 5h 25m | 3h 36m 40s | 7h 13m 7s | +| 15 seconds | 6h 15m | 4h 10m | 8h 19m 45s | +| 30 seconds | 12h 30m | 8h 20m | 16h 39h 30s | + +Based on the expected transition period instead of targeting noon UTC on a Wednesday the transitions +should become eligible at 0600 UTC on a Wednesday, which would result in a transition during EMEA +business hours. + +## Backwards Compatibility + + + +### EIP-2124 - Fork identifier for chain compatibility checks + +EIP-2124 describes a fork identifier for chain compatibility checks, however it is defined in terms +of future expected fork blocks. Since the exact block number is not known this format would need to +be changed to accommodate the fork time. One alternative is to always communicate the +`TRANSITION_TIME`. This will produce no conflicts with blocks until mainnet reaches 1.4 billion +blocks (on the order of 700 years). Another alternative is to communicate the `TRANSITION_TIME` +before the transition and then `TRANSITION_BLOCK` after transition. The downside to this alternative +is that between the time of the transition and when clients upgrade their genesis files that +unsynced nodes may not be able to find peers. + +### Fast Sync, Warp Sync, and Beam Sync + +There will be minor impacts on all of the non-archival synchronization mechanisms. Generally +speaking when these protocols start executing the blocks they will need to know what the current +upgrade is and will need to be able to detect it based on timestamps in the header. + +For Fast Sync (currently Geth, Besu, and Nethermind) the blocks are not executed until both the +complete set of block headers and complete world state for the pivot point is downloaded. Clients +will have all of the data on-hand to make the calculations. Up to two previous Transition Eligible +Blocks will need to be examined. + +For Warp Sync (Parity) a similarly complete database is available before block execution starts. +Similarly up to two previous Transition Eligible Blocks will need to be examined. + +For Beam Sync (Trinity) block execution begins prior to the complete history of block headers and +downloading of world state finishes. In this case the two previous Transition Eligible Block headers +will need to be downloaded and examined prior to the execution of the first block. + +For all of Fast, Warp, and Beam sync the historically noted transition block can be recorded in the +genesis file as an aid to determining where the relevant transitions should occur, but the time +transitions should still be verified. Hence it would not be advisable to simply switch to the +historical node values for a time based transition. + +## Test Cases + + + +> To be completed once Eligible for Inclusion + +## Implementation + + + +> To be completed once Eligible for Inclusion + +## Security Considerations + + + +> Miners may game the "timestamp" to pull up/push back the activation block. (a) future timestamps +> are limited to 2 hours (b) timestamps must always increase (c) 1-2k block delay removes most of +> the incentive. I should elaborate on this once deemed eligible for inclusion. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).