The planed upgrade of ethereum’s Proof of Work chain has been pushed back as Wei Tang of Parity Tech said:
“We need time till 6th September to finish the implementation. Not only because we accepted EIPs late but right now we just happened to be a large code base refactoring and we probably want to merge them first before merging Istanbul EIP.”
Devs were meant to pick a testnet block number on the Friday call this 23rd of August, but now they’ll have to wait for Parity to finish first and then pick a testnet number with Tang stating: “we need two weeks.”
The mainnet hardfork was estimated for October 4th, just before devcon, but now it might be in November depending on how Parity progresses and how the testnet progresses.
Geth, the client managed by the Ethereum Foundation (EF), has merged all Ethereum Improvement Proposals (EIP).
Some 76% of the network currently run Geth, while only 21% run Parity. The latter has finished only one EIP. Another one was worked on by a new contributor, but apparently it didn’t go anywhere, so it was closed. Another two are being worked on, with all this to be finished in two weeks.
There was also a technical discussion regarding the increase of gas costs for some actions or functions because it would apparently break some smart contracts that use a fixed gas amount in some special cases.
Martin Holst Swende, an EF dev, said “we know it’s going to break things, theoretically. All of those things can break a different way.”
So there was a discussion on whether devs should be breaking things with Tang stating:
“What I really worry is that this could be a potential PR disaster. So the issue is basically, if we broke some contracts and we are asked to unfreeze it, it could have a similar situation like the Parity Multisig.”
The Parity Multisig had a bug in the way the smart contract itself was coded, with that leading to 500,000 eth being frozen.
Here, if there is any problem it would be at the protocol level, so it would be different as there would be a bug in the ethereum network itself, if indeed there is one or one that isn’t a tradeoff of sorts. The tradeoff here being, according to the EIP:
“An imbalance between the price of an operation and the resource consumption (CPU time, memory etc) has several drawbacks:
It could be used for attacks, by filling blocks with underpriced operations which causes excessive block processing time.
Underpriced opcodes cause a skewed block gas limit, where sometimes blocks finish quickly but other blocks with similar gas use finish slowly.”
Apparently there could be some sort of bloat or spam attack with Swende stating: “Do we want to wait until the next round of Shanghai attacks which targets are cheap s loads before we do it another upgrade of that and at that time intentionally break those attacking contracts.”
Tang said: “There is a major difference between some attacking networks and we just fix it than having a future upgrades that breaks some non attacking contracts. These are really two different things.”
Tang however said he is fine with implementing it, but there is some sort of discussion about it.
That’s while there is no discussion about the difficulty bomb which will need to be delayed again around January or March next year because the Proof of Work (PoW) chain is not going anywhere soon.
So that might be in its own “upgrade,” with it unclear whether it will include an issuance reduction as well and/or whether it will be combined with the ProgPoW algorithmic change.
For this upgrade, there isn’t really a headline EIP, but there are some interesting proposals. The gas ones for example can increase a bit capacity due to improvements that can fit more within the gas limit.
Another interesting one is an EIP that “introduces a new precompiled contract which implements the compression function F used in the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM, and introducing more flexible cryptographic hash primitives to the EVM.”
Then another EIP re-prices precompiles so as to “greatly assist a number of privacy solutions and scaling solutions on Ethereum.”
Then there’s chain ID usable inside smart contracts to prevent replay attacks between different chains with it potentially being useful for second layers.
All this is to go live sometime in November by optimistic estimates, probably in January, and maybe even in March as last time.
The genesis block of ethereum 2.0 is to launch maybe in January, but this delay doesn’t affect that because it is different teams and because ethereum 2.0 is a brand new blockchain that kind of has nothing to do with the PoW chain.
Then there’s the eth1x work, but that’s not included in Istanbul or what might be Istanbul 2 at this stage.
Copyrights Trustnodes.com
