--- tags: 1559 --- # The State of 1559 - Update 003 🔥 ## TL;DR 👀 * **Funding secured** 💰. The Ethereum Foundation has made a grant to ConsenSys and the 1559 multisig 🎉 * **Forked testnets** 🍴 We're exploring whether we could fork mainnet to build a large state 1559 testnet. * **Tools, tools, tools** 🛠 The Besu team has been hard at work creating a suite of tools to make interacting with the 1559 testnet easier. * **Escalator Tip Simulations** 🤖 Barnabé's team has a new notebook analyzing the impact of using EIP-2593-style fees as the tip component for 1559. * **Tons of content** 📝 We have a new writeup about 1559 UX, a slew of new tangential EIPs and an analysis of a 1559 implementation on another network. ## Funding Update 💵 The Ethereum Foundation has made a grant to ConsenSys and the [1559 multisig](https://gitcoin.co/grants/946/project-title-eip-1559-community-fund) to cover the cost of tooling, project management, communications, client implementations and bug bounties for EIP-1559! We're still in the final stages of finalizing the grant, but it should appear on-chain soon. These funds should be sufficient to get EIP-1559 to a frozen, well tested spec that we can shepherd through AllCoreDevs. It is worth emphasizing the impact that the community has had in making this happen, by donating in record numbers to the initial Gitcoin grant, voicing support for 1559 publicly and repeateadly, and helping with behind the scenes coordination and funding. Thank you all --- now back to work! ## Testnet Update ⛓ Over the past few months, we've been running a clique 1559 testnet to ensure teams' implementations are in consensus. It seems like we're 99% there! Nethermind has joined Besu in being a validator on the network (although there may be one bug left), and Vulcanize's Geth implementation is now in consensus with other Geth and Besu nodes, with Nethermind to follow shortly. There is a [public block explorer](http://eip1559-testnet.ops.pegasys.tech:3000/) for the testnet, as well as an [ethstats page](http://eip1559-testnet.ops.pegasys.tech:3001/) which shows the participating nodes. In parallel to this, the Besu team has tested its PoW implementation of 1559 on a Besu-only testnet, and found no issues. On this week's implementers' call, we agreed to try and fork mainnet to have a multi-client PoW testnet. This would be great because it would allow us to test the implementation against mainnet's large state, and would also let anyone with a mainnet account interact with the network. [It just may be more complicated than it seems](https://discord.com/channels/595666850260713488/692078615269212180/774317478440468491) 😅... but if we get it right, it could be useful to many other EIPs aside from 1559. More on that in the next update! ## Tooling Update 🛠 The Besu team has been building tools to make it easier for people to interact with the current 1559 testnet. You can try them out [here](http://eip1559-tx.ops.pegasys.tech/). The homepage allows you to submit both legacy and 1559-style transactions to the testnet. ![](https://i.imgur.com/DepnDg5.png) One cool thing to note: the legacy transactions are interpreted as 1559-style ones on the testnet, so the `gas price` needs to be higher than the `base fee` for it to be valid, and the `base fee` will be burnt from the gas price during execution 🔥 Another useful feature in the toolbox is the `base fee` API, which allows you to query the `base fee` from a specific block in the testnet. ![](https://i.imgur.com/XWmedzl.png) Aside from the transaction sender tool and `base fee` API, the toolbox also links the EIP itself, these updates, the network block explorer, the ethstats page, as well as instructions and genesis files for nodes to join the testnet. For a complete demo of the tool, you can watch the latest implementers' call recording, [starting 12:00](https://youtu.be/LgvUnCdMXQg?t=720). ## Simulations Update 🤖 Barnabé and his team have released [a new notebook](https://nbviewer.jupyter.org/github/barnabemonnot/abm1559/blob/master/notebooks/floatingEscalator.ipynb) simulating what EIP-1559 with an "escalator tip" could look like. The "escalator tip", inspired by Dan Finlay's [EIP-2593 proposal](https://eips.ethereum.org/EIPS/eip-2593), adds a second dimension, time, to how users can express their tip. In other words, it lets users specify not only the minimum and maximum tip they would like to pay to miners, but also the duration over which they would like to increase it. For example, a user who is in a hurry could say they are willing to give a 10 gwei tip as long as their transaction is included in the next two blocks [0], while a user who doesn't mind waiting but wants to eventually get included could specify their price range, say 1-20 gwei, but over a different time horizon, say, 100 blocks. The notebook compares the strategies of these two classes of users: **hurrying users**, who _"set the escalator slope to their cost for waiting one more unit of time, and balk whenever their current value is negative"_, and **fixed duration users** who *"set the length of the escalator to the same value, and set the slope to ramp as much as possible within that length."* Barnabé gave a quick walkthrough of the notebook on this week's implementers call, [starting at 5:11](https://youtu.be/LgvUnCdMXQg?t=311). ## Content & Other Updates 📝 * The Besu team has started writting EIPs to update the various JSON-RPC calls that would be impacted by EIP-1559. So far, we wrote 4 EIPs, with roughly 5 more to go. The full list is available on the [Mainnet Readiness Checklist](https://github.com/ethereum/pm/blob/master/Fee%20Market%20Meetings/mainnet-readiness.md#eips--reference-tests). * Micah Zoltu has written [a great explainer of the UX benefits of EIP-1559](https://medium.com/@MicahZoltu/dc9c8717906). These can sometimes be abstract to quantify, so Micah's post walks through a specific scenario step by step, and highlights how 1559 would have made it better. * Hasu has another thorough [EIP-1559 analysis](https://insights.deribit.com/market-research/transaction-fee-economics-in-near/), this time about NEAR protocol's implementation. * I gave an [EIP-1559 overview talk](https://www.youtube.com/watch?v=IEQPSJbZsq0) at ETHOnline a few weeks ago. ## Next Steps ✅ I've hinted at these throughout the update, but for clarity, here are the things we'll be working on next: 1. Getting a "large state" proof of work testnet up and running, whether by forking mainnet or starting one from scratch; 2. Trying to address the potential issues around transaction pool management. [This document](https://hackmd.io/unbJUt-HQgStvwmpLPsXsQ) aims to capture the strategies taken by implementing teams; 3. Keep improving the tooling around 1559 to make it easier for non-implementers to try it out and provide feedback; 4. Slowly keep working on the various less-urgent TODOs, such as writting the JSON RPC EIPs, adding reference tests, and so on. Hopefully, by the next update, we've got a way for people wanting to experiment with 1559 to claim testnet ETH on a live network which has similar conditions to mainnet :crossed_fingers: Again, thank you for reading! --- [0] The tip would then be set to 5 at the block when the transaction is submitted, and increment to 10 on the next block. The transaction would be invalid afterwards.
Last changed by  
 
Tim Beiko
4443

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