ArcBlock 如何用 NFT 表示和管理应用资源

打开一个应用，连接自己的 DID Space，在钱包里选择对应的 NFT，然后继续使用存储。这是 ArcBlock 已经提供的产品流程。第一次看到它的人，很容易问：为什么我在钱包里选了一张卡，应用就知道该连接哪个空间？

这里藏着我们对 NFT 的一种实际用法：把资源相关的权利表达成可以被持有和核验的对象，再让提供资源的服务按这些权利处理请求。存储空间、域名、软件许可、应用实例和访问资格，都可以进入这套模型。它们仍然是不同的东西，但身份、权利与持有状态之间有了一致的连接方式。

这篇从存储说起。把一个空间如何被使用讲明白，再看域名和应用，就容易得多。

钱包里的卡片指向什么

DID Space 连接组件提供了一个很具体的例子。用户可以通过 DID Wallet 选择空间，连接成功后，应用得到这个空间的名称、DID 和访问地址等信息。也可以从空间的 gateway 地址发起定向连接，让钱包只显示相关的 NFT。

钱包里那张卡片有展示信息，也有供系统核验的内容。它把一个持有者与一个特定空间的资源关系连接起来。空间里的文件仍保存在存储服务中，读写仍然由服务处理；卡片让应用有办法找到资源，并进入相应的身份与权限验证过程。

这个区别会影响我们怎样设计整个系统。文件容量由存储服务管理，谁可以使用这个空间则需要身份和权利的证明。把两件事分开表达，应用就不必把“一个用户账户”和“这个账户名下的全部资源”当成不可分的一团。

同一个人可以有多个空间。同一个应用也可以让用户选择要连接哪个空间。选择动作本身不会自动授予应用对所有文件的访问权，具体操作仍在服务认可的授权范围内。

一份权利怎样对应到一项资源

在 ArcBlock 的这套设计中，DID 用来标识参与者和资源，Verifiable Credential，简称 VC，用来承载签发者对权利的声明，NFT 则把这份声明与可追踪的持有状态结合起来。

DID 是去中心化标识符。一个用户可以有 DID，一个存储空间或应用实例也可以有自己的 DID。它解决的是识别对象的问题：这里说的究竟是哪个人、哪个服务、哪项资源。标识本身不会自动授予权限。W3C 的 DID 标准也不要求所有 DID 都依赖区块链。^[1]

VC 是带有可验证证明的声明。在这里，资源的控制者可以签发一份声明，说明与某项资源有关的权利。它可以涉及一个软件许可、某个角色的访问资格，或者具有容量和期限条件的存储使用权。验证者能检查声明的来源和完整性，服务再依据自己的规则判断是否认可它。^[2]

NFT 为这类需要逐项识别的对象提供持有与状态记录。当一个权利对象允许转移时，系统可以检查它现在由谁控制，而不只看谁手里留着一份旧声明。

把这些职责放在一起，就能看出各部分怎样合作：

软件许可可以规定运行实例数量；存储使用权可以规定容量和有效期；Passport 可以表示某项服务认可的访问资格。不同对象共享一种表达方式，各自的业务规则仍然保留。

因此，描述一个 NFT 时，“拥有”后面最好跟着一个明确的宾语。拥有管理某个实例的权利，与拥有一份运行软件的许可，含义并不相同。用户能看懂这个区别，服务也必须能判断这个区别。

真正把资源接进来的，是服务端

如果只在一个 NFT 的说明里写上“可以使用某台服务器”，服务器不会因此改变行为。需要有资源管理程序理解这项声明，并把验证结果接到实际操作上。

ArcBlock 把这一部分做进了资源管理设计。用户发起操作时，资源服务核验请求者的身份，检查相关 NFT 的持有状态，并确认其中的权利是否覆盖这次请求。条件满足后，服务才执行启动应用、连接存储或其他获准的操作。

可以把它理解成三个相互配合的层次。链上的对象和记录提供持有及相关状态信息；管理层解释这些信息，结合服务规则作出判断；实际资源负责运行程序、保存数据或提供网络服务。检查与执行发生在需要它们的地方，并不意味着每次读文件都要发起一笔链上交易。

这里的服务端很重要。签名正确，表示某份声明能够通过相应的密码学检查；要不要执行操作，还要看发行人是否被认可、请求者是否有权使用它，以及服务条件是否满足。W3C 同样明确指出，VC 数据模型需要配套的授权框架，才能用于资源访问控制。^[2]

这也解释了为什么我们把 NFT、VC 和资源管理放在一起谈。它们共同参与一次可用的服务关系。只讲发行一个对象，读者还无法知道这个对象怎么用。

从一个空间，到域名和应用

域名是另一个容易理解的例子。DID Names 的域名托管流程支持在其他注册商注册的域名。用户完成相应的托管和订阅流程后，钱包收到 DID Names NFT，并可在 Blocklet 平台上使用该域名。

在这里，NFT 对应的是服务认可的域名使用和管理关系。原注册商仍然承担它在域名注册体系中的职责，DNS 也仍按它的规则工作。这使既有域名能够进入同一套钱包和资源验证体验，而不必把互联网的域名系统重新造一遍。

向应用出示 NFT 或 Passport则展示了另一种关系。应用要求用户证明自己具备某项资格，钱包让用户选择并出示符合要求的对象。这个操作是提供证明，不是把 NFT 发送给应用。资格通过核验后，应用才按照对应角色或权限提供服务。

软件许可和应用实例也有各自的权利对象。许可说明允许怎样运行软件；实例的控制关系说明谁可以管理那个正在运行的应用。把两者区分开，才能表达“可以使用某项软件”和“可以管理某个具体实例”之间的差别。

这些资源既可以独立管理，也可以在一个应用的使用过程中共同出现。应用需要计算、存储和域名时，各项资源的权利可以被分别验证和组合使用。统一表达带来的好处，是应用和资源提供者有共同的识别与验证方式；组合后的服务仍然受每项资源自己的条件约束。

资源交接，交接的是哪一种关系

当某种权利允许转移时，NFT 转移可以承载这项权利的交接。新的持有者通过验证后使用相应资源，原持有者也不能继续仅凭已经转出的对象证明自己仍然拥有同一权利。

这里最值得关注的是“允许转移”和“相应资源”。一份与个人绑定的资格、一项限时使用权，以及一个应用实例的管理权，完全可以有不同的转移规则。身份、角色、资源所有权和使用权需要分别表达，不能因为它们都在钱包里出现，就假定它们可以用同样的方式交接。

服务端也需要处理权利变化对访问的影响。例如，新的请求应依据新的持有状态判断，已经建立的会话则按服务的会话与权限规则处理。链上的转移记录与资源端的执行相互配合，才能让交接具有实际意义。

这一点也决定了模型的适用范围。一个只服务于内部账户的简单应用，可以直接在自己的数据库里管理权限。资源需要在不同应用之间被识别、由用户出示证明，或者按明确规则交给另一位持有者时，这种独立的权利表示才尤其有用。区块链记录不能代替运行服务，也不能替服务方保证可用性。

从钱包回到资源

2021 年，我们在讨论 NFT 与 DID、VC 的关系时，已经把这套思路与底层服务联系起来。今天，DID Space 的连接、DID Names 的使用，以及 Passport 的出示，把这种关系放到了用户能够操作的产品流程里。

回到开头那个动作：用户在钱包里选择一个空间，应用据此找到相关资源，并进入核验和连接过程。用户不需要在脑中展开整个架构，仍然应该能知道自己选了什么、允许了什么，以及服务为什么接受这次请求。

这就是 ArcBlock 用 NFT 管理应用资源的出发点。让资源相关的权利有明确的对象，让对象能够被验证，再让验证结果真正参与服务的执行。一张钱包卡片由此成为用户使用资源的入口，背后每一层仍然各负其责。

参考