发行一个FT或NFT对于DApp开发者来说通常是最基本的需求。因此我也以此作为学习入口。首先让我们来了解以下在EVM技术栈中开发一个NFT和在TONChain中的区别。基于EVM的NFT通常会选择继承ERC-721的标准。所谓NFT，指的是不可分割的加密资产类型，且每个资产具有唯一性，即存在某些专属的特性。而ERC-721就是对这个类型的资产的一种通用的开发范式。让我们看一个常见的ERC721合约需要实现哪些函数以及记录哪些信息。下图是一个ERC721接口。可以看到与FT不同，在转账接口中需要输入的是待转账的tokenId而非数量。这个tokenId也是NFT资产唯一性最基本的体现，当然为了承载更多的属性，通常会为每个tokenId记录一个metadata，这个metadata是一个外部链接，保存了该NFT的其他可扩展数据，例如一张PFP图片的链接，某些属性名称等。
对于熟悉Solidity或者熟悉面向对象的开发者来说，实现这样一个智能合约是件容易的事，只要定义好合约中需要的数据类型，例如一些关键的映射关系mapping，并根据所需功能开发相应的对这些数据的修改逻辑，即可实现一个NFT。
然而在TONChain中这一切变的不太相同，造成不同的核心原因有两个：
在TON中数据的存储是基于Cell实现的，而同一个账户的Cell通过有向无环图来实现。这样就导致需要之久化存储的数据不能无边界的增长下去，因为一个有向无环图来说，数据深度决定的查询成本，当深度无限延伸之后，有可能造成查询成本过高，从而导致合约陷入死锁问题。
为了追求高并发性能，TON舍弃了串行执行的架构，转而采用了一个专为并行而生的开发范式，Actor模型，来重构执行环境。这就造成了一个影响，智能合约之间只能通过发送所谓内部消息的方式异步调用，注意无论是状态修改类型或只读类型的调用都需要遵循这个原则，除此之外，也需要仔细考虑异步调用若失败，如何处理数据回滚的问题。
当然关于技术上其他不同点在上一篇文章中有过详细的论述，本篇文章希望可以聚焦在智能合约开发上，所以不展开讨论。上述两条设计原则让TON中智能合约开发与EVM产生了很大区别。在开始的论述中，我们知道一个NFT合约中需要定义一些映射关系，也就是mapping，来保存NFT相关的数据。其中最重要的就是owners，这个mapping存储了某个tokenID对应的NFT的所有者地址的映射关系，决定了NFT的所有权，转账就是对该所有权的修改。由于理论上这是一个可以无边界的数据结构，需要尽量避免。因此官方推荐以是否存在无边界数据结构作为分片的标准。即当有类似的数据存储需求时，通过主从合约的范式来替代，通过创建子合约的方式来管理每个key对应的数据。并通过主合约管理全局参数，或帮助处理子合约之间的内部信息交互。
这也就意味着在TON中的NFT也需要采用类似的架构来设计，每个NFT都是一个独立的子合约，保存了诸如所有者地址，metadata等专属数据，并通过一个主合约来管理全局数据，例如NFTname，symbol，总供应量等。
在明确了架构后，接下来就需要解决核心功能的需求了，由于采用了这个主从合约的方式，因此就需要明确哪些功能由主合约承载，哪些功能由子合约承载，并且两者之间通过什么内部信息沟通，同时当出现执行错误时，如何回滚之前的数据。通常情况下，在开发复杂的大型项目之前，通过一个类图并明确彼此之间的信息流，并仔细思考内部调用失败后的回滚逻辑是必要的，当然上述NFT开发虽然简单，但也可以做类似验证。
TON选择了设计一种类C语言的、静态类型语言，名为Func来作为智能合约开发语言，那么接下来就让我们从源码来学习如何开发TON智能合约，我选择了TON官方文档中的NFT示例来进行介绍，感兴趣的小伙伴可以自行去查阅。在这个case中实现了一个简单的TONNFT例。让我们看下合约结构，共分为两个功能合约以及三个必要的库。
这两个主要的功能合约即按照上述的原则进行设计，首先让我们来看下主合约nft-collection的代码：
以上就是从源码角度看如何在TON Chain上创建一个NFT的全部内容，望能这篇从源码角度看如何在TON Chain上创建一个NFT可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。