--- tags: acd-update --- # AllCoreDevs Update 003 ⛓ Welcome to another AllCoreDevs update :wave: ## TL;DR :eyes: * We are launching a Core Dev Apprenticeship & have published two new RFPs for major areas of protocol R&D; * Baikal, the pre-London devnet, is up and running. You can test the impact of London EIPs on your project by using it; * The London EIPs list and testnet fork blocks have been finalized. After a succesful testnet fork, we will set the mainnet block; * Rayonism was a major success - a testnet running post-merge Ethereum clients was stood up, transacted on, and finalized! ## Grants & RFPs :moneybag: Over the past few months, we've worked on various paths to onboard contributors to Ethereum protocol development. Here are a few we've announced recently: * [**Core Developer Apprenticeship Program**](https://blog.ethereum.org/2021/05/13/core-dev-apprenticeship/) :hammer_and_wrench: If you are an experienced developer who would like to get into Ethereum protocol developement, this program is an experiement where we'll provide a stipend for folks to start contributing over a few months. Applications are open! * [**Requests for Proposals Repository**](https://github.com/ethereum/requests-for-proposals) 📑 The EF has often put out RFPs for ad-hoc projects, and is increasingly doing so. These are now grouped in a common place. The repository is still sparse, but has two RFPs: one for [State Expiry](https://github.com/ethereum/requests-for-proposals/blob/master/rfps/state-expiry-initial-implementation-and-spec-development.md) and one for [expanding the address size](https://github.com/ethereum/requests-for-proposals/blob/master/rfps/expand-address-to-32-bytes-implementation-and-spec-development.md). These are two major issues we need to tackle where an external team could have a major impact. Both of these approaches are new and still experimental. We'll iterate to see what works best, and I'll share future updates here. ## Baikal :desert_island: Over the past few weeks, client teams have set up the Baikal devnet to test the EIPs which will be included in London. The network is now live and almost every client [1] can sync to it! The specification for the network is available [here](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/client-integration-testnets/baikal.md) and links the EthStats page and faucet. Here is a live look at it: ![](https://i.imgur.com/F59NAhs.png) It's worth noting that, difficulty bomb aside, the EIPs activated in Baikal are the ones which will be going into London. If you've been waiting to experiment with EIP-1559, or test the gas cost impacts of [EIP-3529](https://eips.ethereum.org/EIPS/eip-3529) on your application, now is the time! An update to the [JSON RPC spec](https://github.com/ethereum/eth1.0-specs/pull/47) is in the works and will define the post-1559 behavior of calls that return block and transaction data. We will also be spamming the network with transactions to properly test the `base fee` mechanism in 1559, and will likely fuzz the network to test all the new opcodes' behavior and gas cost changes. Several projects have asked for a testnet to experiment with 1559 on, so we will leave Baikal up at least until the public testnets fork, which brings us to... ## London :uk: On [AllCoreDevs#113](https://github.com/ethereum/pm/issues/309) we ironed out most of the final details for the London network upgrade :tada: First, the upgrade will consist of the following EIPs: - [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - [EIP-3198: BASEFEE opcode](https://eips.ethereum.org/EIPS/eip-3198) - [EIP-3554: Difficulty Bomb Delay to December 1st 2021](https://eips.ethereum.org/EIPS/eip-3554) - [EIP-3529: Reduction in refunds](https://eips.ethereum.org/EIPS/eip-3529) - [EIP-3541: Reject new contracts starting with the 0xEF byte](https://eips.ethereum.org/EIPS/eip-3541) This list is final and all EIPs have been moved to Last Call, so now is the time to review the EIPs and make sure your project is ready to support them. Here are the most recent changes: * EIP-1559 has had a few modifications to minimize potential breakage in the APIs. Specifically, it no longer modifies the block header to replace `gasLimit` by `gasTarget`. Instead, it keeps `gasLimit` and will require miners to manually increase the gas limit by 2x on the fork block to maintain the same network throughput. This will be made easy in client implementations and outreach to miners will begin soon. * EIP-3554 supercedes a previous proposal, [EIP-3238](https://eips.ethereum.org/EIPS/eip-3238), to have the difficulty bomb activate in December rather than Q2 2022, with the goal of either Shanghai or the Merge being ready before then. * EIP-3529 is the latest iteration of the "refunds removal" series that began with [EIP-3298](https://eips.ethereum.org/EIPS/eip-3298), which got superceded by [EIP-3403](https://eips.ethereum.org/EIPS/eip-3403), which is itself now superceded by 3529. * EIP-3541 is the latest addition. It does not do much by itself, but sets the stage for the future deployement of [EIP-3540](https://eips.ethereum.org/EIPS/eip-3540). Finally, the fork blocks for the various testnets have been set. Pulling them from [the spec](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/mainnet-upgrades/london.md), they are: > Ropsten: 10399301 (June 9, 2021) > Goerli: 4979794 (June 16, 2021) > Rinkeby: 8813188 (June 23, 2021) Once the first test network forks sucessfully, we will set a block for mainnet. Given the scope of the changes with EIP-1559, we want to ensure that it is rolled out smoothly on a testnet before hardcoding a mainnet block. The rationale being that it would be dangerous to change a mainnet block if an issue were to happen on a testnet. [2] ### EIP-1559 UI Call :fire: After the success of the first London Infrastructure call, [Trent will be organizing a second one](https://twitter.com/trent_vanepps/status/1393250203289927680) with a focus on wallet support for EIP-1559. The date and time haven't been set yet, but it is expected to happen around May 24-28. MetaMask, Argent, Status and others will be there to discuss the best approach to supporting EIP-1559 in their wallets. If your project also needs to add end-user support for 1559-styles transactions, reach out to Trent! ## Nocturne :moon: Over the past four weeks, client teams across both eth1 and eth2 have been working together, led by [@protolambda](https://twitter.com/protolambda), to prototype what a post-merge network could look like. In short, the current eth1 clients would become the execution engine of the system, processing transactions and building blocks, while the eth2 clients would become the consensus engine, providing ordering and finality for the chain. A total of seven client teams worked together to get this running during the Scaling Ethereum hackathon and the final deliverable was a functioning merged testnet, Nocturne. The network was able to process EVM transactions and use the beacon chain to request and finalize blocks, all while allowing any combination of execution & consensus engine. ![](https://i.imgur.com/h0s2atn.png) This is the first big step towards The Merge! There are still endless technical details to figure out, but [Rayonism](https://rayonism.io/) validated that the general architecture of post-merge clients is sound. Over the next few months, more testing infrastructure will be built and the actual PoW -> PoS transition spec will be finalized. Work is expected to slow down slightly on the merge as London and Altair are deployed, but will be the main focus of execution and consensus teams after these upgrades are live. While it's still far too early for dates, we can now safely say that the end of proof of work for Ethereum is in sight! --- Thanks for reading! Expect another one of these updates in a month or so, after London has been deployed to testnets. --- Published on May 17, 2021. [1] Nethermind, Geth, Besu & TurboGeth currently sync to Baikal, with OpenEthereum coming soon. [2] If we set a mainnet block `X` and then change it to `Y` because of an issue on a testnet, we risk having part of the network miss the upgrade and fork on block `X`.