Censorship resistance is core to Ethereum: a true "world computer" can't choose to exclude specific users or valid programs. The protocol is designed for permissionless access and use. Ensuring no single party can arbitrarily impose restrictions on it is of critical importance. As Ethereum becomes more consequential and its growing ecosystem complexifies, opportunites & pressures to censor increase. While these risks do get discussed, conversations on censorship resistance often center on a specific part of the stack --- censorship.wtf was an attempt at approaching the topic head on. During Devconnect 2023, a full day was spent discussing censorship resistance in the context of Ethereum L1, rollups, applications, infrastructure, hardware, and more.

Latest update Past updates Update 015 Update 014 Update 013 Update 012 Update 011 Update 010 Update 009

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.

[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.

Ethereum Governance refers to how changes are made to the Ethereum protocol. Before diving into the topic, it is worth highlighting that while there are formal and informal processes for how changes get made to the Ethereum protocol, how the protocol is used is permissionless. In other words, for social and technical reasons, a high level of coordination is needed to make changes to Ethereum, but anyone wishing to use Ethereum or build an application on it is free to do so as they please, as long as they follow the rules of the protocol. Stakeholders There are various stakeholders in the Ethereum community, each of which plays a role in the governance process. Starting from the stakeholders closest to the protocol and zooming out, we have: Protocol Developers (a.k.a. "Core Developers"): these people maintain the various Ethereum implementations (e.g. go-ethereum, Nethermind, Besu, Erigon at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar at the consensus layer); EIP Champions: these people propose changes to the Ethereum protocol, in the form of Ethereum Improvement Proposals (EIPs); Miners/Validators: these people run nodes which can add new blocks to the Ethereum blockchain; Node Operators: these people run nodes which propagate blocks and transactions, rejecting any invalid transaction or block that they come across; Application/Tooling Developers: these people write applications that are run on the Ethereum blockchain (e.g. DeFi, NFTs, etc.) or build tooling to interact with Ethereum (e.g. wallets, test suites, etc.);

EIP-1559 is fairly complex. This post is an attempt to explain its benefits as simply as possible. Note: the drawbacks of 1559 are not in scope for this post. These are left to the "Security Considerations" section of the EIP. Since originally writting this post, the official terms in the EIP have changed. For reference, baseFeePerGas == BASE FEE, maxFeePerGas == maxFee == FEE CAP, maxPriorityFeePerGas == priorityFee == tip/miner tip/etc.. EIP-1559 Benefits EIP-1559 is a proposed change to Ethereum's fee market. The proposal would provide UX, economic and security benefits to Ethereum. UX Benefits Generally Quicker Transaction Inclusion Under the current fee market, transactions on Ethereum often end up pending for a long time. Because blocks are always full, each new block is filled with the highest paying transactions since the last block. If a transaction is not immediately included (usually requiring a very high gas price), it is hard to estimate when it will be included.

The eth1.0-apis repository is not versioned (yet!) and hence it can be hard to track the various changes introduced by EIP-1559. Here is a list to make this easier. General Comments EIP-1559 introduces a new transaction type (0x02) and adds a field to the block header (baseFeePerGas). At a high level, anything which either returns a transaction or a block will be affected post-1559. API Changes The following APIs calls are changed with the introduction of EIP-1559: eth_call

Welcome to another AllCoreDevs update :wave: TL;DR :eyes: London is going live on block 12 965 000, there are several watch parties organized 📺 A bug was found (and fixed!) on Ropsten. Relatedly, the EF is hiring an additional test engineer. Apply here 🛠 The Merge now has an EIP: EIP-3675 📝 We're considering a few different roadmap scenarios, but all of them include getting merge testnets up and running ASAP 💪🏻 London 🇬🇧

TO BE POSTED ON FORUM WHEN "Decentralizing Lido" POST LIVE As mentioned in a recent post, one challenge for Lido to decentralize the process of onboarding new validators is measuring validator performance over time and across different node operators. Luckily, this is something that can be done today, for Lido's current set of node operators. Having these measurements would make explicit where, in practice, the "bar" is set today, and can be used as a benchmark for a future, more open, node operator selection process. LEGO would therefore like to request proposals to build an easily accessible dashboard where the Lido community can measure the performance of validators. The dashboard should have information on all current Lido node operators, and track the following metrics:

Various write ups, simulations, documentation, and more related to EIP-1559. Explainers & Analyses General Overview 📺 "Can ETH Become DEFLATIONARY? EIP 1559 Explained" by Finematics "All You Need to Know About EIP-1559" by Uncommon Core "Why 1559?" by Tim Beiko "Fixing the Ethereum Fee Market" by Eric Conner "EIP 1559 and Fee Structure" by Vitalik Buterin

TL;DR :eyes: London is getting activated on testnets over the coming weeks. JSON RPC changes have been documented, and a cheatsheet is available for projects adding 1559 support; The Merge now has a proper spec on the eth2 side. A similar document for eth1 is being worked on, along with an executable spec for eth1; While nothing is decided yet, there has been progress on two candidate EIPs for the Shanghai upgrade: audits for EIP-3074, and a roadmap for EIP-3540. London Testnets :uk: Over the next few weeks, the London upgrade will be activated across Ethereum testnets: Ropsten will come first, around June 24th, then Goerli is scheduled for June 30th and finally Rinkeby will upgrade July 7th [0]. A list of the specific upgrade blocks and London-compatible client versions can be found here. If you haven't already done so, now is the time to upgrade your testnet node! After the testnet forks, we expect to run tests where we bombard the networks with transactions to ensure that everything is working smoothly. Once client developers are confident in London's deployment across testnets, a block for the mainnet fork will be set. Because of the difficulty bomb, this realistically needs to happen in the next 300,000 to 400,000 blocks.

Historical Priority Fee Data Return a list of the lowest accepted priority fee in a block for the past N blocks Histogram? First decile instead of lowest? Client should filter out any blocks that were full, because in such cases the miner likely left transactions that could have been included in the pending pool, which means we may not actually see the miner minimum in the included transactions. Consider: Can we do anything to filter out miner "own" transactions? At the least, we should filter out any transactions with a 0 priority fee. Historical Gas Used Data

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:

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 ☀️ Hiring Updates :hammer_and_wrench:

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 and my Twitter summaries. 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 👀

Call agenda: https://github.com/ethereum/pm/issues/290 Design doc: https://hackmd.io/@n0ble/ethereum_consensus_upgrade_mainnet_perspective Potential issues What happens if the Application client crashes? Can it ping the Consensus client or does it need to wait for a NewHead message? Post-1559, we can have blocks with the same state root. This is more likely post-merge given the block subsidy is 0. Application clients need to be able to handle this This may already be possible on Goerli. We should investigate what happens.

Latest update Why 1559? 1559 Resources List Past Updates Update 007 Update 006 Update 005 Update 004

TL;DR 👀 1559 has been acceped in London 🇬🇧🎉 This is the last 1559 update... but something new is coming soon 🔜 One Last Update 👋🏻 Good news first: after over 2 years since it was originally proposed, and one year since we've revived the effort, EIP-1559 has been accepted into an Ethereum network upgrade. London, which will come sometime this summer, will bring EIP-1559 to mainnet 🍾 That being said, there is still a lot of work to do between now and then: all clients need to finish their implementations against the latest spec, reference tests needs to be written, adjacent EIPs for JSON RPC endpoints need to be created, etc. At this point, though, the work on 1559 moves from being a "working group side effort" to becoming part of the "AllCoreDevs process".

Test Overview For background on the test, see our previous write-up: As part of the testing process of 1559, we wanted to determine whether having “200% full” blocks on a network with a state size comparable to mainnet would cause any issues. To test this, we’ve created a tool which can generate a new network with an arbitrary number of accounts and contract storage slots and a tool to then spam ethereum network with a large number of transactions. This time, a network with 4 Besu nodes (2 Ohio, 1 Paris, 1 Sydney), 4 Geth nodes (Ohio) and 2 Nethermind nodes (1 Germany, 1 USA) was used. Another change between this test and the previous one is that throughout the test, we sent both transactions which transferred ether and transactions which grew the state size, compared to only transfer in the preliminary test.

TL;DR 📝 Large state testing is 99% done, expect a write-up soon 🔜 EIP-1559 has been updated to be Berlin-compatible 🇩🇪 We'll be proposing EIP-1559 for inclusion in the London Hard Fork during the next AllCoreDevs call 🇬🇧 Note: this doesn't guarantee a decison will be made on the next call, or that it will be accepted! Miners are pushing back against EIP-1559 and others are pushing back against the pushback: lots of new write ups from both sides, and a community call is planned for this Friday ⛏ A few bonus posts that were too good to ignore are linked at the end of this update 👇🏻