内容寻址（Content addressing ）
（Content addressing ）内容寻址是一种在信息系统中组织和定位数据的技术，其中用于定位内容的键派生自内容本身。在本概念指南中，我们将介绍内容寻址的工作原理以及为什么它对NFT很重要。
基本问题
想象一下，一个键值存储具有如下界面：
// This example uses TypeScript to annotate the parameters and return types of our methods.
// We won't do any fancy type manipulation, though, so don't worry if you're not into TypeScript.
type Key = string;
type Value = string;
interface KVStore {
put(key: Key, value: Value): Promise<Void>;
get(key: Key): Promise<Value>;
}
此基本接口对于键值存储非常常见。使用 put，我们可以将任何Value与Key相关联，稍后当我们需要它时，我们可以查找带有 get 的键，并希望取回我们的值。
当您开始使用这样的界面时，最重要的决定之一是key们的使用。如果您正在构建一个控制访问模式的应用程序，则可以使用您喜欢的任何keys并在代码中跟踪它们，或者编写一些规则来制定哪些键应该用于哪种类型的数据。
当彼此没协调一致的各方同时发起存储时候，事情变得更加复杂。对于一个全局密钥空间，要么每个人都需要就相同的规则达成一致，要么空间需要拆分为许多"域"或"命名空间"。
假设我们有一个大型键值存储，由数千甚至数百万人共享，每个存储在密钥空间中都有自己的域。这主要解决了写作问题 - 每个人都可以管理他们的密钥，而无需与其他人协调。
但是，现在不太清楚当我们想要再次get数据时，在哪里查找数据。由于每个域都遵循自己的规则，因此很难知道使用什么key来检索内容。此外，如果不同域之间没有协调，则最终可能会在不同的域中多次存储相同的值，而无法轻松判断出存在不同域的key实际上都指向相同的值。
如果这听起来很熟悉，请考虑在解析链接（如 nftschool.dev/concepts/content-addressing）时会发生什么情况。首先，您的操作系统将查询一个全局共享键值存储，该存储分为多个域：域名系统 （DNS）。DNS 将返回一个 IP 地址，您的网卡可以使用该地址通过网络发送 HTTP 请求，其中此站点的命名约定将键 /concepts/content-addressing 转换为响应负载。
网络基本上是"互联网规模"（internet scale）的定义，所以很明显这个系统运行得很好。那么，问题出在哪里呢？
真正的问题是时间。
地址的两个组件（如 nftschool.dev/concepts/content-addressing）都是可变的，这意味着它们可以随时间而变化。如果我们忘记支付账单，域名可能会过期并被出价最高的人购买。或者，如果我们决定快速轻松地使用我们的网站结构，而忘记添加重定向，则路径/concepts/content-addressing可能会返回404错误，而不是本篇文章的站点了。
在网络的背景下，一切都是可变和动态的，这就是它一直以来的方式。网络从未能保证任何形式的持久性，无论是在内容上还是在内容之间链接的"（meta-structure）元结构"中。结果，链接失效也就见怪不怪了。
但对于一个实际上意味着永久性的数字工件，比如NFT，链接失效则是一个存在性问题。链路损坏会影响NFT，因为大多数NFT实际上只是链接（links）。大多数区块链网络上的数据存储比传统的在线存储系统贵得多。例如，根据2021年5月，直接在以太坊上存储一兆字节数据的成本约为21.5以太币（ETH）。这个gas fee当时，这大约是56，000美元。
为了使代表数字艺术的NFT在财务上实用，艺术品本身需要存储在存储成本可控的"链下"，同时将"链上"存储限制在尽可能少的水平。最简单的方法是仅将链下数据的链接存储在NFT本身内。但是，区块链的持久性仅适用于链上数据。如果您存储的NFT带有后来失效的链接，则即使区块链记录保持不变，NFT的值也会受到损害。
更强的链接（A stronger link）
为了安全地从NFT链接到图像和元数据等链下资产，我们需要能够经受住时间冲击的链接。理想的链接将始终解析为最初在永久区块链记录中引用的同一段内容，并且不会绑定到单个服务器所有者或"域"。
内容寻址为我们提供了所需的链接类型。内容寻址系统的工作方式与我们的键值存储类似，但有一个显著区别：您不再需要选择（key）键。相反，这些键（key）是直接从使用确定性函数存储的值（value）派生的，该确定性函数将始终为相同的内容生成相同的键。
现在，我们之前的界面看起来像这样：
interface ContentStore {
put(value: Value): Promise<Key>;
get(key: Key): Promise<Value>;
}
比起接收一个key和一个value，我们的put方法只接收一个value然后返回一个key给调用方。作为无法选择自己的key的交换，您将获得一些有价值的财产。
首先，我们不再需要通过将key空间拆分为多个域来协调存储的编写方。现在有一个通用的域（domain） - 所有可能值（value）的域。因此如果多个人添加相同的value，则key空间中不会发生冲突。他们每个人都从 put 方法中取回相同的key。
这一变化也使我们的value具有（location independence）位置独立性。在具有多个域的原始键值存储中，我们必须在键内包含域以防止名称冲突。要检索值，您需要知道它属于哪个域，以及该域的键空间段中的特定位置。如果我们在区块链上存储基于位置的密钥，我们检索数据的能力取决于密钥中内置的一个域。即使相同的内容存储在一千个其他域中，如果我们所依赖的内容消失或更改其命名约定，我们的查找也会失败。
如何使用内容寻址
到目前为止，我们一直在抽象地谈论内容寻址，但教程的要点是构建东西！我们如何实际利用内容寻址来制作具有持久链接的NFT？
最简单的方法是使用IPFS，（the InterPlanetary File System）星际文件系统。当您的数据存储在IPFS上时，用户可以从具有副本的任何IPFS节点获取它，这可以使数据传输更加高效并减少任何单个服务器上的负载。当每个用户获取一段数据时，他们会保留一个本地副本，以帮助以后可能请求它的其他用户。
要将 IPFS 用于 NFT，请尝试nft.storage。它使您可以轻松地将数据传输到IPFS上，并提供由分散式支持的长期持久性文件币的存储网络。为了帮助促进NFT生态系统的发展，并保护NFT所代表的文物的新数字共享，nft.storage为公共NFT数据提供免费存储和带宽。可以戳这个链接尝试注册一下（https://nft.storage/login/）
