In this article we will shortly describe the upcoming Constantinople update, with the focus on Create2 – a contentious protocol that may have as many advantages as vulnerabilities.
What is Constantinople?
Constantinople is a hard fork, that is “a permanent divergence from the previous version of the blockchain”. As the newer version will not accept nodes running the previous version (hard forks are not backward compatible), nodes and miners will need to update their software. It is a non-contentious hard fork, which means that the majority of the community agrees to it and no second fork will be created (contrary to what happened for example a few years ago with Ethereum and Ethereum Classic).
Constantinople is the second part of the Metropolis update (the first was Byzantium, implemented in October 2017). It is the next step of Ethereum’s journey towards its final stage, Serenity, with a Proof-of-Stake (PoS) protocol. You can read more about Ethereum’s Roadmap here.
Constantinople was originally scheduled to happen mid January 2019. However, security vulnerabilities that may allow for a reentrancy attack have been discovered (easy explanation of the situation here), and it was decided that the fork should be delayed. It is now scheduled to happen on the 27th of February, 2019.
It will include several EIPs (Ethereum Improvement Protocols):
- EIP-145: easy Bitwise shifting in the Ethereum Virtual machine (EVM; runtime environment for smart contracts in Ethereum). This proposal is quite technical (understable explanation here), but all you need to know about it is that it will make certain things on a smart contract much cheaper
- EIP-1052: Smart contract verification; it will save developers money by allowing to check only the most relevant contract data, rather than the whole code.
- EIP-1283: deals with some of the issues with gas (transaction fee paid in ether). It will enable new usages for contract storage, as well as reduce excessive gas costs.
- EIP-1234: related to Ethereum’s transition from Proof-of-Work (PoW) which relies on computational power needed for mining, to Proof-of-Stake (PoS), which relies on stakes (number of tokens held) of individual participants. This proposal also delays the “difficulty bomb” (rate of how difficult it is to add a new block) by 12 months and reduces block rewards from 3 to 2 ETH. We will talk more about this proposal later.
- EIP-1014: proposed by Ethereum’s founder Vitalik Buterin, this proposal aims to leverage state channels and improve scalability. It is the focus of this article, and is explained in more detailed below
If you prefer watching, here’s a short, beginner-friendly video on the Constantinople update (doesn’t cover EIP-1283 as it was added after the video was released):
The point of concern relates to the new proposed smart contract function, called Create2.
This function leverages state channels – an innovative way of allowing users to interact (transact) off-chain, instead of having to do everything on the blockchain. This will have significant implications for the scalability of the network, as transaction times will get lower, and users won’t have to wait for miners to confirm every transaction. You may think of state channels as Ethereum’s lightning network (Bitcoin’s peer-to-peer payment channel). However, while the latter deals only with payments, state channels have no such restrictions. Instead, most interactions can be conducted off-chain (updated after every transaction, but not moved to the blockchain yet), as long as they happen between a certain set of users and they happen within a certain timeframe. Blockchain is then used solely for settlement and dispute resolution. You can watch a short explanation video on state channels below.
Back to the issue at hand: designated as EIP-1014, Create2 will allow interactions to be made with addresses that do not exist yet on-chain. This is significant in the context of counterfactual instantiation, where a smart contract object is created inside of a state channel. Instead of deploying a contract, a commitment is signed. Contracts get deployed in case of a dispute.
Create2 will be important for scaling, as it will allow transaction results to be simulated off-chain. By allowing users to transact off-chain, Create2 also works to remove the friction of onboarding new users.
What do developers think?
During the latest core devs meeting several points were made relating to Create2. Jason Carver noted that many developers may not be fully aware of the possibilities of the upcoming functions, for example that Create2 will allow contracts to be redeployed after self-destruct. This may lead to an issue. Because Create2 doesn’t use a nonce with address generation, the destroyed contract could theoretically be replaced with a malicious one (one might deploy a contract, get people to send money, use self-destruct function, replace the contract with a malicious one that sends the funds to the perpetrator). Jason initially argued for the removal of EIP-1014, but since it’s here to stay, he is now focused on spreading information and educating the community. He writes about the good, the quirky, and the ugly of Create2 in this Medium post.
During the meeting, Jeff Coleman expressed that nobody should be using self-destruct now, and later added that if Create2 becomes a standard, then the self-destruct function can be abandoned and the idea of a contract nonce can be thrown out . He also underlined the importance of init codes: people need to be aware that init codes are part of auditing. He also mentioned a counterintuitive aspect of Create2, namely that, theoretically, redeployments can change the contract bytecode as the address is only committed to the init code. Coleman also noted that the problem lies with non-deterministic init codes.
You can listen to the whole meeting below. The discussion on Create2 takes place between 5:55 and 17:30.
Although there may be some issues with Create2, many developers see the new function as a much needed improvement. For example, developer James May says that although Create2 was “intended as a scalability solution, it is also a usability feature in disguise and a sleeper game-changer.”
For a detailed, much more technical discussion around Create2, mainly between Rajeev Gopalakrishna (an independent Ethereum and cybersecurity researcher) and a few developers (for example, core dev Jason Carver), you can check out this post on Ethereum Magicians.
Isn’t it a big deal?
Yes. And if you’re surprised that you haven’t more about it, you’re not the only one.
You may have not heard much about Create2, despite its potential and possible issues it poses. It’s interesting, as usually anything to do with improved scalability gets a lot of attention. The relatively low coverage of Create2 may be due to the fact that it is not the most contested upgrade of Constantinople. The mantle belongs to EIP-1234, which introduces two major changes. Firstly, it will delay the “difficulty bomb” by 12 months. Ethereum developers can choose and adjust how difficult is it for miners to add a block, and the “difficulty bomb” is meant to incentivise miners to switch from PoW to PoS. However, as Casper (Ethereum’s future PoS protocol) is not being implemented yet, there is no need for the “bomb” to happen now. Secondly, it will change the protocol economics by reducing block rewards from 3 to 2 ETH. This will constitute a 33% drop, and hence is sometimes called “the Thirdening”. It will reduce Ethereum’s inflation rate. While some may argue that this will discourage miners from the network, as this post explains, miners behaviour after the 27th February will depend on the price of electricity and ETH, as well as hashrate and difficulty.
The Constantinople hard fork has significant potential in terms of improved efficiency (EIP-145), speed (EIP-145, EIP-1052), scalability (EIP-1014), economics (lower inflation rate thanks to EIP-1234), and reduced costs (EIP-1283). It is the next step in Ethereum’s development towards Serenity and Proof-of-Stake.
As a final note, it might be useful to ask: will the Constantinople update affect me? Probably not. If you’re a user of Ethereum, but not a miner or node operator, you don’t have to do anything after the fork.