Ethereum Constantinople Explained: What to Expect from The Upcoming Hard-Fork
Constantinople is the second part of Ethereum’s Metropolis. The first being Byzantium which was a successful hard fork in October. Constantinople, the sixth hard fork within the Ethereum ecosystem brings wit it fleeting changes in the underlying EVM(Ethereum Virtual Machine). It implements five new improvement proposals, one by Ethereum creator Vitalik Buterin himself.
Briefly detailed by the official Ethereum blog, a hard fork is:
…is a change to the underlying Ethereum protocol, creating new rules to improve the system. The protocol changes are activated at a specific block number. All Ethereum clients need to upgrade, otherwise they will be stuck on an incompatible chain following the old rules.
Slated to come into effect on block 7,080,000, Constantinople is a non-contentious hard fork, meaning there aren’t any foreseen issues with the proposed hard fork, which should come into effect roughly on January 16th.
Constantinople lays down the foundation for Ethereum’s transition towards Proof-Of-Stake from Proof-Of-Work. This includes changes such as the introduction of new OPCodes, delaying the difficulty bomb, and a reduction in mining reward from 3 ETH to 2 ETH. Apart from this, some of the EIPs(Ethereum Improvement Proposals) outline mechanisms to reduce gas consumption by optimizing several internal activities.
So how does this affect an everyday user? Well, if you are simply holding Ethereum you probably don’t need to do anything as such. On the other hand, miners, nodes, exchanges and other providers such as Infura will have to update their software
The first upgrade, Byzantium included nine improvement proposals.
Proposed Changes
The following are a list of EIP’s that Constantinople implements:
EIP 145 – The proposal introduces native bitwise shifting, given that the EVM(Ethereum Virtual Machine) doesn’t natively offer bitwise shifting operators. This makes things cheaper for a contract and for operations to be carried out easily by a host.
EIP 1014 – This proposal, authored by Vitalik himself outlines a mechanism for allowing interactions with an address that doesn’t exist on-chain as yet. Called ‘Skinny CREATE2’, it is said to be important for state channel use cases.
EIP 1052 – This proposal introduces an EXTCODEHASH OPCode which returns a hash of a contracts bytecode. Aimed at replacing the EXTCODECOPY Opcode which is expensive to use, this proposal is inclined towards saving gas.
EIP 1283 – Aimed at reducing gas consumed, it introduced a new means of gas metering on the SSTORE Opcode. The author also mentions that it enables new usages of contract storage.
EIP 1234 – Perhaps one of the most interesting proposals, EIP 1234 delays the difficulty bomb while reducing miner rewards to 2 ETH from the current 3 ETH. This is primarily because the intended switch to Proof-Of-Stake has been delayed. The drop in miner reward is in hopes of offsetting the difficulty bomb delay. Apart from this, it is also aimed at reducing the likelihood of a miner driven chain split as we approach the transition towards PoS, as detailed in the proposal . According to the specification, this EIP will delay the difficulty bomb, also known as ice age by 29 million seconds. This amounts to roughly 12 months. This also means that the average block time would double to 30 seconds by Winter 2019, as compared to the current 15 seconds. THis should essentially give developers necessary leeway to implement necessary changes required for a full transition toward PoS.
Overall, most of the EIPs focus on technical design related changes. They focus on optimizing interactions within the EVM and reduce overall gas consumption by a huge margin. For example, bitwise shifting would normally cost 35 gas. However, after constantinople, it should cosume a minimal 3 gas. This is a significant improvement, which indirectly aligns with Ethereum’s goal of making things user friendly and inexpensive. Apart from this, Constantinople also lays a solid foundation for the switch to PoS, sealing the Metropolis phase(the first hard fork for Metropolis was called Byzantium, and occured at Block 4,370,000 in October 2017)
Most of the Ethereum clients have implemented necessary changes to facilitate constantinople. This should ensure a smooth hard fork.
It is yet to be seen how Constantinople affects the Ethereum network. It may potentially reduce the cost of interacting with smart contracts. Apart from this, block time should remain the same(around 15 seconds)
It is important to note that the difficulty bomb has been delayed to facilitate PoS development. Eventually, a beacon chain and sharding chain will come into existence, which address scalability concerns surrounding Ethereum.
