Appearance
24 · 存储与数据
LESSON 24 / 35 · 数据层
区块链的核心设计目标是共识与执行，不是把图片、视频和代码廉价地塞进每一个节点。Web3 数据层需要同时回答两个问题：数据放在哪里，以及数据如何被找到、验证和使用。
本页保留学习台线性笔记的两条主线：24.1 去中心化存储，24.2 索引与数据基础设施。存储解决“保留”，索引解决“可用”；两者都不能自动消除中心化、数据来源和合规风险。
学习目标
读完本节，你应能：
- 解释为什么大文件通常不直接放在区块链上。
- 区分位置寻址与内容寻址，并说明 CID 的作用边界。
- 比较 IPFS、Filecoin、Arweave、Storj 和 Sia 的设计取向。
- 说明 The Graph、统一 API、分析平台、后端中间件和 RPC 分别解决什么问题。
- 识别 NFT 元数据失效、中心化服务故障和“永久保存”承诺中的风险。
课程正文
24.1 去中心化存储：数据放在哪里
24.1.1 为什么链上存储昂贵
区块链需要让参与者对共享状态和规则达成一致。全节点通常要复制、验证并保存共识所需的数据，因此区块空间适合记录交易、状态变化和证明，不适合承载大量图片、视频或其他大文件。
NFT 是一个容易理解的例子：链上可以记录所有权和 metadata 引用，图片或其他内容则放在链下。如果内容服务器下线、域名失效或元数据被替换，链上的所有权记录可能仍然存在，但展示内容已经无法获得或与最初看到的内容不同。
**数据可用性（Data Availability，DA）**关注交易数据能否被参与者获得、验证和重建；去中心化存储更多承担一般文件的保存。两者有关，但不能互相替代。
24.1.2 IPFS：内容寻址
传统 URL 是位置寻址：它告诉客户端“去某个位置取文件”。IPFS 使用内容寻址：CID（Content Identifier，内容标识符）由内容生成，可以被理解为文件内容的指纹。
因此：
- 内容发生变化时，CID 通常也会变化；
- 读取者可以检查拿到的内容是否与引用一致；
- 多个节点可以提供同一内容，降低对单一服务器的依赖；
- IPFS 解决的是“如何找到和验证内容”，不是“谁负责长期保存”。
如果没有持续 Pin（固定保存）或其他存储机制，文件仍然可能因为没有节点继续提供而难以取得。多节点保存可以降低单点失效，但不等于永久可得。
24.1.3 Filecoin：有经济激励的存储市场
Filecoin 把存储客户与存储提供者放进市场化合约关系中，客户支付 FIL 购买空间，提供者用证明机制说明自己保存了约定的数据：
- PoRep（Proof of Replication，复制证明）：证明提供者保存了独立的副本；
- PoSt（Proof of Spacetime，时空证明）：证明在约定期间持续保存；
- 抵押和惩罚机制把“持续保存”转化为经济责任。
它的价值在于为持久化提供激励，但速度、读取体验、开发体验和运营复杂度仍要与成熟云服务比较，不能只看去中心化标签。
24.1.4 Arweave、Storj、Sia：不同的取舍
| 网络或协议 | 主要取向 | 理解重点 |
|---|---|---|
| IPFS | 内容寻址 | 找到内容、校验内容，但不自动保证长期保存 |
| Filecoin | 存储市场 | 用合约、证明和 FIL 激励持续保存 |
| Arweave | 长期保存 | 用一次付费、Endowment、Blockweave 和 Permaweb 表达长期保存目标 |
| Storj | 去中心化云存储 | 加密分片、多节点容错和 S3 兼容，偏易用性 |
| Sia | 点对点存储市场 | 通过存储合约和价格机制提供空间，具体产品状态需单独核验 |
“永久”是经济模型、网络参与和成本假设下的长期目标，不是物理意义上的绝对保证。具体产品的价格、节点规模、支持链和服务状态都可能变化。
24.1.5 共同矛盾：去中心化与可用性
去中心化存储都要处理一组互相拉扯的问题：
- 保存责任越分散，读取路径可能越复杂；
- 更强的内容持久性，不一定带来更快的读取速度；
- 更开放的内容传播，不自动解决非法内容、删除请求和版权争议；
- NFT 项目即使使用了 IPFS，也可能仍依赖中心化 Pin 服务、网关、域名或元数据生成器。
所以判断一套存储方案时，不能只问“是不是去中心化”，还要问：谁保存、保存多久、如何恢复、谁提供网关、内容变更如何被发现、失效时谁负责。
24.2 索引与数据基础设施：数据怎么找
24.2.1 原始链上数据的查询困境
链上数据按区块和交易顺序增长，适合验证，却不适合直接回答：
- 某个地址在一段时间内和哪些协议交互？
- 某个 Token 的持有人变化是什么？
- 一个协议的事件按用户、时间和类别聚合后如何展示？
如果每次查询都从节点扫描海量区块和日志，前端很难获得稳定响应。因此，应用需要索引层把原始数据整理成更适合查询的结构。
24.2.2 The Graph：把事件变成可查询数据
The Graph 的常见工作方式是用 Subgraph 描述要关注的事件、实体和关系，再通过 GraphQL 提供查询接口。生态中的角色包括：
- Indexer：运行节点和索引服务，处理查询；
- Curator：发现并支持有价值的 Subgraph；
- Delegator：把 GRT 委托给 Indexer，参与网络激励关系。
索引层提高了可用性，但使用者仍要核对数据覆盖范围、更新延迟、链重组处理、字段定义和数据来源。一个查询结果很方便，不代表它自动就是完整或正确的事实。
24.2.3 工具定位不是同一回事
| 工具类型 | 代表性工具 | 主要解决的问题 |
|---|---|---|
| 协议化索引 | The Graph | 按 Subgraph 结构化事件和实体，提供查询 |
| 统一多链 API | Covalent 等 | 用统一接口降低多链数据接入成本 |
| 链上分析 | Dune 等 | 用 SQL、Dashboard 和公开研究观察数据 |
| 后端中间件 | Moralis 等 | 封装钱包、事件、Token 和 NFT 数据能力 |
| RPC / 节点接入 | Infura、Alchemy 等 | 让应用读取链、发送请求和订阅事件 |
这些工具可以组合使用，但它们的责任边界不同。分析平台的图表、索引服务的字段、RPC 的响应和应用自己的缓存，不能被混成同一个“链上事实来源”。
24.2.4 中心化依赖与生态级故障
中心化 RPC、托管索引、统一 API 和单一网关降低了开发门槛，也会增加依赖：
- 服务宕机或限流，应用可能无法读取数据；
- 不同服务的索引延迟和字段定义可能不同；
- 供应商返回的数据可能被缓存、过滤或按配额限制；
- 某个常用服务出现故障时，影响可能扩散到多个应用。
更成熟的系统会考虑备用 RPC、多个数据源、结果校验、缓存失效和降级体验，而不是把一个 API 当作永远可靠的水管。
概念结构
text
Web3 数据层
├─ 存储：数据放哪里？
│ ├─ 链上：共识强、复制贵，不适合大文件
│ ├─ IPFS：内容寻址 CID，找到内容但不保证持久保存
│ ├─ Filecoin：存储市场 + PoRep/PoSt + FIL 激励
│ ├─ Arweave：Endowment + Blockweave + Permaweb
│ ├─ Storj：加密分片 + S3 兼容
│ └─ Sia：点对点存储合约
│ └─ 共同矛盾：去中心化 / 持久性 ↔ 速度 / 易用 / 合规
└─ 索引：数据怎么找？
├─ 原始链上数据：线性、完整、查询不友好
├─ The Graph：Subgraph + GraphQL
│ └─ Indexer / Curator / Delegator + GRT
├─ Covalent：统一多链 API
├─ Dune：SQL + Dashboard + 研究
├─ Moralis：DApp 后端中间件
└─ Infura / Alchemy：RPC 与节点接入
└─ 中心化服务故障 = 生态级单点风险理解重点是：存储解决“保留”，索引解决“可用”。 数据层的每一段都要问“谁持有、如何验证、谁负责持续可得、失效时如何恢复”。
数据基础设施的职业视角
数据基础设施像给“安全但黑暗的链上宝库”安装灯光、地图和检索系统。后端、数据工程和分析经验可以迁移到这个方向：你需要理解数据源、事件模型、索引延迟、查询成本、服务降级和结果解释。
“岗位需求增长”“高薪”或“十亿用户级基础设施”等表达属于课程材料中的判断或愿景，不是当前市场结论。真正评估岗位时，应查看最新职位描述、团队交付物和公开作品。
可验证问题
- 为什么 CID 能帮助验证内容，却不能保证文件一直有人保存？
- NFT 所有权在链上时，图片或 metadata 为什么仍可能失效？
- Filecoin 的证明机制解决了哪类保存责任？
- The Graph 的 Subgraph 与 RPC 节点分别解决什么问题？
- 统一 API 让开发更方便时，新增了哪些服务依赖？
- 一个数据 Dashboard 的结果，如何回到原始事件或多个独立来源复核？
练习与复盘
选择一个公开 DApp 的数据页面，只做资料分析，不进行资产交互。画出它从链上事件到用户界面的数据路径，标记：
- 数据产生在哪里；
- 文件或 metadata 如何保存；
- 链上引用如何被读取；
- 哪一层负责索引；
- 哪个服务提供 RPC 或网关；
- 哪个环节失效时，用户会看到什么。
最后写下：“保留”与“可用”为什么必须分开评估？
官方资料入口
来源与时效提醒
本页公开整理自课程 24 的 preview、线性笔记和 mindmap，并吸收了课程材料中的截图补充。存储价格、节点规模、服务覆盖、查询量、项目支持链、长期保存和永久性承诺都可能变化；涉及具体项目或服务时，应核对当前官方技术文档、服务状态和独立数据来源。
本页用于数据基础设施学习，不构成对任何存储、索引、RPC 或资产项目的推荐。