以太坊上买 NFT，直觉是”全局合约记着我是持有人”。Flow 从语言层就否定了这个图景：它的智能合约语言 Cadence 把 NFT 设计成资源——一种不能复制、只能 move、不能凭空销毁的一等对象，代币与藏品直接住在用户自己的账户里，而不是某个总合约的映射表中。正因为资产模型换了地基，Flow 生态需要一整套标准合约来补上”全局视角”，这套标准件目前有四个层次：资产接口、元数据视图、上架合约与合集目录。
第一层：NonFungibleToken 接口
onflow 仓库维护的 NonFungibleToken 契约定义最小接口标准：每个 NFT 有类型化的 id，有指向合集的 type；持有端是 Collection 资源，负责”我的账户里装 NFT 的盒子”，提供提现与接收接口，接收方通过 Provider 与 Receiver 资源被交易脚本引用；合约事件包括 Deposit、Withdraw、ContractInitialized。仓库同时列出 Emulator、Testnet、Mainnet 三套环境的已部署地址，并注明自 2020 年上线生产环境、地址是固定的已知地址——开发者用一行 flow CLI 就能把这份合约当依赖装进项目。同质化资产在姊妹仓库 flow-ft，标准思路一致。
第二层：ViewResolver 与 MetadataViews
资源住在用户账户里带来第二个问题：前端渲染一个 NFT 时怎么知道名字、图片、版税这些信息。标准答案是 ViewResolver 资源接口加上 MetadataViews 契约：每个 NFT 资源实现”回答问题”的能力，外部程序向它提交预定义的类型化问题（视图），它返回对应答案，比如展示用名称与封面、创作者列表、版税结构、媒体文件等，每种视图有固定字段。与以太坊”拉取一个 JSON 猜测字段”的做法相比，Flow 的元数据是类型化的现场问答——读不到视图就是没有，不存在解析歧义。
第三层：NFTStorefrontV2 上架合约
交易层的标准件是 NFTStorefrontV2：它把”挂单”本身做成资源——卖家账户里先建一个 Storefront 资源，再往里放若干 Listing 资源，每个 Listing 携带待售 NFT、价格与一组分配比例。仓库文档强调三点：挂单不是 NFT 而是可以交易的资源，购买通过调用 purchase 函数完成；一个 NFT 可以同时出现在多个 Listing 里，卖家因此可以在多个市场同时挂同一件货；每个 Listing 可自定义多路分成比例，版税、平台费、创作者费一次配置各自流向。市场与聚合器则通过监听 Listing 事件同步货架。主网合约部署在固定账户地址，这一串地址都记录在仓库文档里供集成方核对。
第四层：NFT Catalog 合集目录
既然 NFT 分布在全网账户中，钱包怎么发现一个新合集？答案是需要人工提案与审核流程的登记簿 NFT Catalog：项目方通过站点提交提案，填唯一标识与联系信息，审核后进入目录，前端与钱包据此知道某类 NFT 的合约地址与展示信息；仓库同时发布 npm 模块供程序化查询目录内容，历史上社区还讨论过用去中心化方案替换中心化审核环节。四个层次合起来，Flow 给出的是一套”资源在用户手、信息靠视图问答、挂单是资源、发现靠登记”的完整分工——评估这个生态里任何一个 NFT 项目，看它四件标准件各用了哪几件、哪件没接（比如没接 Catalog 的钱包可能根本不显示），比读任何宣传稿都更接近真实的基础设施状态。
换资源模型后的安全直觉
资源语义顺手改写了几条以太坊安全常识。ERC-721 的无限授权问题在 Flow 里近乎不存在：交易要拿走 NFT，必须从你的 Collection 资源里显式取出，你授权拿走的是资源本身，不存在授权一次、被惦记一年的悬置额度。相应地，核验一笔购买的动作也变了：成交后钱包应收到一个带类型标注的资源，形如 A.<项目地址>.<合约>.NFT，类型字符串就是防伪标签——仿冒合集名字再像，也伪造不了资源的类型地址。再叠加 Catalog 的登记审核，Flow 把它是真的拆成了类型、视图、登记三层可以分别验证的事实。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。