--- tags: 1559 --- # 1559 Large State Performance Test ## Test Overview For background on the test, see our previous [write-up](https://hackmd.io/@timbeiko/1559-prelim-perf): > 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. Prior to starting the test, we confirmed that all nodes were in synced with a high number of peers. ### Ramp Up To ramp up the performance test, we began sending only legacy transactions to the network in large number, starting at block [167105](http://3.21.227.120:3000/block/167105), which got processed in 240ms by Nethermind. Then, we added transactions which increase the state size by adding storage slots to the smart contract (which started with `114736207` storage slots) in parallel. Average block time on the network was ~19 seconds (PoW targetting 15 seconds, but difficulty was too high for the mining instance). The two Besu nodes hosted in Paris and Sydney quickly fell behind head. Blocks it got stuck on: * http://3.21.227.120:3000/block/167187 * http://3.21.227.120:3000/block/167192 * http://3.21.227.120:3000/block/167194 The nodes kept processing blocks, albeit extremely slowly. All other nodes on the network kept processing the blocks without issues. See [below](https://hackmd.io/@timbeiko/1559-perf-test#Besu-Paris-amp-Sydney-Nodes-Troubleshooting) for more on the problematic Besu nodes. ### Main Test After the ramp up period, we went from sending only legacy transcations to a mix of 50-50 legacy & 1559 transactions on the network, along with maintaining the transactions that grew the network state. The Besu nodes that had fallen behind were restarted, but that did not immediately fix the problem. The first block for this main test was [167235](http://3.21.227.120:3000/block/167235), and [here](http://3.21.227.120:3000/tx/0xba2863f430ae216e9a82805bf8d99ba93986a682fc73557df37942d38f8f7f9a) is a 1559-style transaction from that block. The test ran up to block [167468](http://3.21.227.120:3000/block/167468), and throughout the ramp up and main test, `85289` storage slots were added to the smart contract, for a total of `114821496` at the end of the test. Some statistics about the test: * Duration: 60 minutes * Mean gas used: 43564661.93131868 * Sum of gas used: 15857536943 * Max gas used: 115763250 * Min gas used: 0 * Median gas used: 41286000.0 * Standard Deviation of gas used: 26262159.560433116 * Variance of gas used: 689701024777648.5 * 90% of blocks were 10M and more #### Observations > Nethermind processing blocks between 150-700ms, consistent with and without pruning. The restarted node caught up quickly (6 blocks/second, for 20-30 blocks). Memory and everything looks healthy. Using ~3 GB of RAM, using a 1GB cache > Besu using ~1.7 GB of RAM #### Screenshots of a Besu node's grafana dashboard during the test ![](https://i.imgur.com/y4pPFzR.png) ![](https://i.imgur.com/8vWRO05.png) ## Clients Info * Besu * Regions: AWS Ohio, Paris, Sydney * Instance type: t3.2xlarge * DB size: 280GB * Geth * Regions: AWS Ohio * Instance type: t3.2xlarge * DB size: ~280GB * Nethermind * Regions: Digital Ocean Germany, USA * Instance type: Linux, 4 CPU, 16GB RAM * DB size: 296GB ## Besu Paris & Sydney Nodes Troubleshooting After the test had concluded, we tried to understand what went wrong with the Besu nodes and, after one week of trying to reproduce the issue, we haven't been able to. We have re-run a similar test multiple times (with a similar mix of nodes from different clients in different regions) and have not seen any issues where Besu nodes get stuck slowly processing blocks. See a full write-up of the follow up test [here](https://hackmd.io/@abdelhamidbakhta/eip1559-perf-update). ## Test Video Recording https://consensys.zoom.us/rec/share/3zae8EBROau0DiR_-O7knj9moxCabqn5d-vFPapgbQnJems3tnUEvfDkFpKDnmeT.v4fKPfnYOURWwk3b Passcode: YN%a8tr+ ## Pre-Test Checklist - [X] Have nodes in >1 Region - [x] Paris - [x] Sydney - [x] Ohio - [x] Germany - [ ] Have metrics turned on for all nodes - [x] Besu - [x] Nethermind - [ ] Geth - [x] Have a list of enodes of all participating nodes - [x] Besu - [x] Nethermind - [x] Geth - [x] Make static nodes connections between all the nodes upfront - [x] Besu - [x] Nethermind - [x] Geth - [x] Confirm that any node is capable of sending one transaction of legacy and eip1559 types each to the network and get included in the block - [x] Besu - [x] Nethermind - [x] Geth - [x] Share the ethstats, Block Explorer addresses with all particpants - [x] Ethstats: http://3.21.227.120:3001/ - [x] Block Explorer: http://3.21.227.120:3000/ - [x] Have access to machine logs and be able to retrieve them when needed - [x] Besu - [x] Nethermind - [x] Geth - [x] Confirm that there are no disconnections between nodes when idle - [x] Besu - [x] Nethermind - [x] Geth - [x] Setup more than one node for tests - [x] Besu - [x] Nethermind - [x] Geth - [X] Confirm representative of each client team - [x] Besu - [x] Nethermind - [X] Confirm that the tx generator tool works ahead of the call (execute 2 - 3 blocks) - [X] (Nice to have) Define storage touching transactions for the test too? - [x] For accounts: ensure that we do not use same accounts over and over again, which would enable caching and falsify the results
Last changed by  
 
Tim Beiko
1427

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