互联网计算机上 NFT 开发者的注意事项

一个 NFT 或非同质化代币是与特定数字或实物资产相关联的区块链上的记录，区块链上独特的数字表示允许 NFT 证明所有权并进行交易。
互联网计算机上的 NFT
互联网计算机区块链（IC）为 NFT 带来了巨大的潜力，对于图像、声音片段或视频等数字资产，整个资产可以存在于链上，并且可以包含在链上游戏或元宇宙体验中。
此外，我们可以想象动态 NFT 会根据 IC 内部和外部数据通过 HTTPS outcalls 发生变化。
对于许多应用程序，定义特征是它们的持久性和不变性（或根据预定义规则的演变），IC 的一些设计决策，例如反向 Gas 模型和容器智能合约的可升级性，需要 NFT 开发人员特别了解。
IC 上的 NFT 实现通常具有以下三个功能：

• 跟踪所有权并允许转让的注册表
• 分类账或交易历史
• 实际资产（在数字资产的情况下）

根据架构的不同，所有这些功能可能位于一个容器中，也可能分布在多个容器中，直至每个 NFT 的资产容器，这些容器中的每一个都不能用完 Cycles，并且应该防止任意代码更改。
在以下部分中，我们将讨论支持 NFT 开发人员及其用户实现这些目标的一些机制、工具和想法。
基础知识
非常慷慨地加满所有容器
确保所有的容器都有足够的 Cycles 来维持几年，IC 上的存储和计算比其他平台便宜很多，因此这通常不是一项巨大的投资。
为了方便其他人为容器充值，您应该考虑将黑洞容器或其他一些不可变代理容器作为控制器添加到 NFT 容器中，这允许用户使用 Tip Jar 服务来为容器充值。
设置宽大的冻结阈值
IC 有一个有用的机制来避免您的碳容器用完 Cycles，容器有一个可配置的 freezing_threshold。
freezing_threshold 可以由容器的控制器设置，并以秒为单位，IC 将其动态评估为 Cycles 中的阈值，该值使得容器至少能够在 freeze_threshold 中给定的时间内为其空闲资源付费。
为了保证这一点，当 Cycles 余额达到阈值时，容器被冻结，所有更新调用，包括心跳，都会立即被拒绝，不会影响容器的 Cycles 余额。
默认值约为 30 天，但对于 NFT，开发人员应将其设置 freezing_threshold 为至少 90 天，最好是 180 天，这确保了 NFT 开发人员及其用户有足够的时间在容器最终用完 Cycles 之前做出反应并为容器充值。
确保可以监控您的容器
在 IC 上，容器的 Cycles 余额仅对控制器可见，由于 NFT（集合）可能比其创建者寿命更长，因此您应该计划由第三方进行监控，您可以通过实施 DIP721 和 EXT 标准中包含的简单查询方法来做到这一点。
同样，将黑洞容器添加为控制器在这方面是一个很好的做法，因为它可以充当代理来获取 canister_status。
您还可以使用更完整的监控解决方案，例如 Canistergeek，最近，Canistergeek 背后的团队在他们的 NFTgeek 产品中添加了一个新功能，可以观察流行的 NFT 集合的 Cycles 余额。
遵循有效实施的最佳实践
有一些 foot guns 可能会使您的容器比您预期的更贵，以下是您在实施 NFT 容器时可能会遇到的几个示例。

• 心跳的使用：不做任何事情的普通心跳每天将花费 ~0.055 T Cycles，论坛上有关于实施允许更便宜的调度的替代方案的讨论。

给 Motoko 开发者的一些建议：

• 使用 TrieMap 而不是 HashMap 避免与 HashMaps 相关的自动调整大小的性能悬崖。
• 如果您需要动态调整结构大小，请使用 Buffer 而不是 Array。
• 使用 Blob 而不是 [Nat8] 存储大型二进制资产。
• 在发送或接收 Candid vec nat8/blob 值时考虑使用 Blob 而不是 [Nat8]，选择权在您手中，但 Blobs 紧凑性提高了 4 倍，垃圾收集（GC）的负担也少了很多。
• 考虑将大的 Blobs 存储在稳定的内存中，以进一步减少 GC 的压力，特别是当该 Blob 的手动内存管理很简单时（例如它们只添加，从不删除）。
• 考虑使用该 compacting-gc 设置，尤其是在仅附加方案中，以允许访问更大的堆并降低复制大型静止对象的成本。

给 Rust 开发者的一些建议：

• 如果您需要（反）序列化状态以进行升级，请注意广泛使用 Vec<u8> 并因此使用 String 类型。
• 阅读 Roman 关于有效 Rust 容器的博客文章。

另一个必读的文章是 Joachim Breitner 关于容器开发良好实践的概括文章。
为了确保您不会对高 Cycles 消耗率或达到指令限制感到惊讶，您甚至可以在上线之前使用最近添加的性能计数器 API 来分析您的容器，此外，可以在此处找到 IC 的所有成本清单：

• internetcomputer.org/docs/current/developer-docs/deploy/computation-and-storage-costs/

实施机制来备份和恢复状态
IC 本身还不支持容器状态的备份和恢复，但是可以在容器本身实现，定期备份是针对容器被解除分配或升级容器出现问题的最坏情况的保险，此论坛帖子描述了 Web3 社交网络 Distrikt 正在使用的方法：

• forum.dfinity.org/t/backup-restore-function-for-a-canister/12849/3

考虑使用专门的服务来存储交易历史
IC 上有专门的服务来保存交易的审计日志，例如 CAP，NFT 集合可以将其用作服务，这允许在浏览器和钱包中简单地集成出处历史，此外，如果主 NFT 容器丢失，可以重建所有权状态。
但是，必须考虑一些缺点，例如，由于必要的容器间调用，NFT 传输会产生额外的成本。
进阶话题
考虑治理
大多数 NFT 的价值主张是它们的永久性和不变性，例如，通过将黑洞容器设置为唯一的控制器，只要 NFT 容器有其开发人员作为控制器，用户就依赖于开发人员的可信赖性（和操作安全性）。
因此，开发人员应该使容器不可变或使用 DAO 管理容器，中间立场是像 Launchtrail 这样的机制，可以对容器进行可审计的更改。
对容器进行黑洞化也有其问题，如果容器代码中存在错误，或者您正在使用稍后可能会弃用的实验性系统 API，则容器可能会停止运行。
有关此主题的更多信息，请参阅“信任容器”一文：

• internetcomputer.org/docs/current/concepts/trust-in-canisters/

考虑经济可持续性
理想情况下，您的容器会实施产生费用的机制，这些费用可以用来无限期地支付其存在的费用。
一种简单的方法是利用（部分）转让费来为容器充值，但更复杂的方案可能涉及抵押或其他高级机制，如果您知道实施巧妙机制的项目，请分享。
链接和资源
以下资源是社区项目，请自行研究并自行承担使用它们的风险。
NFT 接口规范和实现

• DIP 721：类似于ERC-721的接口；
• 可扩展令牌（EXT）：受 ERC-1155 启发的可扩展接口。

NFT 市场和启动板

• Entrepot
• Jelly
• Yumi
• NFT Anvil

在 internetcomputer.org 上开始构建，并在 forum.dfinity.org 加入开发者社区。

作者：Dominic Wörner（DFINITY 开发者关系工程师）翻译：Catherine

-    往  期  推  荐    -

你关心的 IC 内容

技术进展 | 项目信息 | 全球活动

长按关注 IC 微信公众号

随时答疑解惑

＊添加小助手微信 comiocn 进交流社群