压缩 NFT（cNFTs）是一种利用状态压缩技术，将 NFT 数据哈希化并存储在链上的新型数字资产。它通过并发默克尔树结构，将数据哈希存储在账户中，既保障了数据不可篡改，又大幅降低了存储成本。
与传统 NFT 不同，cNFTs 的数据哈希无法反向推断原始数据，但可用于验证所见数据的正确性。支持 cNFT 的 RPC 提供商会在铸造时离线索引数据，用户可通过 Read API 访问这些数据。而 Metaplex Bubblegum 程序作为状态压缩程序的抽象层，让创建、铸造和管理 cNFT 集合变得更加简单。
压缩 NFT 的核心优势
大幅降低存储成本
Solana 的交易成本低廉，但大规模铸造传统 NFT 的成本却不容小觑。使用 Token Metadata 程序设置和铸造 100 万个传统 NFT 大约需要 24,000 SOL。相比之下，cNFTs 可以将相同的设置和铸造成本控制在 10 SOL 以内。这意味着任何大规模使用 NFT 的用户都可以通过使用 cNFTs 将成本降低 1000 倍以上。
技术原理简介
大多数与传统 NFT 相关的成本都来自账户存储空间。压缩 NFT 使用状态压缩概念，将数据存储在区块链的账本状态中，仅使用账户状态存储数据的"指纹"或哈希。这种哈希允许您以加密方式验证数据是否被篡改。
并发默克尔树的工作原理
默克尔树基础
默克尔树是一种用单个哈希表示的二叉树结构。结构中的每个叶节点都是其内部数据的哈希，而每个分支则是其子叶哈希的哈希。反过来，分支也会被一起哈希，直到最终剩下一个最终的根哈希。
对叶数据的任何修改都会改变根哈希。当同一插槽中的多个交易试图修改叶数据时，这会导致问题。由于这些交易必须按顺序执行，除第一个交易外的所有交易都会失败，因为根哈希和传入的证明将被第一个执行的交易无效化。
并发处理机制
并发默克尔树是一种默克尔树，它存储了最近更改的安全变更日志及其根哈希和推导证明。当同一插槽中的多个交易尝试修改叶数据时，变更日志可以用作允许对树进行并发更改的真相来源。
处理并发默克尔树时，有三个变量决定了树的大小、创建树的成本以及对树可以进行的同时更改数量：
- 最大深度：从任何叶到树根的最大跳数
- 最大缓冲区大小：单插槽内可对树进行的最大并发更改数
- 冠层深度：为任何给定证明路径存储在链上的证明节点数
创建 cNFT 集合的实践指南
准备元数据
在开始之前，您需要准备 NFT 元数据，类似于使用 Candy Machine 时的操作。核心上，NFT 只是遵循 NFT 标准的带有元数据的代币。根据您的用例，您可以动态生成此数据，或者事先为每个 cNFT 准备 JSON 文件。
创建集合 NFT
与具有供应量的可替代代币相比，NFT 本质上是唯一的。但是，使用集合将同一系列产生的 NFT 绑定在一起非常重要。集合允许人们发现同一集合中的其他 NFT，并验证单个 NFT 是否是该集合的实际成员（而不是其他人生产的仿制品）。
要让您的 cNFTs 成为集合的一部分，您需要在开始铸造 cNFTs 之前创建一个集合 NFT。这是一个传统的 Token Metadata 程序 NFT，作为将您的 cNFTs 绑定到一个集合中的参考。
创建默克尔树账户
现在我们开始偏离创建传统 NFT 时使用的过程。用于状态压缩的链上存储机制是代表并发默克尔树的账户。此默克尔树账户属于 SPL 状态压缩程序。在执行与 cNFTs 相关的任何操作之前，您需要创建一个具有适当大小的空默克尔树账户。
影响账户大小的变量包括最大深度、最大缓冲区大小和冠层深度。前两个变量必须从现有的有效对中选择。请注意，树可以存储的 cNFT 数量完全取决于最大深度，而缓冲区大小将决定在同一插槽内可以对树进行的并发更改（铸造、转移等）的数量。
使用 Bubblegum 初始化树木
使用 Umi 实例化后，我们准备调用 createTree 方法来实例化默克尔树和树配置账户。需要提供的三个值即 merkleTree、maxDepth 和 maxBufferSize 是创建树所必需的，而其余的是可选的。
当设置为 true 时，public 允许任何人从初始化的树中铸造，如果为 false，则只有树创建者能够从树中铸造。
铸造与交互：cNFT 的实际操作
铸造 cNFTs
使用默克尔树账户及其相应的 Bubblegum 树配置账户初始化后，可以向树铸造 cNFTs。Bubblegum 库提供了两个指令，具体取决于铸造的资产是否属于一个集合。
这两个指令是：
- MintV1
- mintToCollectionV1
两个函数都要求您传入 NFT 元数据和铸造 cNFT 所需的账户列表，例如 leafOwner、merkleTree 账户等。
获取 cNFT 数据
从现有 cNFT 获取数据的最简单方法是使用数字资产标准读取 API（读取 API）。请注意，这与标准 JSON RPC 是分开的。要使用读取 API，您需要使用支持的 RPC 提供商。
转移 cNFTs
与标准 SPL 代币转移一样，安全性至关重要。然而，SPL 代币转移使得验证转移权限非常容易。它内置于 SPL 代币程序和标准签名中。压缩代币的所有权更难以验证。实际验证将在程序端进行，但您的客户端代码需要提供额外信息以使其成为可能。
常见问题
压缩 NFT 与传统 NFT 的主要区别是什么？
压缩 NFT 使用状态压缩技术将数据存储在区块链的账本状态中，只使用账户状态存储数据的哈希值。这使得存储成本大幅降低，同时保持数据的可验证性。传统 NFT 则将完整数据存储在链上账户中，成本显著更高。
如何确保压缩 NFT 数据的安全性？
cNFTs 通过默克尔树结构提供加密验证保障。每个数据片段都被哈希化，最终的根哈希存储在链上。任何对数据的修改都会改变根哈希，从而立即被检测到。虽然数据本身可能存储在链下，但其完整性和真实性可以通过链上哈希进行验证。
压缩 NFT 是否支持所有传统 NFT 的功能？
是的，压缩 NFT 支持大多数传统 NFT 的功能，包括所有权转移、交易和显示。然而，由于技术架构的差异，一些操作可能需要额外的步骤，如提供完整的资产数据进行验证。生态系统的工具和支持正在不断完善中。
开发者在选择最大深度和缓冲区大小时应考虑什么？
选择最大深度主要取决于您需要树持有的 NFT 数量 - 使用公式 2^maxDepth > 所需数量 计算。缓冲区大小则取决于您预期的并发交易量。冠层深度影响交易复杂性和成本，需要根据实际应用场景平衡选择。
压缩 NFT 的数据存储在哪里？
cNFT 数据通过交易传递给状态压缩程序，在那里被哈希并作为"事件"发送到 Noop 程序。哈希然后存储在相应的并发默克尔树中。由于数据通过交易传递甚至存在于 Noop 程序日志中，它将永远存在于账本状态中。
如何查询和获取压缩 NFT 的信息？
您可以使用支持 DAS API 的 RPC 提供商（如 Helius）来查询 cNFT 数据。读取 API 提供了多种方法，包括按所有者、创建者或组查询资产，以及获取资产证明和签名等功能。这使得检索 cNFT 信息与传统 NFT 体验相似。