# 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)