--- 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`.
Last changed by  
 
Tim Beiko
5092

Read more

censorship.wtf

NYC Prague Istanbul Speaker Email Topic3:00 9:00 11:00 Tina Zhen (Istanbul Host) tina@flashbots.net Istanbul Stage Opening + Chapter 0: Bird’s Eye View of the Problem Space3:05 9:05 11:05 Juan Benet juan@protocol.ai Preventing Digital Totalitarianism3:25 9:25 11:25 Vitalik Buterin v@buterin.com Hardening the Ethereum Ecosystem Across the Stack3:45 9:45 11:45 Vitalik Buterin & Juan Benet v@buterin.com, juan@protocol.ai Mutual Q&A4:00 10:00 12:00 Sreeram Kannan sreeram@eigenlabs.org Increasing the Observability of Attestor Censorship4:20 10:20 12:20 Costanza Gallo costanza@ethswarm.org Censorship From 0 to 604:40 10:40 12:40 Tim Beiko (Prague Host) tim@ethereum.org Prague Stage Opening + Chapter 1: Deconstructing the Ethereum L1 CR Problem4:45 10:45 12:45 Danno Ferrin dannoferrin@gmail.com Mind Your Business: State Proofs and Transaction Verification5:05 11:05 13:05 Alon Muroch alon@blox.io Improving Censorship Resistance Using DVT5:25 11:25 13:25 Nixo nixorokish@pm.me Are Solo Stakers Valuable for Censorship Resistance?5:45 11:45 13:45 Sebastian Bürgel sebastian.buergel@hoprnet.org The Dark Endgame of CL, EL & Application Layers Without IP-level Privacy6:05 12:05 14:05 Toni Wahrstätter info@toniwahrstaetter.com Exploring Censorship Across The PBS Stack6:25 12:25 14:25 Sajida Zouarhi Observability and Censorship in Ethereum6:40 12:40 14:40 Tim Beiko (Prague Host) tim@ethereum.org Chapter 2: Exploring Alternatives in Application Infrastructure6:45 12:45 14:45 Henri Binsztok henri@okcontract.io Alternate Frontends: Why and How7:05 13:05 15:05 Yoav Weiss yoav@ethereum.org Account abstraction is easy… unless you care about censorship resistance7:25 13:25 15:25 Garrett MacDonald g@rre.tt Alternate Data Transport Layers7:45 13:45 15:45 Tina Zhen (Istanbul Host) tina@flashbots.net Chapter 3: Surveying the Approaches from L2 Perspectives7:50 13:50 15:50 Nashqueue N/A Exploring Attacks in the Modular Rollup World8:10 14:10 16:10 Santiago Palladino santiago@aztecprotocol.com Deep Dive into Private State and Execution of Smart Contract8:30 14:30 16:30 Omar Espejel espejel@starknet.org Starknet’s Approach to Sequencer Censorship8:50 14:50 16:50 Ed Felten ed@offchainlabs.com Improving Deadline Protocols via Censorship Detection9:10 15:10 17:10 Tina Zhen (Istanbul Host) tina@flashbots.net Chapter 4: Weaving Theories into Practice9:15 15:15 17:15 Mallesh Pai An Economic Definition for Censorship Resistance9:35 15:35 17:35 Justin Drake justin@ethereum.org Weak Censorship Resistance9:55 15:55 17:55 Venkatesh Rao vgururao@gmail.com Beyond Exit and Voice

12/20/2023
AllCoreDevs Updates

Updates about Ethereum core protocol development.

12/12/2023
Protocol Guild Architecture

Some disclaimers: not a solidity dev, probably very inefficient/exploitable/etc. Very rough mental model! Architecture Let's start with a rough diagram: I imagine the guild having the following components: Receipients list: a mapping of all eligible receipient addresses, along with their weights/points/etc. We should assume this list and weights can change over time. Epochs: a "time bucket" to better subdivide grant streams and to use as a reference point for list updates. This could maybe be done "each block", but feels even more inefficient. Also, perhpas these epochs store some metadata about whether tokens for a specific recipient have been claimed in this epoch. Streams: a donation to the guild. Streams need to specify which epoch to start at, as well as a duration/vesting period. A number of token is sent alongside the stream, and every epoch makes available stream total / duration tokens, until the current epoch > start epoch + duration. It may be possible to have tokens pre-vest partially by having start epoch be earlier than the current epoch.

10/8/2022
Besu Execution Client Incentive Program

[toc] Overview The Ethereum Foundation is launching an Execution Layer Client Incentive Program (ELCIP). This program will provide execution-layer client teams with locked ETH in the form of live validators to be released according to certain milestones, including post-merge performance and progress towards enabling withdrawals from the beacon chain. Program Goals & Eligibility The program aims to provide long-term support and incentives for teams towards maintaining reliable clients and a healthy network overall. For client teams to be eligible, they should already be contributing to the general development of Ethereum and intend to support the upcoming transition to proof of stake. Throughout the program, teams will need to maintain certain levels of performance to be eligible for the rewards. More on this below.

9/15/2021
Read more from Tim Beiko
Published on HackMD