The entire mutable state of an EmulatorBase, as one immutable value.
Aggregating it is what lets one state machine serve both platforms, and it is also what makes a transaction land atomically: the ledger state and the bookkeeping that describes it are swapped together, so no reader — and on the JVM no other submitting thread — can observe a UTxO set that has moved on while the applied-transaction log has not caught up.
appliedTxIndex and appliedTxs are derived from appliedTxLog, kept for O(1) lookup. Nothing outside this class writes them: the constructor is private, so EmulatorState.initial and the transitions below are the only way to build one, and no caller can hand back a state whose log and caches disagree (EmulatorStateInvariantTest pins it).
The log records one entry per application, while the two derived views are keyed by hash, so they are not always the same size. Applying one transaction twice needs the direct ledger edits (EmulatorBase.addUtxo) to put its inputs back — the ledger rules reject the second submission otherwise — but it is reachable, and then the log holds both applications while the index holds the later one and appliedTxs holds the hash once. Every hash in the log is in both derived views and vice versa; only the multiplicity differs.
Value parameters
appliedTxIndex
derived: appliedTxLog keyed by transaction hash, holding the latest application of each
appliedTxLog
applied transactions in application order, oldest first — one entry per application
appliedTxs
derived: the distinct hashes in appliedTxLog
context
the validation context, carrying the current slot, protocol parameters and evaluator mode
datums
every datum this emulator has seen, by hash
ledger
the ledger state proper — the UTxO set and the certificate state
The state after applied moved the ledger to newLedger: the log gains an entry, both derived views follow it, and the transaction's datums join the store.
The state after applied moved the ledger to newLedger: the log gains an entry, both derived views follow it, and the transaction's datums join the store.
The log entry is appended unconditionally, so re-applying a transaction the emulator has already applied — only reachable by putting its inputs back with EmulatorBase.addUtxo — records both applications, while the index moves to the later one and appliedTxs is unchanged.
The state with the applied-transaction bookkeeping dropped. The ledger, the context and the datum store are deliberately kept: see EmulatorBase.clearAppliedTxs.
The state with the applied-transaction bookkeeping dropped. The ledger, the context and the datum store are deliberately kept: see EmulatorBase.clearAppliedTxs.
The state with one UTxO added, or replaced if one already sits at input, for the direct ledger edits that bypass validation.
The state with one UTxO added, or replaced if one already sits at input, for the direct ledger edits that bypass validation.
An inline datum on output joins the datum store, which is how a script UTxO seeded with EmulatorBase.addUtxo answers EmulatorBase.getDatum — a real node and Blockfrost both index the datums held in the UTxO set, not only those a transaction carried in its witness set. Only output is indexed, never the whole set: every other UTxO was indexed when it arrived, so seeding N UTxOs costs O(N) rather than O(N²). Nothing is removed: the store is everything the emulator has seen.