Encoders overflow on data nested past 1,000 to 3,000 levels

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

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

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

调研方向

Start with the recursive encoder paths in Data.ts (writeData, plutusDataToCBORValue) and CBOR.ts (internalEncodeSync), then trace how Data.toCBORBytes is used by the hash and inline datum writers named in the issue. Reproduce the reported stack overflow with the nested CBOR input and check the listed hash and TxOut paths. Done means every encoder handles Plutus data and CBOR values at ledger-accepted depths, including provider UTxOs passed to evaluators.

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

描述

bug

Data.toCBORHex(Data.fromCBORHex("81".repeat(3000) + "00")) throws RangeError: Maximum call stack size exceeded on a first call in a fresh process. Since #677 the decode in that call works at 16,384 levels; the encode does not. On a first call, the deepest list each encoder writes is:

  • 2,963 levels for Data.toCBORHex and Data.toDatumHash, 2,961 for Redeemers.toScriptDataHash with the list among its datums, and 2,950 for TxOut.toCBORHex of an output that holds it as an inline datum
  • 1,738 levels for CBOR.toCBORHex and CBOR.toCBORHexWithFormat
  • 996 levels for Data.plutusDataToCBORValue

Once the code is warm, Data.toCBORHex reaches 13,224 levels and CBOR.toCBORHex 5,880. A constructor nested in a constructor fails sooner: CBOR.toCBORHex stops at 838 levels of d87981.

Each encoder recurses once per level. writeData calls writeList, writeMap and writeConstr, which call writeData for each child (Data.ts:665-770). internalEncodeSync (CBOR.ts:1111) calls encodeArraySync, encodeMapEntriesSync and encodeTagSync, which call it back for each child (CBOR.ts:1507, CBOR.ts:1530, CBOR.ts:1583-1599, CBOR.ts:1750, CBOR.ts:1776). plutusDataToCBORValue maps each child through itself (Data.ts:788-837). toDatumHash (Data.ts:1243), toScriptDataHash (Redeemers.ts:648-655, Redeemers.ts:688) and the inline datum writer (DatumOption.ts:85) all go through Data.toCBORBytes.

Since #677 a provider returns a UTxO with a 15,000-level datum, but the SDK cannot pass that UTxO to a local evaluator. The builder hands every selected input and reference input to the evaluator (Evaluation.ts:514-516). The aiken-uplc and scalus-uplc evaluators re-encode each one as a TxOut (packages/aiken-uplc/src/Evaluator.ts:100-111, packages/scalus-uplc/src/Evaluator.ts:33-40), and TxOut writes a provider datum with Data.toCBORBytes. TxOut.toCBORHex of the provider copy of a 15,000-level datum throws, while the same UTxO read from a CIP-30 wallet keeps its original bytes and re-encodes. With passAdditionalUtxos: true, the Blockfrost, Ogmios and Maestro evaluators re-encode the inputs too (BlockfrostEffect.ts:114, Ogmios.ts:220, MaestroEffect.ts:232); by default they receive none (resolve.ts:179).

Anyone can send a UTxO with such a datum to any address. From the code, a build that selects it and evaluates locally fails; no end-to-end build has confirmed this yet. The ledger accepts the data. The Plutus data decoder limits the size of each leaf, not the depth (PlutusCore/Data.hs, decodeData), so a datum can nest about 16,000 levels in one transaction.

Every encoder of Plutus data and CBOR values should write any value the ledger accepts, so a UTxO read from a provider can go to any evaluator.

主要语言
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 摘要。