The key points of Ethereum's next fork are enough to read this article

In the past two weeks, due to the large number of Ethereum core developers going to Toronto to attend the Ethereum scaling conference, the weekly conference call was forced to be cancelled. This Friday night, the Ethereum core developers will continue to hold a conference call, the topic will focus on the Istanbul hard fork and decide on the final selected proposal (EIP).

From a design perspective, the Istanbul hard fork is the last fork of Ethereum towards the Serenity stage (no new tokens will be generated). At the same time, the proposal for this fork involves many issues (Progpow, state leasing, chainID, etc.). If some issues are not resolved in this fork, it will have a significant impact on the subsequent development of the Ethereum ecosystem. According to Ethereum 2.0 researcher Justin Drake, Ethereum 2.0 Phase 0 will be released on January 3, 2020.

Postponing ProgPoW and focusing on “state leasing”

On the 17th of last month, the Istanbul Hard Fork Proposal (EIP) solicitation ended, with a total of 29 proposals collected. These proposals are:

• EIP-615: Subroutines and static jumps for the EVM

• EIP-663: Unrestricted SWAP and DUP instructions

• EIP-1057: ProgPoW, a programmatic proof of work

• EIP-1108: Reduce alt_bn128 precompile gas cost

• EIP-1109: PRECOMPILEDCALL opcode (removes fees for precompiled contracts)

• EIP-1283: No dirty maps, measure the net gas cost of SSTORE

• EIP-1344: Add ChainID opcode

• EIP-1352: Specify restricted address ranges for precompiled/system contracts

• EIP-1380: Reduce gas costs for self-calls

• EIP-1559: Changing ETH 1.0 chain gas fees

• EIP-1965: A method to check if a chainID is valid at a specific block number

• EIP-1702: Generalized Account Versioning Scheme

• EIP-1706: Disable SSTORE when gas fees are low

• EIP-1803: Rename opcodes

• EIP-1829: Precompile for Elliptic Curve Linear Combinations

• EIP-1884: Redefine trie-size dependent opcodes

• EIP-1930: Gas call standards are tightened so that calls can be recovered if there is not enough gas.

• EIP-1985: Reasonable limits for certain EVM parameters

• EIP-1959: New opcode, check if chainID is part of chainID history

• EIP-1962: EC arithmetic and pairing with runtime definitions (supersedes EIP-1829)

• EIP-2014: Extended State Oracle

• EIP-2026: State Lease H - Fixed Account Prepayment

• EIP-2027: State Lease C - Calculating Net Contract Size

• EIP-2028: Reduce Calldata Gas Costs

• EIP-2029: State Lease A - State Counter Contract

• EIP-2031: State Lease B — Net Transaction Counter

• EIP-2035: Stateless Clients - Repricing SLOAD and SSTORE to Pay for Block Proofs

• EIP-2045: Gas cost for EVM opcode particles

• EIP-2046: Reduce gas costs for static calls to precompiled programs

The proposal that was temporarily approved in the previous core developer conference call was EIP 1108 , which proposed a minor change to the gas fee of the Ethereum network. However, the developers emphasized that although the proposal was approved, it would need to submit benchmark data at a subsequent core developer meeting.

In addition, the much-anticipated proposal EIP-1057, which proposes an improved PoW algorithm called "Progressive PoW" or ProgPoW, may be delayed. EIP 1057 proposes an improved PoW algorithm called "Progressive PoW" or ProgPoW, which is designed to better utilize GPU-specific computing capabilities.

Previously, developers raised 50,000 DAI (about $50,000) through crowdfunding on the open source bounty platform Gitcoin as funds for ProgPoW code auditing. However, since the code has not yet found a third-party agency to audit it, it was postponed at the developer meeting on May 24.

Also delayed is EIP-1559, a proposal that aims to change the Ethereum transaction fee model but was "abandoned" by developers because it was too complicated.

Among these proposals, "state leasing" stands out.

The original intention of the design of "state rental" is that the current state size of Ethereum is already very large. If it continues to grow at the current rate, the Ethereum network will become extremely bloated. We are underestimating the long-term cost of storage, which can be approximately modeled as: bytes*time. Therefore, it is necessary to change the current state design of Ethereum.

According to the Ethereum 2.0 roadmap, state leasing will also be deployed in ETH 2.0 (currently planned to be in Phase 2). Whether or not to redevelop ETH 1.0 will be a hot topic of discussion in this Friday's conference call.

Deletion proposal

The above proposals have also sparked widespread discussion in the community, with many developers questioning whether some of the proposals are repetitive and should be deleted.

Developer Alex Beregszaszi said: “I am confused. I think those who propose conflicting, adjacent, duplicate EIPs (there are 3 or 4 EIPs about chainid, repricing, SWAP and DUP) should reach some consensus before proposing them again. If they don’t have clear regulations, then there is no point in arguing about EIPs.”

So far, only a small part of the proposal audit process has been carried out, and it remains to be seen whether the core developers can give a final answer this Friday.

Alex believes that some proposals do not actually need to be carried out in a hard fork, and can be resolved by contacting Ethereum client developers. "Those (EIP) authors should not just try to solve it themselves, but contact some relevant developers, such as client developers, to review their ideas. If everyone waits for the core developers to hold a conference call to discuss implementation, we will not have enough time to discuss all these proposals."

Regarding the above EIP, the developer community (click to enter) is currently discussing reductions to reduce the workload of core developers and improve efficiency.

Hard Fork Schedule

In addition to paying attention to the proposals, the timing of the Istanbul hard fork is also worth paying attention to.

According to the timeline set by former hard fork coordinator Afri Schoedon (who has since left), the hard fork process is broken down into “a fixed 9-month cycle.” The Istanbul hard fork timeline is as follows:

• 2019-05-17 (Friday): Deadline for acceptance of Istanbul proposals

• 2019-07-19 (Friday): Deadline for major client implementations

• 2019-08-14 (Wednesday): Testnet (Ropsten, Gorli or ad hoc testnet) upgrade time

• 2019-10-16 (Wednesday): Mainnet upgrade time (“Istanbul”)

The first phase of proposal collection has been completed, and the next step is the "main client implementation". The so-called "main client implementation" is to merge the accepted EPI into the existing Ethereum client. This step is similar to combining the code together so that it can be fully tested.

However, according to Ethereum’s usual tone, the possibility of this hard fork being completed “on time” is not high. In the previous Constantinople fork, a code vulnerability occurred, which led to the delay of the fork.

Alexey Akhunov, a grantee at the Ethereum Foundation, said in a Gitter chatroom that everyone should think about “deadlines” and not deadlines for the sake of deadlines. Everything should be based on doing a good job.

“I myself was thinking what is the purpose of this deadline?” Akhunov said. “Because this is the first time so many things are being introduced (in a fork), so we are here to make sure that what we are doing is for a reason and not because ‘someone said so.’”

Author | Qin Xiaofeng

Editor | Lu Xiaoming

Produced by | Odaily Planet Daily