Skip to content

[Dijkstra] Add starting account balance intervals - #1308

Open
carlostome wants to merge 4 commits into
masterfrom
carlos/starting-account-balance-intervals
Open

[Dijkstra] Add starting account balance intervals#1308
carlostome wants to merge 4 commits into
masterfrom
carlos/starting-account-balance-intervals

Conversation

@carlostome

@carlostome carlostome commented Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Description

Following the changes in cardano-ledger (IntersectMBO/cardano-ledger#6001) and the amendments to the CIP (cardano-foundation/CIPs#1243)

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

@carlostome carlostome changed the title Add starting account balance intervals [Dijkstra] Add starting account balance intervals Sep 3, 2026
@carlostome
carlostome marked this pull request as ready for review September 3, 2026 15:52
@carlostome
carlostome force-pushed the carlos/starting-account-balance-intervals branch from 8f514a6 to 3851c3e Compare September 4, 2026 10:27

@williamdemeo williamdemeo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with some minor, non-blocking comments.

Question (not a change request). A non-empty txBalanceIntervals makes UsesV4Features tx hold (hasBalanceIntervals in Utxow), which makes allowedLanguagesLegacy exclude V1--V3 scripts, so a transaction carrying a non-empty txBalanceIntervals cannot run V1--V3 scripts. Otoh, a non-empty txStartingBalanceIntervals has no such restriction, since it is not a UsesV4Features constructor.

Is that intentional? The restriction to V4 for non-empty txBalanceIntervals seems reasonable. But I don't see why the same restriction shouldn't hold for a non-empty txStartingBalanceIntervals.

Follow-up suggestion. This PR shows once again how brittle the sts rule patterns are. In this case, in ENTITIES, one premise insertion touched five pattern sites across Computational and PoV, and the eleven-tuple is mostly underscores.

(In my recent properties PRs, I battled with the same issue again.)

Utxow solves this with genPremises and a pattern synonym (see Utxow.lagda.md:539-542). A follow-up doing the same for ENTITIES and SUBENTITIES would let the PoV proofs name certsStep and ddCreds⊆ instead of counting positions. I think you mentioned you planned to tackle the genPremises problems soon. Maybe this can be part of that work.

Comment thread src/Ledger/Dijkstra/Specification/Entities.lagda.md Outdated
Comment thread src/Ledger/Dijkstra/Foreign/Transaction.agda
@carlostome

Copy link
Copy Markdown
Collaborator Author

Follow-up suggestion. This PR shows once again how brittle the sts rule patterns are. In this case, in ENTITIES, one premise insertion touched five pattern sites across Computational and PoV, and the eleven-tuple is mostly underscores.

(In my recent properties PRs, I battled with the same issue again.)

Utxow solves this with genPremises and a pattern synonym (see Utxow.lagda.md:539-542). A follow-up doing the same for ENTITIES and SUBENTITIES would let the PoV proofs name certsStep and ddCreds⊆ instead of counting positions. I think you mentioned you planned to tackle the genPremises problems soon. Maybe this can be part of that work.

I agree but atm genPremises doesn't work for ENTITIES.

@carlostome
carlostome force-pushed the carlos/starting-account-balance-intervals branch from 17f306d to 2073267 Compare September 9, 2026 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants