Inline datums read through providers lose their original bytes

Aperta
  • Qualcosa non va?
#683 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à
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend-api-design

Direzione di ricerca

Start with DatumOption.ts:107-116 and DatumOption.ts:85 to understand how original bytes are recorded and encoded, then compare the provider construction sites named in Koios, Maestro, Blockfrost, and Kupmios. Reproduce the listed datum byte changes through a provider and verify that encoding preserves each provider's bytes, including the deep datum case described in the issue.

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

Descrizione

bug

Take a Koios UTxO whose inline datum is d879820102: constructor 0 with the fields [1, 2] as a definite-length array. KoiosEffect.getUtxos returns it with a datum that no longer encodes to those bytes. TxOut.toCBORHex of that UTxO writes the datum as d8799f0102ff, with the fields indefinite. The same output read with TransactionOutput.fromCBORHex, as the CIP-30 path reads it, writes d879820102 back unchanged. Two more datums that change: the indefinite map bf0102ff becomes a10102, and the one-chunk byte string 5f4101ff becomes 4101. A datum already in the default layout keeps its bytes, for example the indefinite list 9f0102ff.

DatumOption records the bytes it decodes with OriginalBytes.record (DatumOption.ts:107-116) and writes them back on encode (DatumOption.ts:85). The provider sites build each InlineDatum without recording its bytes: Koios (Koios.ts:192), Maestro (Maestro.ts:255), Blockfrost (BlockfrostEffect.ts:230, 313, 407, 504, 571) and Kupmios (KupmiosEffects.ts:105). An encoder then writes the decoded value in the default Plutus data layout (PLUTUS_DATA_OPTIONS, CBOR.ts:278-286).

A UTxO's bytes then depend on where the SDK read it. An output that reuses the fetched datum writes different bytes from the input it came from. The evaluators that re-encode inputs as TxOut (aiken-uplc and scalus-uplc, and Maestro at MaestroEffect.ts:232 with passAdditionalUtxos: true) send datum bytes the chain does not hold. The gap also matters for depth since #677, because TxOut writes recorded bytes without running the encoder. The CIP-30 copy of a 15,000-level datum re-encodes, while TxOut.toCBORHex of the provider copy throws RangeError. Hashing has a separate gap on both paths: Data.toDatumHash re-encodes the decoded value, which #397 covers. #581 proposes keeping original bytes for every component.

A datum read through any provider should encode back to the bytes the provider returned, as a datum read through CIP-30 does.

Lingua principale
TypeScript
Stelle
22
Fork
33
Merge medio
21h 38m
PR unite (30g)
55

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/evolution-sdk

Tutte le issue di IntersectMBO/evolution-sdk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.