--- 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
Last changed by  
 
Tim Beiko
7722

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