kurtosis-tech / ethereum-package Goto Github PK

View Code? Open in Web Editor NEW

162.0 10.0 72.0 5.87 MB

A Kurtosis package that deploys a private, portable, and modular Ethereum devnet

License: MIT License

Starlark 98.61% Python 0.57% Shell 0.51% HTML 0.31%

kurtosis kurtosis-package docker ethereum flashbots kubernetes mev mev-bot blockchain reth

ethereum-package's People

Contributors

Stargazers

Watchers

Forkers

parithosh pinkdiamond1 barnabasbusa crytic locklabsxyz gmh5225 ssghost da-bao-jian joshiedo marioevz calypsoidea avalonche bharath-123 btcsinc h4ck3rk3y gobitfly userbox020 piwonskp loocapro nethermindeth 0xtylerholmes pk910 leeederek abhijeetbhagat crytic remoterami samcm makpara arberx sekmet lzeroanalytics vuittont60 lyfsn tofel pablocastellano igor-ritual bswap-eng anomalyfi jimmygchen kamilchodola exca-dk macladson franjoespejo jacobkaufmann pamenarti shamirlabs flashbots bnovil eth2353 prof-project y0sher trungdlp-wolffun sryps pufferfinance obolnetwork grandinetech chris-moller vjgaur giaki3003 sogolmalek sbellem chainbound gorondan eaglelabs-consulting lambdaclass ralexstokes tedim52 racytech puerhub

ethereum-package's Issues

move away from facts & waits towards get_value for the enr requests

Remove duplicate in prysm launcher

Is this even needed? we have the same flag on line 236.

Originally posted by @h4ck3rk3y in kurtosis-tech/zzz-deprecated-eth2-merge-kurtosis-module#130 (comment)

add support for trusted_setup.txt

https://github.com/ethpandaops/ethereum-genesis-generator/blob/master/entrypoint.sh#L11

Get the Nethermind ENR so that CL clients can connect to it

Add unit tests to the module

This would require some functionality in the CLI to find and execute the unit tests.

count is not considered when doing the check for actual_num_validators

{
  "participants": [
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:master",
      "cl_client_type": "teku",
      "cl_client_image": "consensys/teku:develop",
      "el_max_mem": 1000,
      "count": 10
    },
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:master",
      "cl_client_type": "lighthouse",
      "cl_client_image": "sigp/lighthouse:latest",
      "el_max_mem": 1000,
      "count": 10
    },
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:master",
      "cl_client_type": "lodestar",
      "cl_client_image": "chainsafe/lodestar:latest",
      "el_max_mem": 1000,
      "count": 10
    },
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:master",
      "cl_client_type": "prysm",
      "cl_client_image": "prysmaticlabs/prysm-beacon-chain:latest,prysmaticlabs/prysm-validator:latest",
      "el_max_mem": 1000,
      "count": 10
    },
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:master",
      "cl_client_type": "nimbus",
      "cl_client_image": "statusim/nimbus-eth2:amd64-latest",
      "el_max_mem": 1000,
      "count": 10
    }
  ],
  "network_params": {
    "network_id": "3151908",
    "deposit_contract_address": "0x4242424242424242424242424242424242424242",
    "seconds_per_slot": 12,
    "slots_per_epoch": 32,
    "genesis_delay": 1800,
    "capella_fork_epoch": 2,
    "deneb_fork_epoch": 1000,
    "num_validator_keys_per_node": 10,
    "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"
  },
  "launch_additional_services": true,
  "wait_for_finalization": false,
  "wait_for_verifications": false,
  "verifications_epoch_limit": 5,
  "global_client_log_level": "info"
}

Evaluation error: fail: required_num_validtors - 64 is greater than actual_num_validators - 50
	at [github.com/kurtosis-tech/eth2-package/main.star:27:77]: run
	at [github.com/kurtosis-tech/eth2-package/src/package_io/parse_input.star:106:7]: parse_input
	at [0:0]: fail

Error encountered running Starlark code.```

Add a Starlark/Python Linter to the CI

bug: eth2-package has failing geth node

here was an error executing Starlark code
An error occurred executing instruction (number 34) at github.com/kurtosis-tech/eth2-package/src/participant_network/el/geth/geth_launcher.star[74:28]:
  add_service(name="el-client-0", config=ServiceConfig(image="ethereum/client-go:latest", ports={"engine-rpc": PortSpec(number=8551, transport_protocol="TCP", application_protocol=""), "rpc": PortSpec(number=8545, transport_protocol="TCP", application_protocol=""), "tcp-discovery": PortSpec(number=30303, transport_protocol="TCP", application_protocol=""), "udp-discovery": PortSpec(number=30303, transport_protocol="UDP", application_protocol=""), "ws": PortSpec(number=8546, transport_protocol="TCP", application_protocol="")}, files={"/genesis": "el-genesis-data", "/prefunded-keys": "geth-prefunded-keys"}, entrypoint=["sh", "-c"], cmd=["geth init --datadir=/execution-data /genesis/output/genesis.json && cp -r /prefunded-keys/* /execution-data/keystore/ && { for i in $(seq 1 6); do echo \"password\" >> /tmp/password.txt; done; } && geth --verbosity=3 --unlock=0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766,0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A,0xdF8466f277964Bb7a0FFD819403302C34DCD530A,0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50,0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc,0x1F6298457C5d76270325B724Da5d1953923a6B88 --password=/tmp/password.txt --datadir=/execution-data --networkid=3151908 --http --http.addr=0.0.0.0 --http.vhosts=* --http.corsdomain=* --http.api=admin,engine,net,eth --ws --ws.addr=0.0.0.0 --ws.port=8546 --ws.api=engine,net,eth --ws.origins=* --allow-insecure-unlock --nat=extip:KURTOSIS_IP_ADDR_PLACEHOLDER --verbosity=3 --authrpc.port=8551 --authrpc.addr=0.0.0.0 --authrpc.vhosts=* --authrpc.jwtsecret=/genesis/output/jwtsecret --syncmode=full --bootnodes=\"\""], private_ip_address_placeholder="KURTOSIS_IP_ADDR_PLACEHOLDER"))
  Caused by: Unexpected error occurred starting service 'el-client-0'
  Caused by: An error occurred waiting for all TCP and UDP ports being open for service 'el-client-0' with private IP '10.2.0.5'; as the most common error is a wrong service configuration, here you can find the service logs:
  INFO [05-04|09:02:36.589] Maximum peer count                       ETH=50 LES=0 total=50
  INFO [05-04|09:02:36.590] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
  INFO [05-04|09:02:36.592] Set global gas cap                       cap=50,000,000
  INFO [05-04|09:02:36.592] Defaulting to pebble as the backing database
  INFO [05-04|09:02:36.592] Allocated cache and file handles         database=/execution-data/geth/chaindata cache=16.00MiB handles=16
  INFO [05-04|09:02:36.609] Opened ancient database                  database=/execution-data/geth/chaindata/ancient/chain readonly=false
  INFO [05-04|09:02:36.609] Writing custom genesis block
  INFO [05-04|09:02:36.616] Persisted trie from memory database      nodes=410 size=57.15KiB time="377.625µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=0 livesize=0.00B
  INFO [05-04|09:02:36.621] Successfully wrote genesis state         database=chaindata                      hash=482dd1..960441
  INFO [05-04|09:02:36.621] Defaulting to pebble as the backing database
  INFO [05-04|09:02:36.621] Allocated cache and file handles         database=/execution-data/geth/lightchaindata cache=16.00MiB handles=16
  INFO [05-04|09:02:36.640] Opened ancient database                  database=/execution-data/geth/lightchaindata/ancient/chain readonly=false
  INFO [05-04|09:02:36.640] Writing custom genesis block
  INFO [05-04|09:02:36.646] Persisted trie from memory database      nodes=410 size=57.15KiB time="348.084µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=0 livesize=0.00B
  INFO [05-04|09:02:36.649] Successfully wrote genesis state         database=lightchaindata                      hash=482dd1..960441
  INFO [05-04|09:02:36.693] Maximum peer count                       ETH=50 LES=0 total=50
  INFO [05-04|09:02:36.693] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
  INFO [05-04|09:02:36.696] Set global gas cap                       cap=50,000,000
  INFO [05-04|09:02:36.697] Allocated trie memory caches             clean=154.00MiB dirty=256.00MiB
  INFO [05-04|09:02:36.697] Using pebble as the backing database
  INFO [05-04|09:02:36.697] Allocated cache and file handles         database=/execution-data/geth/chaindata cache=512.00MiB handles=524,288
  INFO [05-04|09:02:36.718] Opened ancient database                  database=/execution-data/geth/chaindata/ancient/chain readonly=false
  Fatal: Failed to register the Ethereum service: ethash is only supported as a historical component of already merged networks
  Fatal: Failed to register the Ethereum service: ethash is only supported as a historical component of already merged networks
  Caused by: An error occurred while waiting for all TCP and UDP ports to be open
  Caused by: Unsuccessful ports check for IP '10.2.0.5' and port spec '{number:30303 transportProtocol:0 applicationProtocol:<nil> wait:0xc0002713d0}', even after '2' retries with '500' milliseconds in between retries. Timeout '15s' has been reached
  Caused by: An error occurred while calling network address '10.2.0.5:30303' with port protocol 'TCP' and using time out '14.49866325s'
  Caused by: dial tcp 10.2.0.5:30303: i/o timeout

Error encountered running Starlark code.

Use calculated timeout instead of fixed one

This behavior existed on the old Go module
https://github.com/kurtosis-tech/eth2-merge-kurtosis-module/blob/master/kurtosis-module/impl/module.go#L229-L262

But has not been ported to Starlark

Add beacon-metrics-gazer

Add beacon-metrics-gazer as a new tool. This requires a new docker image to be ran (beacon-metrics-gazer) + prometheus to target this docker image, and grafana to display the data.

Resolve why setting `--max-peers` to the expected number of peers for the Nimbus launcher results in the Nimbus node not having any peers

This might be a bug in Nimbus

Tested with both 2 Nimbus nodes & 3 Nimbus nodes

Migrate this repo completely to the Starlark version

Requires:

Ensuring the Starlark version ( https://github.com/kurtosis-tech/eth2-module ) has complete parity with the old version, and works
Building the ability to execute Starlark modules directly from Github, without needing to clone them first
Showing @parithosh how to use the Starlark version
Migrating everything in the README to the new one
Switching the 'examples' repo to using the Starlark version ( kurtosis-tech/awesome-kurtosis#13 )
Waiting for a couple weeks, to shake out any issues
Deprecating this repo and pointing it to the Starlark one
Migrate all issues over to the new repo

Error: An error occurred validating 'args'

Getting error after running command :

kurtosis run --enclave-id eth2 github.com/kurtosis-tech/eth2-package "$(cat /mnt/nvme/eth2-package/eth2-package-params.json)"

Im Edit Some files on src and static

Logs :

Error: An error occurred validating arg 'args'
 --- at /home/circleci/project/cli/cli/command_framework/lowlevel/lowlevel_kurtosis_command.go:290 (LowlevelKurtosisCommand.MustGetCobraCommand.func2) ---
Caused by: Error validating args, likely because it is not a valid JSON.
 --- at /home/circleci/project/cli/cli/commands/run/run.go:389 (validatePackageArgs) ---

make this work with `service_name`

use the new portspec syntax

@Peeeekay as it stands the tests are breaking on the examples repo

Add wait for epoch finalization test when assertions can be made on waits

Simplify the genesis data generation

In this PR: ethpandaops/ethereum-genesis-generator#10, the ETH folks made a significant change to how genesis data generator works w.r.t. the config files it takes as input.
Before that, we had to provide the config YAML files all assembled (which is why we have this complex templating logic in the module).
Now, we just have to set the env variable defined in values.env, and the entrypoint.sh scripts takes care of doing the substitution and generating the genesis files.

Since we have a nice way to set env variable in docker container within Kurtosis, I believe we could find a way to completely get rid of the file templating logic we currently have. Plus, right now we're manually calling the python scripts to generate the genesis files. This could maybe go away as well.

To go incrementally, the simplest is maybe to just call the entrypoint.sh script manually at first (replace the python commands). Then if we want to go one level deeper, we can see how we could get the container to automatically generate the files when it starts (i.e. no overriding the entrypoint command as we do now)

Use cmd and entrypoint instead of entry_point_args and cmd_args throughout the code

create minimalistic examples of mev via composability

Allow Dependabot to automatically upgrade the client Docker Images (provided CI checks are successful)

This refers to

pinning working docker images to latest
making dependabot find container_images' throughout the module, running CI, and letting us merge the changes (or it can merge it automatically if we agree)

Disable grafana login

Grafana login page is annoying. Grafana.ini should have:

[auth]
disable_login_form = true

[auth.anonymous]
enabled = true
org_role = Admin

Then it login should be disabled.

Allow different tools to be enabled/disabled

instead of

{
  "participants": [
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:dencun-devnet-8",
      "cl_client_type": "lighthouse",
      "cl_client_image": "ethpandaops/lighthouse:deneb-free-blobs",
      "count": 4
    }
  ],
  "network_params": {
    "capella_fork_epoch": 2,
    "deneb_fork_epoch": 4,
    "num_validator_keys_per_node": 77
  },
  "launch_additional_services": true,
  "wait_for_finalization": false,
  "wait_for_verifications": false,
  "global_client_log_level": "info"
}

have something like this:

{
  "participants": [
    {
      "el_client_type": "geth",
      "el_client_image": "ethpandaops/geth:dencun-devnet-8",
      "cl_client_type": "lighthouse",
      "cl_client_image": "ethpandaops/lighthouse:deneb-free-blobs",
      "count": 4
    }
  ],
  "network_params": {
    "capella_fork_epoch": 2,
    "deneb_fork_epoch": 4,
    "num_validator_keys_per_node": 77
  },
  "launch_additional_services": ['el-forkmon','tx_fuzz' ...]
  "wait_for_finalization": false,
  "wait_for_verifications": false,
  "global_client_log_level": "info"
}

fix the Nimbus CL launcher by passing a valid `--network`

We currently seem to be passing path to a file for the network, it doesn't work.

Here are the logs

INF 2022-11-10 19:40:48.177+00:00 Launching beacon node                      topics="beacnde" version=v22.9.1-a84545-stateofus bls_backend=BLST cmdParams="@[\"--non-interactive=true\", \"--log-level=INFO\", \"--network=/genesis-data/output\", \"--data-dir=/root/consensus-data\", \"--web3-url=http://168.213.144.7:8551\", \"--nat=extip:168.213.144.11\", \"--enr-auto-update=false\", \"--rest\", \"--rest-address=0.0.0.0\", \"--rest-port=4000\", \"--validators-dir=/root/validator-keys\", \"--secrets-dir=/root/validator-secrets\", \"--doppelganger-detection=false\", \"--subscribe-all-subnets=true\", \"--num-threads=4\", \"--jwt-secret=/genesis-data/output/jwtsecret\", \"--metrics\", \"--metrics-address=0.0.0.0\", \"--metrics-port=8008\", \"--bootstrap-node=enr:-Ly4QH8b3iJKukfEPD1XDZoCFpmU7GQR9XI6kJgIqzdBhDDOV0cpPiCIYIlMx5JVignciuApPHn2W7eo8cVvRVUjc0YBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpA5-P2IMAAAOP__________gmlkgnY0gmlwhKjVkAmJc2VjcDI1NmsxoQIVCMARYv9Q1j-6kq9L5MEiYe2qKvzDgWqekewj_e9keYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA\"]" config="(configFile: None[InputFile], logLevel: \"INFO\", logStdout: auto, logFile: None[OutFile], eth2Network: Some(\"/genesis-data/output\"), dataDir: /root/consensus-data, validatorsDirFlag: Some(/root/validator-keys), secretsDirFlag: Some(/root/validator-secrets), walletsDirFlag: None[InputDir], eraDirFlag: None[InputDir], web3Urls: @[\"http://168.213.144.7:8551\"], web3ForcePolling: false, requireEngineAPI: None[bool], nonInteractive: true, netKeyFile: \"random\", netKeyInsecurePassword: false, agentString: \"nimbus\", subscribeAllSubnets: true, slashingDbKind: v2, numThreads: 4, jwtSecret: Some(\"/genesis-data/output/jwtsecret\"), cmd: noCommand, runAsServiceFlag: false, bootstrapNodes: @[\"enr:-Ly4QH8b3iJKukfEPD1XDZoCFpmU7GQR9XI6kJgIqzdBhDDOV0cpPiCIYIlMx5JVignciuApPHn2W7eo8cVvRVUjc0YBh2F0dG5ldHOIAAAAAAAAAACEZXRoMpA5-P2IMAAAOP__________gmlkgnY0gmlwhKjVkAmJc2VjcDI1NmsxoQIVCMARYv9Q1j-6kq9L5MEiYe2qKvzDgWqekewj_e9keYhzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA\"], bootstrapNodesFile: , listenAddress: 0.0.0.0, tcpPort: 9000, udpPort: 9000, maxPeers: 160, hardMaxPeers: None[int], nat: (hasExtIp: true, extIp: 168.213.144.11), enrAutoUpdate: false, weakSubjectivityCheckpoint: None[Checkpoint], syncLightClient: false, trustedBlockRoot: None[Eth2Digest], finalizedCheckpointState: None[InputFile], finalizedCheckpointBlock: None[InputFile], nodeName: \"\", graffiti: None[GraffitiBytes], strictVerification: false, stopAtEpoch: 0, stopAtSyncedEpoch: 0, metricsEnabled: true, metricsAddress: 0.0.0.0, metricsPort: 8008, statusBarEnabled: true, statusBarContents: \"peers: $connected_peers;finalized: $finalized_root:$finalized_epoch;head: $head_root:$head_epoch:$head_epoch_slot;time: $epoch:$epoch_slot ($slot);sync: $sync_status|ETH: $attached_validators_balance\", rpcEnabled: None[bool], rpcPort: None[Port], rpcAddress: None[ValidIpAddress], restEnabled: true, restPort: 4000, restAddress: 0.0.0.0, restAllowedOrigin: None[TaintedString], restCacheSize: 3, restCacheTtl: 60, restRequestTimeout: 0, restMaxRequestBodySize: 16384, restMaxRequestHeadersSize: 64, keymanagerEnabled: false, keymanagerPort: 5052, keymanagerAddress: 127.0.0.1, keymanagerAllowedOrigin: None[TaintedString], keymanagerTokenFile: None[InputFile], lightClientDataServe: true, lightClientDataImportMode: only-new, lightClientDataMaxPeriods: None[uint64], inProcessValidators: true, debugForkChoice: false, discv5Enabled: true, dumpEnabled: false, directPeers: @[], doppelgangerDetection: false, syncHorizon: 50, terminalTotalDifficultyOverride: None[TaintedString], validatorMonitorAuto: false, validatorMonitorPubkeys: @[], validatorMonitorTotals: false, safeSlotsToImportOptimistically: None[uint16], suggestedFeeRecipient: None[Address], payloadBuilderEnable: false, payloadBuilderUrl: \"\")"
NOT 2022-11-10 19:40:48.177+00:00 Starting metrics HTTP server               topics="beacnde" url=http://0.0.0.0:8008/metrics
INF 2022-11-10 19:40:48.181+00:00 Threadpool started                         topics="beacnde" numThreads=4
NOT 2022-11-10 19:40:48.237+00:00 New database from snapshot                 topics="beacnde" genesisBlockRoot=25781dd2 genesisStateRoot=d9e0ff1b tailBlockRoot=25781dd2 tailStateRoot=d9e0ff1b fork="(previous_version: 10000038, current_version: 30000038, epoch: 0)" validators=128 tailStateSlot=0 genesisStateSlot=0
INF 2022-11-10 19:40:48.238+00:00 Loading block DAG from database            topics="beacnde" path=/root/consensus-data/db
ERR 2022-11-10 19:40:48.644+00:00 State from database does not match network, check --network parameter genesis=25781dd2:0 tail=25781dd2:0 headRef=25781dd2:0 stateFork="(previous_version: 10000038, current_version: 30000038, epoch: 0)" configFork="(previous_version: 20000038, current_version: 30000038, epoch: 0)"

How to reproduce?

Use the following YML to start the module

participants:
- elType: geth
  elImage: ethereum/client-go:v1.10.25
  clType: lighthouse
  clImage: sigp/lighthouse:v3.1.2
- elType: geth
  elImage: ethereum/client-go:v1.10.25
  clType: nimbus
  clImage: parithoshj/nimbus:merge-a845450
network:
  networkId: '3151908'
  depositContractAddress: '0x4242424242424242424242424242424242424242'
  secondsPerSlot: 12
  slotsPerEpoch: 32
  altairForkEpoch: 0
  mergeForkEpoch: 0
  totalTerminalDifficulty: 0
  numValidatorKeysPerNode: 64
  preregisteredValidatorKeysMnemonic: giant issue aisle success illegal bike spike
    question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy
    very lucky have athlete
waitForMining: false
waitForFinalization: true
waitForVerifications: true
verificationsEpochLimit: 5
logLevel: info

Use the latest flashbots/mev-boost-relay image for MEV

Port module to use import over load

Update README on the eth2-module

[genesis-generation] Make validator ranges in genesis

Instead of making the validator ranges in beacon-metrics-gazer, make it in genesis time, and include it in the same cl-genesis/validator-ranges.yaml

fix a bug in the eth2-package where it doesn't really parse arguments properly

I am guessing this is a bug from the proto -> no proto move

{
"participants": [
{
"el_client_type": "geth",
"el_client_image": "ethereum/client-go:v1.10.26",
"cl_client_type": "lighthouse",
"cl_client_image": "sigp/lighthouse:v3.3.0"
},
{
"el_client_type": "geth",
"el_client_image": "ethereum/client-go:v1.10.26",
"cl_client_type": "prysm",
"cl_client_image": "gcr.io/prysmaticlabs/prysm/beacon-chain:capella-post-merge,gcr.io/prysmaticlabs/prysm/validator:capella-post-merge"
},
{
"el_client_type": "geth",
"el_client_image": "ethereum/client-go:v1.10.26",
"cl_client_type": "prysm",
"cl_client_image": "gcr.io/prysmaticlabs/prysm/beacon-chain:capella-post-merge,gcr.io/prysmaticlabs/prysm/validator:capella-post-merge"
},
{
"el_client_type": "geth",
"el_client_image": "ethereum/client-go:v1.10.26",
"cl_client_type": "prysm",
"cl_client_image": "gcr.io/prysmaticlabs/prysm/beacon-chain:capella-post-merge,gcr.io/prysmaticlabs/prysm/validator:capella-post-merge"
}
],
"network_params": {
"network_id": "3151908",
"deposit_contract_address": "0x4242424242424242424242424242424242424242",
"seconds_per_slot": 12,
"slots_per_epoch": 32,
"num_validator_keys_per_node": 64,
"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"
},
"wait_for_finalization": true,
"wait_for_verifications": false,
"global_client_log_level": "info"
}

is the input,

it spits out

@parithosh reported it. looking

support mock mev builder

https://notes.ethereum.org/@parithosh/mev-testing-tasks

dev experience enhancement - joining from outside - additional validator keys

Could be nice to have an additional parameter that allow to specify something like numExternalValidatorKeys: 64 so the prelaunch generator could generate additional keys and add them to genesis, so we could join the network from outside without going through the deposit flow.

we could then have a script that detect the p2p CL\EL peers by hitting the apis and build /ip4/127.0.0.1/tcp/62.../p2p/16Ui...aXRz and enode, so we can add them as static peers from outside.
Maybe this could be automated as well and included in the json output of the module.

config files and genesis can be picked from the generator docker volume.

support the new artifact_name syntax

Add option to use Clique consensus

This would require:
a) switching the EL genesis generation config to add a clique block with signers subkeys (see the way that https://github.com/skylenet/ethereum-genesis-generator actually uses it, and also https://geth.ethereum.org/docs/interface/private-network#:~:text=the%20chain%20progresses.-,Clique%20Example,-Below%20is%20an )
b) funding multiple Geth node accounts (right now we only fund a single Geth node, the boot node)

update erigon launcher to be compliant with new cli flags while getting rid of old ones

https://github.com/kurtosis-tech/eth2-merge-kurtosis-module/blob/158e5101fb53875d1aa64fa7c0f0f3ba58fcbbc8/kurtosis-module/impl/participant_network/el/erigon/erigon_launcher.go#L142-L160

This is using the --verbosity and --engine.port flags which do not exist any more

Create forkmon for EL monitoring

Use forkmon for monitoring EL block height:
https://hub.docker.com/layers/skylenet/nodemonitor/darkmode/images/sha256-84cb51d00aea5e226e7e32ccef298b03c1853afc42f5cbd291c4f5bffe3a6a7b?context=explore

Missing MEV productization

This is a ticket to self for things to do after / during gyani/full-mev is merged

make the mev_params passable
create a genesis context that has genesis time, different epochs(capella, bellatrix, genesis forK), and genesis_validators root and use those instead of the hardcoding

Error: An error occurred validating 'args'

Getting error after running command :

kurtosis run --enclave-id eth2 github.com/kurtosis-tech/eth2-package "$(cat /mnt/nvme/eth2-package/eth2-package-params.json)"

Im Edit Some files on src and static

Logs :

Error: An error occurred validating arg 'args'
 --- at /home/circleci/project/cli/cli/command_framework/lowlevel/lowlevel_kurtosis_command.go:290 (LowlevelKurtosisCommand.MustGetCobraCommand.func2) ---
Caused by: Error validating args, likely because it is not a valid JSON.
 --- at /home/circleci/project/cli/cli/commands/run/run.go:389 (validatePackageArgs) ---

fix a bug with erigon assuming that a node already exists as opposed to being the bootnode itself

https://github.com/kurtosis-tech/eth2-merge-kurtosis-module/blob/158e5101fb53875d1aa64fa7c0f0f3ba58fcbbc8/kurtosis-module/impl/participant_network/el/erigon/erigon_launcher.go#L140

Can this node be the boot node then? Or is it only geth that can be the 0th node?

Resolve Geth block numbers getting stuck

It seems like there's an issue where, sporadically, Geth block numbers will get stuck at really low values (e.g. 3, 7, 9, etc.). It doesn't seem to be deterministic either. Maybe a Geth bug??

Remove broken testnet-verifier

The testnet-verifier is currently broken for several reasons.

==
First, I run the module and almost immediately run:

./merge_testnet_verifier --ttd 0 --ttd-epoch-limit 0 --verif-epoch-limit 5 --client geth,http://<IP_GETH_NODE>:8545

and it runs the tests, even though we're not yet at epoch 5. I think it should wait for epoch 5 to be reached based on the description of verif-epoch-limit

==
Second, when I add a beacon node:

./merge_testnet_verifier --ttd 0 --ttd-epoch-limit 0 --verif-epoch-limit 5 --client geth,http://<IP_GETH_NODE>:8545 --client lighthouse,http://<IP_LIGHTHOUSE_BEACON>:4000

It loops forever with:

WARN[10-24|14:22:05] Error getting ttd block/slot             client=Lighthouse clientID=0 error="time before genesis"

When I manually kill it with Ctrl+C, before exiting it prints:

CRIT[10-24|14:50:40] Post-Merge Beacon Blocks Produced        client=Lighthouse clientID=0 pass=false extra="0 < 1"
CRIT[10-24|14:50:40] Post-Merge Justified Epochs              client=Lighthouse clientID=0 pass=false extra="0 < 1"
CRIT[10-24|14:50:40] Post-Merge Finalized Epochs              client=Lighthouse clientID=0 pass=false extra="0 < 2"
CRIT[10-24|14:50:40] Post-Merge Epoch Attestation Performance client=Lighthouse clientID=0 pass=false extra="0 < 85"
CRIT[10-24|14:50:40] Post-Merge Epoch Target Attestation Performance client=Lighthouse clientID=0 pass=false extra="0 < 85"
CRIT[10-24|14:50:40] Post-Merge Sync Participation Percentage client=Lighthouse clientID=0 pass=false extra="0 < 85"

All values are at zero.

==
Third, when I pass also a validator node:

./merge_testnet_verifier --ttd 0 --ttd-epoch-limit 0 --verif-epoch-limit 5 --client geth,http://<IP_GETH_NODE>:8545 --client lighthouse,http://<IP_LIGHTHOUSE_BEACON>:4000 --client lighthouse,http://<IP_LIGHTHOUSE_VALIDATOR>:5042

It immediately crashes complaining it can't reach the validator node.

==
Not entirely sure what's happening. Discussing with @parithosh on Discord, it could be that the verifier is confused because it's waiting for TTD to be reached, but here since we're running the network post merge from the start it's never really reached (and we set TTD to zero).
We should also check how the verifier is reading from the beacon and the validator, it seems it's having trouble retrieving the data.

Lodestar "beacon head slot" metric gets stuck around 31 if the network is run with only one participant

Kurtosis module executed with these params:
kurtosis module exec kurtosistech/eth2-merge-kurtosis-module --execute-params '{"participants": [{"elType": "geth","elImage": "parithoshj/geth:merge-371a525","clType": "lodestar"}],"network": {"numValidatorKeysPerNode": 64, "altairForkEpoch": 1, "mergeForkEpoch": 2},"waitForMining": false, "waitForFinalization": false,"logLevel": "debug"}'

eth2-with-one-lodestar-participant-logs.zip

This error doesn't happen if the network is executed with 2 participants (and one of them has a Lodestar CL) like this:

kurtosis module exec kurtosistech/eth2-merge-kurtosis-module --execute-params '{"participants": [{"elType": "geth","elImage": "parithoshj/geth:merge-371a525","clType": "teku","clImage": "parithoshj/teku:merge-b00acff","beaconExtraParams": ["--Xee-version kiln"]}, {"elType": "geth","elImage": "parithoshj/geth:merge-371a525","clType": "lodestar"}],"network": {"networkId": "3151908","depositContractAddress": "0x4242424242424242424242424242424242424242","secondsPerSlot": 12,"slotsPerEpoch": 32,"altairForkEpoch": 1,"mergeForkEpoch": 3,"totalTerminalDifficulty": 100000000,"numValidatorKeysPerNode": 64,"preregisteredValidatorKeysMnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete"},"waitForMining": false,"waitForFinalization": false,"logLevel": "debug"}'

Consider breaking the eth2-module into multiple small Startosis modules

Especially the things on top like "Grafana", "Prometheus", "Transacation Spammer" Etc could be their own modules. This would highlight composition quite well.

Report eth2-package v0.70

cannot running on latest version 0.70.0

error msg:

here was an error interpreting Starlark code 
Evaluation error: ExecRecipe: unexpected keyword argument "service_name"
	at [github.com/kurtosis-tech/eth2-package:33:88]: run
	at [github.com/kurtosis-tech/eth2-package/src/participant_network/participant_network.star:50:76]: launch_participant_network
	at [github.com/kurtosis-tech/eth2-package/src/participant_network/prelaunch_data_generator/cl_validator_keystores/cl_validator_keystore_generator.star:69:39]: generate_cl_validator_keystores
	at [0:0]: ExecRecipe

Error encountered running Starlark code.

Screenshot Running on v0.70.0 :

Screenshot Running on v0.68.0 :

And please update the package running on cloud vm :

Perhaps rename this to eth2-package instead of eth2-module

Add EL explorer

Add an el explorer like blockscout

fix for 0.62.0 - fix files key/value inversion

Fix the Prysm beacon client which currently fails because fork versions don't match

time="2022-11-11 11:34:09" level=warning msg="The http-web3provider flag has been deprecated and will be removed in a future release,please use the execution endpoint flag instead execution-endpoint"
time="2022-11-11 11:34:09" level=info msg="Finished reading JWT secret from /genesis/output/jwtsecret"
time="2022-11-11 11:34:09" level=warning msg="Running on custom Ethereum network specified in a chain configuration yaml file" prefix=flags
time="2022-11-11 11:34:10" level=warning msg="Subscribing to All Attestation Subnets" prefix=flags
time="2022-11-11 11:34:10" level=warning msg="In order to receive transaction fees from proposing blocks, you must provide flag --suggested-fee-recipient with a valid ethereum address when starting your beacon node. Please see our documentation for more information on this requirement (https://docs.prylabs.network/docs/execution-node/fee-recipient)." prefix=node
time="2022-11-11 11:34:10" level=info msg="Checking DB" database-path="/consensus-data/beaconchaindata" prefix=node
time="2022-11-11 11:34:10" level=info msg="Opening Bolt DB at /consensus-data/beaconchaindata/beaconchain.db" prefix=db
time="2022-11-11 11:34:10" level=error msg="could not load genesis from file: loaded genesis fork version (0x30000038) does not match config genesis fork version (0x10000038)" prefix=main

Label the geth-client that is spun up alongside the builder differently from the other geth clients on the Ethereum nodes

Hey, when I run the eth2-package with full-mev, I expect there to be 2 Geth clients: 1 directly spun up with the MEV-builder, and another regular Geth client as part of an Ethereum full node.

In the output at the end (kurtosis enclave ls), it's not obvious to me as a user which one is which:

============================================== User Services ==============================================
UUID           Name                           Ports                                                  Status
e7f673086384   el-1-geth-lighthouse           engine-rpc: 8551/tcp -> 127.0.0.1:62861                RUNNING
                                              rpc: 8545/tcp -> 127.0.0.1:62863
                                              tcp-discovery: 30303/tcp -> 127.0.0.1:62862
                                              udp-discovery: 30303/udp -> 127.0.0.1:56858
                                              ws: 8546/tcp -> 127.0.0.1:62860
3048d9aafc12   el-2-geth-lighthouse           engine-rpc: 8551/tcp -> 127.0.0.1:62866                RUNNING
                                              rpc: 8545/tcp -> 127.0.0.1:62864
                                              tcp-discovery: 30303/tcp -> 127.0.0.1:62867
                                              udp-discovery: 30303/udp -> 127.0.0.1:62287
                                              ws: 8546/tcp -> 127.0.0.1:62865