---
# System prepended metadata

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

---

# EPF6 - Week 8

## Overview

- Attended core dev call and shared updates
- Coordinated with my mentor to define the first step of Kurtosis Runner integration
- Conducted a dependency analysis and created a graph of components undergoing Kurtosis migration

## Main points

- Met with project mentor and defined the first step on Kurtosis Runner integration:
    - There will be two Kurtosis Runners that will replace the current Docker-based Runner:
    **`KurtosisSDKRunner`** and **`KurtosisCLIRunner`**

        So far the focus will be on *KurtosisSDKRunner*

        They will be responsible for:
        - Launch enclave and run the ethereum package via Kurtosis-sdk
        - Expose Kurtosis service names and port mappings (e.g., *cl-1*, *el-2*, etc.). 


    - We will start by refactoring the `IRunner interface`:
        From:
        ![image](https://hackmd.io/_uploads/SJE8-OwOel.png)
        To:
        ![image](https://hackmd.io/_uploads/SJ-XzOwdlx.png)
        
     - The refactoring of the IRunner interface introduces two new components:
        `KurtosisNetworkConfig` and `KurtosisServiceMap`
        
        Initial structure:
        ![image](https://hackmd.io/_uploads/S1MyXKPOle.png)
        
- Researched and scaffolded *KurtosisSDKRunner* implementation with preliminary testing starting from [week 7 Kurtosis endpoints](https://github.com/IreneBa26/lodestar/commit/8fa5139140e1040e76b70e214261ec852b18362f):
    - This Runner will take a **KurtosisNetworkConfig** as input (entire network topology) and returns a **KurtosisServicesMap**:
        - `KurtosisNetworkConfig` will mirror the **YAML** structure (participants, additional_services, network_params)
        - `KurtosisServicesMap` is a map of live connections after deployment.
        **Keys** are service names (like `cl-1-lodestar-geth`), and **values** are `ServiceContext` objects that let you interact with that service (get ports, execute commands, stream logs)
![image](https://hackmd.io/_uploads/H15DHKwOlg.png)

- Investigated solutions for passing the `.yml` file (i.e. `multiFork.yml`) as *KurtosisNetworkConfig* into the `create()` function.


    Current proposal - an external `loadKurtosisConfig()`         function located in *loadKurtosisConfig.ts* file:
    ![image](https://hackmd.io/_uploads/ryUe3rK_lg.png)

- To better understand what will be migrated, I generated graph dependencies with the cli tool [dependency-cruiser](https://www.npmjs.com/package/dependency-cruiser) and visualized it online with [Graphviz](https://dreampuf.github.io/GraphvizOnline/).
    #### Steps:
    1. **Install the tool:**
       ```bash
       npm install -g dependency-cruiser
       ```

    2. **Generate .dot file:**
       ```bash
       depcruise --output-type dot \
         --exclude "node_modules" \
         packages/cli/test/utils/crucible/multiFork.test.ts > multifork-tree.dot
       ``` 
    3. **Visualize:**
       - Copy contents of `multifork-tree.dot`
       - Paste into [Graphviz Online](https://dreampuf.github.io/GraphvizOnline/)
       - View the dependency graph:
    ![image](https://hackmd.io/_uploads/HJjPWFDdxx.png=50%x)

The visualization shows file dependencies and helps identify migration complexity.

## Learnings & Outcomes

- Refactor *IRunner* so the future Runners can plug into the same testing architecture cleanly
- The new Kurtosis Runner will **simplify** the Network Management: no manual IP assigned, automatic service discovery, better test reproducibility and built-in network topology management
- Initial ideal on how to load the network config `.yml` file
- Assertions (like [nodeAssertion](https://github.com/ChainSafe/lodestar/blob/unstable/packages/cli/test/utils/crucible/assertions/nodeAssertion.ts)) should keep their API, but the client they call (previously in [crucible/clients](https://github.com/ChainSafe/lodestar/tree/unstable/packages/cli/test/utils/crucible/clients)) will now be built from ServiceContext info


## Week 8 TODOs 

- Research how to wire the new runner into the Simulation framework:
    - Current idea: Pass an instance of KurtosisSDKRunner into `Simulation.initWithDefaults()` instead of the Docker Runner
    - Adapt Simulation to work with `KurtosisServicesMap`
- Phase out Docker runner logic
- Ongoing **feedback** from mentor throughout the project
- Attend core dev call
- Investigations on:
    - Determine how to **update code** expecting Job objects so it works with the KurtosisServicesMap
    - Determine how to replace **manually constructed URLs** with Kurtosis-provided endpoints
    - Determine how to convert **JobOptions** configurations into the KurtosisNetworkConfig format
    
### Useful resources checked

- [Visual examples](https://github.com/sverweij/dependency-cruiser/blob/HEAD/doc/real-world-samples.md) of dependency-cruiser