feat: Run cdk-erigon with cdk config files transparently for the user

[vcastellm]

Description

Using the Rust CLI it's now possible to run cdk-erigon that it's present in system's path in a single step providing only the node config file and the genesis file.

cdk --config ../kurtosis-cdk/genesis/cdk-node-config.toml --chain ../kurtosis-cdk/genesis/genesis.json erigon

Avoiding the necessity of using multiple configuration files and different configuration for cdk-node and cdk-erigon

NOTE: This Rust code is the first iteration into the CLI and can be much improved and refactored in subsequent PRs

---

Steps to test this in local:

1. Requirements: Run your kurtosis environment and have a cdk-erigon version installed in your system's PATH
2. scripts/local_config
3. cargo run -- --config ./tmp/cdk/local_config/test.kurtosis.toml --chain ./tmp/cdk/local_config/genesis.json erigon

[joanestebanr]

I don't see how to build the rust client, maybe it needs an entry on Makefile?

[vcastellm]

I don't see how to build the rust client, maybe it needs an entry on Makefile?

It's quite straightforward, in Rust there's the concept of "build scripts" arbitrary commands that can be executed at build time, in this case we use this one https://github.com/0xPolygon/cdk/blob/main/crates/cdk/build.rs, it builds cdk-node at build time so both binaries are built and run with just:

cargo run

Or just build with:

cargo build

Better entry on README

---

Updated the readme with new instructions using make

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[Stefan-Ethernal]

Generally speaking, should we match the current configuration of the CDK, as we are most likely missing some fields (EthTxManager for example)?

[vcastellm]

Generally speaking, should we match the current configuration of the CDK, as we are most likely missing some fields (EthTxManager for example)?

Good observation @Stefan-Ethernal in general we're not adding all config values just some at this point, some of them we use it to construct the config, others are simply missing and others are there to use them for status checking in the future. I preferred just leaving them as is instead of removing them, we can refactor them in upcoming PRs in case the usage we're going to give them.

[sonarqubecloud]

Quality Gate failed

Failed conditions
2 Security Hotspots
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint