[Dijkstra] UTXOS Rule with batch-level validity checking

[williamdemeo]

Description

Stacked PR (This PR targets #1015.)

Plan (tentative)

This PR will close issue #1007 by

• introducing batch helpers in Ledger/Dijkstra/Specification/Utxo.lagda.md:

  • batch collection/verification (getSubTxScripts, batchP2Inputs, batchScriptsOk)

• introduce level-parameterized versions of produced and consumed

• making UTXOS a 2-branch relation: success vs failure

  What we want UTXOS to decide:

  • ok = batchScriptsOk txTop
  • flag = Tx.isValid txTop (top-level only)

  Then:

  • require flag ≡ ok (so the transaction's claimed validity matches the ledger's batch execution result)

  • branch on ok

  • Success branch (commit)

    In the success constructor:

    • apply the normal batch effects (UTxO update, fees accounting, deposits/gov/etc)
    • enforce batch POV using level-parameterized produced/consumed (sums across txTop and all subTxs)
    • enforce fee rule: only top-level fee counts (already true by shape; still make it explicit in the accounting)

  • Failure branch (collateral + nothing else)

    In the failure constructor:

    • Apply only collateral collection using CollateralInputsOf txTop
    • Don't apply any other UTxO changes from the batch (no outputs, no withdrawals, no cert effects, etc.)
    • Update fees by collateral amount (Q: how does ledger collect collateral? Does it go to fees? treasury?)

Notes

I needed the 2-UTxO parameterization (utxoSpend₀ vs utxoRefView) in some places, but
utxoRefView is still just a place holder until we start tracking sub-level change of utxo state. TODO: address this once #1005 is finalized.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• Any semantic changes to the specifications are documented in CHANGELOG.md
• Code is formatted according to CONTRIBUTING.md
• Self-reviewed the diff

[Copilot]

Pull request overview

This PR implements batch-level validity checking for the UTXOS rule in the Dijkstra specification, addressing issues #1006 and #1007. It introduces a two-branch UTXOS relation that handles both successful script execution (applying all batch effects) and failed execution (collecting only collateral).

Key changes include:

• Introduction of batch-level script validation with batchScriptsOk and preservation of value checking via batchPOV
• Two-branch UTXOS rule with success/failure paths based on script execution results
• Refactoring of the Fees module to be parameterized by protocol parameters

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/Ledger/Dijkstra/Specification/Utxo.lagda.md	Implements batch-level UTXOS rule with success/failure branches, batch operations, and UTxO state transitions
src/Ledger/Dijkstra/Specification/Transaction.lagda.md	Adds level-dependent and level-independent type classes for transaction components, adds txSize field to Tx
src/Ledger/Dijkstra/Specification/Script/Validation.lagda.md	Updates references from ValueOf to MintedValueOf for consistency
src/Ledger/Conway/Specification/Fees.lagda.md	Refactors module to take protocol parameters as module parameter; changes scriptsCost signature from PParams → ℕ → Coin to ℕ → Coin
src/Ledger/Conway/Specification/Utxo.lagda.md	Updates import statement for scriptsCost (but not all call sites)
src/Ledger/Conway/Conformance/Utxo.agda	Updates import statement for scriptsCost (but not all call sites)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

depositsSuccess applies updateDeposits to each sub-transaction, but the batch preservation-of-value check batchPOV only uses depositsChange for the top-level transaction (Δdeposits) and completely ignores deposit/gov-proposal effects of sub-transactions. This lets a batch include sub-transactions with deposit-creating or deposit-refunding certificates/proposals that change DepositsOf in successState without any balancing term in batchConsumed/batchProduced, so total Ada in the UTxOState can increase or decrease even when batchPOV holds. To prevent this, the deposit component of preservation-of-value must also account for sub-transaction certificates/proposals (e.g. by incorporating their depositsChange into consumedSub/producedSub or by computing a single batch-level deposits delta and using that consistently for both batchPOV and depositsSuccess).

Suggested change

	depositsSuccess = foldr (λ sub deps → updateDeposits (PParamsOf Γ) sub deps)
	(updateDeposits (PParamsOf Γ) txTop (DepositsOf s))
	(SubTransactionsOf txTop)
	depositsSuccess = updateDeposits (PParamsOf Γ) txTop (DepositsOf s)

[williamdemeo]

subtransactions have no deposits, so they cannot introduce or refund deposits, but we might want to include an additional check/invariant for this.

[Copilot]

@williamdemeo I've opened a new pull request, #1023, to work on those changes. Once the pull request is ready, I'll request review from you.