赏金
通过您的贡献赚取代币。
帖子
4+15
专家问答Xavier.eth298Jun 27, 2025Sui 事务失败：为另一笔交易保留的对象
我在JsonRpcError尝试在 Sui 上执行交易时遇到了持久问题. 该错误表明对象是为另一个事务保留的，尽管我已经实现了延迟的顺序事务处理. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 我试过了： -顺序事务执行（等待前一笔交易完成） -增加了交易之间的 3 秒延迟 而且仍然会持续出现同样的错误. 使用 Sui RPC 提交交易. 同一个对象 ID 在锁定列表中多次出现. 即使仔细安排交易顺序，也会出现错误. 是什么导致对象被 “保留” 用于其他交易？ 在交易中使用对象之前，如何正确检查对象是否可用？ 3.是否有在 Sui 中处理对象锁的最佳实践？ 这可能与交易终结时间有关吗？ 以前有人遇到过这个问题吗？如果您对Sui交易中的适当对象管理有任何见解，将不胜感激！
- Sui
- Transaction Processing
- Move
25+15
专家问答Xavier.eth298Jun 17, 2025能力约束如何与异构集合中的动态字段相互作用？
我正在建立一个需要处理具有不同能力要求的多种资产类型的市场，我遇到了一些关于Move类型系统的基本问题. 我想将不同的资产类型存储在同一个集合中，但它们有不同的能力： -常规 NFT：key + store（可转让） -Soulbound 代币：key 仅限（不可转让） -具有转移限制的自定义资产 public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } 关键问题： -能力要求：使用时dynamic_field::add()，Vstore 编译时是否总是需要的？包装器类型能解决这个问题吗？ -异构存储：单个 Bag 能否存储具有不同能力集（key + store + copyvskey + store）的对象，并在运行时以不同的方式处理它们？ -类型安全：由于动态字段会执行类型擦除，因此在检索值时如何保持类型安全？存储类型元数据的模式是什么？ -见证模式：能力限制如何与幻影类型一起使用？我可以将Asset和存储Asset在同一个集合中并稍后提取类型信息吗？ 建立一个系统，在该系统中，NFT、soulbound 代币和受限资产都需要市场功能，但转移语义不同. 我尝试过包装器类型，每个能力集合有多个集合，单独的类型元数据存储. 每种方法都在类型安全性、燃气成本和复杂性之间进行权衡.
- Sui
- Architecture
05最佳答案+10
专家问答May 29, 2025当 Move 结构有命名字段时，为什么 BCS 需要精确的字段顺序才能进行反序列化？
当 Move 结构有命名字段时，为什么 BCS 需要精确的字段顺序才能进行反序列化？ 我一直在深入研究 Move 中的 BCS 编码/解码，特别是跨链通信和链下数据处理. 在浏览 Sui Move 文档中的示例时，我遇到了一些似乎违反直觉的行为，我正在尝试理解底层的设计决策. 根据BCS规范，“BCS中没有结构（因为没有类型）；该结构只是定义了字段序列化的顺序. ”这意味着在反序列化时，我们必须按照与peel_*结构字段定义完全相同的顺序使用函数. 我的具体问题： 设计理由：当 Move 结构具有命名字段时，为什么 BCS 需要精确的字段顺序匹配？像 JSON 或其他自描述格式一样，将字段名称与值一起序列化不是更强大吗？ 泛型类型交互：文档提到 “包含泛型类型字段的类型最多可以解析到第一个泛型类型字段. ”考虑一下这个结构： struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } 部分反序列化在这里到底是如何工作的？我可以反序列化到more_metadata并忽略两个泛型字段，还是第一个泛型字段（generic_data）完全阻止了进一步的反序列化？ 跨语言一致性：使用 @mysten /bcs JavaScript 库序列化将由 Move 合约使用的数据时，在以下情况下会发生什么： -我不小心重新排序了 JavaScript 对象中的字段？ -Move 结构定义会在合约升级中更改字段顺序？ -我有带有自己的泛型参数的嵌套结构吗？ 实际启示：在生产系统中，团队如何处理 BCS 架构演变？您是否对BCS架构进行了版本控制，还是期望结构字段顺序在部署后不可变？
- Sui
- Move
53最佳答案+10
专家问答Mar 05, 2025Sui Move 模块出版物中的 “多源验证错误” ——自动错误解决
使用 Sui Move 的开发人员在尝试发布或升级模块时经常遇到与 “发现多源验证错误” 相关的问题. 这些错误是由于本地依赖项与其链上依赖项之间的不匹配而发生的，从而导致发布失败和部署挑战. 以下是开发人员面临的错误的综合示例： Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk 这个问题通常是由于： 本地开发环境（例如 Sui CLI）和链上状态之间的版本不匹配. 网络间软件包配置的差异（例如，主网与测试网）. 3.链上环境中缺少或过时的依赖关系. 关键问题 -在发布过程中，我们如何自动检测和解决这些依赖关系不匹配的问题？ -可以开发哪些工具或脚本来确保本地依赖关系始终与链上依赖项保持一致？ -有没有办法通过将依赖关系检查集成到现有的 CI/CD 管道或增强 Sui SDK 来简化这个过程？ 你的任务是提出一个解决这些挑战的解决方案，确保Sui Move开发人员的部署更加顺畅和可靠. 请务必在下面发布您的解决方案.
- Sui
- SDKs and Developer Tools
43最佳答案
- Sui
- Architecture
- SDKs and Developer Tools
- Move
- NFT Ecosystem
- Security Protocols
- Transaction Processing