Inline datums read through providers lose their original bytes

Ouverte
#683 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
22
Forks
33
Merge moyen
21 h 38 min
PR mergées (30 j)
55

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de IntersectMBO/evolution-sdk

Toutes les issues de IntersectMBO/evolution-sdk

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.