Ethereum Constantinople Upgrade Announcement
The Ethereum network will be undergoing a scheduled upgrade at block number 7,080,000, which is predicted to occur on Wednesday, January 16, 2019. The exact date is subject to change depending on block times between now and then and could be activated 1-2 days before or after. A countdown timer can be seen at https://amberdata.io/blocks/7080000. You can monitor the network upgrade in real time at http://forkmon.ethdevops.io/.What is Constantinople?
If you use an exchange (such as Coinbase, Kraken, or Binance), a web wallet service (such as Metamask, MyCrypto, or MyEtherWallet), a mobile wallet service (such as Coinbase Wallet, Status.im, or Trust Wallet), or a hardware wallet (such as Ledger, Trezor, or KeepKey) you do not need to do anything unless you are informed to take additional steps by your exchange or wallet service.As a node operator or miner, what do I need to do?
Download the latest version of your Ethereum client:
- Latest geth client (v1.8.20)
- Latest Parity client (v2.1.11-stable)
- Latest Harmony client (v2.3 Build 72)
- Latest Pantheon client (v0.8.3)
- Latest Trinity client (v0.1.0-alpha.20)
- Latest version of Ethereum Wallet/Mist (v0.11.1)
If you are using an Ethereum client that is not updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the upgrade occurs. You will be stuck on an incompatible chain following the old rules and you will be unable to send ether or operate on the post-upgrade Ethereum network.What is a network upgrade in Ethereum-land?
A network upgrade is a change to the underlying Ethereum protocol, creating new rules to improve the system. The decentralized nature of blockchain systems makes a network upgrade more difficult. Network upgrades in a blockchain require cooperation and communication with the community, as well as with the developers of the various Ethereum clients in order for the transition to go smoothly.What happens during a network upgrade?
After the community comes to an agreement concerning which changes should be included in the upgrade, changes to the protocol are written into the various Ethereum clients, such as geth, Parity, and Harmony. The protocol changes are activated at a specific block number. Any nodes that have not been upgraded to the new ruleset will be abandoned on the old chain where the previous rules continue to exist.What changes are going into Constantinople?
Changes that are implemented in Constantinople are defined using EIPs. Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. The following EIPs will be implemented in Constantinople.EIP 145: Bitwise shifting instructions in EVM
- Provides native bitwise shifting with cost on par with other arithmetic operations.
- EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time. Implementing SHL and SHR using arithmetics cost each 35 gas, while these proposed instructions take 3 gas.
- In short: This EIP adds native functionality to protocol so that it is cheaper & easier to do certain things on chain.
- Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using keccak256( 0xff ++ sender_address ++ salt ++ keccak256(init_code)))[12:] instead of keccak256(RLP(sender_address, nonce))[12:] as the address where the contract is initialized at.
- This allows interactions to be made with addresses that do not exist yet on-chain but can be relied on to only possibly contain code eventually that has been created by a particular piece of init code.
- Important for state-channel use cases that involve counterfactual interactions with contracts.
- In short: This EIP makes it so you can interact with addresses that have yet to be created.
- This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code.
- Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
- Contracts can presently do this using the EXTCODECOPY opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, a new opcode is being implemented called EXTCODEHASH which returns the keccak256 hash of a contract's bytecode.
- In short: This EIP makes it cheaper (less gas is needed) to do certain things on chain.
- This EIP proposes net gas metering changes for SSTORE opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn't match how most implementation works.
- In short: This EIP makes it cheaper (less gas is needed) to do certain things on chain, especially things that are currently "excessively" expensive.
- The average block times are increasing due to the difficulty bomb (also known as the "ice age") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards to adjust for the ice age delay.
- In short: This EIP make sure we don't freeze the blockchain before proof of stake is ready & implemented.
A big thanks to the Ethereum community, and to all Ethereum developers across all clients and platforms who came together to provide input, thoughts, and contribution. Special thanks to Reddit user cartercarlson who let us use his Reddit post and the MyCrypto team who let us use their "Ethereum Constantinople: Everything You Need To Know" Medium post.