Cardano Updates

Gate the tx-generator section on `tx-generator` appearing in the
resolved compose services. Keeps full probe coverage when the daemon
is in the cluster (current behaviour, or when the disabled override is
layered in) and turns the probes into a no-op for testnets that have
parked the service.

Replace generic Error with CastorError.InvalidKeyError in computeEncnumbasis, listing the unsupported curve and supported curves (ED25519, X25519).

Add unit test verifying SECP256K1 throws InvalidKeyError.

Signed-off-by: Zaid <[email protected]>

Two changes to allow the adversary testnet to run alongside other
local cardano-node-antithesis testnets (asteria_game, cardano_amaru,
the master itself) without container_name or network-name clashes:

- Drop the explicit `container_name:` directive on every service.
  Compose's auto-generated <project>_<service>_1 names are unique
  per project; explicit container_name forces a single global name
  that collides with any other compose file using the same value.
  Service-name DNS (p1.example via hostname:) is unaffected.

- Drop the explicit network `name: cardano-node-testnet`. With
  `docker compose -p cardano_node_adversary up`, the default
  network becomes cardano_node_adversary_default, which never
  collides with the master testnet's network or any other
  per-project network on the host.

Master testnet (cardano_node_master) keeps container_name on
purpose because the publish-images / smoke-test scripts already
expect those globally-stable names. The adversary testnet is the
iteration loop, used in parallel with other local testnets — it
needs the project-scoped naming.

Verified locally:

- docker compose -p cardano_node_adversary up -d brings all 12
  services up alongside an existing cardano_amaru cluster (no
  clash).
- tracer-sidecar writes /tracer/chainPoints.log (15+ entries
  within ~1 min).
- All three composer scripts (parallel_driver_flaky_chain_sync,
  eventually_adversary_active, finally_adversary_summary) exit 0
  and emit all 5 SDK assertions with condition=true / hit=true.
- Daemon stderr shows 'Right (Point (At (Block ... SlotNo 316
  ...)))' meaning real chain-sync work completed against p1.

Comment out the service block in docker-compose.yaml and park the
original definition in tx-generator.disabled.yaml as a compose
override fragment so it can be re-enabled with `-f`.

Antithesis run on 685fa5e (https://cardano.antithesis.com/report/tilehuSggX4cnuy5qyXfwpqI/CVALsMOlHQdIyvQsc0sKyxZ79mapUIksHP-v0XZcVds.html)
still flagged tx-generator/parallel_driver_*.sh against the
"Always: Commands finish with zero exit code" property.
Example log lines show command_return_code=1 with a
runtime of ~30-60ms and an empty additional_stderr —
i.e. the script never reached any of our 'exit 0' lines.

Root cause: 'set -euo pipefail' + 'nc -U -q 1 $sock' fails
the assignment when the daemon's control socket isn't yet
bound (early boot, supervisor mid-cycle), and 'set -e'
kills the script before any 'exit 0' branch runs.

Same shape applies to eventually_population_grew.sh: an
empty RSP made jq emit 0, and we then incorrectly fired
the 'tx_generator_population_did_not_grow' Always
assertion against a daemon we never successfully queried.

Fix:

- Replace 'set -euo pipefail' with 'set -u' (matches
  components/asteria-stub/composer/stub/parallel_driver_heartbeat.sh).
- Wrap nc in '|| true', check for empty RSP, and if empty
  emit a 'tx_generator_*_daemon_unreachable' reachability
  event then exit 0. Composer's "Always exit 0" property
  holds; assertion ingestion still records the path was
  taken; daemon is retried on the next tick.
- eventually_population_grew.sh: distinguish "daemon
  unreachable" from "daemon says populationSize=0". Fire
  did_not_grow only when the snapshot RSP is non-empty
  AND parses as JSON.

The remaining tx_generator_*_submit_rejected Always
failures from the 685fa5e run are a separate
duplicate-submit-after-reconnect race tracked at
https://github.com/lambdasistemi/cardano-node-clients/issues/111.

This check that was introduced for the protocol version in the block header
proved to be problematic for testnets. Which makes sense, since it was
designed for mainnet in mind and its introduction was needed to be done
urgently since it was blocking 10.6.2 release. See #5595 for more context

In order to allow for testnets to continue being able to produce blocks
for older protocol versions with latest version of the node we lift this
restriction, but only for any network with `Testnet` network id. This is
implemented as a temporary measure and will be properly fixed in
Dijkstra era. See #5763 for more context

* Verification of `PrevGovActionId` in `proposalsAddAction` happens on
  accumulated `proposals`
* While `preceedingHardFork` check happens on original `st`.

In a usual application, which has identifiers assigned, this inconsistency
would have been a problem. However, in a transaction's `GovActionId`, which is
derived from a hash of a transaction itself, it is impossible to reference
a previous governance action within the same transaction, since one would need
to know the hash of a transaction that contains the proposal it tries to
reference.

Therefore, this commit fixes not an issue, but a mere inconsistency.
This is done in order to avoid developers even considering this edge case.

Remove redudant import

Adds the player workload to the asteria_game testnet's composer
harness. PlayerMain.hs is reshaped from a forever-loop to a
single-pass binary so the Antithesis composer can re-fire it on
its own schedule (a forever loop blocks exclusive scheduling for
serial drivers).

components/asteria-game/composer/stub/parallel_driver_asteria_player.sh:
  - Picks ASTERIA_PLAYER_ID in {1,2,3} based on the wallclock so
    different timelines exercise different players.
  - Player 1 attempts the spawn (PlayerMain gates on id == "1");
    players 2 and 3 observe the asteria UTxO without acting,
    exercising the read path.

components/asteria-game/app/PlayerMain.hs:
  - main: drop the forever loop and the in-process IORef Bool
    "have I spawned yet" guard. Spawn idempotence comes from chain
    state — once the asteria UTxO has been consumed-and-replaced
    with a higher ship_counter, the next attempt's tx is rejected
    by the validator as expected, and reported via the existing
    asteria_player_ship_spawn_failed_<id> sdkUnreachable assertion.
  - Adds asteria_player_pass_errored_<id> and
    asteria_player_pass_completed_<id> SDK assertions so the report
    can score one pass per fire even when the inner observation
    bombs out.

Locally validated on testnets/asteria_game/ compose (3-pass run,
one per player_id):
  - bootstrap idempotence still holds (cold deploy + 2 short-circuit)
  - player 1 attempts spawn end-to-end (observe → build → sign →
    submit → reject); players 2, 3 observe-only
  - sdk.jsonl shows ship_counter and move_planned per pass

KNOWN ISSUE — submission is currently rejected by the spacetime
validator with "PlutusV3 script failed: overspending the budget"
(CekError, ~600k cpu over). This is a pre-existing issue in the
lifted PR #67 Aiken validators — the off-chain wiring works
correctly, but the on-chain validator over-spends its execution
units. Tracked as a follow-up; does not block landing this driver
since the wiring + report assertions are independent of validator
correctness.

After PR #111 dropped tx-generator from cardano_node_master/, the
'Compose smoke test' job that runs scripts/smoke-test.sh against
master fails because the script unconditionally probes the
tx-generator control socket — which is only present on the new
cardano_node_tx_generator/ testnet now.

Skip the tx-generator-specific block when the compose under test
doesn't declare a 'tx-generator:' service. Same script keeps
working for both master (no tx-generator) and the new feature
testnet (still drives the daemon end-to-end).

Add CATS token metadata

Adds an opt-in monitoring profile running Grafana + Mimir + Loki +
Prometheus + blackbox-exporter on a single Colmena machine, fronted by
Caddy with ACME-issued TLS and Google OAuth on Grafana. Cluster-wide
configuration lives under flake.cardano-parts.cluster.infra.monitoring,
read by the bootstrap opentofu workspace, profile-grafana-alloy, and
profile-monitoring itself so all three stay in lockstep.

Storage: cardano-parts.lib.opsTf.mkMonitoringBucketResources provisions
per-cluster Mimir and Loki S3 buckets with Object Lock + lifecycle
wired together so app-level retention and storage-level retention
cannot drift. objectLockMode picks between a 1-day soft lock (default,
~1x storage) and a full-retention hard lock (~2x storage during the
retention window). Both modes use GOVERNANCE locks so a separately-
permissioned operator role holding s3:BypassGovernanceRetention can
break-glass; the EC2 role attached to the monitoring node gets
least-privilege data-plane access only (no DeleteBucket /
PutBucketPolicy / governance bypass) via
cardano-parts.lib.opsTf.mkMonitoringIamPolicy.

Both opsTf builders are pure helpers (no pkgs dependency) so existing
downstream repos that don't use this template's bootstrap workspace
can call them from any terranix-driven workspace without copying
code; the template's bootstrap.nix and cluster.nix are now the
canonical callers.

profile-grafana-alloy: when infra.monitoring.enable = true, alloy
auto-targets the in-cluster monitoring node, making the
grafana-alloy-{metrics,loki}-url sops secrets optional.

opsLib: adds parseDir and readNixImport so monitoring rule files and
the existing tofu grafana workspace can share the same .nix-import
corpus without duplicate helpers.

profile-monitoring + profile-grafana-alloy read cluster infra through
groupFlake.config (the consuming flake's self) rather than
flake.config — the latter closes over cardano-parts' own flake-parts
evaluation where these options carry their declared null defaults,
not the consumer's values.

Template additions wire all of the above into a downstream-consumable
shape: optional monitoring host in colmena.nix, infra.monitoring stanza
in cluster.nix, S3 bucket + IAM policy blocks in opentofu, and a
README section covering retention, lock modes, and the required sops
secrets.

Mirrors 43bf739 (chore(testnet): remove adversary service from
cardano_node_master) — same shape, different component.

The master testnet is the canonical reference cluster: cron-fired
Antithesis runs against it produce the baseline-finding signal that
everyone reads. With tx-generator in active iteration (reconnect
supervisor #105, freshness gate #110, composer-assertion shape work
in #98), keeping it on master pollutes that signal with experiments
in flight.

This commit:

* Creates testnets/cardano_node_tx_generator/ — same topology as
  master (3 producers + 2 relays + tracer + sidecars + log-tailer)
  plus the tx-generator service. Asteria-stub is deliberately
  absent (different feature, lives on master).

* Removes tx-generator from testnets/cardano_node_master/ along
  with its 'utxo-keys' volume mount on configurator and the volume
  declaration. Nothing else on master uses utxo-keys.

* README in the new testnet documents why and how to dispatch.

Workflow dispatch from this point:
  gh workflow run cardano-node.yaml \
    --ref <feature-branch> \
    -f test=cardano_node_tx_generator \
    -f duration=1

publish-images currently only scrapes cardano_node_master's compose;
the new testnet's tx-generator image is pushed manually until the
publish-images script is generalised to all testnets (follow-up).

Adds the asteria-game workload as an isolated testnet so iteration
on the real asteria game can land on `main` without disturbing the
canonical scheduled run on `cardano_node_master`.

testnets/asteria_game/ (copied from cardano_node_master, then edited):
  - same producer/relay/tracer/sidecar/log-tailer/tx-generator
    topology.
  - asteria-game service replaces asteria-stub: same indexer-driven
    composer harness plus /utxo-keys mount so bootstrap can read
    the genesis wallet skey, and CARDANO_NODE_SOCKET_PATH +
    NETWORK_MAGIC env vars so Asteria.Provider.settingsFromEnv
    resolves to relay1's N2C socket.
  - asteria-game image tag pinned to 3042c0a (the prior commit on
    this branch — last commit to touch components/asteria-game/).
  - testnets/cardano_node_master/ untouched — its scheduled
    Antithesis run is unaffected.

Pipeline (additive, no edits to cardano_node_master jobs):
  - scripts/push-asteria_game_images.sh — sibling of
    push-cardano_node_master_images.sh, scans testnets/asteria_game
    for image tags and resolves each via the same nix build path.
  - .github/workflows/publish-images.yaml — new
    smoke-test-asteria-game job runs scripts/smoke-test.sh against
    testnets/asteria_game; the existing cardano_node_master jobs
    are unchanged.

Locally validated: 3-run idempotence (1 cold deploy, 2 short-circuit
via Asteria.Bootstrap.isAlreadyDeployed) on the asteria_game compose.

Antithesis dispatch wiring for this testnet is a follow-up PR.

Fix coding standards link and docusaurus serving

Renames components/asteria-player/ → components/asteria-game/ and
upgrades the lifted PR #67 sources so the bootstrap is safe to
re-run on container restart.

  - cabal package + executable renamed asteria-player → asteria-game.
  - cabal.project SRP pinned to cardano-node-clients PR #98 head
    5707836b (utxo-indexer supervisor + N2C reconnect).
  - flake.nix pulls cardano-node-clients utxo-indexer as a flake
    input so dockerTools bundles the prebuilt binary.
  - nix/docker-image.nix bundles utxo-indexer + asteria-bootstrap +
    asteria-game (player) execs + composer/stub scripts; entrypoint
    is the indexer, the bootstrap runs as a serial driver.
  - composer/stub/ shape replaces composer/asteria/: green-baseline
    heartbeat / eventually_alive / finally_alive plus a new
    serial_driver_asteria_bootstrap that execs /bin/asteria-bootstrap.
  - app/BootstrapMain.hs gains Asteria.Bootstrap.isAlreadyDeployed:
    queries Provider for UTxOs at the asteria spend address and
    short-circuits if any UTxO carries the @"asteriaAdmin"@ token.
    Antithesis can restart the asteria-game container at will and
    bootstrap exits 0 quickly on subsequent invocations.

The asteria_game testnet that wires this image into Antithesis is
added in the next commit.

KNOWN GAP — admin_mint validator is the always-true placeholder
PR #67 ships. The Haskell-side detection plus Antithesis's
@serial_driver_@ scheduling are the contract until a follow-up PR
replaces admin_mint with a one-shot policy parameterised on a seed
@OutputReference@.

Tracks: #67 (asteria-spawn-v2), #98 (utxo-indexer supervisor).
Closes companion: #108 (idempotent bootstrap, content folded here).

Agent-Logs-Url: https://github.com/cardano-foundation/cardano-node-antithesis/sessions/83537079-2f09-4d3a-b518-9bbb15712109

Co-authored-by: paolino <[email protected]>

Allow the local node-to-client socket to bind within seconds of node
startup rather than after the multi-hour LedgerDB replay completes. n2c
ChainSync clients (cardano-db-sync, ogmios, wallet) can begin streaming
blocks during replay; LSQ / TxSubmit / TxMonitor handlers naturally block
on the LedgerDB until ready, relying on the property that NtC has no
client-side timeouts.

Phase 1 (ChainDB):
- New 'LedgerDBStatus' type + 'awaitLedgerDB' STM helper
- 'openDBInternal' returns once Immutable+Volatile are open; LedgerDB
  replay and initial chain selection run on a registry-linked background
  thread (new 'runInitLedgerDB')
- LedgerDB-touching queries wrapped in 'awaitLedgerDB'
- New 'OpenedDBImmutableReady' trace event; existing 'OpenedDB' preserved
- 'closeDB' cancels the background initialiser and only closes the
  LedgerDB if 'cdbLedgerDBStatus' has reached 'LdbReady'

Phase 2 (NodeKernel + runWith):
- 'mkPendingMempool', 'mkPendingBlockchainTime', 'mkPendingDurationUntilTooOld'
  forwarding wrappers that block on a TMVar until populated
- 'initInternalState' split into 'initInternalStateEarly' +
  'completeInternalState'
- 'initNodeKernel' split into 'initNodeKernelEarly' returning
  '(NodeKernel, m ())'; the deferred action opens the real mempool,
  computes the real GsmState, and spawns the four ledger-touching
  background threads (GSM, GDD watcher, blockForging, blockFetchLogic,
  decisionLogicThreads)
- 'runWith' allocates the BlockchainTime / WrapDurationUntilTooOld TMVars,
  builds the kernel synchronously with pending wrappers, calls
  'llrnRunDataDiffusion' immediately, and forks a 'Node.lateInit' thread
  that runs 'hardForkBlockchainTime' and 'realDurationUntilTooOld' once
  the LedgerDB is ready, populates the TMVars, and runs the completer

Verified: 'cabal build all' clean and 'cabal test storage-test' passes
69/69 on the 3.0.1.0 release tag.