Parity implements EIP delay, Ethereum Istanbul upgrade or postponed until November

According to Trustnodes.com on August 28th, Wei Tang of Parity Tech said that the Ethereum Istanbul hard fork upgrade plan has been postponed. He said:

We expect to complete the client implementation by September 6. Not only because we accepted the Ethereum Improvement Protocol (EIP) late, but we happen to be working on a large-scale codebase refactoring, so we hope to merge the refactored code first and then merge the Essaba EIP.

The developers had planned to upgrade the number of blocks in the test network on the conference call on August 23, but now they must wait for the implementation of Parity, Tang said:

We need two weeks.

• Market Analysis: Falling as expected, risk control is the number one priority
• Mysterious predictions hit one after another, is BTC rushing to $56,000 according to the script?
• Four forces compete for blockchain + supply chain finance. What can a pure technology company rely on to obtain a market?

The hard fork upgrade of the Ethereum main network was originally scheduled to take place on October 4, but it is now postponed to November. Currently, the client Goth managed by the Ethereum Foundation (EF) has merged all EIPs.

Ethereum client merges Istanbul EIP progress, August 2019

The percentage of clients running Geth in the Ethereum network is about 76%, while only 21% running Parity. The latter only completed the merger of one EIP; another EIP merger was completed by a new contributor, but it is clear that it has not progressed, so it was closed; there are two EIP mergers In progress, all EIP mergers will be completed within two weeks.

Discussion on changing the cost of gas

In addition, a technical discussion on the upgrade of Istanbul involves increasing the cost of gas for certain activities or functions in the chain, as this obviously undermines the use of smart contracts with a fixed amount of gas in certain special circumstances.

Martin Holst Swende, developer of the Ethereum Foundation, said:

We know that in theory, this will break the original situation.

Tang said:

What I really worry about is that this could be a potential public relations disaster. The problem now is that if we break some contracts and unfreeze them, this might happen like Parity multiple signatures.

Previously, due to the vulnerability of Parity's multi-signature in the coding of smart contracts, about 500,000 Ethereums were frozen.

The problem with Parity is at the protocol level, which is not the same as the vulnerability in the Ethereum network, which requires various mechanisms to weigh. According to EIP:

There are several disadvantages to the price of an operation and the imbalance between its consumed resources (CPU time, memory, etc.):

It can be used for attacks, filling blocks by using underpriced operations, resulting in longer block processing times.

Low-cost opcodes can cause the amount of gas used in the block to be unstable. Sometimes the block processing time is short, and sometimes the same amount of gas can be used for longer processing times. In addition, this may also invite some form of spam attack, Swende said:

Do we still want to wait until the next round of attacks against cheap loads, and then upgrade this and deliberately destroy the contracted ones?

In this regard, Tang said:

There is a big difference between different attack networks. We just fix the attacked contract instead of upgrading it in the future, and then destroy some unattacked contracts. This is totally different.

There was no discussion of difficulty bombs in this conference call, and it will be postponed again in January or March next year.

EIP involved in the upgrade of Istanbul

This Istanbul upgrade does not have a really heavy EIP, but there are several EIPs that are very interesting. For example, an EIP involving gas can be improved to eventually increase the block size.

Another interesting EIP, which "brings a new pre-compiled contract, implements a compression function in the BLAKE2b cryptographic hash algorithm, which aims to improve the blockchain between Zcash and the Ethereum Smart Contract Virtual Machine (EVM). Interoperability and the introduction of more flexible cryptographic hash primitives into the Ethereum smart contract virtual machine."

In addition, there is an EIP that re-compiles the pre-compilation to "maximize the help of some privacy solutions and extension solutions in Ethereum."

Finally, by using the Chain ID in smart contracts, replay attacks between different chains can be prevented, which may help Ethereum's Layer 2 network.

It is optimistic that all of this will be achieved in November, and of course it may be postponed until January, or even March, just like the last hard fork upgrade of Ethereum.

The creation module of Ethereum 2.0 may be released in January, and the above upgrade delay will not affect its release because they are two different teams. At the same time, Ethereum 2.0 is a brand new blockchain that will not use a consensus mechanism for proof of workload.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!