logos-blockchain-testing/book/src/glossary.md

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.