Transactions with witness data nested past 1,000 levels fail to decode

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

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

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

调研方向

Start with Data.ts around Data.FromCDDL (1078), CDDLSchema (1044), and Schema.typeSchema(DataSchema), then inspect TransactionWitnessSet.ts (462-469), Redeemers.ts, Redeemer.ts, and Transaction.ts (268). Trace the schema checks on both sides of the iterative conversion in cborValueToPlutusData; reproduce with the 2,000-level witness datum or redeemer from the issue. Done when the schema forms of Data and transaction decoding handle ledger-accepted nesting without the stack overflow.

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

描述

bug

Transaction.fromCBORHex of a transaction whose witness set holds "81".repeat(2000) + "00", a list nested 2,000 levels deep, as a datum or as redeemer data throws ParseError with "Maximum call stack size exceeded". Since #677, Data.fromCBORHex reads the same list at 16,384 levels. On a first call in a fresh process, every schema form of Data stops at 991 to 996 levels:

  • Schema.decodeSync(Data.FromCBORHex()), Schema.decodeSync(Data.FromCDDL) and Data.withSchema(...).fromCBORHex
  • Redeemer.fromCBORHex, and TransactionWitnessSet.fromCBORHex with the list as a datum or in a redeemer map
  • Transaction.fromCBORHex, with the list as a witness datum or in a redeemer

Once the code is warm, Data.FromCBORHex reads up to 2,023 levels and Transaction.fromCBORHex up to 1,647 levels. A constructor nested in a constructor fails sooner: Transaction.fromCBORHex stops at 836 levels of d87981.

Each form decodes through Data.FromCDDL (Data.ts:1078). Its input side is CDDLSchema, which is the recursive CBORSchema union (Data.ts:1044), and its output side is Schema.typeSchema(DataSchema). Both sides type-check the value with one call frame per level, before and after the conversion that #677 made iterative (cborValueToPlutusData, Data.ts:962). Data.FromCBORBytes composes CBOR.FromBytes with FromCDDL (Data.ts:1095-1123), and Data.withSchema composes FromCBORHex (Data.ts:1206-1220). The witness set decodes its datums with PlutusData.FromCDDL (TransactionWitnessSet.ts:462-469). Redeemers go through Data.CDDLSchema and Data.FromCDDL (Redeemers.ts:319, Redeemers.ts:367, Redeemer.ts:220, Redeemer.ts:258). Transaction.fromCBORHex reaches both through Transaction.FromCDDL (Transaction.ts:268).

Transaction.fromCBORHex and Transaction.addVKeyWitnessesHex are how a wallet or dApp reads and signs a transaction it did not build, and the second throws the same ParseError on the 2,000-level example. Tools that read transactions from the chain decode them the same way. The ledger accepts the data. The Plutus data decoder limits the size of each leaf, not the depth (PlutusCore/Data.hs, decodeData), so a witness datum or a redeemer can nest about 16,000 levels in one transaction. The limit does not reach inline datums in outputs: DatumOption decodes them with Data.fromCBORBytes (DatumOption.ts:107-116), and a transaction with a 15,000-level inline datum decodes.

Transaction.fromCBORHex and the schema forms of Data should decode any datum or redeemer the ledger accepts.

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