[FR] - Generalize Plutus guard witnesses over supported script versions

Aperta
  • Qualcosa non va?
#1,386 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
haskell
Ambito
api, backend-api-design

Direzione di ricerca

Start by reading the Plutus guard witness constructor introduced in PR #1381 and the ledger language and era support machinery it relies on. Assess whether that machinery provides a reusable constraint for supported guarding languages, then generalize the constructor while preserving V4 behavior. Add tests for supported and rejected language/era combinations, and document downstream API migration; done means the constraint, behavior, tests, and migration are covered.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Dijkstra era type: enhancement

The Plutus guard witness constructor in #1381 fixes the script language to PlutusV4. We agree with carbolymer's review comment that the API should ideally express which script versions support the guarding purpose through a constraint, rather than hardcoding one version.

Track that generalization as a separate follow-up. This issue should not block merging #1381 and exposing native and Plutus V4 guard witnesses in the experimental transaction API. Keep the current V4 restriction for that PR.

The follow-up should:

  • Investigate a reusable constraint or type-level representation for Plutus languages that support the guarding purpose, consistent with ledger language and era support.
  • Generalize the Plutus guard witness constructor to use that evidence while continuing to reject unsupported language/era combinations.
  • Preserve existing Plutus V4 behavior and add tests for the supported combinations and rejection of unsupported ones.
  • Document any downstream API migration required by the change.

Keeping the V4 restriction is the interim alternative. The review notes that there is no known existing constraint for this purpose and that introducing a class solely for this PR would not be worthwhile; the follow-up should assess whether an abstraction can be shared with the existing language/era machinery.

Lingua principale
Haskell
Stelle
41
Fork
32
Merge medio
1g 9h
PR unite (30g)
22

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di IntersectMBO/cardano-api

Tutte le issue di IntersectMBO/cardano-api

Issue simili

Altre issue su Haskell

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.