Ethereum Constantinople Hard Fork | Everything You Need to Know | Explained Simply

On Thursday, December 6th, 2018 during the bi-weekly Ethereum Dev Core Meeting, the team decided to move forward with the launch of the Ethereum Constantinople hard fork. The launch will occur at block number 7,080,000, with an anticipated date of January 14, 2019. To learn more about the details of a Hard Fork, check out this article.

High-Level Overview of Ethereum Constantinople

Constantinople brings with it much-needed performance upgrades to the Ethereum blockchain. It also addresses the problems related to the Difficulty Bomb and Miner Rewards.

Constantinople is a very intensive and extensive update. It will break backward compatibility, meaning the update will come into existence as a Hard Fork. However, at this time it is not expected that Ethereum will split into 2 currencies. This Hard Fork should feel more like a system upgrade. Normally, when people hear the phrase hard fork, they feel that the chain will split into 2 and a 2nd coin will be created. This is not always the case. If everyone agrees with the changes and there is consensus on the update when the hard fork happens everyone just switches to the new version.

5 Updates with Ethereum Constantinople

There are 5 major changes that make up the Constantinople update. A majority of the changes are related to performance. This is an area that Ethereum desperately needed to address, as there becomes increasingly more competition from other platforms that are faster.

To address this concern the Ethereum developers are improving the Ethereum Virtual Machine (EVM). You can think of the EVM as the engine behind the scenes that executes the code associated with Smart Contracts.]

The 5 improvements included in Constantinople are listed as EIP and then a chronologically ordered number. EIP stands for Ethereum Improvement Proposal. Any member of the Ethereum community can write a proposal and submit it for review. If a majority of the community agrees with the proposal, it will be accepted and scheduled into an upcoming release.

The first improvement is EIP 145, which is a technical improvement written by developers Alex Beregszaszi and Pawel Bylica. This improvement adds Bitwise shifting instructions to the EVM. Bitwise shifting is the process of moving the bits of a binary number to the left or the right. With the new instructions, this operation will use approximately 10X less gas. In plain English, this means that running smart contracts will become more efficient and cheaper.

The second update we will discuss is EIP 1052, co-written by Nick Johnson and Pawel Bylica. This update introduces a new operation that allows smart contracts to verify the code of another smart contract more efficiently. Previously, this verification would require that you pull the code of the other contract and verify it. With the new update, a hash of the code is returned for verification rather than the entire code. This becomes very important when you have many smart contracts interacting with one another, using hash verification speeds up the process dramatically.

Next, we will look at EIP 1014, written by the Founder himself Vitalik Buterin. EIP 1014 adds State channels to the Ethereum network. State channels can be easily compared to Bitcoins Lightning network. The main thing to know here is that State channels allow for transactions to be settled in a payment channel away from the main blockchain. This can allow for higher throughput and improve the transactions per second.

From the EIP 1014 Github page, the motivation for this update is below:

Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code.

What this basically means is that the update will allow for the main chain to reference off chain transactions that have not been broadcast to the main chain yet.

The 4th proposal is EIP 1234, Constantinople Difficulty Bomb Delay and Block Reward Adjustment, Championed by Afri Schoedon. EIP 1234 is the proposal that has been garnering the most attention. The approved proposal has to do with delaying the difficulty bomb and reducing the block reward. A couple of questions here: What is the Difficulty Bomb? and Why would we want to reduce the block reward?

Block Reward

Lets’ start by discussing the block reward. Until now, miners on the Ethereum network receive 3 Ether (ETH) as a reward for mining a new block. A new block is created every 15 seconds, meaning that every day 5-6,000 blocks are added to the chain.  With a block reward of 3 ETH, 15-18,000 ETH are being added to the total supply every day.

This can become a big issue, and if you would like to learn more, check out our article on CryptoCurrency Price Inflation.

This new update reduces the mining reward from 3 ETH to 2 ETH which will reduce the yearly inflation of the coin. The goal of this is ultimately to drive the price higher, as we know that when there is less of something it becomes worth more. Bitcoin has a similar, automated mechanism, where the block reward is cut in half every 210,000 blocks.

Difficulty Bomb

EIP 1234 also delays the release of the difficulty bomb by 1 year. But what is the difficulty bomb? It has to do with Ethereums’ plans to move away from the Proof of Work algorithm, and their adoption of Proof of Stake. You can learn about Proof of Stake and it’s importance by reviewing this Deep Dive.

To summarize, right now on the Ethereum blockchain, miners are needed to process transactions and create new blocks. They are compensated for their proof of work with a block reward. With Proof of Stake, however, miners are not needed and will essentially lose their job. When Etereum finally switches to proof of stake, miners can choose to not adopt the new update and keep the old version of the chain going. This would be a true Hard Fork, dividing the Ethereum community in 2 with people supporting both chains.

This situation has happened to Ethereum in the past, which is why we now have Ethereum and Ethereum Classic. The Ethereum developers are trying to make sure this situation does not repeat itself. The solution that they have come up with is to add the Difficulty Bomb into the protocol. The difficulty bomb is a mechanism that makes mining a new block exponentially more difficult over time. The difficulty continues to increase until mining a new block becomes impossible. When blocks can no longer be mined the network is halted or frozen, and this scenario is known as the Ethereum Ice Age. This concept was added to the protocol on September 7th, 2015.

The Difficulty Bomb accomplishes 2 things. First, it adds pressure to the Ethereum developers to come up with an update for the protocol to avoid an ice age from occurring. Secondly, it forces miners to adopt new updates. Otherwise, they will be stuck mining for a network that is not making them any money. The difficulty bomb is a very good idea, but all good ideas come with their own drawbacks. The idea was introduced in late 2015, and the goal was to make the network almost unusable by the end of 2016. The thinking was that the migration to Proof of Stake would have already taken place. Obviously, that did not happen, and we are now left with EIP 1234 which delays the difficulty bomb 1 year. This puts the anticipated start date of the difficulty bomb on January 14th, 2020.

Lastly, we have EIP-1283, which is based on an earlier proposal EIP 1087 that was authored by Nick Johnson. EIP-1283 is called, Net gas metering for SSTORE without dirty maps. A long, confusing sounding EIP name that makes it possible for multiple updates to use the same storage slot within a transaction to reduce cost. This can be done because the transaction doesn’t write to disk until the end of a transaction.

Conclusion

As mentioned above, this will feel more like a system upgrade rather than a hard fork. This hard fork does begin to lay the groundwork for additional upcoming forks including Plasma and Casper. All with the goal of migrating the network from Proof of Work to Proof of Stake. If you have enjoyed reading this article, please consider leaving your feedback below.