What the Fork?! A Look At Ethereum’s Constantinople Fork thus far

By: Jesse AbramowitzBlockchain Developer

If you haven’t heard, this week has been intense for any Ethereum Core developer. With the entire blockchain community buzzing about Ethereum’s latest fork Constantinople, it has unfortunately been postponed for very, very valid reasons.

I’d like to commend the amazing work to all of the developers for recognizing the situation and losing a lot of sleep to fix it.

To date, I haven’t been able to find any updates following the Ethereum developers call so I figured that it would be good idea to provide an outline of what has happened thus far. I know that a lot of people are curious about this so I figured this article would help make their lives easier too.

Let’s dive right in!

The Fork

Ethereum is constantly updating, as most blockchains do. This is accomplished through a fork — where the blockchain is copied at a certain point to a new chain with the protocol updates and the old chain “dies”. Or if it is contentious lives and becomes two currencies to battle it out.

More information about forks can be found here and about past forks here.

Constantinople

Istanbul, or Turkish Istanbul was formerly known as Constantinople. It was one of the largest ancient cities of the Byzantine and Ottoman Empires. According to the Encyclopedia Britannica, for over 2,500 years, it was the major bridge between Europe and Asia and stood between conflicting surges of religion, culture and imperial power. Constantinople was and is still considered one of the most coveted cities in the world…

Although the real Constantinople has no relation to the Ethereum fork, it’s still interesting to understand its etymology and its importance on the Ethereum Network.

This article does a great job explaining everything you need to know about the Constantinople fork.

What Happened So Far

There is a lot of money on the line when dealing with blockchains so all forks are tested out rigorously.

First, they test it on a Ropsten testnet which caused some delays to the original fork.

Then they forked it on Rinkby testnet on January 9th.

After the fork, ChainSecurity released this article showing that changes in the gas price of certain operations leave contracts vulnerable to re-entrancy attacks. ChainSecurity determined that the code is vulnerable in an unexpected way because it simulates a secure treasury sharing service where Two parties can jointly receive funds, decide on how to split them, and receive a payout if they agree*.

An attacker will create such a pair with where the first address is the attacker contract listed below and the second address is any attacker account. For this pair the attacker will deposit some money.

Not good.

Fixes

There are some really good fixes have been discussed here on this thread and talked about at length during the Ethereum Core Developers call on January 18th.

Difficulty Bomb

Before going any further, we need to understand what the difficulty bomb is and why it was so important that a fork happens immediately. In decentralized systems, changes can be hard and may take a while.

To avoid impending delays the Difficulty Bomb was introduced.

At a certain point, the Bomb will increase the hash difficulty of the Ethereum chain mining blocks slower. This is why it needs to be delayed by a fork every so often facilitating the need for forks.

On the Ethereum Developer Call, Lane Retting, an Ethereum core developer, said he ran some scripts and the difficulty bomb is set to reduce block times to 30 seconds by late April and is currently slowing block times (very slightly).

This means that the fork has to happen soon.

Date of new Fork

The final decision was to remove the EIP 1283 from the fork and push the fork back 6 weeks. The block number of the new fork is 7.28 million on Feburary 27th.

Fork implementation

This is where it gets interesting. We know both Ropsten and Rinkby have been updated. The new fork will be removing the flawed EIP 1283. This means that both Ropsten and Rinkby would either have the security risk going forward and be a less true representation of the Ethereum Network OR they would have to rollback the blocks since the fork and re-implement the new fork.

This, of course, would give a lot of developers a lot of stress.

If not handled correctly, this would destroy two test networks.

On the call, Peter Szilagyi proposed that there should be two forks on the Ethereum network both happening at the same time: First, the original Constantinople, and next, a second, fixed version where they remove the EIP. This will have no difference on the Mainnet but it will save Rinkby and Ropsten.

The Problem

The Solution

This way, they can just run the second fork, and thus be an accurate simulation of Ethereum again (The Devs decided to temporarily call this second fork Constanti_Nope_). There are no block rollbacks needed. As well, it will make testing easier as they can implement the second fork almost immediately on the two test chains.

Conclusion

Forks are hard but they need to happen. Ethereum is very lucky that has so many amazing developers dedicating their lives to it that they were able to catch a bug fix it and move on with the originally planned fork.

What do you think about the Constantinople Fork? Let us know in the comments below!

Update: The second Fork is now being called Petersburg.

Jesse Abramowitz is a Blockchain Developer at BlockX Labs. He has worked on multiple DApps, projects, and Blockchain Networks. Currently, he is also a lab assistant at a local college and is always looking to help, teach and build on the blockchain.

You can reach him at: [email protected]