Ethereum blockchain is soon going for another hardfork - Constantinople. According to earlier Roadmap of Ethereum, Metropolis is the third phase of Ethereum. It was then decided to take it forward in two separate hardforks Byzantium and Constantinople respectively. Both hard forks are introducing major updates to the greater Ethereum ecosystem.

What is Constantinople?

Constantinople fork will be the concluding part of Metropolis phase and we will enter Serenity. Constantinople is expected to make adjustments to Ethereum’s economic policy, which partly focuses on delaying the difficulty bomb and ETH issuance.

What is the expected date for Constantinople hard fork on Mainnet?

Based on discussion in the last coredev call, the fork is expected to be around January 16, 2019. The block# will be decided in coming weeks in coredev call.

Updated (Dec 09, 2018): Constantinople mainnet hard fork scheduled for block #7080000, estimated around the 16th of January, 2019!

Which EIPs are considered?

At the initial stage of Metropolis, Constantinople was planned to introduce the following features:
● Abstraction of transaction origin and signature
● Blockhash refactoring

But with passing time, now we are going ahead with more features. Below are the EIPs considered for Constantinople so far.

  • EIP 145: Bitwise shifting instructions in EVM. To provide native bitwise shifting with cost on par with other arithmetic operations.
  • EIP 1014: Skinny CREATE2. This EIP allows for a significant performance increase in state channels by removing the need for an additional contract to allow for counterfactual addressing.
  • EIP 1052: EXTCODEHASH Opcode. This EIP specifies a new opcode, which returns the keccak256 hash of a contract’s code.
  • EIP 1283: Net gas metering for SSTORE without dirty maps (replaces 1087). This EIP proposes net gas metering changes for SSTORE opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn’t match how most implementation works. This acts as an alternative for EIP-1087, where it tries to be friendlier to implementations that use different optimization strategies for storage change caches.
  • EIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment. Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly. This EIP is one of the most controversial one as it is going to affect miner community a lot. You can Read the draft here: eip-1234.md

As the project Ethereum is moving ahead, core developer team are taking all efforts to be transparent and keep community on the same page. The Constantinople Progress Tracker indicates that all clients have implemented EIPs to be considered for the upcoming fork.

ProgPow is another implementation considered for Constantinople HF. This algorithm is ASIC resistance and is designed to be optimising for a specific type of mining hardware, the goal is to maximally utelise all the function of that hardware. More on ProgPow will be coming soon.

What happened in Ropsten testnet Constantinople hard fork?

Ethereum Ropsten testnet Constantinople hard fork was set to be activated on Ropsten at block number 4,230,000, on October 13, 2018. However, team soon realized that something went wary. Block 4,230,000 featured zero transactions after mining and the Ropsten network was stalled at block 4,299,999.

Afri Schoedon from Parity wrote, “The fact that all clients are ‘stuck’ means that there is no valid Constantinople block yet.” He explained in the Constantinople special call that client releases were very late, less than one week before the fork; miners failed to upgrade their software. No one was mining the Constantinople chain and high hash rate on Byzantium chain was observed. Then consensus issue between geth and Parity was discovered, also Harmony was for some reason using the wrong config.

Hudson Jameson from Ethereum Foundation told that they had trouble monitoring the fork, knowing which was the canonical chain. There was no fork monitor, only basic ethstats page. They weren't coordinating with the miners until the last second. A few things went wrong but issues were resolved and Ethereum developer team is now moving towards mainnet hard fork. Based on the discussion in the last call, team agreed on a few action plans for making mainnet HF go smooth:

  • Coordinate with miners
  • Add time between release and fork
  • Fix fork monitor
  • Define a better communication, "war room"
  • AllCoreDevs channel works for now, along with e.g. a hackmd file that's a source of truth for what's going on.

Read more:

EtherWorld's collection of Good Read on Blockchain & Cryptocurrency.

Read EtherWorld's Blockchain Weekly for update on Blockchain news, technology and projects.

Create your personal Cryptocurrency Portfolio with Digital Asset Calculator

____________________________________________________________________________________________________

Disclaimer: This is not an investment advice and should NOT be viewed as project endorsement by EtherWorld. Readers are suggested to do their research before investing into any project.

Follow us at Twitter, Facebook, Google+, Medium and Steemit.

____________________________________________________________________________________________________