Inline datums read through providers lose their original bytes

Abierto
  • ¿Algo no está bien?
#683 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
22
Forks
33
Merge medio
21 h 38 min
PR fusionados (30 d)
55

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de IntersectMBO/evolution-sdk

Todos los issues de IntersectMBO/evolution-sdk

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.