--- tags: acd-update --- # AllCoreDevs Update 002 :chains: Welcome to another AllCoreDevs update :wave: ## TL;DR :eyes: * Berlin went live, OpenEthereum had an issue on the fork but rapidly shipped a fix, the gas limit will likely go up a _bit_; * London has a devnet up with EIP-1559! Planning multiple forks simultaneously is a lot of work, so we're having an extra ACD call; * Core devs are starting to prototype the merge - check out [Rayonism](https://rayonism.io/) ☀️ ## Hiring Updates :hammer_and_wrench: * Gnosis [is hiring core developers for OpenEthereum](https://boards.greenhouse.io/gnosis/jobs/4497327002), now with increased compensation :money_with_wings: * Nethermind [is hiring new grads to work on their client](https://twitter.com/nethermindeth/status/1371830786777833473) - a very rare junior opening for such a role! * ConsenSys [is hiring developers to work on its Besu client](https://consensys.net/open-roles/2397547/). ## Berlin :flag-de: On block 12244000, the Berlin network upgrade hit the Ethereum mainnet :tada:! While the fork block went by smoothly, shortly after the upgrade, OpenEthereum experienced a consensus issue. Developers rapidly noticed the problem (etherscan being down made it hard to _not_ notice..!) and jumped on a Zoom call to diagnose and fix the issue. Roughly 1h30 after the issue was triggered, the root cause was found. In short, the issue was caused by the BLS-12381 precompile. It had been activated in some Berlin testnets, but was not part of the mainnet fork. Instead of disabling the precompile, the OE implementation had it set to activate on a block extremely far in the future. When a transaction called this precompile address by mistake, the way OE priced the call differed from the other implementations. For more on this, Alex Stokes had [a gread Twitter thread](https://twitter.com/ralexstokes/status/1382750001026146304) explaining the issue. We've also started [a retrospective](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/retrospectives/berlin.md) in the eth1.0-specs repository. Lastly, the OpenEthereum team is working on issuing a complete postmortem of the incident. OpenEthereum users should now use [v2.3.4 of the client](https://github.com/openethereum/openethereum/releases/tag/v3.2.4). ### EIP-2930 Explainer :brain: In order to mitigate potential breakage by EIP-2929, Berlin also included EIP-2930. The EIP allows transactions to be submitted with an access list to benefit from slightly lower gas costs in some cases. The cases in which access lists are beneficial to use are not always obvious. Luckily, Franco Victorio of Nomic Labs has put togeher [a document explaining the changes in gas costs caused by using access lists, and how to generate them](https://hackmd.io/@fvictorio/gas-costs-after-berlin). If your project is potentially affected by EIP-2929 or 2930, you should read this. ### Gas Limit Increases :chart_with_upwards_trend: As mentioned in the previous update, with Berlin being live, the bulk of the DoS risks from larger blocks on the Ethereum mainnet has been addressed. This means we can now (**slowly!**) begin increasing the gas limit. As Péter Szilágyi noted [on Twitter](https://twitter.com/peter_szilagyi/status/1384438441803403268), EIP-2929, along with snapshots in Geth, mean we can raise the gas limit slighly higher. He proposed starting at 15M to see how that goes. But! While the DoS risks have been mitigated, the state growth concerns still haven't. Raising the gas limit means increasing the rate at which the state grows, and the burden on nodes to sync and stay synced to the network. Until we have a long-term solution (e.g. statelessness), we still need to be cautious. Especially, [as Péter also noted](https://twitter.com/peter_szilagyi/status/1384444565797670912), when we aren't sure if statelessness is even feasible. ## London :uk: With Berlin out of the way, we are now deep in the implementation and testing phase for London. At this point, three EIPs are scheduled for the upgrade: [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), which needs no introduction, [EIP-3238](https://eips.ethereum.org/EIPS/eip-3238), which delays the difficulty bomb to 2022Q2, and [EIP-3198](https://eips.ethereum.org/EIPS/eip-3198), which adds an opcode to return the `BASE FEE` from a block. We now have a first integration testnet, [Aleut](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/client-integration-testnets/aleut.md), to which the majority of clients are syncing [1]. If you would like to join the network, the config files and bootnodes are shared in the spec. Documentation isn't great yet, and you may have to use a dev branch of your favorite client, but this should improve in the coming weeks! On the planning front, London is unique in that it is the first network upgrade to be planned while another one was still being deployed. Alongisde that, client teams have begun prototyping The Merge (more on that below). The past 3-4 AllCoreDevs calls have all been _packed_ and spilled over, so we have decided to add an out-of-cycle call [this Friday](https://github.com/ethereum/pm/issues/301) to continue discussing London. In short, we need to figure out if we want to add anything else to London, when we want to roll the upgrade out, and what to do about things that may not make the cut, including the rapidly-growing-in-popularity [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074). Another busy call ahead! ## Rayonism :sunny: As mentioned above, client teams have begun focusing on The Merge :tm:. The initial effort is called [Rayonism](https://rayonism.io/), an ode to a the Russian art movement _"painting a sharded space with rays to a dynamic runtime."_ Over the next month, prototypes will be built based on the ["Executable Beacon Chain" proposal](https://ethresear.ch/t/executable-beacon-chain/8271). The full set of specs can be found in the [ethereum/rayonism](https://github.com/ethereum/rayonism) repository. The effort is part of the Scaling Ethereum hackathon and is open to all. If you would like to contribute, you can join the [discord channel](https://discord.gg/ky9aV9SMEE) to get involved. There is also [a tutorial](https://github.com/protolambda/mergenet-tutorial) for those who are interested in seeing it work :smile: Of course, this being done as part of a hackathon means that things will change quicly, documentation, when present, may get out of date, and the prototypes built here will not be suitable for production. But, by the end of it, we should have a very good idea of the technical requirements to make the merge happen, and how to "productionize" the prototypes built. In closing, if you want a view into the post-merge future, Barnabé wrote [a great post about it](https://barnabe.substack.com/p/eth2) this week! --- Thanks for reading! You can expect the next update in a few weeks, once the London spec has been finalized. --- Published on April 20, 2021 [1] Note: Aleut does not include EIP-3238 given that the EIP only changes mainnet constants for the difficulty bomb.