# fusaka-devnet-1 specs :::info :mega: fusaka-devnet-1 targets to launch on 9th June 2025 and goes down on 17th of June 2025 ::: :::info ~~We aim to test all validator custody features in this devnet~~ We aim to test all validator custody features in the [next devnet](https://notes.ethereum.org/@ethpandaops/fusaka-devnet-2). ::: :::info Meta EIP status tracker: https://notes.ethereum.org/@marioevz/fusaka-sfi-tracker ::: ### Changes include: - Data column sidecars by root - validator custody (optional) - distributed blob building - shifting cell proof computation to transaction sender ### Discussion: - Who is going to work on EELS/EEST for proof computation to tx sender? ## EIP List for fusaka-devnet-1 The list below links the specific commit versions of the EIPs included in devnet-1. Fusaka mega [EIP-7607](https://eips.ethereum.org/EIPS/eip-7607) [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://github.com/ethereum/EIPs/blob/ed447a1105230659fdce084710ae36bc309ff99f/EIPS/eip-7594.md) [EIP-7823: Set upper bounds for MODEXP](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7823.md) [EIP-7825: Transaction Gas Limit Cap](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7825.md) :new: [EIP-7883: ModExp Gas Cost Increase](https://eips.ethereum.org/EIPS/eip-7883) [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) [EIP-7917: Deterministic proposer lookahead](https://eips.ethereum.org/EIPS/eip-7917):new: [EIP-7918: Blob base fee bounded by execution cost](https://eips.ethereum.org/EIPS/eip-7918) :new: ### Test Releases **Consensus Specs:** [v1.6.0-alpha.1](https://github.com/ethereum/consensus-specs/releases/tag/v1.6.0-alpha.1) :heavy_check_mark: **Exection Spec Tests:** [[email protected]](https://github.com/ethereum/execution-spec-tests/releases/tag/[email protected]) :heavy_check_mark: ### Spec versions required & Open PRs **Beacon Metrics** [PeerDAS metrics: add data column, kzg, custody metrics](https://github.com/ethereum/beacon-metrics/pull/14) Open :exclamation: **Beacon API** [`produceBlock` and `publishBlock`: Remove blobs and KZG proofs](https://github.com/ethereum/beacon-APIs/issues/519) Merged :heavy_check_mark: **Builder Specs** **Consensus Specs** [Basic validator custody](https://github.com/ethereum/consensus-specs/pull/3871) Merged :heavy_check_mark: [EIP-7917: Deterministic proposer lookahead](https://github.com/ethereum/consensus-specs/pull/4190) Merged :heavy_check_mark: [Clarify node behavior when validator custody changes](https://github.com/ethereum/consensus-specs/pull/4320) Merged :heavy_check_mark: [Remove Deneb/Electra from blob schedule and default to Electra limit](https://github.com/ethereum/consensus-specs/pull/4341) Merged :heavy_check_mark: [Validator custody: Increase only and optional dynamic backfill.](https://github.com/ethereum/consensus-specs/pull/4357) Merged :heavy_check_mark: [EIP-7917: Refactor return types from List to Vector](https://github.com/ethereum/consensus-specs/pull/4361) Merged :heavy_check_mark: **Execution APIs** **Execution Spec PRs** [Update EIP-7892: harden the spec with p2p details.](https://github.com/ethereum/EIPs/pull/9840) Merged :heavy_check_mark: ~~[Update EIP-7883: Assume minimal base/mod length of 32](https://github.com/ethereum/EIPs/pull/9855) Open :exclamation:~~ **Execution Spec Tests PRs** [feat(tests): peerdas tracking issue](https://github.com/ethereum/execution-spec-tests/issues/1301) Open :exclamation: ### Validator custody | Client | Status | |------------|---------| | Teku | Supports with backfill | | Nimbus | Not yet supported | | Prysm | Supports without backfill | | Lighthouse | Not yet supported | | Grandine | Not yet supported | | Lodestar | Supports without backfill | ## Kurtosis Interop Conifg (Pre-devnet testing) ```yaml participants_matrix: el: - el_type: nethermind el_image: ethpandaops/nethermind:fusaka - el_type: reth el_image: ethpandaops/reth:fusaka-devnet1 - el_type: besu el_image: ethpandaops/besu:fusaka-devnet-1 - el_type: geth el_image: ethpandaops/geth:fusaka-devnet-1 - el_type: erigon el_image: ethpandaops/erigon:fusaka-devnet-1 - el_type: nimbus el_image: ethpandaops/nimbus-eth1:fusaka-devnet-1 cl: - cl_type: lodestar cl_image: ethpandaops/lodestar:nc-test-peerdas-7917 supernode: true - cl_type: lighthouse cl_image: ethpandaops/lighthouse:unstable supernode: true - cl_type: prysm cl_image: ethpandaops/prysm-beacon-chain:fusaka-devnet-1 supernode: true - cl_type: grandine cl_image: ethpandaops/grandine:peerdas-fulu supernode: true - cl_type: teku cl_image: ethpandaops/teku:master supernode: true network_params: fulu_fork_epoch: 1 bpo_1_epoch: 2 bpo_1_max_blobs: 12 bpo_1_target_blobs: 9 bpo_2_epoch: 3 bpo_2_max_blobs: 6 bpo_2_target_blobs: 4 bpo_3_epoch: 4 bpo_3_max_blobs: 9 bpo_3_target_blobs: 6 bpo_4_epoch: 5 bpo_4_max_blobs: 18 bpo_4_target_blobs: 12 bpo_5_epoch: 6 bpo_5_max_blobs: 9 bpo_5_target_blobs: 6 withdrawal_type: "0x02" genesis_delay: 40 additional_services: - dora - spamoor #pull through cache to not get rate limited by dockerhub docker_cache_params: enabled: true url: "docker.ethquokkaops.io" spamoor_params: image: ethpandaops/spamoor:master max_mem: 4000 spammers: - scenario: eoatx config: throughput: 200 - scenario: blobs config: throughput: 20 ``` ### Testing: #### EIP-7594: PeerDAS - Peer Data Availability Sampling * Validator custody testing - kurtosis - add validators and verify cgc value changes * This can be easy by setting validators to 0x02 credential and make manual deposits * MEV workflow testing - pending of flashbots/mock builder * Minimal spec testing * Minimal spec testing with mev workflow * Validator custody testing with assertoor. Have a new assertoor test where 0x02 credentials are toped up 32eth at a time and monitoring the node's cgc value to ensure that its going up as expected. * Sync testing script found [here](https://github.com/ethpandaops/kurtosis-sync-test/blob/main/README.md#peerdas-sync-test) * Figure out proper cgc behaviour, do we want the cgc value to change before fulu? Otherwise we might be without supernodes during fork transition. This would really stress the actual fork * Finalized root bug - what should the genesis root hash be? @potuz @hangleang * Prysm <> Grandine peering bug * What steps can we do to have resource optimization? We see significantly more ram usage with fulu active. * We see very stable 9 blob spamming with pre fulu. * Once fulu active, with the same constant load, we see significantly less blobs included. * We might need some assertoor test for checking the content of blob pool and see if a proposer have included all the blobs that is has seen locally. And then we can investigate if there are any client pairs that are struggling with local blob building with peerdas. #### EIP-7825: Transaction gas limit cap * Spamoor - create a new scenario with aiming to have 30M+ in a single transaction - @pk910 * Assertoor - verify that all ELs reject such tx * Malicous test - get a node that accepts 30M tx+ and see if we can propagate it in the network. Spamoor config: ```yaml= # wallet settings seed: gasburnertx-5 # seed for the wallet refill_amount: 5000000000000000000 # refill 5 ETH when refill_balance: 1000000000000000000 # balance drops below 1 ETH refill_interval: 600 # check every 10 minutes # scenario: gasburnertx total_count: 0 throughput: 1 max_pending: 2 max_wallets: 40 rebroadcast: 120 base_fee: 20 tip_fee: 2 gas_units_to_burn: 31000000 client_group: "" ``` Besu :heavy_check_mark: ``` 04 Jun 12:06:51 | Rejected invalid block 65 (0xcc465caeaca9e0a764bc1229350a61890ae76668a4ee83b19b3f1a15b6bde261), ExtraData: Nethermind v1.33.0a, reason: TxGasLimitCapExceeded: Gas limit 32050000 exceeed cap of 30000000. ``` Nethermind: #### EIP-7823, EIP-7883, EIP-7918 * Hive tests #### EIP-7892: Blob Parameter Only Hardforks * Kurtosis tests, going up, down with max blobs * Figure out final form of BPO [format](https://github.com/ethereum/EIPs/pull/9623) * Figure out future forks in blob schedule planning * Figure out if we want hard fork names in the blob schedule fields. * Test future compatibility, see if we can start with fulu genesis and higher BPO at genesis. * out of order fork execution issues, glamsterdam becoming active without triggering bpos #### EIP-7917: Deterministic proposer lookahead * Kurtosis local test to determine that interop works among all clients ## Client Interop Readiness Manu's test scenarios: https://hackmd.io/@manunalepa/BJzNsCnvyx ### Prysm | Scenario | Grandine | Lighthouse | Lodestar | Nimbus | Prysm | Teku | | -------- | -------- | ---------- | -------- | ------ | ----- | ---- | | 1a | :question: | :question: | :question: | :question: | :question: | :question: | | 1b | :question: | :question: | :question: | :question: | :question: | :question: | | 2a| :question: | :question: | :question: | :question: | :question: | :question: | | 2b | :question: | :question: | :question: | :question: | :question: | :question: | | 3a | :question: | :question: | :question: | :question: | :question: | :question: | | 3b | :question: | :question: | :question: | :question: | :question: | :question: | | 4 | :question: | :question: | :question: | :question: | :question: | :question: | ## Reference spec for previous devnet: https://notes.ethereum.org/@ethpandaops/fusaka-devnet-0 ### Open future Questions: - Alternately, should a pre-determined blob increase schedule triggered by a BPO mechanism (as proposed [here](https://hackmd.io/@ralexstokes/blob-acc-2025#Blob-schedule-for-Fusaka)) be included in fusaka-devnet-0?
Last changed by  
 
ethpandaops For the ethpandaops team, devops for EL/CL layers
1074

Read more

fusaka-devnet-3 specs

:::info :mega: fusaka-devnet-3 targets to launch on 7th Jul 2025 ::: :::info We aim to test all validator custody features in this devnet ::: :::info Meta EIP status tracker: https://notes.ethereum.org/@marioevz/fusaka-sfi-tracker

7/3/2025
fusaka-devnet-2 specs

:::info :mega: fusaka-devnet-2 targets to launched on 26rd June 2025 ::: :::info We aim to test all validator custody features in this devnet ::: :::info Meta EIP status tracker: https://notes.ethereum.org/@marioevz/fusaka-sfi-tracker

6/27/2025
Introduction

The idea is to look into vouch/dirk to verify the overhead and beenefits of it against a standard validator client with baked in keys. Current setup: Validator client with direct keys attached to it. Scale VC horizontally given a validator count limit. Wanted setup: Distributed shares of the validator key across different nodes with a given signing threshold (e.g. 3/5 or 3/4)

6/25/2025
Berlinterop perf

Number of commits on performance branches: 58 Added 8 new tests (Json lib stress test, emtpty payload, heavy ECAdd from Marius) (On branch) added support for EEST zkEVM tests (28 test suites - 100+ newPayloads) Nimbus-EL contribution to gas-benchmarks! Perfnet prevented from major issues which were unable to be spotted on benchmarks purely. GOAL from Monday: *EL clients above 20Mgas/s *[ACHIEVED] Monday VS Friday worst WITHOUT Modexp:

6/13/2025
Read more from ethpandaops
Published on HackMD