Istanbul to Berlin: Ethereum Milestones on the Serenity Road
Earlier this month, Péter Szilágyi, leader of the Ethereum Foundation group confirmed the upcoming network upgrade date, Istanbul. Ethereum’s eighth overall Hard Fork and the second time of this year will take place on December 4. However, on November 20, it is estimated that the date has been moved to December 7, according to the primary announcement.
Istanbul will introduce a number of enhancements such as the ability to interact with Zcash, a cheaper zero-knowledge second-class scalability solution, and adjust gas prices for certain activities, marking another milestone on the way to Ethereum 2.0. This is the expected “ultimate” version of the network. Exactly how does Istanbul fit in overall?
Release and stages of fork
There is no complicated open-source system in the final state – the software is always working, continually being improved and updated. This is especially true of Ethereum, which has always been on the road to becoming a distributed “world computer” and a platform for decentralized applications. This is what it set out to start as a series of consecutive landmarks.
An enhanced version of the network called Ethereum 2.0, Eth2 or Serenity is the current goal that the Ethereum developer community is pursuing. The upgrade is expected to witness some major developments, such as the transition from proof-of-work to the proof-of-stake consensus algorithm to save energy, realize a new scalable model called “sharding”. Moreover, introduce the more efficient Ethereum Virtual Machine, capable of executing high-performance smart contracts. Researcher Daniel Ryan has formulated five overarching design goals for Ethereum 2.0: decentralization, resilience, security, simplicity, and longevity.
Differences in the language used to describe network update stages can be confusing: There are hard forks named after major cities in the world, numbered stages, releases that denoted by version code and dreamy titles as “serenity”. However, it ultimately depends on a fairly simple structure.
The most significant improvement in the development process is called a release. An individual release may be issued by means of one or several hard forks – the change of the Blockchain protocol marks a complete departure from its old version.
So far, three releases – the current release called Metropolis – have been deployed in two steps: the hard fork Byzantium and Constantinople, with Istanbul still the destination. The next hard forks, Berlin (scheduled for June 2020) and London, will mark the release of the fourth edition, Ethereum 2.0, or, Serenity.
The hard forks trigger the change for the currently active Ethereum mainnet. However, the roadmap to Ethereum 2.0 facilitates the creation of separate new chains – such as the final existence of two active Ethereum chains with different consensus mechanisms. The implementation of the Ethereum 2.0 chain will have a sequence of phases specified in the roadmap.
Istanbul: improvements are accepted
The proposal of Ethereum improvement is the main governance way that the Ethereum community relies on to promote network development. They specify proposals regarding changes in the core protocol, the client API (Application Programming Interface) and smart contract standards.
Authors often find ways to suggest a time for the fork schedule and target specific hard forks that are published in advance. There is currently a push in the community to shift to an “EIP-focused” approach to system upgrades, where more frequent and smaller forks can allow proposals to grow at the rate of own them. Berlin, the “appointed” hard fork will follow Istanbul, which is expected to be the first test in this model.
Istanbul still followed the “central to the Fork” approach, where many proposals at different stages of their lifecycles were made and considered during the summons of core developers ( All Core Devs). Developers have classified EIP as desired and ready to proceed to hard fork (accepted), wish but not ready (temporarily accepted, assuming it will proceed with the next hard fork) or not desired (permanently denied). Only six were accepted out of the 38 EIP presented, with another eight EIP approved for the Berlin hard fork. Here is an outline of the accepted proposals:
EIP-152 offers the ability to verify the PoW Equihash algorithm in Ethereum contracts, enabling interoperability between Zcash and Ethereum blockchains.
EIP-1108 reduces the cost of precompiling gas, creating a cheaper generation of non-interactive zero-knowledge proof, or zk-SNARK. This is good news for two reasons. Firstly, the change will enhance the development of privacy-focused applications using this type of encryption.
Therefore, using zk-SNARKs as a second layer solution can be a tool to help alleviate some of Ethereum’s scalability issues, by moving a significant amount of computational work out of the chain.
EIP-1344 adds an opcode that returns the unique identifier of the current string. It introduces how contracts can track their Ethereum chains. This will improve the resilience of the system to review attacks on signed transactions.
EIP-1884 is probably the most controversial of the accepted proposals, causing controversy since at least August this year. It is introduced by Martin Holst Swende, a security leader at the Ethereum Foundation. This proposal aims to revalue some opcode (instructions were given to the Ethereum Virtual Machine for implementing smart contracts) to get a right balance between gas cost and resource consumption.
The problem that EIP-1884 is supposed to solve is rooted in a number of activities that are becoming more resource-intensive with the Ethereum blockchain expansion. Currently, blocks with similar gas consumption take a lot of time to complete, which is not only a problem but also a factor of a denial of service attack.
Friction appeared during the convening of 69 core developers on August 23, where Parity Technologies’ Wei Tang expressed concern about the possibility that changing opcode costs would disrupt some of the contracts that were deployed. He said that backward compatibility must be preserved, allowing old contracts to operate at cost.
Hudson Jameson, the community association of the Ethereum Foundation, responded that there is a “precedent that OPCODE prices can and will change. So your contracts should not be based on the assumption that they will not change”. He added that the transition would help people better prepare for the more dramatic change that is about to happen.
EIP-1884 will affect a number of contracts in many projects. Hubert Ritzdorf from security firm Blockchain ChainSecurity has come up with a list of contracts that could be most profoundly affected.
EIP-2028 reduces data costs in transactions that are likely to result in larger blocks, thus improving the network’s scalability. This will also make second layer scalability solutions (such as zk-SNARKs) more accessible.
EIP-2200 performs net gas quantification, changing the way storage costs are calculated in EVM. This will activate the new functionality of contract hosting and reduce some excessive costs.
Still in the process of implementation
EIP-1057 is another prominent proposal that the Ethereum community considered during the integration into the Istanbul hard fork. This proposal seeks to replace the current Ethash mining algorithm with a new proof-of-work function called ProgPoW, which stands for Programmatic Proof-of -Work. The core developers temporarily accepted the initiative and waited for the audit results to be included in the Berlin hard fork.
The idea behind this algorithm update is to adjust it for commodity hardware using graphics processing units. It makes mining more difficult for settings equipped with an integrated circuit chip specifically for the application.
This measure is designed to restore some degree of decentralization to mining power distribution while leveling the field by making Ethereum mining more appealing to individual and small business users without Invest in specialized hardware. ASIC has been a major driver behind the mining industrialization in the past few years, resulting in large, centralized clusters.
Earlier this year, Ethereum Foundation security leader Martin Holst Swende said that the introduction of ProgPoW will minimize the level of ASIC and other hardware accelerators dominating the network. He added that another reason for the change is due to Ethash’s inherent security flaws.
Although there seems to be an agreement between the core developers regarding the “desirability” of ProgPoW, not everyone in the community is happy about the prospect of changing the mining algorithm before switch to PoS in Ethereum 2.0.
The one that caused the most dissent was Aragon – a project that managed decentralized autonomous organizations, which the community voted on November 2 to oppose any changes to Ethash before the switch to Ethereum 2.0.
Despite some stress, there is no indication that an important Ethereum user base is strongly opposed to the proposed change. This shows that the development will not lead to serious cracking.
If the independent audit confirms the robustness of the new algorithm, it will likely be implemented with the Berlin hard fork, which is currently scheduled for June 2020, as Ethereum continues to advance to the version. 2.0 of the network.
- Non-Profit Human Rights Foundation: Stablecoins Lack Of Privacy
- Bitcoin Is Reflecting The Fractal Fractal Of 2014 Price, Likely Bottom At $ 6000