Your must-read guide to understanding the upcoming Ethereum Hard Fork; Ethereum Constantinople. This guide will take you through the blockchain basics in order to properly understand the implications of the fork and the changes it will bring to the Ethereum Community.

After months of testing and delay, Ethereum Constantinople is finally on its way. Expected to be executed by January end, the long-awaited Ethereum update is bringing with it a lot of changes. Constantinople is part 2 of the Metropolis update. We have covered Metropolis in detail before. So, in this guide let’s put Constantinople under the microscope and see what all changes it is bringing into the ecosystem.

Ethereum Constantinople is going to be a hard fork. With the whole “ETH-ETC” and the “Hash War” saga, the term manages to conjure up a pretty negative picture. However, that is not necessarily the case all the time. So, before we even begin anything, let’s educate you about forking and why they are essential.

What is a Fork?

A fork is a condition whereby the state of the blockchain diverges into chains where a part of the network has a different perspective on the history of transactions than a different part of the network. In other words, it is a divergence in the perspective of the state of the blockchain.

What is a Soft Fork?

Whenever a chain needs to be updated there are two ways of doing that: a soft fork or a hard fork. Think of soft fork as an update in the software which is backward compatible. What does that mean? Suppose you are running MS Excel 2005 in your laptop and you want to open a spreadsheet built in MS Excel 2015, you can still open it because MS Excel 2015 is backward compatible.

BUT, having said that there is a difference. All the updates that you can enjoy in the newer version won’t be visible to you in the older version. Going back to our MS excel analogy again, suppose there is a feature which allows to put in GIFs in the spreadsheet in the 2015 version, you won’t see those GIFs in the 2005 version. So basically, you will see all text but won’t see the GIF.

What is a Hard Fork?

The primary difference between a soft fork and hard fork is that it is not backward compatible. Once it is utilized there is absolutely no going back whatsoever. If you do not join the upgraded version of the blockchain then you do not get access to any of the new updates or interact with users of the new system whatsoever. Think PlayStation 3 and PlayStation 4. You can’t play PS3 games on PS4 and you can’t play PS4 games on PS3.

Andreas Antonopoulos describes the difference between hard and soft fork like this: If a vegetarian restaurant would choose to add pork to their menu it would be considered to be a hard fork. if they would decide to add vegan dishes, everyone who is vegetarian could still eat vegan, you don’t have to be vegan to eat there, you could still be vegetarian to eat there and meat eaters could eat there too so that’s a soft fork.

So, that is what a fork and a hard fork is.

The thing is, that these forks happen all the time. All systems need to update, which is essentially a fork. It is only when the community is divided about a fork when the issues happen. Thankfully, the Ethereum community is not completely divided about the Constantinople hard-fork There are still some minor issues of course, which we are going to talk about later (check EIP 1234 section below).

The 4 Stages of Ethereum

This, not the first time Ethereum has upgraded of course and it won’t be the last time.

Ethereum was not designed to be just a mode of currency. It was designed to be a platform for decentralized applications. However, before it can do so, it needs to go through various stages of growth. With each stage, Ethereum “levels up” by incorporating more and more properties making its system more robust and seamless.

The complete launch process of Ethereum was divided into 4 stages. This was done to make sure that various phases got their own developmental time and that every stage was developed as efficiently and optimally as possible.

The 4 stages are as follows:

• Frontier: This was what everyone got when Ethereum was first launched.
• Homestead
• Metropolis: The current phase. Since there are so many updates in Metropolis, it was subdivided into Byzantium and Constantinople
• Serenity: The final stage.

Introducing Ethereum Constantinople

The Constantinople hard fork is expected to happen around block height 7,080,000 which is expected to occur sometime between January 14th and January 18th. This update is going to introduce five Ethereum Improvement Proposals or EIPs to the ecosystem:

• EIP 145: Developed by two ethereum developers, Alex Beregszaszi and Pawel Bylica which introduces a native ‘bitwise shifting’ that can run through bytecode at a cost which is similar to other arithmetic operations.
• EIP 1052: Offers a means of optimized large-scale code execution on ethereum. This will allow only the compressed code containing essential contract data is checked, as opposed to the whole code. This was authored by Nick Johnson and Bylica.
• EIP 1283: This EIP is based on EIP 1087 which was again written by Nick Johnson. This EIP helps in reducing the amount of gas developers need to pay to run and execute their smart contracts by cutting off excessive and unnecessary gas usage.
• EIP 1014: This EIP was created by Vitalik Buterin himself. This will basically help Ethereum to leverage state channels to enable them to communicate with off-chain addresses. This will help in the scalability of the entire system.
• EIP 1234: Easily the most controversial update which has been championed by the release manager of Parity, Afri Schoedon. This will gradually remove the difficulty bomb from Ethereum’s system and reduce block reward from 3 ETH to 2 ETH for a 12-month period.

Now, let’s look into all these EIPs in detail.

EIP 145 – Bitwise Shifting

A bit shift is a bitwise operation which moves each digit in a number’s binary representation to the left or right a required number of times. The “<<” is the logical left shift operator while “>>” is the logical right shift operator.

To understand how it works, let’s consider an example.

3 can be written in a binary format, using 8-bits notation, like this: 00000011

If we want to right shift this by 1, then it will look like this:

00000011 >> 1

This will push the digits to the right side by one. The last digit, which in this case is “1” gets completely removed and lost. Plus, a “0” is always added in the beginning.

So, 00000011 >> 1 will become 00000001 or 1.

Similarly, if we left shift 3 by 1, we will get:

00000011 << 1

In this case, the digits are shifted towards the left, and the left most digit, in this case, “0” gets pushed out. After that, a “0” is added at the end.

So, 00000011 << 1 becomes 00000110 or 6.

Now, if you look in a little more deeply, you will observe something quite fascinating.

If you left shift a binary number N times, then it multiplies that multiplies that number by 2^N times.

 0010 << 1 —->  0100

So, 0010 is 2 and left shifting that by 1 gives us 0100, which is 4 or 2*(2^1).

Two left shifts gives us 0010 << 2 —> 1000 which is 8 or 2 * (2^2).

On the other hand, if we right shift a number N times, then we divide the number by 2^N and the quotient is the answer (you throw away the remainder).

So, let’s right shift 8 2 times. 1000 >> 2 will give us 0010 which is 2 or 8 / (2^2).

Ok, so you are probably wondering, what’s the point of knowing all these things and how is it going to help me in Ethereum? Think of the number of operations that bitwise shift includes:

• Exponent operation
• Multiplication or division

These operations when done in sequence can become really expensive. However, one single operation which covers both of these is much cheaper. This will help Ethereum developers with code optimization.

What this does is that it will help underlying decentralized applications like CryptoKitties to be processed faster by the Ethereum Virtual Machine(EVM).

EIP 1052 – Optimizing Large-Scale Code

This EIP will help specify a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract’s code. The thought process behind this is to only allow essential data of the contract code to be checked rather than the entirety of the code itself.

Many contracts need to perform checks on a contract’s bytecode, but do not necessarily need the bytecode itself. Eg. a smart contract may need to check another contract’s bytecode if it belongs to a particular group or not, or it may perform certain analyses on code and whitelist any contract with matching bytecode if the analysis passes.

Currently, the contracts do this extremely inefficiently by using the EXTCODECOPY opcode but it is extremely expensive for large contracts. The EXTCODEHASH opcode will only return the keccak256 hash of a contract’s bytecode and help developer save a lot of money.

Source: Understanding Ethereum Constantinople: A Hard Fork – Blockgeeks