Understanding Ethereum Constantinople: A Hard Fork
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.
- 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.
EIP 1283 – Net Gas Metering
Built upon EIP 1087 and EIP 1153, EIP 1283 is proposing a novel method of “gas metering” for the SSTORE opcode which will enable:
- Charging users a fee for holding data that is permanently stored on the blockchain
- Reduce excessive gas costs
In simple terms, it reduces the amount developers need to pay when building smart contracts. Like we have mentioned before, gas costs are a real problem for developers because smart contract hosting takes a lot of money. As Nick Johnson, the author of the original proposal, puts it,
“In some cases in the past, we were charging gas for things that didn’t actually happen or didn’t actually cost any real resources and now we’re trying to adjust things so we only charge gas that aligns with the work we actually have to do.”
By charging users a fee for holding data that is permanently stored on the blockchain, it will disincentivize them from continuing to do so and “using up storage for things you don’t need them for.”
EIP 1014 – State Channels
So, what are state channels?
A state channel is a two-way communication channel between participants which enable them to conduct interactions, which would normally occur on the blockchain, off the blockchain. What this will do is that it will decrease transaction time exponentially since you are no longer dependent on a third party like a miner to valid your transaction.
Let’s look at the requirements to do an off-chain state channel?
- A segment of the blockchain state is locked via multi-signature or some sort of smart contract, which is agreed upon by a set of participants.
- The participants interact with each other by signing transactions among each other without submitting anything to the miners.
- The entire transaction set is then added to the blockchain.
The state channels can be closed at a point which is predetermined by the participants according to Slock.it founder Stephan Thual. It could either be:
- Time lapsed eg. the participants can agree to open a state channel and close it after 2 hours.
- It could be based on the total amount of transactions done eg. close the chain after $100 worth of transactions have taken place.
Image Courtesy: Stephan Tual Medium Article
So, in the image above. We have a car which directly interacts with the charger and does a total of $39.19 worth of transactions. Finally, after a series of interactions, the entire transaction chunk is added to the blockchain. Imagine how much time it would have taken if they had to run every single transaction through the blockchain!
That is the main use case of a state channel, it will immensely help in blockchain scalability. In fact, Bitcoin’s lightning network is essentially a fancy state channel which deals only with payments.
EIP 1014, which is being personally worked on by Vitalik Buterin, will allow interactions to be made with addresses which do not really exist on the blockchain, however, they can be relied upon to
“only possibly eventually contain code that has been created by a particular piece of init code.”
State channel developer Liam Horne has described EIP 1014 to be “a significant performance increase in state channels.”
EIP 1234 – Transition of POS
Ok, so before we understand the significance of this EIP, let’s understand certain things, mainly:
- Proof of Work
- Proof of Stake
Now, we have covered all this in our article on the Casper Protocol which you can read right here.
What is Proof of Work?
Most cryptocurrencies including Bitcoin run on “proof-of-work.” Proof-of-work as a process has the following steps to it:
- The miners solve cryptographic puzzles to “mine” a block to add to the blockchain.
- This process requires an immense amount of energy and computational usage. The puzzles have been designed in a way which makes it hard and taxing on the system.
- When a miner solves the puzzle, they present their block to the network for verification.
- Verifying whether the block belongs to the chain or not is an extremely simple process.
Ethereum, as of right now, is using the Proof of Work (POW) consensus mechanism. Now, that you know what POW is and the role that the miners play, it is time to understand what “difficulty” means.
What is difficulty?
Ok, so before we understand the term, let’s do a thought experiment.
The idea behind mining is for miners to use their mining power to solve these cryptographically hard puzzles and get Ethereum in return as a reward. Unlike Bitcoin, Ethereum doesn’t have a hard cap on its total supply. But, you still need to regulate the amount of Ether that is floating around in the system to make sure that the supply-demand equation doesn’t go out of balance.
This is why, both Bitcoin and Ethereum have a “difficulty” parameter hard-coded into their system. The difficulty makes sure that the time taken between the creation of the blocks remains the same. So, if the block creation time is too low, then the difficulty goes up and if it is too high, then it will go down.
The following chart shows the difficulty in Ethereum’s network from December 11, 2018, to January 11, 2019.
Current Ethereum Difficulty stands at 2,691,878,354,888,980.00000000
Alright, so now onto Proof of Stake (PoS).
What is Proof of Stake?
Proof of stake will make the entire mining process virtual and replace miners with validators. This is how the process will work:
- The validators will have to lock up some of their coins as stake.
- After that, they will start validating the blocks. Meaning, when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it.
- If the block gets appended, then the validators will get a reward proportionate to their bets.
Ok, so now you know the bare details. You know the basics of PoW, PoS and difficulty, now let’s get into the bare details of EIP 1234.
Ethereum’s method of PoS implementation is called the Casper Protocol. Obviously making a sudden shift from PoW to PoS will be extremely inadvisable. In order to smooth over the transition, Ethereum is going to first introduce a hybrid PoW-PoS consensus mechanism called “Casper FFG”.
As a part of this transition, they have decided to also introduce a “difficulty bomb” which will make mining so hard on the Ethereum blockchain, that the miners will have no incentive to do so and everyone will eventually move on to PoS. The point where mining becomes so difficult that it is almost impractical is called the “ice age”. The difficulty bomb was introduced on 7th September 2015 and has been programmed to raise difficulty exponentially.
Now, this is all well and good, however, the Casper Protocol is not ready yet for full implementation and there is still some work left to be done. This is why, instead of just delaying Constantinople as a whole, they have delayed the difficulty bomb by 29 million seconds or approx 12 months.
This brings us to the next problem.
Because the difficulty has been delayed it will become much simpler for miners to mine blocks and they will be able to do so with much more regularity. So, to counterbalance this, the block reward will go down from 3 ETH to 2 ETH. This reduction can be thought of as a “stop-gap” to the “supply bleed”.
This EIP has caused a huge controversy in the community. The author of the EIP. Afri Schoeden has called it the “the best proposal to stabilize issuance while simultaneously delaying the bomb.”
However, there are other members in the Ethereum community how have opposed this EIP arguing that the reduction of the difficulty will lead to more centralization.
The entire crypto community is looking forward to the Constantinople hard fork. By doing that, Ethereum will take another major step toward serenity and full implementation. As you can imagine, there are some truly radical changes coming in which will not only greatly benefit developers, but it will help them gain momentum towards full PoS implementation as well. We just have to wait and watch to see how it all works out.