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