The journey to Istanbul is about to begin. Most of the passengers have boarded the flight but the door closing may be delayed for passengers who already have checked in but not reached to the gate yet.

This is the current status of Ethereum's 'Flight to Istanbul', where EIPs are the passengers.

The Istanbul upgrade

Ethereum developers and community members are now preparing for the next upgrade - Istanbul. Constantinople upgrade witnessed a few hiccups. After the success of Constantinople 2 and St. Petersburg fork, a lot of discussion around designing a new process to provide a framework for future upgrades on Ethereum Network surfaced. Istanbul is now following one of the proposed designs of having a roadmap with 'the deadlines' to be on-schedule.

Background

The discussion around the process improvement of Ethereum protocol started back in March 2017 with Alex Beregszaszi's Meta EIP 233. This EIP describes the formal process of preparing and activating hard forks.

In Dec 2018, Afri Schoedon proposed to write an EEP to define the Ethereum Network Upgrade Process. EEP-5 primarily covers Ethereum 1.0 upgrades. It suggested moving from ad-hoc hardfork to fixed-schedule and provides a general outline process with all required stages of hardfork. That breaks down to a fixed 9-months cycle to release protocol upgrades accepted prior to the hard deadline in May to mainnet. All proposals accepted after that date should go into a subsequent hardfork nine months later. It was also pre-announced and requested for collaboration at Eth Magician.

Roadmap - Istanbul

Proposed Timelines for Istanbul upgrade

On Jan 4th in All Core Devs call roadmap of Istanbul was proposed and the proposal was provisionally accepted.

Istanbul & ETH1x Roadmap Planning Meeting in Berlin on April 17-18th helped getting more volunteers and added clarity on the process to be followed.

Initially, there were some disagreement on the upgrade cycle or the buffer buffer between two releases, but they agreed to follow the proposed timeline for Istanbul. Up till Core Devs call 57, developers weren't sure if Ethereum upgrade should follow the path of HardFork with bunch of EIPs together in every 6-9 months, or go for small releases (every 3 months) as suggested by Alexey Akhunov in Core Devs call 56. Eventually dust settled and now there seems to be consensus on 6 months buffer between the two forks. You may follow the discussion here.

Istanbul upgrade process

As mentioned earlier, for Istanbul upgrade, developers and volunteers have agreed to stick to the proposed timeline. However, Alex Beregszaszi, author of Istanbul Hardfork Meta, proposes to extend the Istanbul EIP proposal submission deadline till the 23rd of May (the day before the next ACD call) to ensure every proposed EIP is merged as draft.

Clarity around the upgrade process is still missing. May be some documentation is required in this area. It was also discussed in ACD #61 and agreed to have more process documentations around the HF process. Nonetheless, a process document for 'proposing a formal process of selection of EIPs for upgrade' referred in PR #1929 is shelved. Follow the discussion at EthMagician .

For more update on Istanbul read

____________________________________________________________________________________________________

FAQ

• How to propose an EIP for Istanbul?

With reference to process documented in EIP 233 and discussion in last All Core Devs Meeting 61, anyone who wishes to propose an EIP for the Istanbul hard fork must make a PR against the Meta EIP 1679 on or before May 17th.

• At what state, EIP can be signaled to be considered?

The EIP must be published as at least Draft. It may not be fully specified but has a general idea that it is likely to improve the process. There is no technical specification available for the proposal to an upgrade yet; however, for an EIP to be called as an EIP, there are set of standards specified in EIP 1.

• How to get an EIP reviewed and merged?

If an EIP is fairly new and not gone through the EIP process cycle yet, then it is recommended to get EIP reviewed just after the idea has taken shape and further author aims for it to be included in Ethereum's next upgrade.
At the moment, reviewing an EIP is one of the challenges faced by EIP champion/author. Not many reviewers available and those who are, are mostly busy writing an EIP :) Regardless, one may reach reviewers and discuss more about EIP review and merging at Gitter

The current EIP editors are

• Nick Johnson (@arachnid)
• Casey Detrio (@cdetrio)
• Hudson Jameson (@Souptacular)
• Vitalik Buterin (@vbuterin)
• Nick Savers (@nicksavers)
• Martin Becze (@wanderer)
• Greg Colvin (@gcolvin)
• Alex Beregszaszi (@axic)

Once the EIP is ready, the EIP editor will:
* Assign an EIP number
* Merge the corresponding pull request
* Send a message back to the EIP author with the next step.

• What is the process of acceptance of EIPs for upgrade?

EIPs which are already proposed by the process mentioned above are added to the canonical list of EIPs in meta EIP 1679 under proposed section. It is moved to Accepted EIPs section only after it has been accepted by Core Devs in subsequent meetings.

EIPs proposed by the deadline are going to be deliberated on the upgrade with very few exceptions. If an EIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion.

• What is Client implementation deadline for Istanbul?

July 19th is the proposed soft deadline for client implementation for Istanbul. Which means, all listed EIPs are expected to be implemented in clients by the deadline, how many clients - not specified. There may be a little flexibility on finishing up of the implementation depending on the complexity.

• Decision on Core EIP accepted for a hardfork is in the hands of the Ethereum client developers. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the EIP process.
• Core EIPs must be implemented in at least three viable Ethereum clients before it can be considered Final and accepted for upgrade.
• Test cases for an implementation are mandatory for EIPs that are affecting consensus changes.

EIPs for Istanbul

EIP 1679 is the Meta EIP for Istanbul Hardfork.

Proposed EIPs

• EIP-615: Subroutines and Static Jumps for the EVM
• EIP-1057: ProgPoW, a Programmatic
  Proof-of-Work
  • There is a
    pending audit,
    above and beyond standard security considerations, that should be evaluated
    prior to inclusion.
• EIP-1108: Reduce alt_bn128 precompile gas costs
• EIP-1283: Net gas metering for SSTORE without dirty maps
• EIP-1344: Add ChainID opcode
• EIP-1352: Specify restricted address range for precompiles/system contracts
• EIP-1380: Reduced gas cost for call to self
• EIP-1559: Fee market change for ETH 1.0 chain
• EIP-1702: Generalized account versioning scheme
• EIP-1706: Disable SSTORE with gasleft lower than call stipend
• EIP-1803: Rename opcodes for clarity
• EIP-1829: Precompile for Elliptic Curve Linear Combinations
• EIP-1884: Repricing for trie-size-dependent opcodes
• EIP-2028: Calldata gas cost reduction

This is the canonical list that has been merged but there are other more PRs under review. So, expect this list to GROW.

Istanbul trackers

• Track the progress of Istanbul Upgrade with Ethereum Cat herders here.

Bug Bounty declared

Critical Instanbul Bugs: 20 ETH Bounty, Subject To Exponential Decay is declared.

Going by the timeline seems to be a good idea to enforce speed but not sure if it will be able to enforce quality as well. Some of the questions are still unanswered and more clarity is required around the roadmap.

References: EIP 1, EEP-5, EIP233, EIP 1679, Notes from ACD meetings.

____________________________________________________________________________________________________

Disclaimer: This is not an investment advice and should NOT be viewed as project endorsement by EtherWorld. Readers are suggested to do their research before investing into any project.