一万个 NFT 挤进一个账户：Solana 压缩 NFT 的默克尔树账本

在 Solana 上，一枚普通 NFT 对应一组链上账户，量大时账户租金是一笔真实开销。Metaplex 的 Bubblegum 程序给出了另一条路：官方仓库的说法是“重思链上数据的存储方式”，把 NFT 的创建扩展到新的数量级。实现的核心工具是默克尔树——成千上万枚 NFT 的元数据摘要被编进一棵树的叶子，链上只需要记住树根等少量状态。这类资产被称为压缩 NFT，它让“链上资产”这个词第一次出现了两种账本形态。

传统账本与默克尔账本的差别

普通 NFT 把所有权与元数据放在专门的账户里，任何节点都能按地址直查。压缩 NFT 把每条记录的“存在证明”做成哈希叶节点，逐层两两哈希汇聚到一个根；链上账户保存根哈希与树的结构参数，具体叶子数据不常驻在单独账户里。你持有第几亿片叶子，由一条从叶子到根的路径（Merkle 证明）来证明归属。省下的每一份常驻存储，都直接兑换成成本优势：官方文档把这套结构定位为面向大规模铸造与分发的方案。

归属怎么查、怎么转

因为没有独立账户，钱包看压缩 NFT 不再靠“扫账户”，而是依赖索引服务返回叶子列表加证明路径。转移则分两种路径：直接把叶子“证明式地”转给新持有人，所有权更新后根哈希重新计算，全程不新建 NFT 账户；或者先把这枚压缩 NFT“解压”成普通 NFT——放弃紧凑结构、恢复独立账户形态，之后走标准转账流程。取舍很直白：压缩形态交易便宜，但可组合性弱，很多依赖独立账户的协议功能（例如被当作账户持有的场景、部分市场挂单路径）需要先解压。

数据放哪：别把“压缩”当成“存储”

值得厘清的一点：压缩技术动的是所有权账本的表达形式，作品文件本身的存放问题一个都没少——图片在链上还是对象存储、元数据地址是否不可变，判断逻辑与其他链完全一致。叶子条目记录的仍然是指向内容的 URI 与属性摘要，因此对内容寻址、可用性、可修改性的核验标准不变。反过来说，批量分发型项目偏爱压缩方案，常和空投、积分、门票这类高并发发放结合，看到百万级供应量时，第一反应应当是看树由谁配置、元数据由谁签发，而不是默认便宜等于临时。

树本身也有可配置的参数：默克尔树的最大深度决定单棵树能容纳多少叶子，路径证明的体积随之变化；被称为 canopy 的机制允许把树顶若干层的节点保留在链上，从而缩小每笔交易需要携带的证明字节。深度与 canopy 的组合是“单树容量、证明体积、链上常驻存储”三者的权衡，通常在创建树时一次性定死——所以读懂一棵配置树的参数，基本就读到了平台方在扩容能力与验证成本之间做出的工程取舍。

使用者视角的三条注意

1. 钱包显示：压缩 NFT 需要索引支持，钱包没显示不等于资产不存在，用官方或主流索引器的地址视图复核。
2. 转移前确认形态：想进不支持压缩资产的市场或协议，先评估解压费用与时机，解压是单向改造还是可逆操作以工具文档为准。
3. 授权与代理：树的管理角色（如配置树与签发的相关权限）集中在少数账户上，评估托管方责任时把它当作结构性变量，这与普通 NFT 逐个看授权名单是两种风险画像。

本文只解释存储与所有权机制，不涉及任何估值或买卖建议；实现细节以 Metaplex 官方仓库与文档为准。