With the Constantinople Hardfork, Ethereum will complete the transition into the Metropolis phase. We’ll take a look at what features have made it into the upgrade.
In mid-January, at block 7,080,000, Ethereum will activate the Constantinople Hardfork. This Hardfork is the second and final part of the Metropolis upgrade. The first ran under the title “Byzantine” and was activated on October 17, 2017. With Contantinople, Ethereum will finally move into the “Metropolis” phase. This is the last transition to Serenity, the final state of Ethereum.
As with all hardforks, users and businesses should upgrade their client in time to avoid accidentally ending up on the wrong chain. So look for an upgrade from Geth or Parity in early January if you have an Ethereum node.
Now we come to what Hardfork will activate for changes. Originally it was planned to make the transition to Proof of Stake with Metropolis. But this goal was (once again) postponed. Instead, Metropolis implements some rather small features that are by and large only of interest to technicians. The upgrades result in a month-long, if not year-long, discussion among developers and address several minor issues discovered in using Ethereum’s scripting language.
With Constantinople, the following upgrades are activated:
EIP 145: Bitwise shifting instructions in EVM
Bitwise shifting is an information technology operation in which the bits – ones or zeros – are taken individually from eight bits instead of as part of a byte and shifted one or more places to the right or left. For example, 00111100 becomes 01111000.
So far, Ethereum’s virtual machine has only enabled such bitwise shifting as a complex – and thus expensive – combination of other operations. With EIP145 it should now become a native command that causes the same gas costs as other native arithmetic operations.
What is this good for? On the one hand, Bitwise shifting completes the spectrum of operations of a smart contract. On the other hand, Bitwise shifting occurs in some cryptographic algorithms that can be implemented more easily in the Ethereum Smart Contracts.
EIP 1014: Skinny CREATE2
This EIP proposes a new, complementary code for the CREATE function that creates Smart Contracts. Instead of taking only three arguments from the stack as before, CREATE2 uses four arguments. Instead of a concrete address, CREATE2 uses a hash, which makes the change comparable to P2SH transactions at Bitcoin that are sent to a hash of a script instead of an address.
CREATE2 allows you to interact with addresses that do not yet exist on the Ethereum blockchain, removing a restriction on the previous CREATE function. Especially for state channels – Ethereum’s offchain solution, comparable to Lightning – this can be extremely helpful. In the discussion among the developers, EIP 1014 enjoys accordingly a large approval.
EIP 1052: EXTCODEHASH opcode
This EIP introduces a new code that represents the Keccak256 hash of the Smart Contract code. This helps other contracts to check its code without loading it themselves. This can be useful for several applications, such as Smart Contracts that only accept payments from certain other contracts, or Smart Contracts that maintain a kind of whitelist of other contracts verified as valid.
So far it is possible to perform this operation through a different opcode, but this is expensive, especially when larger smart contracts are involved. EIP 1052 also completes the opcode spectrum.
EIP 1283: Net gas metering for SSTORE without dirty maps
EIP 1283 introduces a new method for measuring gas consumption for the
EIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment
As with every Ethereum Hardfork, it also contains an EIP that defuses the Difficulty Bomb and prevents the ice age of the ever longer block interwalls from occurring. This is more or less a mechanism that drives the Ethereum community to agree on a harfork within a certain time window.
At the same time, this EIP also reduces the block reward for the miners. Instead of five so far, they will only receive two ETH per block in the future.