[FEATURE] - cardano-testnet

[Jimbo4350]

What

Expose a cardano-testnet executable that makes it trivial to spin up a local network with:

• N number of nodes
• In any Era excluding Byron The latest era and the potentially incoming era.
• Each node configurable with their own config files
• A "quick start" mode where we make config file decisions for the user with additional options for determining how quickly they want an epoch to pass e.g --fast-epoch | --slow-epoch | --normal-epoch
• Utilize ledger events to avoid having timeouts

We need to also complete the following (not exhaustive):

• Remove testnet subdir #4580
• Remove base record from Conf #5261
• Refactoring filepath references in cardano-testnet to improve data flow clarity #5293
• Remove testnetMagic field from data Conf  #5300
• Remove YAML config record from data Conf #5322
• Implement a single testnet function in cardano-testnet #4539
• Improve cardano-testnet's executable help #4773
• Restructure cardano-testnet directory #5319
• Selectively expose modules from cardano-testnet #4602
• Default to JSON logs in cardano-testnet #3721
• Parameterize cardano-testnet on config yaml files #3719
• [FR] - Modify cardano-testnet to do more configuration in genesis #4132
• [BUG] Get foldBlocks working with cardano-testnet #4624
• Improve cardano-testnet's executable help #4773
• Remove all other *TestnetOptions data declarations in cardano-testnet #4791
• Update cardanoTestnet to use create-staked command #5475
• Remove unused code in cardano-testnet #5491
• Remove all rewrites of the configuration file

Why

1. Currently we have horrible shell scripts that we use to setup a local testnet quickly. These bitrot and require maintenance which is time consuming.
2. Users want a quick and dirty (or more nuanced) way of testing their transactions. Connecting to a public testnet is additional work (getting the right config files, syncing the chain, getting ADA from the faucet etc) therefore a local alternative is preferable especially in the early stages of testing.

Personas

• SPOs
• dApp Devs
• Exchanges
• Wallets
• 3rd party tools
• ADA holders

Definition of Done (DoD)

• Acceptance Criteria + User Stories & DoD created and singed-off (by PO, dev & test owners)
• Builds successfully on CI
• Code & Test review (as per Acceptance Criteria)
• There is documentation and/or examples for the new functionality (usage/response)
• Log/record changes on Vnext (or similar depending on what we adopt)
• Ticket number(s) included in PR description
• All Acceptance Criteria met and covered by dev/unit/property/integration tests
• System/E2E automated tests + System Test Engineer Owner Sign-off

NOTE: Ideally, we should merge only fully implemented and tested features into the master branch.
So all the above steps are required for the PR to be merged.
In order to avoid the PRs becoming stale and requiring to be rebased on master, these can be merged
after a reasonable time (current agreement is 3 days) if the System Test Engineer Owner's sign-off
was not provided (last step in the DoD).

IMPORTANT: Any deviation from the plan should be discussed and agreed as a comment in the Feature file.

Sign-off

• Product Owner
• Dev Owner
• System Test Engineer Owner

Related PRs

1. PR # here

Acceptance Criteria

Acceptance Criteria & User Stories define here (or in a separate file (linked here) for a big feature)

cardano-testnet executable makes it trivial to spin up a local network with:

• N number of nodes
• In any Era excluding Byron
• Each node configurable with their own config files
• A "quick start" mode where we make config file decisions for the user with additional options for determining how quickly they want an epoch to pass e.g --fast-epoch | --slow-epoch | --normal-epoch

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[Jimbo4350]

bump

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[smelc]

Each node configurable with their own config files

@Jimbo4350> what do you expect to be configured in these config files?

[smelc]

For my PoC, I'm starting with allowing to specify a different executable for every node. As discussed with @CarlosLopezDeLara, it could be handy to test clusters with different versions of the node within it, for example close to a hard fork.