{"id":13546022,"url":"https://github.com/ethpandaops/ethereum-package","last_synced_at":"2026-01-12T06:52:46.544Z","repository":{"id":63619282,"uuid":"558430532","full_name":"ethpandaops/ethereum-package","owner":"ethpandaops","description":"A Kurtosis package that deploys a private, portable, and modular Ethereum devnet","archived":false,"fork":false,"pushed_at":"2024-12-06T17:36:40.000Z","size":6707,"stargazers_count":267,"open_issues_count":32,"forks_count":160,"subscribers_count":13,"default_branch":"main","last_synced_at":"2024-12-06T21:38:56.194Z","etag":null,"topics":["blockchain","docker","ethereum","flashbots","geth","kubernetes","kurtosis","kurtosis-package","lighthouse","mev","mev-boost","mev-bot","reth","simulation","starlark","testing"],"latest_commit_sha":null,"homepage":"","language":"Starlark","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ethpandaops.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-10-27T14:32:05.000Z","updated_at":"2024-12-06T16:30:53.000Z","dependencies_parsed_at":"2023-12-20T12:50:07.361Z","dependency_job_id":"4d30d4f3-6075-4cf2-b723-f175e60b7451","html_url":"https://github.com/ethpandaops/ethereum-package","commit_stats":null,"previous_names":["kurtosis-tech/eth2-package","ethpandaops/ethereum-package","kurtosis-tech/ethereum-package"],"tags_count":37,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ethpandaops%2Fethereum-package","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ethpandaops%2Fethereum-package/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ethpandaops%2Fethereum-package/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ethpandaops%2Fethereum-package/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ethpandaops","download_url":"https://codeload.github.com/ethpandaops/ethereum-package/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246860244,"owners_count":20845634,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blockchain","docker","ethereum","flashbots","geth","kubernetes","kurtosis","kurtosis-package","lighthouse","mev","mev-boost","mev-bot","reth","simulation","starlark","testing"],"created_at":"2024-08-01T12:00:30.180Z","updated_at":"2026-01-12T06:52:46.535Z","avatar_url":"https://github.com/ethpandaops.png","language":"Starlark","funding_links":[],"categories":["Uncategorized"],"sub_categories":["Uncategorized"],"readme":"# Ethereum Package\n\n![Run of the Ethereum Network Package](run.gif)\n\nThis is a [Kurtosis][kurtosis-repo] package that will spin up a private Ethereum testnet over Docker or Kubernetes with multi-client support, Flashbot's `mev-boost` infrastructure for PBS-related testing/validation, and other useful network tools (transaction spammer, monitoring tools, etc). Kurtosis packages are entirely reproducible and composable, so this will work the same way over Docker or Kubernetes, in the cloud or locally on your machine.\n\nYou now have the ability to spin up a private Ethereum testnet or public devnet/testnet (e.g. Goerli, Holesky, Sepolia, dencun-devnet-12, verkle-gen-devnet-2 etc) with a single command. This package is designed to be used for testing, validation, and development of Ethereum clients, and is not intended for production use. For more details check network_params.network in the [configuration section](./README.md#configuration).\n\nSpecifically, this [package][package-reference] will:\n\n1. Generate Execution Layer (EL) \u0026 Consensus Layer (CL) genesis information using [the Ethereum genesis generator](https://github.com/ethpandaops/ethereum-genesis-generator).\n2. Configure \u0026 bootstrap a network of Ethereum nodes of *n* size using the genesis data generated above\n3. Spin up a [transaction spammer](https://github.com/MariusVanDerWijden/tx-fuzz) to send fake transactions to the network\n4. Spin up and connect a [testnet verifier](https://github.com/ethereum/merge-testnet-verifier)\n5. Spin up a Grafana and Prometheus instance to observe the network\n6. Spin up a Blobscan instance to analyze blob transactions (EIP-4844)\n\nOptional features (enabled via flags or parameter files at runtime):\n\n- Block until the Beacon nodes finalize an epoch (i.e. finalized_epoch \u003e 0)\n- Spin up \u0026 configure parameters for the infrastructure behind PBS (Proposer-Builder Separation) using `mev-boost`, with support for multiple relay implementations:\n  - `flashbots` - Full Flashbots MEV infrastructure\n  - `helix` - High-performance [Helix relay](https://github.com/gattaca-com/helix) with TimescaleDB backend\n  - `mev-rs` - Alternative relay implementation\n  - `commit-boost` - Commit-boost based infrastructure\n  - `mock` - Mock builder for testing\n  - [More details on PBS implementation](./README.md#proposer-builder-separation-pbs-emulation).\n- Spin up \u0026 connect the network to a [beacon metrics gazer service](https://github.com/dapplion/beacon-metrics-gazer) to collect network-wide participation metrics.\n- Spin up and connect a [JSON RPC Snooper](https://github.com/ethDreamer/json_rpc_snoop) to the network log responses \u0026 requests between the EL engine API and the CL client.\n- Specify extra parameters to be passed in for any of the: CL client Beacon, and CL client validator, and/or EL client containers\n- Specify the required parameters for the nodes to reach an external block building network\n- Generate keystores for each node in parallel\n\n## Quickstart\n\n[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/new/?editor=code#https://github.com/ethpandaops/ethereum-package)\n\n1. [Install Docker \u0026 start the Docker Daemon if you haven't done so already][docker-installation]\n2. [Install the Kurtosis CLI, or upgrade it to the latest version if it's already installed][kurtosis-cli-installation]\n3. Run the package with default configurations from the command line:\n\n   ```bash\n   kurtosis run --enclave my-testnet github.com/ethpandaops/ethereum-package\n   ```\n\n### Run with your own configuration\n\nKurtosis packages are parameterizable, meaning you can customize your network and its behavior to suit your needs by storing parameters in a file that you can pass in at runtime like so:\n\n```bash\nkurtosis run --enclave my-testnet github.com/ethpandaops/ethereum-package --args-file network_params.yaml\n```\n\nWhere `network_params.yaml` contains the parameters for your network in your home directory.\n\n#### Run on Kubernetes\n\nKurtosis packages work the same way over Docker or on Kubernetes. Please visit our [Kubernetes docs](https://docs.kurtosis.com/k8s) to learn how to spin up a private testnet on a Kubernetes cluster.\n\n### Considerations for Running on a Public Testnet with a Cloud Provider\n\nWhen running on a public testnet using a cloud provider's Kubernetes cluster, there are a few important factors to consider:\n\n1. State Growth: The growth of the state might be faster than anticipated. This could potentially lead to issues if the default parameters become insufficient over time. It's important to monitor state growth and adjust parameters as necessary.\n\n2. Persistent Storage Speed: Most cloud providers provision their Kubernetes clusters with relatively slow persistent storage by default. This can cause performance issues, particularly with Execution Layer (EL) clients.\n\n3. Network Syncing: The disk speed provided by cloud providers may not be sufficient to sync with networks that have high demands, such as the mainnet. This could lead to syncing issues and delays.\n\nTo mitigate these issues, you can use the `el_volume_size` and `cl_volume_size` flags to override the default settings locally. This allows you to allocate more storage to the EL and CL clients, which can help accommodate faster state growth and improve syncing performance. However, keep in mind that increasing the volume size may also increase your cloud provider costs. Always monitor your usage and adjust as necessary to balance performance and cost.\n\nFor optimal performance, we recommend using a cloud provider that allows you to provision Kubernetes clusters with fast persistent storage or self hosting your own Kubernetes cluster with fast persistent storage.\n\n### Shadowforking\n\nIn order to enable shadowfork capabilities, you can use the `network_params.network` flag. The expected value is the name of the network you want to shadowfork followed by `-shadowfork`. Please note that `persistent` configuration parameter has to be enabled for shadowforks to work! Current limitation on k8s is it is only working on a single node cluster. For example, to shadowfork the Holesky testnet, you can use the following command:\n\n```yaml\n...\nnetwork_params:\n  network: \"holesky-shadowfork\"\npersistent: true\n...\n```\n\n#### Shadowforking custom verkle networks\n\nIn order to enable shadowfork capabilities for verkle networks, you need to define electra and mention verkle in the network name after shadowfork.\n\n```yaml\n...\nnetwork_params:\n  electra_fork_epoch: 1\n  network: \"holesky-shadowfork-verkle\"\npersistent: true\n...\n```\n\n#### Taints and tolerations\n\nIt is possible to run the package on a Kubernetes cluster with taints and tolerations. This is done by adding the tolerations to the `tolerations` field in the `network_params.yaml` file. For example:\n\n```yaml\nparticipants:\n  - el_type: reth\n    cl_type: teku\nglobal_tolerations:\n  - key: \"node-role.kubernetes.io/master6\"\n    value: \"true\"\n    operator: \"Equal\"\n    effect: \"NoSchedule\"\n```\n\nIt is possible to define toleration globally, per participant or per container. The order of precedence is as follows:\n\n1. Container (`el_tolerations`, `cl_tolerations`, `vc_tolerations`)\n2. Participant (`tolerations`)\n3. Global (`global_tolerations`)\n\nThis feature is only available for Kubernetes. To learn more about taints and tolerations, please visit the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).\n\n#### Tear down\n\nThe testnet will reside in an [enclave][enclave] - an isolated, ephemeral environment. The enclave and its contents (e.g. running containers, files artifacts, etc) will persist until torn down. You can remove an enclave and its contents with:\n\n```bash\nkurtosis enclave rm -f my-testnet\n```\n\n## Management\n\nThe [Kurtosis CLI](https://docs.kurtosis.com/cli) can be used to inspect and interact with the network.\n\nFor example, if you need shell access, simply run:\n\n```bash\nkurtosis service shell my-testnet $SERVICE_NAME\n```\n\nAnd if you need the logs for a service, simply run:\n\n```bash\nkurtosis service logs my-testnet $SERVICE_NAME\n```\n\nCheck out the [full list of Kurtosis CLI commands](https://docs.kurtosis.com/cli)\n\n## Debugging\n\nTo grab the genesis files for the network, simply run:\n\n```bash\nkurtosis files download my-testnet $FILE_NAME $OUTPUT_DIRECTORY\n```\n\nFor example, to retrieve the Execution Layer (EL) genesis data, run:\n\n```bash\nkurtosis files download my-testnet el-genesis-data ~/Downloads\n```\n\n## Basic file sharing\n\nApache is included in the package to allow for basic file sharing. The Apache service is started when additional services are enabled. It will expose the network-configs directory, which might needed if you want to share the network config publicly.\n\n```yaml\nadditional_services:\n  - apache\n```\n\n## Configuration\n\nTo configure the package behaviour, you can modify your `network_params.yaml` file. The full YAML schema that can be passed in is as follows with the defaults provided:\n\n```yaml\n# Specification of the participants in the network\nparticipants:\n  # EL(Execution Layer) Specific flags\n    # The type of EL client that should be started\n    # Valid values are geth, nethermind, erigon, besu, ethereumjs, reth, nimbus-eth1, ethrex, dummy\n  - el_type: geth\n\n    # The Docker image that should be used for the EL client; leave blank to use the default for the client type\n    # Defaults by client:\n    # - geth: ethereum/client-go:latest\n    # - erigon: erigontech/erigon:latest\n    # - nethermind: ethpandaops/nethermind:master\n    # - besu: hyperledger/besu:latest\n    # - reth: ghcr.io/paradigmxyz/reth\n    # - ethereumjs: ethpandaops/ethereumjs:master\n    # - nimbus-eth1: statusim/nimbus-eth1:master\n    # - ethrex: ghcr.io/lambdaclass/ethrex:latest\n    # - dummy: ethpandaops/dummy-el:master\n    el_image: \"\"\n\n    # The log level string that this participant's EL client should log at\n    # If this is emptystring then the global `logLevel` parameter's value will be translated into a string appropriate for the client (e.g. if\n    # global `logLevel` = `info` then Geth would receive `3`, Besu would receive `INFO`, etc.)\n    # If this is not emptystring, then this value will override the global `logLevel` setting to allow for fine-grained control\n    # over a specific participant's logging\n    el_log_level: \"\"\n\n    # The storage type for the EL client: \"full\" or \"archive\"\n    # IMPORTANT: Consider updating el_volume_size if you set this\n    # If this is emptystring, each client will use its default behavior:\n    #   - reth, erigon: default to archive (use \"full\" to save space)\n    #   - geth, besu, nethermind: default to full (use \"archive\" to keep historical data)\n    #   - ethereumjs, ethrex, nimbus-eth1, dummy: unused (full only?)\n    # Example: el_storage_type: \"full\" or \"archive\"\n    el_storage_type: \"\"\n\n    # A list of optional extra env_vars the el container should spin up with\n    el_extra_env_vars: {}\n\n    # A list of optional extra labels the el container should spin up with\n    # Example: el_extra_labels: {\"ethereum-package.partition\": \"1\"}\n    el_extra_labels: {}\n\n    # A list of optional extra params that will be passed to the EL client container for modifying its behaviour\n    el_extra_params: []\n\n    # A list of optional extra mount points that will be passed to the EL client container\n    # Key is the mount path (becomes a directory), value MUST reference a key from extra_files\n    # The file will be available at \u003cmount_path\u003e/\u003cextra_files_key\u003e\n    # Example: el_extra_mounts: {\"/config\": \"my_config_file\"}  # Creates /config/my_config_file\n    el_extra_mounts: {}\n\n    # A list of host devices to mount into the EL client container\n    # Useful for hardware device access like TPM, HSM, etc.\n    # Example: el_devices: [\"/dev/tpm0\"]\n    # Defaults to empty list\n    el_devices: []\n\n    # A list of tolerations that will be passed to the EL client container\n    # Only works with Kubernetes\n    # Example: el_tolerations:\n    # - key: \"key\"\n    #   operator: \"Equal\"\n    #   value: \"value\"\n    #   effect: \"NoSchedule\"\n    #   toleration_seconds: 3600\n    # Defaults to empty\n    el_tolerations: []\n\n    # Persistent storage size for the EL client container (in MB)\n    # IMPORTANT: Consider settings this if you are setting el_storage_type\n    # Defaults to 0, which means that the default size for the client will be used\n    # Default values can be found in /src/package_io/constants.star VOLUME_SIZE\n    el_volume_size: 0\n\n    # Resource management for el containers\n    # CPU is milicores\n    # RAM is in MB\n    # Defaults to 0, which results in no resource limits\n    el_min_cpu: 0\n    el_max_cpu: 0\n    el_min_mem: 0\n    el_max_mem: 0\n\n  # CL(Consensus Layer) Specific flags\n    # The type of CL client that should be started\n    # Valid values are nimbus, lighthouse, lodestar, teku, prysm, and grandine\n    cl_type: lighthouse\n\n    # The Docker image that should be used for the CL client; leave blank to use the default for the client type\n    # Defaults by client:\n    # - lighthouse: ethpandaops/lighthouse:unstable\n    # - teku: ethpandaops/teku:master\n    # - nimbus: statusim/nimbus-eth2:multiarch-latest\n    # - prysm: ethpandaops/prysm-beacon-chain:develop\n    # - lodestar: chainsafe/lodestar:latest\n    # - grandine: sifrai/grandine:stable\n    cl_image: \"\"\n\n    # The log level string that this participant's CL client should log at\n    # If this is emptystring then the global `logLevel` parameter's value will be translated into a string appropriate for the client (e.g. if\n    # global `logLevel` = `info` then Teku would receive `INFO`, Prysm would receive `info`, etc.)\n    # If this is not emptystring, then this value will override the global `logLevel` setting to allow for fine-grained control\n    # over a specific participant's logging\n    cl_log_level: \"\"\n\n    # A list of optional extra env_vars the cl container should spin up with\n    cl_extra_env_vars: {}\n\n    # A list of optional extra labels that will be passed to the CL client Beacon container.\n    # Example; cl_extra_labels: {\"ethereum-package.partition\": \"1\"}\n    cl_extra_labels: {}\n\n    # A list of optional extra params that will be passed to the CL client Beacon container for modifying its behaviour\n    # If the client combines the Beacon \u0026 validator nodes (e.g. Teku, Nimbus), then this list will be passed to the combined Beacon-validator node\n    cl_extra_params: []\n\n    # A list of optional extra mount points that will be passed to the CL client container\n    # Key is the mount path (becomes a directory), value MUST reference a key from extra_files\n    # The file will be available at \u003cmount_path\u003e/\u003cextra_files_key\u003e\n    # Example: cl_extra_mounts: {\"/config\": \"my_config_file\"}  # Creates /config/my_config_file\n    cl_extra_mounts: {}\n\n    # A list of host devices to mount into the CL client container\n    # Useful for hardware device access like TPM, HSM, etc.\n    # Example: cl_devices: [\"/dev/tpm0\"]\n    # Defaults to empty list\n    cl_devices: []\n\n    # A list of tolerations that will be passed to the CL client container\n    # Only works with Kubernetes\n    # Example: el_tolerations:\n    # - key: \"key\"\n    #   operator: \"Equal\"\n    #   value: \"value\"\n    #   effect: \"NoSchedule\"\n    #   toleration_seconds: 3600\n    # Defaults to empty\n    cl_tolerations: []\n\n    # Persistent storage size for the CL client container (in MB)\n    # Defaults to 0, which means that the default size for the client will be used\n    # Default values can be found in /src/package_io/constants.star VOLUME_SIZE\n    cl_volume_size: 0\n\n    # Resource management for cl containers\n    # CPU is milicores\n    # RAM is in MB\n    # Defaults to 0, which results in no resource limits\n    cl_min_cpu: 0\n    cl_max_cpu: 0\n    cl_min_mem: 0\n    cl_max_mem: 0\n\n    # Whether to act as a supernode for the network\n    # Supernodes will subscribe to all subnet topics\n    # This flag should only be used with peerdas\n    # Defaults to false\n    supernode: false\n\n    # Whether to use a separate validator client attached to the CL client.\n    # Defaults to false for clients that can run both in one process (Teku, Nimbus)\n    use_separate_vc: true\n\n  # VC (Validator Client) Specific flags\n    # The type of validator client that should be used\n    # Valid values are nimbus, lighthouse, lodestar, teku, prysm and vero\n    # ( The prysm validator only works with a prysm CL client )\n    # Defaults to matching the chosen CL client (cl_type)\n    vc_type: \"\"\n\n    # The Docker image that should be used for the separate validator client\n    # Defaults by client:\n    # - lighthouse: sigp/lighthouse:latest\n    # - lodestar: chainsafe/lodestar:latest\n    # - nimbus: statusim/nimbus-validator-client:multiarch-latest\n    # - prysm: ethpandaops/prysm-validator:develop\n    # - teku: ethpandaops/teku:master\n    # - vero: ghcr.io/serenita-org/vero:latest\n    vc_image: \"\"\n\n    # The log level string that this participant's validator client should log at\n    # If this is emptystring then the global `logLevel` parameter's value will be translated into a string appropriate for the client (e.g. if\n    # global `logLevel` = `info` then Teku would receive `INFO`, Prysm would receive `info`, etc.)\n    # If this is not emptystring, then this value will override the global `logLevel` setting to allow for fine-grained control\n    # over a specific participant's logging\n    vc_log_level: \"\"\n\n    # A list of optional extra env_vars the vc container should spin up with\n    vc_extra_env_vars: {}\n\n    # A list of optional extra labels that will be passed to the validator client validator container.\n    # Example; vc_extra_labels: {\"ethereum-package.partition\": \"1\"}\n    vc_extra_labels: {}\n\n    # A list of optional extra params that will be passed to the validator client container for modifying its behaviour\n    # If the client combines the Beacon \u0026 validator nodes (e.g. Teku, Nimbus), then this list will also be passed to the combined Beacon-validator node\n    vc_extra_params: []\n\n    # A list of optional extra mount points that will be passed to the validator client container\n    # Key is the mount path (becomes a directory), value MUST reference a key from extra_files\n    # The file will be available at \u003cmount_path\u003e/\u003cextra_files_key\u003e\n    # Example: vc_extra_mounts: {\"/config\": \"my_validator_config\"}  # Creates /config/my_validator_config\n    vc_extra_mounts: {}\n\n    # A list of host devices to mount into the validator client container\n    # Useful for hardware device access like TPM, HSM, etc.\n    # Example: vc_devices: [\"/dev/tpm0\"]\n    # Defaults to empty list\n    vc_devices: []\n\n    # A list of tolerations that will be passed to the validator container\n    # Only works with Kubernetes\n    # Example: el_tolerations:\n    # - key: \"key\"\n    #   operator: \"Equal\"\n    #   value: \"value\"\n    #   effect: \"NoSchedule\"\n    #   toleration_seconds: 3600\n    # Defaults to empty\n    vc_tolerations: []\n\n    # Resource management for vc containers\n    # CPU is milicores\n    # RAM is in MB\n    # Defaults to 0, which results in no resource limits\n    vc_min_cpu: 0\n    vc_max_cpu: 0\n    vc_min_mem: 0\n    vc_max_mem: 0\n\n    # A list of indices of the beacon nodes that the validator client should connect to\n    # Defaults to null\n    vc_beacon_node_indices: null\n\n    # Count of the number of validators you want to run for a given participant\n    # Default to null, which means that the number of validators will be using the\n    # network parameter num_validator_keys_per_node\n    validator_count: null\n\n    # Whether to use a remote signer instead of the vc directly handling keys\n    # Note Lighthouse VC does not support this flag\n    # Defaults to false\n    use_remote_signer: false\n\n  # Remote signer Specific flags\n    # The type of remote signer that should be used\n    # Valid values are web3signer\n    # Defaults to web3signer\n    remote_signer_type: \"web3signer\"\n\n    # The Docker image that should be used for the remote signer\n    # Defaults to \"consensys/web3signer:latest\"\n    remote_signer_image: \"consensys/web3signer:latest\"\n\n    # A list of optional extra env_vars the remote signer container should spin up with\n    remote_signer_extra_env_vars: {}\n\n    # A list of optional extra labels that will be passed to the remote signer container.\n    # Example; remote_signer_extra_labels: {\"ethereum-package.partition\": \"1\"}\n    remote_signer_extra_labels: {}\n\n    # A list of optional extra params that will be passed to the remote signer container for modifying its behaviour\n    remote_signer_extra_params: []\n\n    # A list of tolerations that will be passed to the remote signer container\n    # Only works with Kubernetes\n    # Example: remote_signer_tolerations:\n    # - key: \"key\"\n    #   operator: \"Equal\"\n    #   value: \"value\"\n    #   effect: \"NoSchedule\"\n    #   toleration_seconds: 3600\n    # Defaults to empty\n    remote_signer_tolerations: []\n\n    # Resource management for remote signer containers\n    # CPU is milicores\n    # RAM is in MB\n    # Defaults to 0, which results in no resource limits\n    remote_signer_min_cpu: 0\n    remote_signer_max_cpu: 0\n    remote_signer_min_mem: 0\n    remote_signer_max_mem: 0\n\n  # Participant specific flags\n    # Node selector\n    # Only works with Kubernetes\n    # Example: node_selectors: { \"disktype\": \"ssd\" }\n    # Defaults to empty\n    node_selectors: {}\n\n    # A list of tolerations that will be passed to the EL/CL/validator containers\n    # This is to be used when you don't want to specify the tolerations for each container separately\n    # Only works with Kubernetes\n    # Example: tolerations:\n    # - key: \"key\"\n    #   operator: \"Equal\"\n    #   value: \"value\"\n    #   effect: \"NoSchedule\"\n    #   toleration_seconds: 3600\n    # Defaults to empty\n    tolerations: []\n\n    # Count of nodes to spin up for this participant\n    # Default to 1\n    count: 1\n\n    # Snooper local flag for a participant.\n    # Snooper can be enabled with the `snooper_enabled` flag per client or globally\n    # Snooper dumps all JSON-RPC requests and responses including BeaconAPI, EngineAPI and ExecutionAPI.\n    # Default to null\n    snooper_enabled: null\n\n    # Enables Ethereum Metrics Exporter for this participant. Can be set globally.\n    # Defaults null and then set to global ethereum_metrics_exporter_enabled (false)\n    ethereum_metrics_exporter_enabled: null\n\n    # Enables Xatu Sentry for this participant. Can be set globally.\n    # Defaults null and then set to global xatu_sentry_enabled (false)\n    xatu_sentry_enabled: null\n\n    # Prometheus additional configuration for a given participant prometheus target.\n    # Execution, beacon and validator client targets on prometheus will include this\n    # configuration.\n    prometheus_config:\n      # Scrape interval to be used. Default to 15 seconds\n      scrape_interval: 15s\n      # Additional labels to be added. Default to empty\n      labels: {}\n\n    # Blobber can be enabled with the `blobber_enabled` flag per client or globally\n    # Defaults to false\n    blobber_enabled: false\n\n    # Blobber extra params can be passed in to the blobber container\n    # Defaults to empty\n    blobber_extra_params: []\n\n    # Blobber image to be used for the blobber container\n    # Defaults to empty\n    blobber_image: ethpandaops/blobber:latest\n\n    # A set of parameters the node needs to reach an external block building network\n    # If `null` then the builder infrastructure will not be instantiated\n    # Example:\n    #\n    # \"relay_endpoints\": [\n    #  \"https://0xdeadbeefcafa@relay.example.com\",\n    #  \"https://0xdeadbeefcafb@relay.example.com\",\n    #  \"https://0xdeadbeefcafc@relay.example.com\",\n    #  \"https://0xdeadbeefcafd@relay.example.com\"\n    # ]\n    builder_network_params: null\n\n    # Participant flag for keymanager api\n    # This will open up http ports to your validator services!\n    # Defaults null and then set to default global keymanager_enabled (false)\n    keymanager_enabled: null\n\n    # Per-participant override for checkpoint sync. If set, this will override the global checkpoint_sync_enabled flag for this participant.\n    # Defaults to null (uses global checkpoint_sync_enabled setting)\n    checkpoint_sync_enabled: null\n\n    # If set to true, the beacon node will be created and then immediately stopped.\n    # No health checks are performed during creation (ready_conditions are disabled).\n    # The service can be started later using: kurtosis service start \u003cenclave\u003e \u003cservice-name\u003e\n    # This is useful for testing or when you want to manually control when the beacon node starts.\n    # Defaults to false\n    skip_start: false\n\n# Participants matrix creates a participant for each combination of EL, CL and VC clients\n# Each EL/CL/VC item can provide the same parameters as a standard participant\nparticipants_matrix: {}\n  # el:\n  #   - el_type: geth\n  #   - el_type: besu\n  # cl:\n  #   - cl_type: prysm\n  #   - cl_type: lighthouse\n  # vc:\n  #   - vc_type: prysm\n  #   - vc_type: lighthouse\n\n\n# Default configuration parameters for the network\nnetwork_params:\n  # Network name, used to enable syncing of alternative networks\n  # Defaults to \"kurtosis\"\n  # You can sync any public network by setting this to the network name (e.g. \"mainnet\", \"sepolia\", \"holesky\", \"hoodi\")\n  # You can sync any devnet by setting this to the network name (e.g. \"dencun-devnet-12\", \"verkle-gen-devnet-2\")\n  network: \"kurtosis\"\n\n  # The network ID of the network.\n  network_id: \"3151908\"\n\n  # The address of the staking contract address on the Eth1 chain\n  deposit_contract_address: \"0x00000000219ab540356cBB839Cbe05303d7705Fa\"\n\n  # Number of seconds per slot on the Beacon chain\n  seconds_per_slot: 12\n\n  # Duration of a slot in milliseconds\n  # Defaults to 12000ms (12 seconds)\n  slot_duration_ms: 12000\n\n  # Gloas fork timing parameters (optimized for faster slots)\n  # Attestation due timing for Gloas fork\n  # Defaults to 2500 basis points (25% of slot duration)\n  attestation_due_bps_gloas: 2500\n\n  # Aggregate due timing for Gloas fork\n  # Defaults to 5000 basis points (50% of slot duration)\n  aggregate_due_bps_gloas: 5000\n\n  # Sync message due timing for Gloas fork\n  # Defaults to 2500 basis points (25% of slot duration)\n  sync_message_due_bps_gloas: 2500\n\n  # Contribution due timing for Gloas fork\n  # Defaults to 5000 basis points (50% of slot duration)\n  contribution_due_bps_gloas: 5000\n\n  # Payload attestation due timing for Gloas fork\n  # Defaults to 7500 basis points (75% of slot duration)\n  payload_attestation_due_bps: 7500\n\n  # EIP-7805 timing parameters\n  # View freeze cutoff timing\n  # Defaults to 7500 basis points (75% of slot duration)\n  view_freeze_cutoff_bps: 7500\n\n  # Inclusion list submission due timing\n  # Defaults to 6667 basis points (~67% of slot duration)\n  inclusion_list_submission_due_bps: 6667\n\n  # Proposer inclusion list cutoff timing\n  # Defaults to 9167 basis points (~92% of slot duration)\n  proposer_inclusion_list_cutoff_bps: 9167\n\n  # Maximum request blocks for Deneb fork\n  # Defaults to 128\n  max_request_blocks_deneb: 128\n\n  # Maximum request blob sidecars for Electra fork\n  # Defaults to 1152 (128 * 9 blobs)\n  max_request_blob_sidecars_electra: 1152\n\n  # The number of validator keys that each CL validator node should get\n  num_validator_keys_per_node: 128\n\n  # This mnemonic will a) be used to create keystores for all the types of validators that we have and b) be used to generate a CL genesis.ssz that has the children\n  # validator keys already preregistered as validators\n  preregistered_validator_keys_mnemonic: \"giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete\"\n\n  # The number of pre-registered validators for genesis. If 0 or not specified then the value will be calculated from the participants\n  preregistered_validator_count: 0\n\n  # Additional mnemonics to generate validators from\n  # These validators will be included in genesis but won't have keystores generated\n  # Useful for pre-registering validators with custom withdrawal credentials or states\n  # Default: []\n  additional_mnemonics:\n    - # The mnemonic to derive validator keys from\n      mnemonic: \"estate dog switch misery manage room million bleak wrap distance always insane usage busy chicken limit already duck feature unhappy dial emotion expire please\"\n      # The validator index to start deriving keys from\n      # Defaults to 0\n      start: 0\n      # The number of validators to generate from this mnemonic\n      count: 10\n      # The withdrawal address for these validators\n      # Only used when wd_prefix is 0x01 or 0x02 (execution layer withdrawal credentials)\n      wd_address: 0x000000000000000000000000000000000000dEaD\n      # The withdrawal credentials prefix\n      # 0x00: BLS withdrawal credentials (default)\n      # 0x01: Execution layer withdrawal credentials (uses wd_address)\n      # 0x02: Compounding withdrawal credentials (uses wd_address)\n      wd_prefix: 0x01\n      # The validator balance in gwei\n      # Defaults to 32000000000 (32 ETH)\n      balance: 32000000000\n      # The initial validator status\n      # 0: active (default)\n      # 1: slashed\n      # 2: exited\n      status: 1\n\n  # How long you want the network to wait before starting up\n  genesis_delay: 20\n\n  # Unix timestamp for genesis. If specified (non-zero), this overrides genesis_delay.\n  # When set to 0 (default), the genesis time is automatically calculated based on current time and genesis_delay.\n  # Use this field to set a specific genesis time for the network.\n  # Defaults to 0\n  genesis_time: 0\n\n  # The gas limit of the network set at genesis\n  # Defaults to 60000000\n\n  genesis_gaslimit: 60000000\n\n  # Max churn rate for the network introduced by\n  # EIP-7514 https://eips.ethereum.org/EIPS/eip-7514\n  # Defaults to 8\n  max_per_epoch_activation_churn_limit: 8\n\n  # Churn limit quotient for the network\n  # Defaults to 65536\n  churn_limit_quotient: 65536\n\n  # Ejection balance\n  # Defaults to 16ETH\n  # 16000000000 gwei\n  ejection_balance: 16000000000\n\n  # ETH1 follow distance\n  # Defaults to 2048\n  eth1_follow_distance: 2048\n\n  # The number of epochs to wait validators to be able to withdraw\n  # Defaults to 256 epochs ~27 hours\n  min_validator_withdrawability_delay: 256\n\n  # The period of the shard committee\n  # Defaults to 256 epoch ~27 hours\n  shard_committee_period: 256\n\n  # The epoch at which the deneb/electra/fulu forks are set to occur. Note: PeerDAS and Electra clients are currently\n  # working on forks. So set either one of the below forks.\n  # Altair fork epoch\n  # Defaults to 0\n  altair_fork_epoch: 0\n\n  # Bellatrix fork epoch\n  # Defaults to 0\n  bellatrix_fork_epoch: 0\n\n  # Capella fork epoch\n  # Defaults to 0\n  capella_fork_epoch: 0\n\n  # Deneb fork epoch\n  # Defaults to 0\n  deneb_fork_epoch: 0\n\n  # Electra fork epoch\n  # Defaults to 0\n  electra_fork_epoch: 0\n\n  # Fulu fork epoch\n  # Defaults to 0\n  fulu_fork_epoch: 0\n\n  # Gloas fork epoch\n  # Defaults to 18446744073709551615\n  gloas_fork_epoch: 18446744073709551615\n\n  # Network sync base url for syncing public networks from a custom snapshot (mostly useful for shadowforks)\n  # Defaults to \"https://snapshots.ethpandaops.io/\"\n  # If you have a local snapshot, you can set this to the local url:\n  # network_snapshot_url_base = \"http://10.10.101.21:10000/snapshots/\"\n  # The snapshots are taken with https://github.com/ethpandaops/snapshotter\n  network_sync_base_url: https://snapshots.ethpandaops.io/\n\n  # Force network sync with a custom snapshot\n  # This enables quicker EL sync (use with caution)\n  # Defaults to false\n  force_snapshot_sync: false\n\n  # The block height of the shadowfork\n  # This is used to sync the network from a snapshot at a specific block height\n  # Defaults to \"latest\"\n  # Example: shadowfork_block_height: 340000 for hoodi\n  shadowfork_block_height: \"latest\"\n\n  # The number of data column sidecar subnets used in the gossipsub protocol\n  data_column_sidecar_subnet_count: 128\n  # Number of DataColumn random samples a node queries per slot\n  samples_per_slot: 8\n\n  # Minimum number of subnets an honest node custodies and serves samples from\n  # Defaults to 4\n  custody_requirement: 4\n\n  # Maximum number of blobs per block for Electra fork (default 9)\n  max_blobs_per_block_electra: 9\n  # Target number of blobs per block for Electra fork (default 6)\n  target_blobs_per_block_electra: 6\n  # Base fee update fraction for Electra fork (default 5007716)\n  base_fee_update_fraction_electra: 5007716\n\n  # EIP-7805 fork epoch\n  # Defaults to 18446744073709551615\n  eip7805_fork_epoch: 18446744073709551615\n\n\n  # Preset for the network\n  # Default: \"mainnet\"\n  # Options: \"mainnet\", \"minimal\"\n  # \"minimal\" preset will spin up a network with minimal preset. This is useful for rapid testing and development.\n  # 192 seconds to get to finalized epoch vs 1536 seconds with mainnet defaults\n  # Please note that minimal preset requires alternative client images.\n  # For an example of minimal preset, please refer to [minimal.yaml](.github/tests/minimal.yaml)\n  preset: \"mainnet\"\n\n  # Preloaded contracts for the chain\n  additional_preloaded_contracts: {}\n  # Example:\n  # additional_preloaded_contracts: '{\n  #  \"0x123463a4B065722E99115D6c222f267d9cABb524\":\n  #   {\n  #     balance: \"1ETH\",\n  #     code: \"0x1234\",\n  #     storage: {},\n  #     nonce: 0,\n  #     secretKey: \"0x\",\n  #   }\n  # }'\n\n  # Repository override for devnet networks\n  # Default: ethpandaops\n  devnet_repo: ethpandaops\n\n  # A number of prefunded accounts to be created\n  # Defaults to no prefunded accounts\n  # Example:\n  # prefunded_accounts: '{\"0x25941dC771bB64514Fc8abBce970307Fb9d477e9\": {\"balance\": \"10ETH\"}}'\n  # 10ETH to the account 0x25941dC771bB64514Fc8abBce970307Fb9d477e9\n  # To prefund multiple accounts, separate them with a comma\n  #\n  # prefunded_accounts: '{\"0x25941dC771bB64514Fc8abBce970307Fb9d477e9\": {\"balance\": \"10ETH\"}, \"0x4107be99052d895e3ee461C685b042Aa975ab5c0\": {\"balance\": \"1ETH\"}}'\n  prefunded_accounts: {}\n\n  # Maximum size of gossip messages in bytes\n  # 10 * 2**20 (= 10485760, 10 MiB)\n  # Defaults to 10485760 (10MB)\n  max_payload_size: 10485760\n\n  # Enable Perfect PeerDAS\n  # This flag is meant to be used with 16 nodes where each node gets 8 unique columns\n  # Ensure that you set the number of validator keys per node to less than or equal to 8 so that validator custody is not affected\n  # Defaults to false\n  perfect_peerdas_enabled: false\n\n  # Gas limit for the network\n  # Default to 0\n  # If set to 0, the gas limit will be set to the default gas limit for the clients\n  # Set this value to gas limit in millionths of a gwei\n  # Example: gas_limit: 60000000\n  # This will override the gas limit for each EL client\n  # Do not confuse with genesis_gaslimit which sets the gas limit at the genesis file level\n  gas_limit: 0\n\n\n  # BPO\n  # BPO1-5 epoch (default 0/18446744073709551615)\n  bpo_1_epoch: 0\n  # Maximum number of blobs per block for BPO1-5\n  # If only max is set, target is auto-calculated as 2/3 of max\n  # If only target is set, max is auto-calculated as 3/2 of target\n  bpo_1_max_blobs: 15\n  # Target number of blobs per block for BPO1-5\n  bpo_1_target_blobs: 10\n  # Base fee update fraction for BPO1-5 (default 0)\n  bpo_1_base_fee_update_fraction: 8346193\n\n  bpo_2_epoch: 18446744073709551615\n  bpo_2_max_blobs: 21\n  bpo_2_target_blobs: 14\n  bpo_2_base_fee_update_fraction: 11684671\n\n  bpo_3_epoch: 18446744073709551615\n  bpo_3_max_blobs: 0\n  bpo_3_target_blobs: 0\n  bpo_3_base_fee_update_fraction: 0\n\n  bpo_4_epoch: 18446744073709551615\n  bpo_4_max_blobs: 0\n  bpo_4_target_blobs: 0\n  bpo_4_base_fee_update_fraction: 0\n\n  bpo_5_epoch: 18446744073709551615\n  bpo_5_max_blobs: 0\n  bpo_5_target_blobs: 0\n  bpo_5_base_fee_update_fraction: 0\n\n  # Withdrawal type - available options (0x00, 0x01, 0x02)\n  # Default to \"0x00\"\n  withdrawal_type: \"0x00\"\n\n  # Withdrawal address\n  # Default to \"0x8943545177806ED17B9F23F0a21ee5948eCaa776\" - 0 address of mnemonic\n  withdrawal_address: \"0x8943545177806ED17B9F23F0a21ee5948eCaa776\"\n\n  # Validator balance (available ranges: 32-2048)\n  # Default to 32 ETH\n  validator_balance: 32\n\n  # Minimum number of epochs for data column sidecars requests\n  # Default to 4096\n  min_epochs_for_data_column_sidecars_requests: 4096\n\n  # Minimum number of epochs for block requests\n  # Default to 33024\n  min_epochs_for_block_requests: 33024\n\n# Global parameters for the network\n\n# By default we do not launch anything\n# - Default: []\nadditional_services:\n  - apache\n  - assertoor\n  - blobscan\n  - blockscout\n  - blutgang\n  - bootnodoor\n  - broadcaster\n  - checkpointz\n  - custom_flood\n  - dora\n  - dugtrio\n  - erpc\n  - forkmon\n  - forky\n  - full_beaconchain_explorer\n  - grafana\n  - mempool_bridge\n  - prometheus\n  - spamoor\n  - tempo\n  - tracoor\n  - tx_fuzz\n\n# Configuration place for blockscout explorer - https://github.com/blockscout/blockscout\nblockscout_params:\n  # blockscout docker image to use\n  # Defaults to ghcr.io/blockscout/blockscout:latest\n  image: \"ghcr.io/blockscout/blockscout:latest\"\n  # blockscout smart contract verifier image to use\n  # Defaults to ghcr.io/blockscout/smart-contract-verifier:latest\n  verif_image: \"ghcr.io/blockscout/smart-contract-verifier:latest\"\n  # Frontend image\n  # Defaults to ghcr.io/blockscout/frontend:latest\n  frontend_image: \"ghcr.io/blockscout/frontend:latest\"\n  # Environment variables\n  env: {}\n\n# Configuration place for dora the explorer - https://github.com/ethpandaops/dora\ndora_params:\n  # Dora docker image to use\n  # Defaults to the latest image\n  image: \"ethpandaops/dora:latest\"\n  # A list of optional extra env_vars the dora container should spin up with\n  env: {}\n\n# Configuration place for checkpointz - https://github.com/ethpandaops/checkpointz\ncheckpointz_params:\n  # Checkpointz docker image to use\n  # Defaults to the latest image\n  image: \"ethpandaops/checkpointz:latest\"\n\n# Define custom file contents to be mounted into containers\n# These files are referenced by name in el_extra_mounts, cl_extra_mounts, and vc_extra_mounts\nextra_files: {}\n  # Example:\n  # my_config_file.yaml: |\n  #   setting1: value1\n  #   setting2: value2\n  # my_script.sh: |\n  #   #!/bin/bash\n  #   echo \"Custom script\"\n\n# Configuration place for transaction spammer - https://github.com/MariusVanDerWijden/tx-fuzz\ntx_fuzz_params:\n  # TX Spammer docker image to use\n  # Defaults to the latest master image\n  image: \"ethpandaops/tx-fuzz:master\"\n  # A list of optional extra params that will be passed to the TX Spammer container for modifying its behaviour\n  tx_fuzz_extra_args: []\n\n# Configuration place for prometheus\nprometheus_params:\n  storage_tsdb_retention_time: \"1d\"\n  storage_tsdb_retention_size: \"512MB\"\n  # Resource management for prometheus container\n  # CPU is milicores\n  # RAM is in MB\n  min_cpu: 10\n  max_cpu: 1000\n  min_mem: 128\n  max_mem: 2048\n  # Prometheus docker image to use\n  # Defaults to the latest image\n  image: \"prom/prometheus:latest\"\n\n# Configuration place for grafana\ngrafana_params:\n  # A list of locators for grafana dashboards to be loaded be the grafana service\n  additional_dashboards: []\n  # Resource management for grafana container\n  # CPU is milicores\n  # RAM is in MB\n  min_cpu: 10\n  max_cpu: 1000\n  min_mem: 128\n  max_mem: 2048\n  # Grafana docker image to use\n  # Defaults to the latest image\n  image: \"grafana/grafana:latest\"\n\n# Bootnodoor params\nbootnodoor_params:\n  # Bootnodoor docker image to use\n  # Defaults to the latest image\n  image: \"ethpandaops/bootnodoor:latest\"\n  min_cpu: 100\n  max_cpu: 1000\n  min_mem: 128\n  max_mem: 512\n  # A list of optional extra args the bootnodoor container should spin up with\n  extra_args: []\n\n# Configuration place for tempo tracing backend\ntempo_params:\n  # How long to retain traces\n  retention_duration: \"12h\"\n  # Rate limiting for trace ingestion (bytes per second)\n  ingestion_rate_limit: 20971520  # 20MB\n  # Burst limit for trace ingestion (bytes)\n  ingestion_burst_limit: 52428800  # 50MB\n  # Maximum duration for trace searches\n  max_search_duration: \"30s\"\n  # Maximum bytes per individual trace\n  max_bytes_per_trace: 52428800  # 50MB\n  # Resource management for tempo container\n  # CPU is milicores\n  # RAM is in MB\n  min_cpu: 10\n  max_cpu: 1000\n  min_mem: 128\n  max_mem: 2048\n  # Tempo docker image to use\n  # Defaults to the latest image\n  image: \"grafana/tempo:latest\"\n\n# Configuration place for the assertoor testing tool - https://github.com/ethpandaops/assertoor\nassertoor_params:\n  # Assertoor docker image to use\n  # Defaults to the latest image\n  image: \"ethpandaops/assertoor:latest\"\n\n  # Check chain stability\n  # This check monitors the chain and succeeds if:\n  # - all clients are synced\n  # - chain is finalizing for min. 2 epochs\n  # - \u003e= 98% correct target votes\n  # - \u003e= 80% correct head votes\n  # - no reorgs with distance \u003e 2 blocks\n  # - no more than 2 reorgs per epoch\n  run_stability_check: false\n\n  # Check block proposals\n  # This check monitors the chain and succeeds if:\n  # - all client pairs have proposed a block\n  run_block_proposal_check: false\n\n  # Run normal transaction test\n  # This test generates random EOA transactions and checks inclusion with/from all client pairs\n  # This test checks for:\n  # - block proposals with transactions from all client pairs\n  # - transaction inclusion when submitting via each client pair\n  # test is done twice, first with legacy (type 0) transactions, then with dynfee (type 2) transactions\n  run_transaction_test: false\n\n  # Run blob transaction test\n  # This test generates blob transactions and checks inclusion with/from all client pairs\n  # This test checks for:\n  # - block proposals with blobs from all client pairs\n  # - blob inclusion when submitting via each client pair\n  run_blob_transaction_test: false\n\n  # Run all-opcodes transaction test\n  # This test generates a transaction that triggers all EVM OPCODES once\n  # This test checks for:\n  # - all-opcodes transaction success\n  run_opcodes_transaction_test: false\n\n  # Run validator lifecycle test (~48h to complete)\n  # This test requires exactly 500 active validator keys.\n  # The test will cause a temporary chain unfinality when running.\n  # This test checks:\n  # - Deposit inclusion with/from all client pairs\n  # - BLS Change inclusion with/from all client pairs\n  # - Voluntary Exit inclusion with/from all client pairs\n  # - Attester Slashing inclusion with/from all client pairs\n  # - Proposer Slashing inclusion with/from all client pairs\n  # all checks are done during finality \u0026 unfinality\n  run_lifecycle_test: false\n\n  # Run additional tests from external test definitions\n  # Entries may be simple strings (link to the test file) or dictionaries with more flexibility\n  # eg:\n  #   - https://raw.githubusercontent.com/ethpandaops/assertoor/master/example/tests/block-proposal-check.yaml\n  #   - file: \"https://raw.githubusercontent.com/ethpandaops/assertoor/master/example/tests/block-proposal-check.yaml\"\n  #     config:\n  #       someCustomTestConfig: \"some value\"\n  tests: []\n\n\n# If set, the package will block until a finalized epoch has occurred.\nwait_for_finalization: false\n\n# The global log level that all clients should log at\n# Valid values are \"error\", \"warn\", \"info\", \"debug\", and \"trace\"\n# This value will be overridden by participant-specific values\nglobal_log_level: \"info\"\n\n# Snooper global flag for all participants\n# Snooper can be enabled with the `snooper_enabled` flag per client or globally\n# Snooper dumps all JSON-RPC requests and responses including BeaconAPI, EngineAPI and ExecutionAPI.\n# Default to false\nsnooper_enabled: false\n\n# Enables Ethereum Metrics Exporter for all participants\n# Defaults to false\nethereum_metrics_exporter_enabled: false\n\n# Parallelizes keystore generation so that each node has keystores being generated in their own container\n# This will result in a large number of containers being spun up than normal. We advise users to only enable this on a sufficiently large machine or in the cloud as it can be resource consuming on a single machine.\nparallel_keystore_generation: false\n\n# Disable peer scoring to prevent nodes impacted by faults from being permanently ejected from the network\n# Default to false\ndisable_peer_scoring: false\n\n# Whether the environment should be persistent; this is WIP and is slowly being rolled out across services\n# Note this requires Kurtosis greater than 0.85.49 to work\n# Note Erigon, Besu, Teku persistence is not currently supported with docker.\n# Defaults to false\npersistent: false\n\n# Docker cache url enables all docker images to be pulled through a custom docker registry\n# Disabled by default\n# Defaults to empty cache url\n# Images pulled from dockerhub will be prefixed with \"/dh/\" by default (docker.io)\n# Images pulled from github registry will be prefixed with \"/gh/\" by default (ghcr.io)\n# Images pulled from google registry will be prefixed with \"/gcr/\" by default (gcr.io)\n# If you want to use a local image in combination with the cache, do not put \"/\" in your local image name\ndocker_cache_params:\n  enabled: false\n  url: \"\"\n  dockerhub_prefix: \"/dh/\"\n  github_prefix: \"/gh/\"\n  google_prefix: \"/gcr/\"\n\n\n# Configuration place for mempool bridge (https://github.com/ethpandaops/mempool-bridge)\nmempool_bridge_params:\n  # The image to use for mempool bridge\n  image: ethpandaops/mempool-bridge:latest\n  # The mode for mempool bridge operation\n  # Valid values are \"p2p\" or \"rpc\"\n  # Default: \"p2p\"\n  mode: \"p2p\"\n  # The source enodes to use for mempool bridge\n  # Example:\n  # P2P mode:\n  # source_enodes:\n  #   - enode://1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef@127.0.0.1:30303\n  #   - enode://1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef@127.0.0.1:30304\n  # RPC mode:\n  # source_enodes:\n  #   - http://127.0.0.1:8545\n  #   - http://127.0.0.1:8546\n  # Default: []\n  source_enodes: []\n\n  # The log level for mempool bridge\n  # Valid values are \"error\", \"warn\", \"info\", \"debug\", and \"trace\"\n  # If empty, will use the global_log_level value\n  # Default: \"\" (uses global_log_level)\n  log_level: \"\"\n\n  # The number of concurrent goroutines to use when sending transactions to targets\n  # Default: 10\n  send_concurrency: 10\n\n  # The interval in seconds for polling the source for new transactions\n  # Default: \"10s\"\n  polling_interval: \"10s\"\n\n  # The retry interval duration for retrying failed operations\n  # Default: \"30s\"\n  retry_interval: \"30s\"\n\n# Supports six values\n# Default: \"null\" - no mev boost, mev builder, mev flood or relays are spun up\n# \"mock\" - mock-builder \u0026 mev-boost are spun up\n# \"flashbots\" - mev-boost, relays, flooder and builder are all spun up, powered by [flashbots](https://github.com/flashbots)\n# \"mev-rs\" - mev-boost, relays and builder are all spun up, powered by [mev-rs](https://github.com/ralexstokes/mev-rs/)\n# \"commit-boost\" - mev-boost, relays and builder are all spun up, powered by [commit-boost](https://github.com/Commit-Boost/commit-boost-client)\n# \"helix\" - helix relay, flashbots builder and mev-boost are spun up, powered by [helix](https://github.com/gattaca-com/helix)\n#            Note: Helix uses TimescaleDB (PostgreSQL with time-series extension) for data storage\n# We have seen instances of multibuilder instances failing to start mev-relay-api with non zero epochs\nmev_type: null\n\n# Parameters if MEV is used\nmev_params:\n  # The image to use for MEV boost relay\n  mev_relay_image: ethpandaops/mev-boost-relay:main\n  # The image to use for the builder\n  mev_builder_image: ethpandaops/reth-rbuilder:develop\n  # The image to use for the CL builder\n  mev_builder_cl_image: sigp/lighthouse:latest\n  # Extra parameters to send to the CL builder\n  mev_builder_cl_extra_params: []\n  # The subsidy to use for the builder (in ETH)\n  mev_builder_subsidy: 0\n  # The image to use for mev-boost\n  mev_boost_image: ethpandaops/mev-boost:develop\n  # Parameters for MEV Boost. This overrides all arguments of the mev-boost container\n  mev_boost_args: []\n  # Extra parameters to send to the API\n  mev_relay_api_extra_args: []\n  # Extra environment variables to send to the API\n  mev_relay_api_extra_env_vars: {}\n  # Extra parameters to send to the housekeeper\n  mev_relay_housekeeper_extra_args: []\n  # Extra environment variables to send to the housekeeper\n  mev_relay_housekeeper_extra_env_vars: {}\n  # Extra parameters to send to the website\n  mev_relay_website_extra_args: []\n  # Extra environment variables to send to the website\n  mev_relay_website_extra_env_vars: {}\n  # Extra parameters to send to the builder\n  mev_builder_extra_args: []\n  # Prometheus additional configuration for the mev builder participant.\n  # Execution, beacon and validator client targets on prometheus will include this configuration.\n  mev_builder_prometheus_config:\n    # Scrape interval to be used. Default to 15 seconds\n    scrape_interval: 15s\n    # Additional labels to be added. Default to empty\n    labels: {}\n  # Image to use for mock mev\n  mock_mev_image: ethpandaops/rustic-builder:main\n  # Whether to launch Adminer for the MEV relay PostgreSQL database\n  launch_adminer: false\n\n# Enables Xatu Sentry for all participants\n# Defaults to false\nxatu_sentry_enabled: false\n\n# Xatu Sentry params\nxatu_sentry_params:\n  # The image to use for Xatu Sentry\n  xatu_sentry_image: ethpandaops/xatu:latest\n  # GRPC Endpoint of Xatu Server to send events to\n  xatu_server_addr: localhost:8080\n  # Enables TLS to Xatu Server\n  xatu_server_tls: false\n  # Headers to add on to Xatu Server requests\n  xatu_server_headers: {}\n  # Beacon event stream topics to subscribe to\n  beacon_subscriptions:\n    - attestation\n    - single_attestation\n    - block\n    - block_gossip\n    - chain_reorg\n    - finalized_checkpoint\n    - head\n    - voluntary_exit\n    - contribution_and_proof\n    - blob_sidecar\n    - data_column_sidecar\n# Apache params\n# Apache public port to port forward to local machine\n# Default to port None, only set if apache additional service is activated\napache_port: null\n\n# Global tolerations that will be passed to all containers (unless overridden by a more specific toleration)\n# Only works with Kubernetes\n# Example: tolerations:\n# - key: \"key\"\n#   operator: \"Equal\"\n#   value: \"value\"\n#   effect: \"NoSchedule\"\n#   toleration_seconds: 3600\n# Defaults to empty\nglobal_tolerations: []\n\n# Global node selector that will be passed to all containers (unless overridden by a more specific node selector)\n# Only works with Kubernetes\n# Example: global_node_selectors: { \"disktype\": \"ssd\" }\n# Defaults to empty\nglobal_node_selectors: {}\n\n# Global parameters for keymanager api\n# This will open up http ports to your validator services!\n# Defaults to false\nkeymanager_enabled: false\n\n# Global flag to enable checkpoint sync across the network\n# Default to false\ncheckpoint_sync_enabled: false\n\n# Global flag to set checkpoint sync url\ncheckpoint_sync_url: \"\"\n\n# Configuration place for spamoor as transaction spammer\nspamoor_params:\n  # The image to use for spamoor\n  image: ethpandaops/spamoor:latest\n  # Resource management for spamoor\n  # CPU is milicores\n  # RAM is in MB\n  min_cpu: 10\n  max_cpu: 1000\n  min_mem: 20\n  max_mem: 300\n  # A list of spammers to launch on startup\n  # example:\n  # - scenario: eoatx  # The spamoor scenario to use (see https://github.com/ethpandaops/spamoor)\n  #   name: \"Optional name for this example spammer\"\n  #   config:\n  #     throughput: 10  # 10 tx per block\n  # - scenario: erctx\n  #   config:\n  #     throughput: 10  # 10 tx per block\n  spammers: []\n  # A list of optional params that will be passed to the spamoor command for modifying its behaviour\n  extra_args: []\n\n# Ethereum genesis generator params\nethereum_genesis_generator_params:\n  # The image to use for ethereum genesis generator\n  image: ethpandaops/ethereum-genesis-generator:5.2.2\n  # Pass custom environment variables to the genesis generator (e.g. MY_VAR: my_value)\n  extra_env: {}\n\n# Configuration for public ports and NAT exit IP addresses\nport_publisher:\n  # Global NAT exit IP address for all services (optional)\n  # If set, this will be used for all service groups (overrides individual nat_exit_ip settings)\n  # Set to \"auto\" to automatically detect public IP from ident.me\n  # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (uses per-service settings)\n  nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # Execution Layer public port exposed to your local machine\n  # Disabled by default\n  # Public port start defaults to 32000\n  # You can't run multiple enclaves on the same port settings\n  el:\n    enabled: false\n    public_port_start: 32000\n    # nat_exit_ip: IP address to expose for EL P2P networking (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # Consensus Layer public port exposed to your local machine\n  # Disabled by default\n  # Public port start defaults to 33000\n  # You can't run multiple enclaves on the same port settings\n  cl:\n    enabled: false\n    public_port_start: 33000\n    # nat_exit_ip: IP address to expose for CL P2P networking (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # Validator client public port exposed to your local machine\n  # Disabled by default\n  # Public port start defaults to 34000\n  # You can't run multiple enclaves on the same port settings\n  vc:\n    enabled: false\n    public_port_start: 34000\n    # nat_exit_ip: IP address to expose for VC networking (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # remote signer public port exposed to your local machine\n  # Disabled by default\n  # Public port start defaults to 35000\n  # You can't run multiple enclaves on the same port settings\n  remote_signer:\n    enabled: false\n    public_port_start: 35000\n    # nat_exit_ip: IP address to expose for remote signer networking (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # Additional services public port exposed to your local machine\n  # Disabled by default\n  # Public port start defaults to 36000\n  # You can't run multiple enclaves on the same port settings\n  additional_services:\n    enabled: false\n    public_port_start: 36000\n    # nat_exit_ip: IP address to expose for additional services (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # MEV public port exposed to your local machine\n  # Disabled by default\n  # Public port start defaults to 37000\n  # You can't run multiple enclaves on the same port settings\n  mev:\n    enabled: false\n    public_port_start: 37000\n    # nat_exit_ip: IP address to expose for MEV services (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n\n  # Other public port exposed to your local machine (like ethereum metrics exporter, snooper)\n  # Disabled by default\n  # Public port start defaults to 38000\n  # You can't run multiple enclaves on the same port settings\n  other:\n    enabled: false\n    public_port_start: 38000\n    # nat_exit_ip: IP address to expose for other services (optional)\n    # Only used if global nat_exit_ip is not set\n    # Set to \"auto\" to automatically detect public IP from ident.me\n    # Defaults to KURTOSIS_IP_ADDR_PLACEHOLDER (container IP)\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER\n```\n\n### Example configurations\n\n\u003cdetails\u003e\n    \u003csummary\u003ePort Publisher Configuration Examples\u003c/summary\u003e\n\n**Global NAT Exit IP (Backward Compatible)**\n\n```yaml\nport_publisher:\n  nat_exit_ip: \"auto\"  # All services use auto-detected public IP\n  el:\n    enabled: true\n    public_port_start: 32000\n  cl:\n    enabled: true\n    public_port_start: 33000\n  additional_services:\n    enabled: true\n    public_port_start: 36000\n```\n\n**Per-Service NAT Exit IP (Granular Control)**\n\n```yaml\nport_publisher:\n  nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER  # Not set globally\n  el:\n    enabled: true\n    public_port_start: 32000\n    nat_exit_ip: \"auto\"  # Only EL uses public IP\n  cl:\n    enabled: true\n    public_port_start: 33000\n    nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER  # CL uses container IP\n  additional_services:\n    enabled: true\n    public_port_start: 36000\n    nat_exit_ip: \"192.168.1.100\"  # Custom IP for additional services\n```\n\n**Mixed Configuration**\n\n```yaml\nport_publisher:\n  nat_exit_ip: KURTOSIS_IP_ADDR_PLACEHOLDER  # Not set globally\n  el:\n    enabled: true\n    public_port_start: 32000\n    nat_exit_ip: \"auto\"  # Auto-detect for EL\n  cl:\n    enabled: true\n    public_port_start: 33000\n    nat_exit_ip: \"auto\"  # Auto-detect for CL\n  additional_services:\n    enabled: true\n    public_port_start: 36000\n    # Uses default KURTOSIS_IP_ADDR_PLACEHOLDER for additional services\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n    \u003csummary\u003eVerkle configuration example\u003c/summary\u003e\n\n```yaml\nparticipants:\n  - el_type: geth\n    el_image: ethpandaops/geth:\u003cVERKLE_IMAGE\u003e\n    el_extra_params:\n    - \"--override.verkle=\u003cUNIXTIMESTAMP\u003e\"\n    cl_type: lighthouse\n    cl_image: sigp/lighthouse:latest\n  - el_type: geth\n    el_image: ethpandaops/geth:\u003cVERKLE_IMAGE\u003e\n    el_extra_params:\n    - \"--override.verkle=\u003cUNIXTIMESTAMP\u003e\"\n    cl_type: lighthouse\n    cl_image: sigp/lighthouse:latest\n  - el_type: geth\n    el_image: ethpandaops/geth:\u003cVERKLE_IMAGE\u003e\n    el_extra_params:\n    - \"--override.verkle=\u003cUNIXTIMESTAMP\u003e\"\n    cl_type: lighthouse\n    cl_image: sigp/lighthouse:latest\nnetwork_params:\n  deneb_fork_epoch: 0\nwait_for_finalization: false\nglobal_log_level: info\n\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n    \u003csummary\u003eA 3-node Ethereum network with \"mock\" MEV mode.\u003c/summary\u003e\n    Useful for testing mev-boost and the client implementations without adding the complexity of the relay. This can be enabled by a single config command and would deploy the [mock-builder](https://github.com/marioevz/mock-builder), instead of the relay infrastructure.\n\n```yaml\nparticipants:\n  - el_type: geth\n    el_image: ''\n    cl_type: lighthouse\n    cl_image: ''\n    count: 2\n  - el_type: nethermind\n    el_image: ''\n    cl_type: teku\n    cl_image: ''\n    count: 1\n  - el_type: besu\n    el_image: ''\n    cl_type: prysm\n    cl_image: ''\n    count: 2\nmev_type: mock\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n    \u003csummary\u003eA 5-node Ethereum network with three different CL and EL client combinations and mev-boost infrastructure in \"full\" mode.\u003c/summary\u003e\n\n```yaml\nparticipants:\n  - el_type: geth\n    cl_type: lighthouse\n    count: 2\n  - el_type: nethermind\n    cl_type: teku\n  - el_type: besu\n    cl_type: prysm\n    count: 2\nmev_type: flashbots\nnetwork_params:\n  deneb_fork_epoch: 1\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n    \u003csummary\u003eA 3-node Ethereum network with Helix relay for MEV-boost infrastructure\u003c/summary\u003e\n\n```yaml\nparticipants:\n  - el_type: geth\n    el_image: ethpandaops/geth:master\n    cl_type: lighthouse\n    cl_image: ethpandaops/lighthouse:unstable\n    count: 2\n  - el_type: nethermind\n    el_image: ethpandaops/nethermind:master\n    cl_type: prysm\n    cl_image: ethpandaops/prysm-beacon-chain:develop\n\nmev_type: helix\nmev_params:\n  mev_relay_image: ghcr.io/gattaca-com/helix-relay:main\n  mev_builder_image: ethpandaops/reth-rbuilder:develop\n  mev_boost_image: ethpandaops/mev-boost:develop\n  mev_builder_cl_image: ethpandaops/lighthouse:unstable\n  mev_builder_subsidy: 1\n\nadditional_services:\n  - dora\n  - spamoor\n\nnetwork_params:\n  min_validator_withdrawability_delay: 1\n  shard_committee_period: 1\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n    \u003csummary\u003eA 2-node geth/lighthouse network with optional services (Grafana, Prometheus, tx_fuzz, EngineAPI snooper)\u003c/summary\u003e\n\n```yaml\nparticipants:\n  - el_type: geth\n    cl_type: lighthouse\n    count: 2\nsnooper_enabled: true\nadditional_services:\n  - prometheus\n  - grafana\n  - tx_fuzz\nethereum_metrics_exporter_enabled: true\n```\n\n\u003c/details\u003e\n\n## Extra Files and Mounts\n\nThe `extra_files` feature allows you to define custom file contents in your configuration and mount them into any container (EL, CL, or VC).\n\n### How It Works\n\n1. **Define file contents** in the top-level `extra_files` section\n2. **Mount the files** into containers using `el_extra_mounts`, `cl_extra_mounts`, or `vc_extra_mounts`\n3. **Access the files** inside the container at `\u003cmount_path\u003e/\u003cfile_name\u003e`\n\n### Important: Understanding Mount Paths\n\nDue to how Kurtosis handles artifacts, mount paths become **directories**, not files. When you mount a file:\n\n- The mount path you specify becomes a directory\n- Your file is placed inside that directory with its original name from `extra_files`\n\n### Complete Example\n\n```yaml\n# Define your custom files at the top level\nextra_files:\n  validator_config.json: |\n    {\n      \"graffiti\": \"MyValidator\",\n      \"enable_doppelganger\": true,\n      \"suggested_fee_recipient\": \"0x1234...\"\n    }\n\nparticipants:\n  - el_type: geth\n    cl_type: lighthouse\n\n    # Mount files into the consensus layer client\n    cl_extra_mounts:\n      \"/configs\": \"validator_config.json\" # File available at: /configs/validator_config.json\n```\n\n## Beacon Node \u003c\u003e Validator Client compatibility\n\n|               | Lighthouse VC | Prysm VC | Teku VC | Lodestar VC | Nimbus VC\n|---------------|---------------|----------|---------|-------------|-----------|\n| Lighthouse BN | ✅            | ✅       | ✅      | ✅          | ✅\n| Prysm BN      | ✅            | ✅       | ✅      | ✅          | ✅\n| Teku BN       | ✅            | ✅       | ✅      | ✅          | ✅\n| Lodestar BN   | ✅            | ✅       | ✅      | ✅          | ✅\n| Nimbus BN     | ✅            | ✅       | ✅      | ✅          | ✅\n| Grandine BN   | ✅            | ✅       | ✅      | ✅          | ✅\n\n## Custom labels for Docker and Kubernetes\n\nThere are 6 custom labels that can be used to identify the nodes in the network. These labels are used to identify the nodes in the network and can be used to run chaos tests on specific nodes. An example for these labels are as follows:\n\nExecution Layer (EL) nodes:\n\n```sh\n  \"kurtosistech.com.custom/ethereum-package.client\": \"geth\",\n  \"kurtosistech.com.custom/ethereum-package.client-image\": \"ethereum-client-go-latest\",\n  \"kurtosistech.com.custom/ethereum-package.client-language:\": \"go\",\n  \"kurtosistech.com.custom/ethereum-package.client-type\": \"execution\",\n  \"kurtosistech.com.custom/ethereum-package.connected-client\": \"lighthouse\",\n  \"kurtosistech.com.custom/ethereum-package.node-index\": \"1\",\n```\n\nConsensus Layer (CL) nodes - Beacon:\n\n```sh\n  \"kurtosistech.com.custom/ethereum-package.client\": \"lighthouse\",\n  \"kurtosistech.com.custom/ethereum-package.client-image\": \"sigp-lighthouse-latest\",\n  \"kurtosistech.com.custom/ethereum-package.client-language:\": \"rust\",\n  \"kurtosistech.com.custom/ethereum-package.client-type\": \"beacon\",\n  \"kurtosistech.com.custom/ethereum-package.connected-client\": \"geth\",\n  \"kurtosistech.com.custom/ethereum-package.node-index\": \"1\",\n```\n\nConsensus Layer (CL) nodes - Validator:\n\n```sh\n  \"kurtosistech.com.custom/ethereum-package.client\": \"lighthouse\",\n  \"kurtosistech.com.custom/ethereum-package.client-image\": \"sigp-lighthouse-latest\",\n  \"kurtosistech.com.custom/ethereum-package.client-language:\": \"rust\",\n  \"kurtosistech.com.custom/ethereum-package.client-type\": \"validator\",\n  \"kurtosistech.com.custom/ethereum-package.connected-client\": \"geth\",\n  \"kurtosistech.com.custom/ethereum-package.node-index\": \"1\",\n```\n\n- `ethereum-package.client` describes which client is running on the node.\n- `ethereum-package.client-image` describes the image that is used for the client.\n- `ethereum-package.client-type` describes the type of client that is running on the node (`execution`,`beacon` or `validator`).\n- `ethereum-package.connected-client` describes the CL/EL client that is connected to the EL/CL client.\n- `ethereum-package.client-language` describes the implementation language of the running service.\n- `ethereum-package.node-index` describes the index of the node (participant) that the service belongs to.\n\n## Proposer Builder Separation (PBS) emulation\n\nTo spin up the network of Ethereum nodes with an external block building network (using Flashbot's `mev-boost` protocol), simply use:\n\n```bash\nkurtosis run github.com/ethpandaops/ethereum-package '{\"mev_type\": \"flashbots\"}'\n```\n\nStarting your network up with `\"mev_type\": \"flashbots\"` will instantiate and connect the following infrastructure to your network:\n\n1. `Flashbot's block builder \u0026 CL validator + beacon` - A modified Geth client that builds blocks. The CL validator and beacon clients are lighthouse clients configured to receive payloads from the relay.\n2. `mev-relay-api` - Services that provide APIs for (a) proposers, (b) block builders, (c) data\n3. `mev-relay-website` - A website to monitor payloads that have been delivered\n4. `mev-relay-housekeeper` - Updates known validators, proposer duties, and more in the background. Only a single instance of this should run.\n5. `mev-boost` - open-source middleware instantiated for each EL/Cl pair in the network, including the builder\n\nThe package also supports other MEV implementations:\n\n- `\"mev_type\": \"helix\"` - Uses the high-performance [Helix relay](https://github.com/gattaca-com/helix) with TimescaleDB backend for data storage\n- `\"mev_type\": \"mev-rs\"` - Alternative relay implementation powered by [mev-rs](https://github.com/ralexstokes/mev-rs/)\n- `\"mev_type\": \"commit-boost\"` - Infrastructure powered by [commit-boost](https://github.com/Commit-Boost/commit-boost-client)\n\nEach implementation provides different features and performance characteristics suitable for various testing and development scenarios.\n\n\u003cdetails\u003e\n    \u003csummary\u003eCaveats when using \"mev_type\": \"flashbots\"\u003c/summary\u003e\n\n- Validators (64 per node by default, so 128 in the example in this guide) will get registered with the relay automatically after the 1st epoch. This registration process is simply a configuration addition to the mev-boost config - which Kurtosis will automatically take care of as part of the set up. This means that the mev-relay infrastructure only becomes aware of the existence of the validators after the 1st epoch.\n- After the 3rd epoch, the mev-relay service will begin to receive execution payloads (eth_sendPayload, which does not contain transaction content) from the mev-builder service (or mock-builder in mock-mev mode).\n- Validators will start to receive validated execution payload headers from the mev-relay service (via mev-boost) after the 4th epoch. The validator selects the most valuable header, signs the payload, and returns the signed header to the relay - effectively proposing the payload of transactions to be included in the soon-to-be-proposed block. Once the relay verifies the block proposer's signature, the relay will respond with the full execution payload body (incl. the transaction contents) for the validator to use when proposing a SignedBeaconBlock to the network.\n\n\u003c/details\u003e\n\nThis package also supports a `\"mev_type\": \"mock\"` mode that will only bring up:\n\n1. `mock-builder` - a server that listens for builder API directives and responds with payloads built using an execution client\n1. `mev-boost` - for every EL/CL pair launched\n\nFor more details, including a guide and architecture of the `mev-boost` infrastructure, go [here](https://docs.kurtosis.com/how-to-full-mev-with-ethereum-package/).\n\n## Pre-funded accounts at Genesis\n\nThis package comes with [21 prefunded keys for testing](https://github.com/ethpandaops/ethereum-package/blob/main/src/prelaunch_data_generator/genesis_constants/genesis_constants.star).\n\nHere's a table of where the keys are used\n\n| Account Index | Component Used In   | Private Key Used | Public Key Used | Comment                     |\n|---------------|---------------------|------------------|-----------------|-----------------------------|\n| 0             | Builder             | ✅                |                 | As coinbase                |\n| 0             | mev_custom_flood    |                   | ✅              | As the receiver of balance |\n| 3             | tx_fuzz | ✅                |                 | To spam transactions with  |\n| 8             | assertoor           | ✅                | ✅              | As the funding for tests   |\n| 11            | mev_custom_flood    | ✅                |                 | As the sender of balance   |\n| 12            | l2_contracts        | ✅                |                 | Contract deployer address  |\n| 13            | spamoor             | ✅                |                 | Spams transactions         |\n\n## Developing On This Package\n\nFirst, install prerequisites:\n\n1. [Install Kurtosis itself][kurtosis-cli-installation]\n\nThen, run the dev loop:\n\n1. Make your code changes\n1. **Run the linter to format and check your code:**\n\n   ```bash\n   kurtosis lint --format\n   ```\n\n   This ensures your Starlark code follows the project's formatting standards and catches any syntax issues.\n\n1. Rebuild and re-run the package by running the following from the root of the repo:\n\n   ```bash\n   kurtosis run . \"{}\"\n   ```\n\n   NOTE 1: You can change the value of the second positional argument flag to pass in extra configuration to the package per the \"Configuration\" section above!\n   NOTE 2: The second positional argument accepts JSON.\n\nTo get detailed information about the structure of the package, visit [the architecture docs](./docs/architecture.md).\n\nWhen you're happy with your changes:\n\n1. Create a PR\n1. Add one of the maintainers of the repo as a \"Review Request\":\n   - `parithosh` (Ethereum Foundation)\n   - `barnabasbusa` (Ethereum Foundation)\n   - `pk910` (Ethereum Foundation)\n   - `samcm` (Ethereum Foundation)\n   - `h4ck3rk3y` (Kurtosis)\n   - `mieubrisse` (Kurtosis)\n   - `leederek` (Kurtosis)\n1. Once everything works, merge!\n\n## PeerDAS\n\nWe can use a set of pre-generated node keys to achieve a perfect column distribution on a 128-column network with an 8-column custody requirement.\nFor this to work, we need a network of 16 nodes running, so each node would custody 8 unique columns.\n\nHere's a table of the private keys that can be used to create the nodes:\n\n| nodeId | sep256k1 privKey | columns |\n|--------|-------------|---------|\n| 0x9908...4159 | 0x86e8...4c8d | 17, 51, 52, 76, 103, 113, 117, 118 |\n| 0xacd4...84e1 | 0xe156...c0da | 24, 35, 78, 80, 101, 107, 114, 122 |\n| 0x3916...b3d | 0x932b...9dd5 | 16, 25, 57, 66, 69, 70, 77, 115 |\n| 0x95a8...373b | 0x6eca...ae2c | 9, 30, 82, 99, 105, 116, 123, 125 |\n| 0x4a53...c82 | 0x2e2e...df9b | 10, 14, 61, 85, 86, 90, 111, 126 |\n| 0x4722...8ff9 | 0x2ea0...32e9 | 2, 5, 18, 32, 33, 49, 83, 94 |\n| 0x912d...add3 | 0xc070...da04 | 3, 13, 48, 50, 74, 97, 119, 121 |\n| 0x93cd...3477 | 0xd915...e831 | 40, 42, 53, 58, 62, 87, 89, 120 |\n| 0x1e19...dd2a | 0x077c...89be | 41, 43, 47, 54, 56, 63, 92, 98 |\n| 0x8165...f316 | 0x5a3e...a8a6 | 8, 22, 38, 60, 79, 91, 93, 112 |\n| 0xe705...fe55 | 0xa10f...c636 | 6, 29, 44, 68, 75, 81, 109, 110 |\n| 0x1835...f044 | 0xbeb4...f299 | 0, 11, 26, 27, 34, 36, 39, 95 |\n| 0x4fb2...e3ce | 0x735e...4947 | 4, 15, 28, 55, 72, 73, 88, 108 |\n| 0xd1f9...50c9 | 0x75ba...167a | 7, 12, 31, 37, 45, 65, 71, 84 |\n| 0x024a...8dc5 | 0xd93a...e1a7 | 1, 19, 20, 21, 46, 64, 67, 124 |\n| 0x3f2b...0db3 | 0xbcde...0608 | 23, 59, 96, 100, 102, 104, 106, 127 |\n\nPrivate keys can be found in the `static_files/peerdas-node-keys` directory.\n\n\u003c!------------------------ Only links below here --------------------------------\u003e\n\n[docker-installation]: https://docs.docker.com/get-docker/\n[kurtosis-cli-installation]: https://docs.kurtosis.com/install\n[kurtosis-repo]: https://github.com/kurtosis-tech/kurtosis\n[enclave]: https://docs.kurtosis.com/advanced-concepts/enclaves/\n[package-reference]: https://docs.kurtosis.com/advanced-concepts/packages\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fethpandaops%2Fethereum-package","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fethpandaops%2Fethereum-package","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fethpandaops%2Fethereum-package/lists"}