# Performance devnet track **People to bother with questions:** Pari (ethpandaops), Kamil (nethermind), Carlos (nethermind) There are **3** major components to this track: - [`OPCODE` benchmarks on all clients](https://notes.ethereum.org/@ethpandaops/berlinterop-perf#OPCODE-benchmarks) - [State growth related benchmarks](https://notes.ethereum.org/@ethpandaops/berlinterop-perf#State-growth-related-benchmarks) - [Security of higher gas limits](https://notes.ethereum.org/@ethpandaops/berlinterop-perf#Security-of-higher-gas-limits) ## Overall goal of the track: - What changes or EIPs do we need in Fusaka? (Besides the Modexp repricing) - Figure out a timeline and blockers for the path to 100M gas, What needs a fork and what needs client attention? There are different approaches that we would need to adequately test each component. The rest of the document will go into details on the tools and devnets that client teams would need to pay attention to. There is an issue tracker used by the Nethermind team found [here](https://github.com/NethermindEth/eth-perf-research/issues). The issue tracker will be used to track various workstreams in the future. ## `OPCODE` benchmarks on all clients We want to benchmark how performant a client is for each `OPCODE`. This requires us to test it with `cached` as well as `uncached` modes since the outputs tend to vary vastly. **Tooling:** - [gas-benchmarks](https://github.com/NethermindEth/gas-benchmarks): Tool that allows us to define a test, warmup conditions, iterations and pushes the data in a SQL database for visualization. - [perf-devnet-1](https://perf-devnet-1.ethpandaops.io/): Mainnet shadowfork to benchmark higher gas limits. Currently at 100M gas. Relatively realistic loads. - [perf-devnet-0](): Older but fresh network, focussed on simply aimed at getting largest gas limit numbers. - [spamoor](https://github.com/ethpandaops/spamoor): Tool to send transactions based on scenarios you want to see. **Instructions:** - Please push your changes to a branch in your client teams repository called `performance`, the tool will pick up the change and the dashboard will reflect the changes once testing is done. - Reach out to Pari(ethpandaops), Marcin(nethermind) or Carlos(nethermind) for updating images on perf devnets. Funds can be sent on request. **Dashboards:** - [Gas limit monitoring](https://grafana.observability.ethpandaops.io/d/fel9iensrsdtsa/gas-limit-monitoring?orgId=1&from=now-24h&to=now&timezone=browser&var-posgreSQL=benuragv7iuwwb&var-ClientName=$__all&var-TestTitle=$__all) - [perf-devnets](https://grafana.observability.ethpandaops.io/dashboards/f/cenuglw1iqtxca/performance): Please reach out to get your client team dashboard added here. **Goal:** - Have the worst performing `OPCODE` of every client above 20M by the end of the week (Exception of Modexp). 20M implies we can have an upper limit of 3s blocks for 60M gas limit. - What tests are missing? How do we better integrate with STEEL/EEST? ## State growth related benchmarks We need a network with a significantly larger state that helps us identify scaling and sync issues once state is larger. **Tooling:** - Bloatnet: Devnet that uses a forked geth to generate a large state (aim is 2x mainnet). - [spamoor](https://github.com/ethpandaops/spamoor): Tool to send transactions based on scenarios you want to see, including bloating state. **Instructions:** - Please let us know which branch we should use to test on bloatnet. Reach out to Pari(ethpandaops), Carlos(nethermind), Gballet(geth). - Please go through the test case doc [here](https://hackmd.io/ob66NuW9QBORHLz7emhSCw#Geth-desired-test-cases) and add test cases. **Dashboards:** - [Bloatnet bootnode dashboard](https://perfnet.core.nethermind.dev:8084/d/denslx0obry0wa/go-ethereum-metrics?orgId=1&from=now-6h&to=now&timezone=browser&var-chain=bloatnet-bootstrap&var-instance=bloatnet-bootstrap-0&var-quantile=0.5&var-query0=&var-prometheus_ds=prometheus_ds_1&refresh=10s) **Goal:** - Have a comprehensive plan for what data to collect and how we plan on collecting it in the next weeks. Doc for co-ordination [here](https://hackmd.io/ob66NuW9QBORHLz7emhSCw). - Have a plan for how we do timed RPC tests and understanding the degradation we will see at higher state sizes. - What is our plan for Archive nodes long term? # Security of higher gas limits The security of higher gas limits is not only limited to `OPCODE` pricing or state size, but it also includes CL side considerations. This track is aimed at looking at the whole picture of Ethereum at higher limits with the security lens. **Tooling:** - [Table with CL worst case sizes](https://notes.ethereum.org/cYhT5iptTvWi3ygQ2EZRVA?view) - State tests **Instructions:** - Please reach out to Pari(ethpandaops), Marius(geth) or to Toni (protocol prototyping) for disucssions on security angles we should look at. **Ideas:** - Look into JSON overhead for larger blocks - Attempt 3s-6s block processing delays in EL, see effect on network stability - The [Pectra blob retrospecitve blogpost](https://ethpandaops.io/posts/eip7691-retrospective/) talks about difficulties going over 60M with 9 blobs. How do we gather data to validate this? Is this an acceptable tradeoff? - We can theoretically have 8192 deposits in one block with 256M gas. This is over the limit the CL can process. So we need to figure this out in the next fork or two. **Dashboards:** - Placeholder for a dashboard showing CL max payload size over time **Goal:** - What are acceptable gas limits taking the CL side into consideration? Are there processing bottlenecks we aren't aware of.