After long wait, Metropolis is finally here. Ethereum core developers have already succeeded the fork for Byzantium - The first Metropolis HF on the testnet a few weeks ago. The Ropsten test network underwent a hard fork on September 19, 2017 (UTC) at block number 1.7mil (1,700,000). A countdown timer can be seen at https://fork.codetract.io/.
The Ethereum network will be undergoing a planned hard fork at block number 4.37mil (4,370,000), which will likely occur between 12:00 UTC and 13:00 UTC on Monday, October 16, 2017.
New features include opcodes such as REVERT and RETURNDATACOPY, as well as precompiles that can be used to support a wide array of cryptographic algorithms.
To understand the phases of Metropolis as ELI5 (explain like I am 5) and other features being implemented in this HF, please read "Introduction to Byzantium and Constantinople".
As the time of hard fork is approaching, there are many questions with users that needs to be answered in order to achieve smooth transition. The Ethereum Foundation is very well taking care of users dilemma and publishing updates and information regularly regarding Byzantium Hard Fork .
What do I need to do?
If you are an Ethereum Blockchain user, download the latest version of your Ethereum client:
Latest version of Ethereum Wallet/Mist.
Latest geth client (v 1.7.1)
Latest Parity client (v 1.7.6)
Latest Harmony client (v 2.1.0)
If you are a web or mobile Ethereum wallet user,
using Ethereum websites and mobile applications that allow you to store ether and/or make transactions, no action required as they are running their own Ethereum client infrastructure to facilitate their services.
using a third-party web-based or mobile Ethereum wallet, your wallet provider may need to update for the hard fork. You can check with them to see if they are asking their users to take any action.
What happens if I do not participate in the hard fork?
If you are using an Ethereum client that is not updated for the upcoming hard fork, your client will sync to the pre-fork blockchain once the fork occurs. You will be stuck on an incompatible chain following the old rules, without replay protection against the main network. Old clients will be able to construct transactions, but will not be able to see the effects of those transactions.
Important Note for Dapp Developers
The way to detect failed transactions will change with Byzantium, even for contracts created before the Byzantium hard fork is enacted. After the fork, eth.getTransactionReceipt(…) will return a status field. The status field has a value of 0 when a transaction has failed and 1 when the transaction has succeeded. For more information, please see this post on the Ethereum StackExchange.
What if something goes wrong?
In the event that a critical bug is discovered, the Ethereum Foundation team will communicate via Ethereum Foundation blog and Ethereum Foundation Twitter account. Of course, EtherWorld.co is always there to facilitate the communication.
Casper PoC4 has been released. This includes an implementation of the fork choice rule, the Casper contract, and a complete pyethereum library, though not yet a full node that can connect to the network.
A “testing language” has been implemented that allows us to quickly implement tests for the Casper chain. This can also theoretically be used for the proof of work chain, and an extension to sharding is in progress.
Implementation of a proof of concept for sharding is in progress.
Implementation of the account redesign in the sharding PoC is in progress.
The Casper papers continue to be in progress.
The number of message types in Casper FFG has been reduced from 2 to 1, which will also simplify the incentive structure. A formal proof of the safety property has been written. This will be incorporated in PoC5.
The fork choice rule has also been simplified.
Pyethapp now supports python 3.
The “scalable light client data availability verification” note has been edited with an improved scheme
All Byzantium changes have been documented on pull-requests. The next issue to address is the treatment of the empty account states on precompiled contracts, where different clients do different things. A GitHub issue was created to discuss this.
Many improvements are to be seen in near future to Ethereum core code, Whisper, Swarm as well as Ethereum’s future scaling plans.
For news, technical blogs and project updates on Blockchain Technology, please join us at our Website, Facebook, Medium and follow us at Twitter. Please feel free to share this post, and email us your suggestions.