# EPF6 - Week 15

## Overview
- Attended Lodestar Weekly Standups and [shared updates](https://github.com/ChainSafe/lodestar/wiki/Lodestar-Weekly-Standups-2025#epf-contributors-progress)
- Continued refining the YAML configuration (`multiFork.yml`) to mirror the parameters from multiFork.test.ts without introducing invalid flags.
- Reviewed CLI flags directly via `./lodestar validator --help` and `./lodestar beacon --help` to confirm compatibility with Lodestar’s current implementation.
- Cleaned and refactored the code to stabilize the ongoing PR, focusing on removing invalid parameter options.

## Main points

- **YAML configuration refinement**
- Adjusted multiFork.yml to properly use vc_extra_params instead of cl_extra_params.
- Confirmed that parameters such as `--builder.selection=default` and `--builder.selection=executiononly` correctly reflect Lodestar’s block-building logic.

- **MEV issues and debugging**
- Re-tested with different `mev_type` options:
- `mev_type: flashbots` → beacon nodes fail due to unsupported --builder flags in Lodestar.
- `mev_type: mock` → beacon nodes attempt to connect to MEV-boost services that haven’t started yet.
- Root cause identified: ethereum-package launches beacon nodes before MEV-boost services, causing health-check timeouts.
- Decided to skip MEV setup temporarily and continue testing without MEV types.
- **Exchange with Kurtosis developer**
- Shared YAML and logs with the Kurtosis team for cross-validation
- They confirmed that the network config runs correctly on their side, meaning the problem is environment-specific (not structural).
- This confirmation was valuable: it isolates the issue to local setup and verifies that Lodestar’s YAML equivalent to `multiFork.test.ts` is functionally sound.
- **NodePair refactor progress**
- Continued integrating `BeaconClient`, `ExecutionClient`, and `ValidatorClient`.
- Addressed IDE errors during integration and used them to identify what needs to be adapted for compatibility with the existing **assertion structure**.

## Learnings & Outcomes

- Confirmation from the Kurtosis developer validated the YAML setup, indicating the issue is localized rather than systemic.
- **Progress on NodePair refactor**:
The direction is moving toward a full replication of the original node creation logic, specifically implementing the functions:
- `createBeaconNodeFromKurtosis()`
- `createExecutionNodeFromKurtosis()`
- `createValidatorNodeFromKurtosis()`

Each of these will construct role-specific client instances (beacon, execution, validator) directly from the `KurtosisServicesMap`, preserving the structure and fields expected by the existing assertion system.

The **goal** is for the resulting `NodePair[]` array, backed by Kurtosis service contexts, to be fully compatible with the current assertion framework (nodeAssertion, accountBalanceAssertion, etc.) **without modifying their APIs**.

## Week 16 TODOs

- Continue improving YAML parity with `multiFork.test.ts`.
- Continue refining the **NodePair integration** and ensure **compatibility** with existing assertions.
- Maintain focus on stabilizing and cleaning the PR for review.
- Document validated config parameters (`.yml`) to share with the Lodestar team.
- Gather feedback from team on current direction of config migration.