Istanbul upgrade is expected to be on Ethereum mainnet around December 5, 2019 at Block # 9,069,000.
Next All core Dev call: Friday, November 29, 2019. Stay tuned!!(Nov 15, 2019)
- Most of the clients are ready with block number added.
- Harmony J will not be a part of Istanbul. It is discontinuing supporting Eth1.x and would continue to build on Eth 2.0. Anyone interested to maintain the repo may reach the team on EthereumJ Gitter, updated Mikhail Kalinin.
- Ethernode looking for help to get updated.
- Upgrade your node with latest upgrade of respective clients. ~16% of nodes have updated so far.
____________________________________________________________________________________________________(Nov 1, 2019)
- Mainnet upgrade around Dec 05, 2019.
- Block # 9,069,000.
A discussion around EIP Centric upgrade.
____________________________________________________________________________________________________(Oct 25, 2019)
- Mainnet upgrade date: Dec 4, 2019.
- Block number will be decided soon.
- James Hancock is new HF coordinator for Ethereum upgrade.
- EIP 2124: Minor adjustment to be done by Peter (Geth) based on Piper Merriam suggestions and then will proceed.
- Networking protocol is least visited, need more love from community.
- Eth 64 proposal will be open for all.
- James will write a blog on upcoming IceAge.
____________________________________________________________________________________________________(Oct 04, 2019)
Ropsten testnet Report
As reported in Ethereum Core Devs Meeting 72 Notes, Péter Szilágyi provided a summary of what happened in Ropsten Testnet for Istanbul.
"Ropsten fork came 2 days earlier than expected. It was a surprise, but it turn that somebody is mining Ropsten with about 1.5 Giga Hashes. Some of these pushing was really hard. It came a little early that scared us because it looked like the fork failed. Then it turn out that the fork did succeed. The problem was this miner who was pushing with 1.6 Giga Hashes Ropsten, is actually pushing the non forked chain. So we have a huge miner on non Istanbul currently. For past couple of days we've spent trying to figure out what happening in Ropsten because the network currently is really unhealthy. It boils out to the fact that most people did not upgrade yet, so most of the nodes are non-Istanbul nodes. Since there are really heavy non-Istanbul chain, it makes upgraded nodes minority; thats quite annoying to upgrade currently. It did surface a few issues. Currently, what's happening are non upgraded Istanbul nodes are eclipsing the upgraded one."
"Even though Ropsten fork currently was a bit of a shit show there are really no worries that a similar thing might happen for mainnet. " - Péter Szilágyi
Gorli and Rinkeby testnet Report
Gorli and Rinkeby are completly immune to the issue that happened to Ropsten because they are Proof of Authority testnets. In that, only majority chain can progress. So, either you have non upgraded chain or you have an updated Istanbul chain progressing, but you cannot have two concurrent one. The Cat Herders will reach out to the Gorli team for further update.
Ice Age EIP will not be included in Istanbul. It seems like there's no major reason to do it now. Based on James calculations, it should give well enough time to plan for another fork and not delay Istanbul.
EIP 2124: Fork ID
Geth team has a proposal for Ropsten's issue that was faced during Istanbul testnet.
Peter explained, "the reason Ropsten is having a hard time doing anything is because the pool of forked nodes and the pool of non forked nodes have no idea whether peer is forked or not in advance. The only thing, currently they can do is try to advertise each other's for chains to blocks to each other and they download it from each other and then they realize that okay, something deep something deep down is not compatible or some block is invalid.
The problem is that if we don't do anything to somehow separate peers from each other at the more lower level, at the networking level; then it just puts a really nasty strain on the whole block processing, block validation everything. "
Proposed solution is in EIP 2124 which was already accepetd long back.
"So, when two peers do a handshake with each other currently, they exchange the genesis block, the hash of the genesis block. The problem is that this one cannot detect if two peers share the same genesis block but then forked away from each other. Kind of like Ethereum and Ethereum Classic or Ropsten or Istanbul etc.
The idea was that instead of exchanging the hash of the genesis block, we should exchange something else that contains both the Genesis hash but also all the old forks somehow mashed together; the idea of Fork ID, which is just to check some of the genesis hash along with all the fork block numbers and the proposal.
Core Devs decided to go ahead with the proposed EIP. Bring objections to AllCoreDevs in 2 weeks if anyone have anything opposing to Geth team defining Eth 64 as Fork ID thing and rolling it out.
____________________________________________________________________________________________________(Sep 06, 2019)
- All clients implemented all EIPs. Some more discussion around EIP-152 (Blake 2b) is continued.
- Cat Herders will write a blog about EIP-1884/SLOAD issues and concerns. It is also being discussed at Eth Magician.
- Istanbul will be on Testnet around October 2nd, 2019 depending on the block number.
- Mainnet HF date not decided yet.
____________________________________________________________________________________________________(Aug 27, 2019)
Hardfork Meta: Istabul
- EIP-152: Add Blake2 compression function
- EIP-1108: Reduce alt_bn128 precompile gas costs
- EIP-1344: Add ChainID opcode
- EIP-1884: Repricing for trie-size-dependent opcodes
- EIP-2028: Calldata gas cost reduction
- EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change
- Client status can be tracked here.
Read more article about Istanbul here
Next announced Ethereum upgrade is Berlin
____________________________________________________________________________________________________ Disclaimer: This is not an investment advice and should NOT be viewed as project endorsement by EtherWorld. Readers are suggested to do their research before investing into any project.
Disclaimer: This is not an investment advice and should NOT be viewed as project endorsement by EtherWorld. Readers are suggested to do their research before investing into any project.