# Glossary

- **Validator**: node role responsible for participating in consensus and block
  production.
- **Executor**: a validator node with the DA dispersal service enabled. Executors
  can submit transactions and disperse blob data to the DA network, in addition
  to performing all validator functions.
- **DA (Data Availability)**: subsystem ensuring blobs or channel data are
  published and retrievable for validation.
- **Deployer**: component that provisions infrastructure (spawns processes,
  creates containers, or launches pods), waits for readiness, and returns a
  Runner. Examples: LocalDeployer, ComposeDeployer, K8sDeployer.
- **Runner**: component returned by deployers that orchestrates scenario
  execution—starts workloads, observes signals, evaluates expectations, and
  triggers cleanup.
- **Workload**: traffic or behavior generator that exercises the system during a
  scenario run.
- **Expectation**: post-run assertion that judges whether the system met the
  intended success criteria.
- **Topology**: declarative description of the cluster shape, roles, and
  high-level parameters for a scenario.
- **Scenario**: immutable plan combining topology, workloads, expectations, and
  run duration.
- **Blockfeed**: stream of block observations used for liveness or inclusion
  signals during a run.
- **Control capability**: the ability for a runner to start, stop, or restart
  nodes, used by chaos workloads.
- **Slot duration**: time interval between consensus rounds in Cryptarchia. Blocks
  are produced at multiples of the slot duration based on lottery outcomes.
- **Block cadence**: observed rate of block production in a live network, measured
  in blocks per second or seconds per block.
- **Cooldown**: waiting period after a chaos action (e.g., node restart) before
  triggering the next action, allowing the system to stabilize.
- **Run window**: total duration a scenario executes, specified via
  `with_run_duration()`. Framework auto-extends to at least 2× slot duration.
- **Readiness probe**: health check performed by runners to ensure nodes are
  reachable and responsive before starting workloads. Prevents false negatives
  from premature traffic.
- **Liveness**: property that the system continues making progress (producing
  blocks) under specified conditions. Contrasts with safety/correctness which
  verifies that state transitions are accurate.
- **State assertion**: expectation that verifies specific values in the system
  state (e.g., wallet balances, UTXO sets) rather than just progress signals.
  Also called "correctness expectations."
- **Mantle transaction**: transaction type in Nomos that can contain UTXO transfers
  (LedgerTx) and operations (Op), including channel data (ChannelBlob).
- **Channel**: logical grouping for DA blobs; each blob belongs to a channel and
  references a parent blob in the same channel, creating a chain of related data.
- **POL_PROOF_DEV_MODE**: environment variable that disables expensive Groth16 zero-knowledge
  proof generation for leader election. **Required for all runners** (local, compose, k8s)
  for practical testing—without it, proof generation causes timeouts. Should never be
  used in production environments.