Announcement | Ethereum Constantinople Upgrade Announcement

The Ethereum network will activate the planned upgrade at block 7,080,000 , which is expected to be Wednesday, January 16, 2019. The specific date may be postponed or advanced by 1 to 2 days due to fluctuations in block times during this period. The countdown can be seen on this website https://amberdata.io/blocks/7080000. You can also observe the network upgrade in real time on this website http://forkmon.ethdevops.io/.

What is Constantinople?

“Constantinople” is the code name for this network upgrade. Previously, there were code names such as “Spurious Dragon” and “Byzantium”.

As Ethereum users or holders, what should we do?

If you are using:

• Centralized exchanges (such as Coinbase, Karken, or Binance)

• Web wallet services (such as Metamask, MyCrypto or MyEtherWallet)

• Mobile wallet (such as Coinbase Wallet, Status.im, Trust Wallet or imToken)

• Hardware wallet (such as Ledger, Trezor or KeepKey)

You don’t need to do anything ! Unless you receive a notification from your exchange or wallet asking you to take additional steps (but this depends on the service you use, not the Ethereum chain).

I am running a full node/I am mining, can I just lie down and do nothing?

Please download the latest Ethereum client :

• The latest geth client (v1.8.20)

• The latest Parity client (v2.1.11-stable)

• The latest Harmony client (v2.3 Build 72)

• The latest Pantheon client (v0.8.3)

• The latest Trinity client (v0.1.0-alpha.20)

• The latest Ethereum Wallet/Mist (v0.11.1)

I am running a full node/I am mining, what if I don’t update?

If you have not updated to the latest version of the client mentioned above, after the upgrade is activated, your client will use the consensus rules before the fork to synchronize with other nodes that have not been updated and continue consensus (if there are still miners producing blocks there) . Since the consensus rules have changed and are incompatible with each other, clients that have not been updated will not be able to send transactions to the updated Ethereum network, but can only send transactions to the network that has not been updated.

What is a “network upgrade” for Ethereum?

Network upgrades are changes to the underlying Ethereum protocol, with the goal of adding new rules that enhance the system's functionality. The decentralized nature of the blockchain system means that upgrades are not as simple as updating an app on your phone. Network upgrades in the blockchain require coordination and communication from the entire community, including transactions between multiple Ethereum client developers, to make the upgrade go smoothly.

What does the network upgrade process look like?

Once the community agrees on what updates should be included in the upgrade, developers of Ethereum clients (such as geth, Parity, and Harmony) will write the relevant update code into the client software. These protocol updates will be activated after the specified block height. Nodes that have not updated to the latest rules will remain in the network before the update and continue to operate using the old consensus rules.

What updates are included in the Constantinople fork?

Updates included in network upgrades are labeled and referred to by EIPs. Ethereum Improvement Proposals (EIPs) describe some standards implemented for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. The following EIPs are updates included in the Constantinople upgrade:

EIP 145: Bitwise shifting instructions in the EVM

• Provides native bitwise move instructions at comparable cost to other arithmetic operations

• EVM currently has no bitwise shift instructions, but supports other logical and arithmetic operations. Bitwise shifts can be implemented using arithmetic operations, but this will have higher gas consumption and take more time to process. Using arithmetic operations, it takes 35 gas to implement SHL and SHR, but the native instructions provided by this proposal only consume 3 gas.

• In a nutshell: This EIP adds a native feature to the protocol that makes bitwise shift operations in the EVM cheaper and simpler.

EIP 1014: Skinny CREATE2

• Add a new opcode 0xf5 , which requires 4 stack arguments: endowment , memory_start , memory_length , salt . The specific performance is the same as CREATE, but use keccak256( 0xff ++ sender_address ++ salt ++ keccak256(init_code)))[12:] instead of keccak256(RLP(sender_address, nonce))[12:] as the contract initialization address.

• Broaden our scope of interaction: Some contracts do not exist on the chain yet, but it is certain that they can only contain code created by a specific part of init_code. With this EIP, we can interact with such contracts.

• Very important for state channels that involve conterfactual interactions with contracts.

• In short: This EIP allows you to interact with contracts that haven’t been created yet.

EIP 1052: EXTCODEHASH opcode

• This EIP specifies a new opcode that returns the keccak256 hash of a contract code.

• Many contracts need to check the bytecode of a contract, but do not need the bytecode itself. For example, a contract may want to check whether the bytecode of another contract is one of a set of possible implementations; or it may want to analyze the code of another contract and add all contracts that can pass the analysis (i.e., contracts whose bytecode matches) to a whitelist.

• Contracts can currently use the EXTCODECOPY opcode, but this opcode is relatively expensive in scenarios where only the hash is needed, especially for large contracts. A new opcode EXTCODEHASH will be implemented that will only return the keccak256 hash of a contract's bytecode.

• In a nutshell: This EIP will make related operations cheaper (consuming less Gas).

EIP 1283: Changes to the calculation of gas used by the SSTORE opcode

• This EIP proposes to change the net gas metering method of the SSTORE opcode to enable new uses of contract storage and reduce unnecessary gas consumption when the calculation method does not match most current implementations (Translator's note: because some operations are not required in most current implementations, but the original calculation method will also include the Gas required for these operations).

• In a nutshell: This EIP will make certain operations cheaper (requiring less Gas to complete the operation) and reduce the current "redundant" and expensive Gas consumption.

EIP 1234: Delaying the difficulty bomb and adjusting block rewards

• Average block times will continue to rise due to the accelerating difficulty bomb (also known as the "Ice Age"). This EIP proposes to delay the difficulty bomb by about 12 months and reduce the block reward (to accommodate the delayed Ice Age).

• In short: This EIP ensures that we don’t stop Ethereum from producing blocks until PoS is ready and implemented.

Thank you for your support!

Sincere thanks to the Ethereum community, developers of all Ethereum clients, and participants who gathered together through different platforms, invested their energy and contributed their ideas .

Special thanks to Reddit user “cartercarlson” for granting us permission to use his Reddit post (Editor’s note: the “Constantinople Update Summary” a few days ago); and the MyCrypto team for granting us permission to use their Medium article “Ethereum Constantinople: Everything You Need To Know”.

Disclaimer: This is an emerging, evolving, and highly technical field. If you choose to implement the recommendations in this article and continue to participate, please ensure that you fully understand the impact of these recommendations on you. You should understand the risks involved, including but not limited to unexpected code bugs. When choosing recommendations, please independently evaluate the risks of the results. This article and the recommendations contained in it are not an agreement to sell and do not constitute any warranty of any kind, including but not limited to warranties of the Ethereum network and Ethereum clients mentioned in this article.

Author: Hudson Jameson

Translation: Ajian