# To enable/disabled the check_latest_version workflow execution which will be triggered by this scheduled pipeline: https://app.circleci.com/settings/project/github/kurtosis-tech/eth2-package/triggers
# To enable/disabled the check_latest_version workflow execution which will be triggered by this scheduled pipeline: https://app.circleci.com/settings/project/github/kurtosis-tech/ethereum-package/triggers
# TODO revert this - setting this to true to get all existing tests to run on CI during merge
# TODO revert this - setting this to true to get all existing tests to run on CI during merge
@@ -24,13 +24,13 @@ Optional features (enabled via flags or parameter files at runtime):
...
@@ -24,13 +24,13 @@ Optional features (enabled via flags or parameter files at runtime):
2.[Install the Kurtosis CLI, or upgrade it to the latest version if it's already installed][kurtosis-cli-installation]
2.[Install the Kurtosis CLI, or upgrade it to the latest version if it's already installed][kurtosis-cli-installation]
3. Run the package with default configurations from the command line:
3. Run the package with default configurations from the command line:
```bash
```bash
kurtosis run --enclave my-testnet github.com/kurtosis-tech/eth2-package
kurtosis run --enclave my-testnet github.com/kurtosis-tech/ethereum-package
```
```
#### Run with your own configuration
#### Run with your own configuration
Kurtosis 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:
Kurtosis 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:
```bash
```bash
kurtosis run --enclave my-testnet github.com/kurtosis-tech/eth2-package "$(cat ~/network_params.json)"
kurtosis run --enclave my-testnet github.com/kurtosis-tech/ethereum-package "$(cat ~/network_params.json)"
```
```
Where `network_params.json` contains the parameters for your network in your home directory.
Where `network_params.json` contains the parameters for your network in your home directory.
...
@@ -421,7 +421,7 @@ To configure the package behaviour, you can modify your `network_params.json` fi
...
@@ -421,7 +421,7 @@ To configure the package behaviour, you can modify your `network_params.json` fi
## Proposer Builder Separation (PBS) emulation
## Proposer Builder Separation (PBS) emulation
To spin up the network of Ethereum nodes with an external block building network (using Flashbot's `mev-boost` protocol), simply use:
To spin up the network of Ethereum nodes with an external block building network (using Flashbot's `mev-boost` protocol), simply use:
```
```
kurtosis run github.com/kurtosis-tech/eth2-package '{"mev_type": "full"}'
kurtosis run github.com/kurtosis-tech/ethereum-package '{"mev_type": "full"}'
```
```
Starting your network up with `"mev_type": "full"` will instantiate and connect the following infrastructure to your network:
Starting your network up with `"mev_type": "full"` will instantiate and connect the following infrastructure to your network:
@@ -57,25 +57,25 @@ We'll explain these phases one by one.
...
@@ -57,25 +57,25 @@ We'll explain these phases one by one.
All EL clients require both a genesis file and a JWT secret. The exact format of the genesis file differs per client, so we first leverage [a Docker image containing tools for generating this genesis data][ethereum-genesis-generator] to create the actual files that the EL clients-to-be will need. This is accomplished by filling in several genesis generation config files found in [the `static_files` directory][static-files].
All EL clients require both a genesis file and a JWT secret. The exact format of the genesis file differs per client, so we first leverage [a Docker image containing tools for generating this genesis data][ethereum-genesis-generator] to create the actual files that the EL clients-to-be will need. This is accomplished by filling in several genesis generation config files found in [the `static_files` directory][static-files].
The generated output files then get stored in the Kurtosis enclave, ready for use when we start the EL clients. The information about these stored files is tracked in [the `el_genesis_data` struct](https://github.com/kurtosis-tech/eth2-package/blob/main/src/participant_network/prelaunch_data_generator/el_genesis/el_genesis_data.star).
The generated output files then get stored in the Kurtosis enclave, ready for use when we start the EL clients. The information about these stored files is tracked in [the `el_genesis_data` struct](https://github.com/kurtosis-tech/ethereum-package/blob/main/src/participant_network/prelaunch_data_generator/el_genesis/el_genesis_data.star).
### Starting EL clients
### Starting EL clients
Next, we plug the generated genesis data [into EL client "launchers"](https://github.com/kurtosis-tech/eth2-package/tree/main/src/participant_network/el) to start a mining network of EL nodes. The launchers come with a `launch` function that consumes EL genesis data and produces information about the running EL client node. Running EL node information is represented by [an `el_client_context` struct](https://github.com/kurtosis-tech/eth2-package/blob/main/src/participant_network/el/el_client_context.star). Each EL client type has its own launcher (e.g. [Geth](https://github.com/kurtosis-tech/eth2-package/tree/main/src/participant_network/el/geth), [Besu](https://github.com/kurtosis-tech/eth2-package/tree/main/src/participant_network/el/besu)) because each EL client will require different environment variables and flags to be set when launching the client's container.
Next, we plug the generated genesis data [into EL client "launchers"](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/participant_network/el) to start a mining network of EL nodes. The launchers come with a `launch` function that consumes EL genesis data and produces information about the running EL client node. Running EL node information is represented by [an `el_client_context` struct](https://github.com/kurtosis-tech/ethereum-package/blob/main/src/participant_network/el/el_client_context.star). Each EL client type has its own launcher (e.g. [Geth](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/participant_network/el/geth), [Besu](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/participant_network/el/besu)) because each EL client will require different environment variables and flags to be set when launching the client's container.
### Generating CL client data
### Generating CL client data
CL clients, like EL clients, also have genesis and config files that they need. We use [the same Docker image with tools for generating genesis data][ethereum-genesis-generator] to create the necessary CL files, we provide the genesis generation config using templates in [the `static_files` directory][static-files], and we store the generated output files in the Kurtosis enclave in the same way as the EL client genesis files. Like with EL nodes, CL genesis data information is tracked in [the `cl_client_context` struct](https://github.com/kurtosis-tech/eth2-package/blob/main/src/participant_network/el/el_client_context.star).
CL clients, like EL clients, also have genesis and config files that they need. We use [the same Docker image with tools for generating genesis data][ethereum-genesis-generator] to create the necessary CL files, we provide the genesis generation config using templates in [the `static_files` directory][static-files], and we store the generated output files in the Kurtosis enclave in the same way as the EL client genesis files. Like with EL nodes, CL genesis data information is tracked in [the `cl_client_context` struct](https://github.com/kurtosis-tech/ethereum-package/blob/main/src/participant_network/el/el_client_context.star).
The major difference with CL clients is that CL clients have validator keys, so we need to generate keys for the CL clients to use during validation. The generation happens using [the same genesis-generating Docker image][ethereum-genesis-generator], but via a call to [a different tool bundled inside the Docker image](https://github.com/protolambda/eth2-val-tools).
The major difference with CL clients is that CL clients have validator keys, so we need to generate keys for the CL clients to use during validation. The generation happens using [the same genesis-generating Docker image][ethereum-genesis-generator], but via a call to [a different tool bundled inside the Docker image](https://github.com/protolambda/eth2-val-tools).
### Starting CL clients
### Starting CL clients
Once CL genesis data and keys have been created, the CL client nodes are started via [the CL client launchers](https://github.com/kurtosis-tech/eth2-package/tree/main/src/participant_network/cl). Just as with EL clients:
Once CL genesis data and keys have been created, the CL client nodes are started via [the CL client launchers](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/participant_network/cl). Just as with EL clients:
- CL client launchers implement come with a `launch` method
- CL client launchers implement come with a `launch` method
- One CL client launcher exists per client type (e.g. [Nimbus](https://github.com/kurtosis-tech/eth2-package/tree/main/src/participant_network/cl/nimbus), [Lighthouse](https://github.com/kurtosis-tech/eth2-package/tree/main/src/participant_network/cl/lighthouse))
- One CL client launcher exists per client type (e.g. [Nimbus](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/participant_network/cl/nimbus), [Lighthouse](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/participant_network/cl/lighthouse))
- Launched CL node information is tracked in [a `cl_client_context` struct](https://github.com/kurtosis-tech/eth2-package/blob/main/src/participant_network/cl/cl_client_context.star)
- Launched CL node information is tracked in [a `cl_client_context` struct](https://github.com/kurtosis-tech/ethereum-package/blob/main/src/participant_network/cl/cl_client_context.star)
There are only two major difference between CL client and EL client launchers. First, the `cl_client_launcher.launch` method also consumes an `el_client_context`, because each CL client is connected in a 1:1 relationship with an EL client. Second, because CL clients have keys, the keystore files are passed in to the `launch` function as well.
There are only two major difference between CL client and EL client launchers. First, the `cl_client_launcher.launch` method also consumes an `el_client_context`, because each CL client is connected in a 1:1 relationship with an EL client. Second, because CL clients have keys, the keystore files are passed in to the `launch` function as well.
...
@@ -83,10 +83,10 @@ There are only two major difference between CL client and EL client launchers. F
...
@@ -83,10 +83,10 @@ There are only two major difference between CL client and EL client launchers. F
After the Ethereum network is up and running, this package starts several auxiliary containers to make it easier to work with the Ethereum network. At time of writing, these are:
After the Ethereum network is up and running, this package starts several auxiliary containers to make it easier to work with the Ethereum network. At time of writing, these are:
-[Forkmon](https://github.com/kurtosis-tech/eth2-package/tree/main/src/forkmon), a "fork monitor" web UI for visualizing the CL clients' forks
-[Forkmon](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/forkmon), a "fork monitor" web UI for visualizing the CL clients' forks
-[Prometheus](https://github.com/kurtosis-tech/eth2-package/tree/main/src/prometheus) for collecting client node metrics
-[Prometheus](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/prometheus) for collecting client node metrics
-[Grafana](https://github.com/kurtosis-tech/eth2-package/tree/main/src/grafana) for visualizing client node metrics
-[Grafana](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/grafana) for visualizing client node metrics
-[An ETH transaction spammer](https://github.com/kurtosis-tech/eth2-package/tree/main/src/transaction_spammer), which [has been forked off](https://github.com/kurtosis-tech/tx-fuzz) of [Marius' transaction spammer code](https://github.com/MariusVanDerWijden/tx-fuzz) so that it can run as a container
-[An ETH transaction spammer](https://github.com/kurtosis-tech/ethereum-package/tree/main/src/transaction_spammer), which [has been forked off](https://github.com/kurtosis-tech/tx-fuzz) of [Marius' transaction spammer code](https://github.com/MariusVanDerWijden/tx-fuzz) so that it can run as a container
## [Testnet Verifier][testnet-verifier]
## [Testnet Verifier][testnet-verifier]
...
@@ -95,10 +95,10 @@ Once the Ethereum network is up and running, verification logic will be run to e
...
@@ -95,10 +95,10 @@ Once the Ethereum network is up and running, verification logic will be run to e
<!------------------------ Only links below here -------------------------------->
<!------------------------ Only links below here -------------------------------->
# This is set to match this file https://github.com/kurtosis-tech/eth2-package/blob/main/static_files/genesis-generation-config/cl/config.yaml.tmpl#L11
# This is set to match this file https://github.com/kurtosis-tech/ethereum-package/blob/main/static_files/genesis-generation-config/cl/config.yaml.tmpl#L11