Add `--testnet-config-dir` flag for tx-generator

[palas]

Add --testnet-config-dir flag for tx-generator

Context

tx-generator allows users and testers to automatically send transactions to a cardano network. This can be used, for example, for checking how the network behaves under high-pressure. This checks are typically performed on a testnet, and cardano-testnet is a tool that can be used to easily spawn testnets. So is often the case that we want to run cardano-testnet to spawn a testnet, and then use tx-generator on that testnet.

tx-generator has both a high-level and a low-level interface, and for this issue we are focusing on the high-level one, which internally gets translated into the low-level one automatically. The high-level interface can be accessed through the sub-command json_highlevel.

The main configuration for json_highlevel comes from a json file (you can see an example of what it looks like here). This JSON file determines aspects of how the tests will be run, like:

• How many transactions will be generated (tx_count)
• How many inputs or outputs each transaction will have (inputs_per_tx and outputs_per_tx)
• How fast the transactions will be generated (tps)

But also more environmental aspects like:

• The Cardano era that the network is in (era)
• The keep-alive timeout for mini-protocol used to connect to the Cardano node (keepalive)

And, the most relevant ones for this issue, how to connect to and how to use the Cardano network:

• Path to local node socket for protocol queries (localNodeSocketPath)
• List of nodes to submit transactions to (Node-to-Node protocol) (targetNodes)
• Path to node configuration file (nodeConfigFile)
• Path to signing key with sufficient funds (genesis key) (sigKey)

If the network that we want to use tx-generator on has been spawned by using cardano-testnet. These last 4 attributes could be filled automatically.

So this issue proposes adding a new flag --testnet-config-dir that takes the configuration folder of a Cardano testnet spawned by cardano-testnet, and it automatically fills this four fields using the information extracted from that configuration folder.

Of course, the user still has to specify the rest of required values.

[Jimbo4350]

A couple of naming suggestions:

--force-infra → --override-nix: The fields it protects (localNodeSocketPath, sigKey, nodeConfigFile, targetNodes) are the _nix_-prefixed fields in NixServiceOptions. "Infra" is vague — --override-nix ties directly to the codebase naming and makes it clear that the supplied testnet data overrides the user's nix service config for those fields.

--fill-defaults → --default-tx-params: "Defaults" is ambiguous when you're already dealing with nix config values and testnet-discovered values. This flag specifically controls whether hardcoded tx param defaults (tps, tx_count, etc.) are applied — the name should say that.

With the renamed flags, does this table match your intent?

--default-tx-params	--override-nix	What happens
ON	OFF	Testnet data + default tx params form baseline. User's nix config overrides anything.
OFF	OFF	Testnet data forms baseline. User's nix config overrides anything. User must provide all tx params.
ON	ON	Default tx params filled. Testnet data overrides user's nix config for discovered fields.
OFF	ON	No defaults. Testnet data overrides user's nix config for discovered fields. User must provide all tx params.

[palas]

@Jimbo4350, it is true that the fields overridden by --force-infra are: _nix_localNodeSocketPath, _nix_sigKey, _nix_nodeConfigFile, and _nix_targetNodes

But I think calling it --override-nix is misleading because other fields are also prefixed with _nix in the type, and also the _nix is not on the JSON, it gets discarded by Aeson, see the example in the README.md of tx-generator: https://github.com/IntersectMBO/cardano-node/tree/master/bench/tx-generator#getting-started

Maybe we can call it --override-connection-settings, because it seems that is what they are called here: https://github.com/IntersectMBO/cardano-node/tree/master/bench/tx-generator#configuration-parameters

[palas]

@Jimbo4350, about the --default-tx-params, I also think it is not accurate. There are fields that are fields that do not really correspond to transacitons, for example: _nix_init_cooldown or _nix_keepalive.

Maybe something more accurate would be --autofill-required

[Jimbo4350]

▎ But we aim to make --testnet-config-dir as flexible and helpful as possible and, because of that, we aim for --testnet-config-dir to go a bit further.

Why? The simplest thing would be to have as few overrides as possible and make the behaviour obvious to the user.

▎ Notice that era, although not an "infra" field, we still get the default from the testnet config.

Do we? Where did it come from before this proposed integration? It's listed as a field of the tx-generator's JSON config file.

Here's what I'm thinking:

If you're using a testnet spun up by cardano-testnet, the following are testnet-determined (must match testnet or txs fail):

• localNodeSocketPath, targetNodes, nodeConfigFile, sigKey — connection + credential
• era, min_utxo_value, tx_fee — correctness-constrained by pparams

The rest are tx-generator-determined (user workload):

• tx_count, tps, inputs_per_tx, outputs_per_tx, add_tx_size, init_cooldown, debugMode, keepalive

So why not just one flag, --testnet-dir DIR?

• Testnet-determined fields: sourced from DIR. User cannot override.
• Workload fields: from user config, with built-in defaults (determined by tx-generator) for anything missing.

We could also log what was sourced from the testnet dir, so the user can see exactly what was set for them making the behaviour even more obvious.