The day is almost nigh, Ethereum’s 8th network upgrade is upon us.
The 8th Ethereum hard fork is set to happen on December 6th, 2019. For those who are not as familiar with the term
hard fork
, think of the process as a “network upgrade.” The exact date is subject to change due to variable block times and timezones. You can watch the
Istanbul Hard Fork Countdown Clock
on Etherscan.
Istanbul is one of the many hard forks of
that will take place before
.
Ethereum’s transition from its current proof of work consensus mechanism towards proof of stake consensus. The current fixed block number for the transition is:
Block Number: #9069000.
The expected date for the hard fork is Friday, December 6, 2019.
Istanbul Upgrades
Istanbul brings upgrades that will alter the cost of various opcodes to prevent spamming blocks and improve overall denial-of-service attack resilience. This upgrade will enable greater Ethereum and Zcash interoperability as well as with other Equihash-based proof of work cryptocurrencies. There will be various changes to opcodes (operation codes), which will also increase scalability performance for solutions based on zero-knowledge privacy technology like SNARKs and STARKs.
Accepted EIP’s
EIP’s are Ethereum Improvement Proposals that are debated and discussed before every Ethereum hard fork. Anyone can write an EIP and propose their improvement for the Ethereum network. In total 11 EIP’s were proposed for the Istanbul upgrade and six were selected for implementation.
Below are the EIP’s that were accepted for Istanbul:
: Adds Blake2 compression function F precompile. This EIP will enable the BLAKE2b hash function and other higher-round 64-bit BLAKE2 variants to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins.
: Reduce alt_bn128 precompile gas costs because elliptic curve arithmetic precompiles are currently overpriced. Re-pricing the precompiles would greatly assist a number of privacy solutions and scaling solutions on Ethereum.
: Currently, there is no specification for how chain ID is set for a particular network and instead relies on choices made manually by the client implementers and the chain community. This EIP proposes to use the chain ID to prevent replay attacks between different chains and it would be beneficial to have the same possibility inside smart contracts when handling signatures, especially in regards to Layer 2 signature schemes.
: The rapid growth of the Ethereum state has caused certain opcodes to be more resource-intensive than they were previously. Therefore, this EIP reprices certain opcodes, to obtain a good balance between gas expenditure and resource consumption.
: Calling on-chain data requires paying gas on the Ethereum network. Part of the EIP will reduce the gas cost from its current value of 68 gas per byte to 16 gas per byte which will help increase the bandwidth as more data can fit into a single block.
: Provides a structured definition of 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.
For Ethereum Users
If you hold or use ether with any of the following services, then there’s nothing you need to do:
Hold or transact ether through a mobile wallet like MetaMask or Coinbase Wallet
Hold ether on an exchange such as Coinbase, Binance, Kraken, etc.
Utilize a hardware wallet like Ledger or Trezor.
Some of these services may inform you to take additional actions such as your exchange, hardware device, or wallet service so just make sure you follow those if applicable.
For Node Runners
Ethereum is a decentralized, peer-to-peer network, so anyone who is currently running Ethereum infrastructure will need to update their software to an Ethereum client version that is “fork-ready,” and should do so before December 1st.
If you’re using
, then no changes are required. Infura is ready and there’s no action needed from you. Infura has been running reliable Ethereum infrastructure for over three years and have proven adept at handling large-scale updates during network hard forks. They’ll take care of the upgrade so you can continue building great software.
The following software versions are due for release in late September. If you “miss the fork” and fail to upgrade your software in time, you’ll no longer have an accurate view of the source of blockchain data. Missing the fork would require you to resynchronize your node with the Ethereum blockchain, which could take hours or even days.
How Nodes can get “fork-ready”:
Regularly check client pages for the software update announcement:
Review the fork updates to determine if any changes are needed in your applications, or if any users will be impacted.
Update your node prior to the fork block.
What’s Next?
There are a list of scheduled Ethereum hard forks after Istanbul as part of ETH 1.x which is the comprehensive set of upgrades to the Ethereum mainnet intended for near-term adoption.
More information about Ethereum 1.x and the team behind its continued improvements and upgrades can be found
and
.
You can read about the
(ETH 2.0) including all the phases to achieve proof of stake on Ethereum.
[embed]https://youtu.be/25sv6xLprU4[/embed]
The first phase of Serenity will see the rollout of the
which is a
blockchain and will mark the execution of the long-planned switched from proof of work to proof of stake consensus mechanism. The Beacon Chain will be stood up and will run alongside the original Ethereum PoW chain, ensuring there is no break in the continuity of the chains. Stay tuned for future posts about Ethereum network upgrades and the path to
.