Inline datums read through providers lose their original bytes

未关闭
  • 哪里不对？
#683 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript
领域
backend-api-design

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
22
派生
33
平均合并
21 小时 38 分钟
30 天内合并 PR
55

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

IntersectMBO/evolution-sdk 的其他 Issue

查看 IntersectMBO/evolution-sdk 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。