Changes in Ethereum’s Constantinople Hark Fork

Kaven Choi
Etherscan Blog
Published in
2 min readMar 4, 2019


Let us begin with what is a Hark Fork for a blockchain, in the world of the distributed ledger, all party utilizing the blockchain agreed on a fixed set of consensus or rules that they all have to follow. The blockchain is immutable and so what happens when the developers would want to introduce an improvement to the working blockchain?

The upgrade to the blockchain is where a hark fork comes into play. We cannot “update” a blockchain per se like your regular OS update. When the Ethereum developers introduce improvements, the blockchain (Ethereum in this case) would need to branch out into a different “chain” implementing the changes into a new chain hence called a fork. If the majority of the users agreed on the changes, they could follow the latest chain or fork with the upgrade. The previous chain without the upgrade is either slowly obsoleted or being maintained by parties that opposed a proposed improvement to the chain.

An agreed upon block number is usually used to mark the beginning of the newly updated chain which in this case for Ethereum block number: 7280000

Now, let us take a look at the changes for the Constantinople Hard Fork introduced as EIP (Ethereum Improvement Proposals):

EIP 145: Bitwise shifting instructions in EVM

  • Developed by Alex Beregszaszi and Pawel Bylica which introduces to provide native bitwise shifting with cost on par with other arithmetic operations which are more efficient processing wise on the host and are cheaper to use by a contract.

EIP 1014: Skinny CREATE2

  • Introduced by Vitalik Buterin to allow interactions to (actually or counterfactually in channels) be made with addresses that do not exist on-chain yet but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.

EIP 1052: EXTCODEHASH opcode

  • Introduced by Nick Johnson and Pawel Bylica, this EIP specifies a new opcode, which returns the keccak256 hash of a contract’s code. Offering optimization and gas saving for contracts.

EIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment

  • Introduced by Afri Schoedon, the difficulty bomb from Ethereum’s system and reduce block reward from 3 ETH to 2 ETH for 12 months.

For the list of EIPS, drafts or final, you may refer here.

EDIT: removing EIP 1283 which is not included.