Ethereum's next fork focus, see this is enough

In the past two weeks, a weekly conference call was cancelled due to the numerous Ethereum core developers who went to Toronto to attend the Ethereum scaling conference. On the 5th night of this week, Ethereum core developers will continue to hold a conference call, focusing on the hard-forward fork around Istanbul and deciding on the final proposal (EIP).

From a design perspective, Istanbul hard forks Ethereum will move towards the final fork of the Serenity stage (no new tokens will be produced). At the same time, the proposal for this fork involves a lot of problems (Progpow, state lease, chainID, etc.). If some problems are not resolved in this fork, it will have a significant impact on the subsequent ecological development of Ethereum. According to Ethereum 2.0 researcher Justin Drake , Ethereum 2.0 Phase 0 will be released on January 3, 2020.

Postpone ProgPoW and focus on "state rental"

On the 17th of last month, the Istanbul Solid Bifurcation Proposal (EIP) was closed and 29 proposals were collected. These proposals are:

• Facebook's "currency" A-share blockchain concept stocks are red and multi-party questioning Libra is a big risk
• How does Ma Huateng see Facebook to release digital currency?
• Is BTC the ninth largest "currency" in the world?

• EIP-615 : EVM subroutine and static jump
• EIP-663 : Unrestricted SWAP and DUP commands
• EIP-1057 : ProgPoW, a programmatic proof of work
• EIP-1108 : Reduce alt_bn128 pre-compiled gas cost
• EIP-1109 : PRECOMPILEDCALL opcode (deleting the cost of the pre-compiled contract)
• EIP-1283 : No dirty maps, measuring the net gas cost of SSTORE
• EIP-1344 : Add ChainID opcode
• EIP-1352 : Specify a restricted address range for precompilation/system contracts
• EIP-1380 : Reduce the cost of self-calling gas
• EIP-1559 : Change ETH 1.0 chain gas cost
• EIP-1965 : How to check if the chainID is valid at a specific block number
• EIP-1702 : Generalized Account Version Control Scheme
• EIP-1706 : Disable SSTORE when gas costs are low
• EIP-1803 : Rename the opcode
• EIP-1829 : Precompilation of Elliptic Curve Linear Combinations
• EIP-1884 : Redefine opcodes that depend on trie-size
• EIP-1930 : The Gas call standard is strict and can be restored if there are not enough gas calls.
• 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 definition (replaces EIP-1829)
• EIP-2014 : Extended State Oracle
• EIP-2026 : Status Leasing H – Fixed Account Advance
• EIP-2027 : Status Leasing C – Accounting Net Contract Size
• EIP-2028 : Reduce the cost of Calldata Gas
• EIP-2029 : Status Leasing A – Status Counter Contract
• EIP-2031 : Status Leasing B–Net Trading Counter
• EIP-2035 : Stateless Client – Repricing SLOAD and SSTORE to Pay Block Certificate
• EIP-2045 : Gas cost of EVM opcode particles
• EIP-2046 : Reduce the cost of gas for static calls to precompiled programs

Previous core developer conference calls, the provisionally approved proposal was EIP 1108 – a minor change to the cost of the Ethereum network's Gas was proposed. However, the developer emphasized that although the proposal was approved, it would need to submit baseline data at a later core developer meeting.

In addition, the highly anticipated proposal EIP-1057 may be postponed. EIP 1057 proposes an improved PoW algorithm, called "progressive PoW" or ProgPoW, designed to make better use of GPU-specific computing functions.

Previously, developers raised 50,000 DAI (about $50,000) through crowdfunding platform Gitcoin to fund the ProgPoW code audit. However, since the code has not yet found a third-party agency to audit, it was announced to be postponed at the developer conference on May 24.

Also delayed is EIP-1559 , which aims to change the Ethereum transaction fee model, but because it is too complicated, developers are “abandoned”.

In these proposals, "state leasing" is particularly dazzling.

The original intention of "state lease" is that the size of Ethereum is already very large. If it continues to grow at the current rate, the Ethereum network will become extremely bloated. While we are underestimating the long-term cost of storage, storage costs can be modeled approximately as: byte*time, so it is necessary to make changes to the current Ethereum state design.

According to the Ethereum 2.0 roadmap, state leases will also be deployed at ETH 2.0 (currently planned for Phase 2). Whether or not to re-use time and effort in ETH1.0, I believe it will become a hot topic of discussion on this Friday's conference call.

Reduction proposal

The above proposals have also been widely discussed in the community. Many developers have questioned that some of the proposals are duplicated and should be deleted.

Developer Alex Beregszaszi said: "I am confused. I think those proposals that propose conflicting, adjacent, and duplicate EIPs (three to four EIPs are all about chainid, repricing, SWAP, and DUP) should be raised again. Some consensus has been reached before. If they are not clearly defined, then there is no point in arguing about EIP."

Until now, the proposal audit process has only been carried out for a short period of time, and whether the core developers can give the final answer this Friday is still pending.

Alex believes that some proposals do not need to be done in hard forks, you can contact Ethereum client developers to solve. "Those (EIP) authors shouldn't just try to solve it themselves, but rather contact some relevant developers, such as client developers, to review their ideas. If everyone waits for the core developer to hold a conference call to discuss implementation, We will not have enough time to discuss all of these proposals."

For the EIP above, the developer community (click to enter) is currently being discussed for reductions to reduce core developer workload and increase efficiency.

Hard fork schedule

In addition to focusing on the proposal, the timing of the hard fork in Istanbul is also worthy of attention.

According to the timetable set by the former hard-forked coordinator Afri Schoedon (departed), the hard-fork process is broken down into “a fixed 9-month cycle”. The hard fork schedule for Istanbul is as follows:

• 2019-05-17 (Friday): Acceptance of the "Istanbul" proposal deadline
• 2019-07-19 (Friday): Deadline for major client implementations
• 2019-08-14 (Wednesday): Test Network ((Ropsten, Gorli or ad hoc testnet)) upgrade time
• 2019-10-16 (Wednesday): Main network upgrade time ("Istanbul")

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

However, according to the constant tonality of Ethereum, the possibility of this hard fork “on time” is not high. In the previous fork of Constantinople, there was a code loophole that caused the fork to be postponed.

Alexey Akhunov, a recipient of the Ethereum Foundation, said in the Gitter chat room that everyone should consider the "deadline" and should not end up for the deadline. Everything is based on good work.

“I am also thinking about the purpose of this deadline?” Akhunov said. “Because this is the first time (in the fork) to introduce so many things, so we are here to make sure that what we do is there. The reason, not because 'someone said so.'"

Author | Qin Xiaofeng

Edit | Lu Xiaoming

Produced | Odaily Planet Daily

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