--- tags: acd-update --- # AllCoreDevs Update 001 ⛓ ## Welcome 👋🏻 Welcome to the first AllCoreDevs update! The purpose of these updates is to provide the Ethereum community easily digesteable summaries of what is going on with core protocol development. They serve as companion to both the [call recordings & transcripts](https://github.com/ethereum/pm#previous-meetings) and my [Twitter summaries](https://twitter.com/TimBeiko/status/1372903072377184257). Hopefully this helps share the issues that core developers are thinking through to a broader part of the Ethereum community so more people can be aware of what's happening, share feedback, and even contribute to solutions. Thanks for reading 😁 ## TL;DR 👀 * Berlin is live on testnets: application & wallet devs, now is the time to try it out! * London is being prepared: EIP-1559 implementations are underway, and the scope of the upgrade is being kept tight to hit the July/August deadline. * The focus of Shanghai is still being discussed: either core developers will move all their attention to The Merge, or a last set of highly requested EIPs will be deployed as the merge gets prototyped. ## Berlin 🇩🇪 Having been deployed to all major testnets, Berlin is coming to mainnet on April 14th at block 12,244,000. The upgrade brings security improvements to Ethereum, and sets the stage for the deployment of EIP-1559 in London. If you run a node and haven't upgraded it yet, now is the time! See the client versions in the [announcement post](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/). On the security front, [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) addresses an issue where the gas price of opcodes which access Ethereum's state were underpriced relative to their computational cost. Exploiting this, malicious actors could create blocks which repeatedly call these opcodes and are orders of magnitude slower to process than average blocks. 2929 mitigates this by raising these gas costs by ~3x. Improved database management by clients, such as Geth's [snapshot database format](https://blog.ethereum.org/2020/07/17/ask-about-geth-snapshot-acceleration) are also helpful in processing state-access-heavy blocks more efficiently. In order to mitigate the negative impact of 2929 on users, a companion EIP is introduced in Berlin: [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930). It allows users to specify an "access list" when submitting their transaction to benefit from lower gas prices than those specified in 2929. There is some complexity in how the gas prices get calculated, but, at a high level, if clients know in advance which part of the state will be touched by a transaction, they can pre-load it, and charge less gas for those accesses. I encourage you to refer to the EIP for exact calculations. For application and wallet developers who would like to experiment with generating access lists, expect a tool from Geth :soon: You can track the progress on it [here](https://github.com/ethereum/go-ethereum/pull/22550). **More broadly, if you are an application or wallet developer, now's the time to test-drive Berlin on testnets!** With regards to EIP-1559, Berlin helps on two fronts. First, EIP-2929 addresses the largest risk with EIP-1559: having DoS attacks on blocks that are 2x larger than today. This was [the first objection that was raised by client developers about the EIP](https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783/45?u=timbeiko), and came up every time the EIP was discussed in AllCoreDevs. In other words, we could not safely ship 1559 without 2929. Second, Berlin brings in support for multiple transaction types at the protocol level with [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718). The access lists introduced with EIP-2930 require a new transaction type, and EIP-2718 provides a generalized framework to support them. This means that implementing 2718 & 2930 as part of Berlin allows client teams to do all the architectural groundwork required for supporting 1559-style transactions in London. Finally, one concern that has been raised with regards to Berlin is that the cost of DeFi transactions would be increased by EIP-2929. While some of these increases can be mitigated by EIP-2930, not all of them can. The obvious solution to prevent a fee increase for these types of transaction would be to raise the block gas limit. There is always a tradeoff in doing so, though: raising the block size accelerates state growth, which makes it harder for nodes to stay synchronized on the network. On the other hand, not raising the block gas limit also has a cost on all users of the network who pay the high fees. With the largest DoS risks mitigated by 2929, slowly raising the block size until those increased fees are offset could be a just compromise. ## London 🇬🇧 With Berlin about to roll out on mainnet, core developers are now focusing on the next network upgrade, London. This upgrade is somewhat special in that its deployement to mainnet has to happen before a specific time (August) due to the [difficulty bomb](https://docs.ethhub.io/questions-about-ethereum/what-is-the-difficulty-bomb/). This makes London the first time core developers have started to work on an update before the previous one has been deployed to mainnet. The upgrade will bring the long-awaited [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) to mainnet. If you are not familiar with the EIP, I've put together a [ressource list](https://hackmd.io/@timbeiko/1559-resources) and [have documented its development process over the past year](https://hackmd.io/@timbeiko/1559-updates). This EIP alone is a larger change to Ethreum than every EIP in Berlin combined, and implementations and testing have to be done on a shorter timeline than regular upgrades, so core developers are trying to limit the scope of London to get it done on time. So far, only EIP-1559 and [EIP-3238](https://eips.ethereum.org/EIPS/eip-3238), which pushes back the difficulty bomb, have been included in the upgrade. As the work on implementing and testing 1559 wraps up, core developers will be in a better position to decide whether additional EIPs should be added to London alongisde these two. ## Shanghai 🇨🇳 Because London's scope is deliberately being kept small, core developers have already started high-level planning for Shanghai. Here, we have two main possibilities. First, we could implement the set of EIPs which are unlikely to make it in London such as [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074), which allows for "sponsored transactions" and more, [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537), which adds support for the BLS-12381 curve (used by the beacon chain), [EIP-2327](https://eips.ethereum.org/EIPS/eip-2327), which would be beneficial to the Solidity and Optimism teams, and [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935), which would help with light & stateless clients. Alternatively, there is an increased desire from the community to focus on the consensus (eth2)- and application (eth1)-layer merge, or, simple The Merge :tm:. A proposal for a [simplified merge spec](https://notes.ethereum.org/@vbuterin/B1mUf6DXO) has been made into a [PR on the eth2-specs repo](https://github.com/ethereum/eth2.0-specs/pull/2257) and is very close to something that client teams should be able to prototype. While the merge spec may be simple, there will be several engineering issues to work through in order for application-layer clients to use the beacon chain as their consensus engine. Getting client developers from both sides to focus on these issues is how we will both discover and resolve them. Client teams still need to better digest these specs and to start building prototypes before they can decide whether we are ready to switch our entire focus to The Merge, or if more work needs to be done by a small working group prior to having everyone involved. To accelerate this, clients from both the application and consensus layer will work on prototypes of the latest spec during the [Scaling Ethereum hackathon](https://scaling.ethglobal.co/). The end of the hackathon corresponds nicely to when most of the work with London and Altair (the consenus-layer upgrade coming in June) should be done. This means the prototypes should be ready just in time for us to make a decision about Shanghai :tada: --- And that's it for this update! The next AllCoreDevs call is scheduled for [Friday Apr. 2, 14:00 UTC](https://github.com/ethereum/pm#agendas). See you then! --- Originally published: Mar 26, 2021