Berlin

From Consensus Paper
Jump to navigation Jump to search
Berlin
Consensus upgrade
TypeHard fork
StatusPlanned
PreviousMuir Glacier
Ethereum family

Berlin is a planned hard fork on Ethereum.

Proposal Reviews[edit | edit source]

The list is provided as to accommodate reviews, so it excludes specifications that doesn't technically require a hard fork, such as EIP-1803: Rename opcodes for clarity.

Time based upgrade transition[edit | edit source]

This refers to EIP-2456. Rather than basing upgrade on block numbers, it is based on block timestamps.

  • Argument Argument This makes hard fork time predictable and free of influence of hash power changes.
  • Objection Objection The specification requires checking past headers to see whether the upgrade is already active. Previously, we do not require historical headers to determine executing EVM version, but now we do.
  • Objection Objection Timestamp manipulation is an issue. Timestamp is a variable that miners have control, so they have incentive to manipulate timestamps of blocks around hard forks for their advantages.[1]

Difficulty bomb handling[edit | edit source]

This refers to EIP-2515, which replaces difficulty bomb with difficulty freeze, meaning after BOMB_BLOCK, future block difficulty will have a linear increase of parent block difficulty.

  • Argument Argument It's hard to predict future block time under the current difficulty bomb schedule. By replacing the bomb with a freeze we can fix this issue.
  • Objection Objection When difficulty freezes, the protocol is no longer responsible to hash power changes. If the hash power increases in a rate faster than the linear increase of the difficulty freeze, block time becomes shorter. For users, some might argue that the system becomes more responsive. For miners, they enjoy better issuance. This does not provide incentives for users and miners to abandon the chain or to make efforts for upgrades.
  • Objection Objection If time-based hard fork is enabled, then it's no longer necessary to predict block time.

Subroutines[edit | edit source]

This refers to EIP-2315 (simple subroutines for the EVM):

  • Argument Argument It significantly simplifies generated EVM code of function calls, making static analysis easier and resulting in shorter contracts.[2]
    • Opinion Opinion Part of the reason why provided example has significant difference is because all function are marked public and thus require it to be available externally. However, in real contracts, many of the cases can be optimized by inlining.[3]
    • Objection Objection A majority of the space saving is due to an addition of stack. EVM is changed from single-stack machine to double-stack machine. We could introduce opcodes such as "rotate stack" to accomplish similar functionality.
  • Objection Objection The specification can be strengthened for even better static analysis capatibility.[4]
    • Objection Objection If further improvements are made, then we may end up going back to EIP-615, whose complexity was the major factor for it not gaining enough support.[5]

References[edit | edit source]