Documentation

Generate a byte-count limit that straddles the real serialised size of tx, giving roughly equal probability of the size check passing or failing.

Generate an EvaluationReport that contains at least one script failure at an arbitrary witness index, optionally mixed with passing entries.

Create a chain sync handler which records events as they are called back.

Whether a transaction is within the protocol's maximum transaction size, measured the same way the real wallet measures it: Wallet accepts a transaction of exactly the maximum size, so this is <=, not <.

Number of outputs a fanout transaction distributes. Output 0 is the continuing head output; the rest are the chunk.

A wallet that answers findFittingFanoutTx truthfully - real script evaluation, real size limit - while counting the candidate transactions it is asked about.

The count is exact: the chunk search reaches the outside world only through these two fields, and fitsTx calls $sel:isTxWithinSizeLimits:TinyWallet once per constructed candidate before anything else, so one increment is one candidate built. Building a candidate rebuilds the head's accumulators, which is what makes the count worth bounding.

Run the chunk search against a closed head, returning how many candidate transactions were built and the one the search settled on.

Whether a transaction passes the size limit and script execution budget the chunk search is held to.

Most candidates a capped binary search can build: the range is [1..deployedFanoutBatchSize] and each probe halves it, so this counts the halvings. Notably it does not depend on the head size.

Why a chunk of the given size is or is not a usable fanout candidate, naming the limit it runs into. Only ever rendered into a counterexample.

A wallet that accepts every transaction, for tests that only care about which error the chunk search reports.

A block used for testing. This is a simpler version of the cardano-api Block and can be de-/constructed easily.

Thin wrapper which generates a TestBlock at some specific slot.

Pick a block point in a list of blocks.

Pick a rollback point from a list of blocks and also yield the tail of blocks to be replayed.

Generate a non-sparse sequence of blocks each containing an observable transaction, starting from the returned on-chain head state.

Note that this does not generate the entire spectrum of observable transactions in Hydra, but only init and deposits, which is already sufficient to observe at least one state transition and different levels of rollback.