Inline datums read through providers lose their original bytes

Offen
#683 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
22
Forks
33
Ø Merge
21 Std. 38 Min.
Gemergte PRs (30 T.)
55

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus IntersectMBO/evolution-sdk

Alle Issues in IntersectMBO/evolution-sdk

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.