Essence of Ethereum Core Developers Conference (1)

Source | AllCoreDevs Update

Author | Tim Beiko

Author | Tim Beiko

first level title

Welcome 👋🏻

This series of articles aims to summarize the progress of core protocol development, so that the Ethereum community can better understand and digest. The "AllCoreDevs Updates" series can be said to be a companion piece to "Core Devs Meeting Videos & Transcripts" and my Twitter Wrap Up.

Thanks for reading 😁

first level title

➤ London hard fork in preparation: EIP-1559 implementation is underway, and the scope of the upgrade is narrow in order to meet the July or August deadline.

➤ The upgrade focus of the Shanghai hard fork is still under discussion: either the core developers will focus their energy on the eth1->eth2 merge, or deploy those EIPs that are more popular after the merger prototypefirst level titleupgrade berlin

The content of the Berlin upgrade has been deployed on all major testnets, and will be launched on the mainnet on April 14th at block height 12,244,000. This upgrade will improve the security of Ethereum and prepare for the deployment of EIP-1559 in the London upgrade. If the reader is running a node and hasn't updated the client version yet, do so ASAP! As for the updated version of the client,

"Ethereum Berlin Upgrade Announcement"

There are announcements.

On the security side, the gas fees for opcodes accessing the Ethereum state are prohibitively low compared to their computational cost, and EIP-2929 addresses this issue. Taking advantage of the low gas costs of opcodes, malicious actors can create blocks that repeatedly call these opcodes, which are orders of magnitude slower to process than normal blocks. EIP-2929 alleviates this by providing ~3x the gas cost. On the client side, database management has been improved. For example, the snapshot database format of the Geth client also helps to more efficiently handle blocks with high state access.

However, in order to alleviate the negative impact of EIP-2929 on users, Berlin Upgrade introduced the matching EIP-2930. It allows users to specify an "access list" when submitting a transaction to use gas fees lower than those specified in 2929. The calculation of the gas fee is a bit complicated, but, at a high level, if clients know in advance which part of the state a transaction will involve, they can preload and charge less gas for those accesses. I encourage everyone to refer to this EIP for exact calculations.

For application and wallet developers who want to experience the function of generating "access lists", the Geth client will soon launch related tools 🔜 You can click here to view the development progress:

https://github.com/ethereum/go-ethereum/pull/22550. More broadly, if you're an app or wallet developer, now's the time to test out the content of Berlin's upgrade on the testnet!

Finally, everyone has another worry about the Berlin upgrade, worrying that EIP-2929 will increase the cost of DeFi transactions. However, the introduction of EIP-2930 will offset some (not all). The obvious solution to prevent this type of transaction gas fee increase is to increase the block gas limit.

However, there are always pros and cons to doing so: increasing the block size speeds up state growth, which makes it more difficult for nodes to synchronize with the network. On the other hand, not increasing the block gas limit will increase the transaction cost of network users (paying expensive gas fees). Perhaps this is a more fair compromise: introduce 2929 to reduce the risk of DoS, and then slowly increase the block size until the gas fee increased by 2929 is gradually offset.

first level title

london upgradeWith the Berlin hard fork on the way to mainnet, core developers are now focusing on the next network upgrade: London. This upgrade is a bit special, since the difficulty bomb will happen in August, so the London upgrade must be deployed before then. That is to say, the development and update of the next upgrade (London) will start before the previous upgrade is deployed. This is the first time that the core developers have encountered such a situation.The London upgrade will deploy the long-awaited EIP-1559 on the mainnet. If the reader is new to the EIP, I've put together a list of resources and documented the development process over the past year.

translation of

The changes brought about by this EIP alone to Ethereum are greater than all the EIP upgrades in Berlin combined. And the implementation and testing time is shorter than previous upgrades, so the core developers are trying to narrow the scope of the London upgrade so that it can be completed on time. So far, the London upgrade has only included EIP-1559 and EIP-3238 (proposing to delay the difficulty bomb until Q2 2022). After the implementation and testing of 1559 is over, the core developers will be in a more active position, and then decide which EIPs to add.

first level title

Shanghai upgrade

Since the scope of London's upgrade has been deliberately narrowed, the core developers have begun high-level planning for Shanghai's upgrade. We have the following two main possibilities:

First, we can implement EIPs that are impossible to deploy in London, such as:

➤ EIP-3074: Allow "funded transactions" and more

➤ EIP-2537: Add support for BLS-12381 curve (used by beacon chain)

➤ EIP-2327: Beneficial to the Solidity and Optimism teams

➤ EIP-2935: Helpful for light clients and stateless clients

Alternatively, the community is increasingly focusing on the merger between the consensus (eth2) and application (eth1) layers, simply put, the Merge™️. The eth2 spec repository already has a PR for the "simplified merge spec" proposal, and is very close to what the client team should be able to prototype.

While the merged specification may be relatively simple, there are still several engineering issues that need to be resolved in order for application-layer clients to use the beacon chain as their consensus engine. Bringing the attention of client developers on both sides to these issues is how we find and fix them.

The client team still needs to get a better handle on digesting the specs and start building prototypes before they can decide if we're ready to turn all our energy into the merge effort, or if a small working group is needed before everyone gets involved Get more work done. To accelerate this process, clients from the application and consensus layers will develop prototypes of the latest specifications during the Scaling Ethereum Hackathon.

The above is the update content of this issue! The next AllCoreDevs meeting will be held on Friday, April 2nd at 22:00 Beijing time. See you next time!

ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.