This upgrade mainly includes four proposals, EIP-2565, EIP-2718, EIP-2929 and EIP-2930.
Original title: “Introduction | Overview of “Berlin” Upgrade Content”
Written by: Pooja Ranjan
Translation: Ajian
Following the upgrade of “Muir Glacier”, the Ethereum blockchain plans to implement the “Berlin” upgrade. According to its specifications, the Ethereum mainnet blockchain is expected to be activated at block height 12,244,000 on April 10, 2021. The specific time may be advanced or delayed due to fluctuations in block production time.
It has been 15 months since the last network upgrade, and we have made a lot of progress during this period. The client of the Ethereum network is ready to activate 4 proposals to improve the performance of the network and lay the foundation for further upgrades in the future.
Unlike previous Ethereum network upgrades, the content and progress of this upgrade will not be shown in a single EIP. If you want to understand its content, please read the “Berlin” network upgrade specification and track its progress in the eth1.0-specs repo.
What changes will be included in the “Berlin” upgrade?
The “Berlin” upgrade will introduce the following EIPs to the Ethereum network:
EIP-2565: Change the gas cost of modulus/exponentiation
The EIP-2565 proposal is a repricing of the previous EIP-198 (large number modulus exponentiation operation); at the beginning, EIP-198 introduced a pre-compiled module for modulus exponentiation operation, which allows us to introduce many Cryptographic algorithms that require modular exponentiation, such as RSA signature verification. EIP-2565 reduces the gas cost of the module, making it equal to the cost of performing other operations. Watch Kelly Olson’s introductory video for an overview of the proposal and some interesting charts on Gas repricing.
EIP-2718: Standardized transaction envelope
The EIP introduces a new transaction type, which itself can be used as an envelope to more conveniently enable support for multiple transaction types.
When Ethereum first launched the mainnet, there was only one transaction type, with fields “To” (indicating the purpose of the transaction) and “Data” (to include arbitrary data in the transaction). In order to reach a consensus, Ethereum clients must be in agreement to ensure that they will apply the same state changes when processing the same transaction. Therefore, if the “To” field is 0, all clients must interpret the “Data” field as a deployment contract and execute it in a specific way.
After some time, the need for the type of transaction has changed. The EIP-155 (simple protection against replay attacks) proposal reflects this (Translator’s Note: EIP-155 uses the “chain ID” field to prevent transactions from being replayed on different networks compatible with the Ethereum protocol). However, no new transaction types were introduced at that time. It was the client team that reached a social consensus and took different interpretations of this field. The “Spurious Dragon” (that is, included in EIP-155) hard forks are hard forks of consensus changes because all clients need to reach a consensus on the interpretation of this field. EIP-2718 cannot help relieve the complexity brought by EIP-155, but it can prevent the introduction of more complexity in the future, and it also makes it easier to add new transaction types (such as transactions in the form of EIP-1559) . For an in-depth understanding of the proposal, please watch the video Micah Zoltu explaining EIP-2718.
EIP-2929: Improve the Gas overhead of state access opcodes
This EIP increases the gas consumption of a transaction when SLOAD, *CALL, BALANCE, EXT* and SELFDESTRUCT are called for the first time. For example, it increased the gas consumption of CALL family functions from 700 to 2600, while the gas consumption of SLOAD family increased from 800 to 2100. However, (within a transaction) this high cost is only triggered once for any address or storage slot. If it is called multiple times, the subsequent calls will only consume 100 Gas each time.
The purpose of increasing the gas consumption of these operations is to mitigate the DoS attack interface that still exists in the Ethereum protocol. In addition, it also helps to limit the size of witness data in an environment where stateless Ethereum is implemented. Currently, the bandwidth required to incorporate Merkel’s proof is far greater than the reasonable scale required to verify a block, so everyone is looking for some way to impose an upper limit on the witness data. Although EIP-2929 cannot solve all problems, it does take a step forward. Another benefit is that calls to pre-compiled modules will become cheaper: the EIP removes the extra 700 Gas that needs to be paid when accessing pre-compiled modules.
EIP-2930: Optional access list
The idea behind the proposal is to correct the destructive effect of EIP-2929 on existing contracts and alleviate the increase in gas consumption caused by EIP-2929. The proposal will introduce a new type of transaction that can include an access list (a list of addresses and storage item keys), allowing the transaction to indicate the status of its planned access. By specifying an access list, the client can handle transactions more easily, and Gas consumption can therefore be safely reduced.
Watch Vitalik B. and Martin S.’s video on EIP-2929 and 2930 to learn more details and its benefits to the Ethereum blockchain.
What’s the news about EIP management and Ethereum governance?
Look at the curious baby who has questions about the upgrade interval!
The “Muir Glacier” upgrade includes only one proposal, which is to postpone the ice age of Ethereum PoW mining. Because we can’t wait to deploy with any other proposals, the “Muir Glacier” upgrade occurred in January 2020.
In order to design a better network upgrade program, volunteers from the Ethereum community, including EIP editors, EIP authors, client developers, Ethereum cat herders, and other community members, jointly established the EIPIP organization. The ethereum herder organization also hosted a survey on the installation of key ethereum components to better understand the status quo of the diversity of ethereum clients.
At the same time, client developers are also struggling to implement proposals that improve performance, security, and help future upgrades. Because there are no frequent upgrades and developers can make the most of their development time, it can be expected that more new features will be introduced in the subsequent “London” upgrade, in the near future.
Having said that, progress is endless. Your feedback is very important for us to continue to improve the quality of the upgrade process.
I am a node operator/miner, what should I do?
Please download the latest version of the Ethereum client you are using.
Thanks to all developers, client teams, EIP authors, EIP editors, and friends who joined the Ethereum network upgrade process! See you next time you upgrade.
You can follow our ethereum cat-herder organization in these places: Twitter, Medium, GitHub, Website. And our Discord.
You can use tokens to express your love for us on Gitcoin and Clr.fund !
Source link: medium.com
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.