Editor's note: This article is from 36 Krypton strategic cooperation blockchain media "Odaily Planet Daily" (public ID: o-daily, APP download)
Author | Qin Xiaofeng
Edit | LU Xiaoming
Produced by | Odaily Planet
For the past two weeks, the weekly conference calls have been canceled as many EtherCore developers have traveled to Toronto for the EtherScaling conference. This Friday night, the EtherCore developers will continue their conference call with topics centered around the Istanbul hard fork and deciding on the finalized proposal (EIP).
On a design level, the Istanbul hard fork is the last fork (no new tokens will be created) in the Serenity phase that Ether will move towards. 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 ecological development of Ether. Also according to Justin Drake, a researcher of Ether 2.0, Ether 2.0 stage 0 will be released on January 3, 2020.
Postponement of ProgPoW to focus on 'state leasing'
On the 17th of last month, the Istanbul Hard Fork Proposal (EIP) call ended with 29 proposals collected. The proposals were:
EIP-615: Subroutines and Static Jumps for EVMs
EIP-663: Unlimited SWAP and DUP Instructions
EIP-1057: ProgPoW, a programmed proof of work
EIP-1108: Reducing the cost of alt_bn128 precompiled gas
EIP-1109: PRECOMPILEDCALL OPERATING CODE (Removal of CALL charges for precompiled contracts)
EIP-1283: Measuring the net gas cost of SSTORE without dirty maps
EIP-1344: Adding a ChainID opcode
EIP-1352: Specifying Restricted Address Ranges for Pre-Compilation/System Contracts
EIP-1380: reducing the cost of self-calling gas
EIP-1559: Changing the ETH 1.0 chain gas fee
EIP-1965: method for checking if chainID is valid at a specific block number
EIP-1702: Version Control Program for Broad Accounts
EIP-1706: disable SSTORE when gas costs are low
EIP-1803: Rename Opcode
EIP-1829: Pre-compilation of Elliptic Curve Linear Combinations
EIP-1884: redefining trie-size dependent opcodes
EIP-1930: Gas call criteria are tightened and can be recovered if there are not enough gas calls.
EIP-1985: Reasonable Limits for Certain EVM Parameters
EIP-1959: new opcode to check if chainID is part of chainID history
EIP-1962: EC arithmetic and pairing with runtime definitions (replaces EIP-1829)
EIP-2014: Extended State Oracle
EIP-2026: Status Lease H - Fixed Account Advances
EIP-2027: Status Lease C - Accounting for Net Contract Size
EIP-2028: Reducing the Cost of Calldata Gas
EIP-2029: Status Lease A - Status Counter Contracts
EIP-2031: Status Lease B - Net Trading Desk
EIP-2035: Stateless Clients - Repricing SLOAD and SSTORE to Pay for Block Proofs
EIP-2045: gas cost of EVM opcode particles
EIP-2046: Reducing the cost of gas for static calls to precompiled programs
Previously on the core developer call, the provisionally approved proposal was EIP 1108 - proposing minor changes to the Gas fee for the Ethernet network. However, the developers emphasized that the proposal, while approved, would require benchmark data to be presented 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 to better utilize GPU-specific computing capabilities, may be delayed.
Previously, the developers raised 50,000 DAI (about $50,000) through crowdfunding via open source bounty platform Gitcoin to fund the ProgPoW code audit. However, the code was announced to be postponed at the May 24 developer meeting as it has not found a third-party organization to audit it so far.
Also delayed was EIP-1559, a proposal to change the Ether transaction fee model that was "abandoned" by developers due to its complexity.
Among these proposals, 'Status Lease' stands out.
The original intent of the "state leasing" design was that the size of Ether's state is currently so large that if it continues to grow at its current rate, the Ether network will become extremely bloated. And since we are underestimating the long-term cost of storage, which can be approximated and modeled as: bytes * time, it is necessary to make changes to the current state design of Ethernet.
Based on the Ether 2.0 roadmap, it looks like state leasing will also be deployed in ETH 2.0 (the current plan is for it to be in Stage 2). Whether or not to go through the time-consuming and laborious process of redevelopment at ETH 1.0 is sure to be a hot topic of discussion on this Friday's conference call as well.
Deletion of proposals
The above proposals have also caused extensive discussion in the community as well, with many developers questioning that some of the proposals are repetitive and should be trimmed down.
Developer Alex Beregszaszi said, "I'm confused. I think that those proposals with conflicting, neighboring, and duplicative EIPs (there are 3 or 4 EIPs all about chainid, repricing, SWAP, and DUP) should have some consensus before they are proposed again. There is little point in arguing about EIPs if they are not clearly defined."
Until now, the proposal audit process is only a fraction of the way through, and whether the core developers will be able to give a final answer this Friday is still up in the air.
Alex believes that some proposals don't really need to be made in a hard fork and can be solved by contacting Ether client developers. "Instead of just trying to solve it on their own, those (EIP) authors should reach out to some of the relevant developers, such as client-side developers to review their ideas. If everyone waits for the core developers to have a conference call to discuss implementation, we won't have enough time to discuss all these proposals."
For the EIP above, the developer community (click to enter) is also currently discussing a reduction to reduce core developer workload and increase efficiency.
hard fork timeline
In addition to focusing on the proposal, the timing regarding the Istanbul hard fork is equally noteworthy.
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 below:
Friday, 2019-05-17: Deadline for acceptance of the "Istanbul" proposal
Friday, 2019-07-19: Deadline for major client implementations
Wednesday, 2019-08-14: Testnet ((Ropsten, Gorli or ad hoc testnet)) upgrade time
Wednesday, 2019-10-16: Time for main network upgrade ("Istanbul")
Now that the first phase of proposal gathering has been completed, the next step is the "main client implementation". The so-called "main client implementation" is the merging of the accepted EPIs into the existing Ethernet client, which is similar to putting code together so that it can be fully tested.
However, according to the usual tone of Ether, the hard fork is not likely to be completed "on time". In the previous Constantinople fork, there was a code bug that caused the fork to be delayed.
Alexey Akhunov, a recipient of the Ethernet Foundation, said in a Gitter chat room that everyone should think about "deadlines", not for the sake of deadlines, but for the sake of doing good work.
"I myself was thinking about what is the purpose of this deadline?" Akhunov said, "Because this is the first time so many things have been introduced [in a fork], so we're here to make sure that we're doing what we're doing for a reason, not because 'someone said so'."
