---
# System prepended metadata

title: EPF6 - Week 14
tags: [Ethereum Protocol Fellowship 6]

---

# EPF6 - Week 14

## Overview
- Attended core dev call and shared updates
- Reviewed my mentor's comments and continued code polishing, as the Kurtosis swap had broken several parts of the code
- Focus shifted to pre-deployment validation of network configs: adapting parameters from multiFork.test.ts into YAML and testing them inside Kurtosis.
- Investigated how `clientOptions` map into Kurtosis `vc_extra_params` and how to support MEV-related flags.

## Main points

- **Transforming test configs**

    - Explored the idea of transforming each `.test.ts` into a `.yml` equivalent, or at least emulating them as closely as possible.
    - **Goal**: ensure the YAML config mirrors the exact per-node options used in the TypeScript tests.

- **Testing `clientOptions` parameters**

    - From `multiFork.test.ts`:
        ```typescript
        clientOptions: { "builder.selection": "default" }
        clientOptions: { "builder.selection": "executiononly" }
        ```
    - These options configure Lodestar’s block builder selection strategy, tied to MEV and block building flow
    - Confirmed that mining: true in the execution client (Geth) is necessary to keep the chain progressing

- **Discord feedback on Kurtosis config**

    - Flags like `"builder.selection"` don’t exist under Lodestar beacon CLI but do under the **validator client (VC)** reference list
    - Solution: switch from `cl_extra_params` → `vc_extra_params`
    - Mis-typed flag `builder.blinded-local` should be corrected to `--blindedLocal=true`
    - To spin up MEV stack, must clarify `mev_type: flashbots`

- **Updated YAML tested**

    ```yaml
    participants:
      - el_type: geth
        cl_type: lodestar
        count: 1
        vc_extra_params: ["--builder.selection=default"]
        el_extra_params: ["--mine"]

      - el_type: geth
        cl_type: lodestar
        count: 1
        vc_extra_params:
          ["--builder.selection=default", "--blindedLocal=true"]

      - el_type: geth
        cl_type: lodestar
        count: 1
        vc_extra_params: ["--builder.selection=executiononly"]

      - el_type: geth
        cl_type: lodestar
        count: 1
        vc_extra_params: ["--builder.selection=default"]

      - el_type: geth
        cl_type: lighthouse
        count: 1

    network_params:
      preset: minimal
      altair_fork_epoch: 2
      bellatrix_fork_epoch: 4
      capella_fork_epoch: 6
      deneb_fork_epoch: 8
      electra_fork_epoch: 10
      genesis_delay: 120

    mev_type: flashbots
    ```

- **Error encountered**

    - The error observed: **Beacon services failed to start**
    - Hypothesis: Lodestar beacon does not support *MEV/Builder* functionality
    - Ethereum-package may still be adding `--builder` flags automatically to Lodestar beacon, causing it to crash
    - Related upstream work: [ethpandaops/ethereum-package#725](https://github.com/ethpandaops/ethereum-package/pull/725)

## Learnings & Outcomes

- YAML configs must map exactly to client-specific options, Lodestar is strict about unsupported flags
- Validator client (`vc_extra_params`) is probably the correct place to inject builder.selection parameters
- **Hypothesis**: MEV integration in Kurtosis configs is still unstable with Lodestar, more alignment with ethereum-package upstream is most likely needed
- Confirmed that pre-deployment validation of configs is essential, as misapplied flags prevent enclaves from starting

## Week 15 TODOs

- Investigate upstream PR [#725](https://github.com/ethpandaops/ethereum-package/pull/725) to confirm whether the Lodestar beacon is still launched with unsupported `--builder` flags
- Explore whether MEV support for Lodestar is feasible or should be skipped for now
- Re-evaluate whether it makes sense to keep researching `.yml` config parameters or shift focus back to **Kurtosis NodePair replication** as the core migration task
- Work on refining YAML configs to mirror `multiFork.test.ts` parameters without introducing invalid flags
- Keep cleaning/refactoring code to stabilize the PR
- Gather feedback from team on current direction of config migration

### Useful resources checked

ethereum-package PR: [https://github.com/ethpandaops/ethereum-package/pull/725](https://github.com/ethpandaops/ethereum-package/pull/725)