去中心化存储：IPFS、Filecoin 与 Arweave

导语：当"文件在哪台服务器上"这个问题本身失效

传统 Web 用位置寻址（Location Addressing）：https://example.com/a.png 的语义是"去 example.com 这台服务器上取 a.png"。服务器下线、域名易主、路径被改，链接就断了。据互联网档案馆统计，普通网页链接的平均寿命不到三年。

去中心化存储换了个问法：不问"文件在哪"，而问"这段内容的指纹是什么"。**内容寻址（Content Addressing）**让地址由内容本身计算得出，因此内容不变则地址不变、内容一变地址就变。本文拆解 IPFS、Filecoin、Arweave 三条路线各自的机制与代价，并回答"我该把什么数据放上去"。

一句话总结：IPFS 解决"寻址"，Filecoin 解决"谁帮你长期存"，Arweave 解决"存一次永远可读"——三者是分层互补而非互相替代的关系。

1. 内容寻址：一切的起点

1.1 从哈希到 CID

把文件内容做一次密码学哈希，得到的就是它的身份。IPFS 把这个概念包装成 CID（Content Identifier），一个自描述、可多编码的标识符：

# 添加文件，返回 CID
ipfs add hello.txt
# added QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLzEUux8 hello.txt

# 同一内容再次添加，CID 不变
ipfs add hello.txt
# added QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLzEUux8 hello.txt

CID 的结构分两部分：前面的**多编码前缀（multibase/multicodec）**说明用什么哈希算法，后面的摘要才是内容指纹。目前主流是 CIDv1 + base32，因为它大小写不敏感、可安全放进 URL：

CIDv1 结构：
  <multibase><version><multicodec><multihash-type><length><digest>
  b         af       01         70               20       12 20 4c...

1.2 为什么 CID 天然抗篡改

因为 CID 是内容摘要，任何一比特改动都会得到完全不同的 CID。这意味着下载者不需要信任提供者：拿到文件后自己算一遍哈希，与 CID 比对即可。这是去中心化存储的信任根基——它把"信任服务器"替换成"验证数学"。

1.3 Merkle DAG：大文件怎么分块

单文件整体哈希无法支持随机读取与增量传输。IPFS 因此用 Merkle DAG：把文件切成固定大小的块（默认 256 KiB），对每块算哈希，再用一个根节点引用所有子块的哈希。

分块带来的两个直接好处：相同块只存一份（去重）与只改动的块需要重传（增量同步）。这与 Git 的存储模型本质相同，只是 IPFS 面向的是通用文件而非文本 diff。

1.4 与 HTTP 的对比

内容寻址的代价是内容不可变：改一个字就要换一个地址，这给"动态网站"带来额外复杂度（通常用 IPNS 或 ENS 做一层可变指针）。

2. IPFS：寻址层，而非存储层

2.1 DHT 与内容路由

CID 只是地址，谁来提供内容是另一个问题。IPFS 用分布式哈希表（DHT），具体是 Kademlia 变体：每个节点按 XOR 距离维护路由表，查询时逐步逼近离目标 CID 最近的节点。

# 启动节点并查看连接
ipfs daemon &
ipfs swarm peers | head -5

# 提供内容
ipfs add -r ./site
ipfs pin add <CID>

# 通过网关读取（不必本地运行节点）
curl https://ipfs.io/ipfs/<CID>

2.2 常见误解：IPFS 不保证持久

这是实践中最容易踩的坑：ipfs add 只让内容在本机存在，一旦本机 GC 或离线，别人就取不到了。要让内容长期可用，必须：

1. ipfs pin add 把内容钉住，防止被垃圾回收；
2. 有至少一个常在线节点持续提供该内容；
3. 或者用**固定服务（Pinning Service）**代为托管。

2.3 网关模式与生产实践

生产环境很少让终端用户直连 P2P，而是用专用网关做缓存与加速：

# 运行本地网关
ipfs config Addresses.Gateway /ip4/0.0.0.0/tcp/8080

# 通过网关路径读取（Path Gateway）
https://<your-gateway>/ipfs/<CID>/index.html

# 子域名网关（利于浏览器同源与缓存）
https://<CID>.ipfs.<your-domain>/

子域名网关之所以重要，是因为浏览器把 ipfs.io 视为单一源，恶意 HTML 可能读取同源其他内容；子域名隔离把每个 CID 变成独立源。Nginx 侧可用通配符证书 + proxy_pass 实现：

server {
    listen 443 ssl;
    server_name ~^(?<cid>.+)\.ipfs\.example\.com$;
    location / {
        proxy_pass http://127.0.0.1:8080/ipfs/$cid$request_uri;
    }
}

2.4 IPFS Cluster 与多节点固定

单节点 pin 存在单点故障。生产上更稳妥的做法是用 IPFS Cluster 让多个节点对同一批 CID 达成共识并各自 pin：

# 初始化并启动 cluster
ipfs-cluster-service init
ipfs-cluster-service daemon &

# 让整个集群固定一个 CID（默认复制因子 = 全部节点）
ipfs-cluster-ctl pin add <CID>

# 指定复制因子（例如 3 副本）
ipfs-cluster-ctl pin add --replication-min 2 --replication-max 3 <CID>

Cluster 的一致性用 Raft 维护，因此它本身是一个受信联盟而非开放网络——这与 Filecoin 的开放市场是两种不同的信任模型。

3. Filecoin：用密码学证明约束存储服务商

3.1 核心问题：如何证明"真的存了"

如果只靠口头承诺，存储节点完全可以删掉数据照样收钱。Filecoin 的答案是两类可验证证明：

3.2 复制证明 PoRep

PoRep 的关键在于防女巫复制（Sybil Resistance）：节点必须为每一份副本做一次唯一且不可并行的编码计算，因此"声称存了 10 份"就必须真的付出 10 份计算。实现上用 zk-SNARK 把证明压缩成常量大小，链上验证成本与数据量无关。

密封（Sealing）流程：
  1. 原始数据 → 分片为 32 GiB 扇区（Sector）
  2. 计算唯一编码（含节点 ID，防止复制粘贴）
  3. 生成 PoRep 证明并提交上链
  4. 扇区进入 Active 状态，开始 PoSt 计时

3.3 时空证明 PoSt

PoSt 有两类，工程上常组合使用：

• WindowPoSt：每 24 小时对全部扇区提交一次证明，分 48 个窗口错峰；
• WinningPoSt：节点被选为出块者时，需对部分扇区快速证明。

若在期限内未提交 WindowPoSt，扇区会进入故障状态并被罚没质押（Collateral）。这就是"用经济激励 + 密码学证明"替代信任的完整闭环。

3.4 存储交易与检索

# 用 lotus 客户端发起存储交易
lotus client deal <DATA_CID> <MINER_ID> <PRICE> <DURATION_EPOCHS>

# 查询交易状态
lotus client list-deals

# 检索（通过 IPFS 网关或检索市场）
lotus client retrieve <DATA_CID> ./out

需要注意 Filecoin 的存储与检索是两条独立市场：存储交易保证数据在链上被密封保存，但不保证高速检索。要低延迟读取，通常配合 IPFS 网关、CDN 或检索市场（Retrieval Market）解决。这也是为什么很多项目把 Filecoin 当"冷备"，把 IPFS/中心化对象存储当"热层"。

3.5 质押、罚没与扇区生命周期

矿工要参与存储必须提供两类质押：初始质押（Initial Pledge）与锁定奖励（Locked Rewards）。若发生故障，罚没规则大致如下：

因此选择存储矿工不能只看价格，还要看其历史故障率与质押充足度。价格过低的报价往往意味着矿工赌自己不会被抽中证明。

4. Arweave：一次付费，永久存储

4.1 经济模型：永续捐赠（Endowment）

Arweave 的核心主张是一次性付费、永久可读。它的解法是把一次性费用拆成"当下存储成本 + 一笔永续捐赠"，后者投入一个随时间衰减的基金池，用于支付未来矿工的存储报酬。

总费用 = 当前存储成本 + 捐赠(Endowment)
捐赠按年释放，释放速率逐年递减
假设存储硬件成本每年下降约 30%，
则捐赠池的衰减速度可以覆盖无限期的存储需求

这个模型成立的前提是存储成本持续下降。若成本下降停滞，模型会出现缺口——这是 Arweave 最大的理论争议点。

4.2 区块编织（Blockweave）

Arweave 的账本不叫区块链而叫区块编织（Blockweave）：每个区块除了引用前一个区块，还引用一个随机历史区块（Recall Block）。矿工必须先能访问那个历史区块才能出块，这就迫使矿工保留历史数据，而不只是最新状态。

4.3 上传与成本

# 用 arweave CLI 上传
arweave deploy ./file.png --key-file wallet.json

# 或通过 Bundlr（现 Irys）批量打包上传，降低单文件开销
irys upload ./file.png -t arweave -w wallet.json

上传成本按数据量计价，2024 年后约为每 MiB 若干 AR。小文件由于交易开销占比高，通常用**打包（Bundling）**服务合并上链。

5. 三者选型对比

实践建议按数据温度分层：

• 热层：CDN 或对象存储（如 Cloudflare R2 对象存储 ），低延迟、可覆盖写；
• 温层：IPFS + Pinning 或自建网关，做内容寻址与去中心化分发；
• 冷层：Filecoin 做合约期大容量备份，Arweave 做需要"永远可读"的关键档案。

6. 生产环境的坑与对策

6.1 NFT 元数据的"断链"问题

绝大多数 NFT 的 tokenURI 指向 IPFS CID，但项目方一旦停止 pin，图片就取不到了。这类"rug pull 式断链"在熊市屡见不鲜。对策是元数据上链 + 内容多源固定，并优先选择 Arweave 或带 SLA 的固定服务。相关标准与字段约定可参考NFT 标准与数字资产 。

6.2 大文件与去重陷阱

内容寻址的去重是优点也是风险：如果多份文件共享同一块，只删一份并不会真正释放空间；反过来，上传者可能通过共享块推断出他人文件内容。敏感数据必须在上传前加密（如先做客户端 AES 加密再 ipfs add）。

6.3 与数据可用性层的关系

Rollup 需要把交易数据发布到某个数据可用性层（DA Layer），其技术诉求（可验证、抗扣留、低成本）与去中心化存储高度重叠，但目标不同：DA 层追求短期但强保证的可用性，存储网络追求长期保存。两者的机制对比可参考模块化区块链与数据可用性层 。

6.4 成本估算的粗略口径

选型时先算清三个量：数据量、保留期、检索频率。以 1 TiB 数据为例：

经验法则：读多写少放热层，写一次读极少放冷层。若数据需要"几十年后还能读"且预算可预付，Arweave 最省心；若能接受按年续约，Filecoin 单位成本更低。

小结

去中心化存储的本质是用密码学证明替代对服务商的信任：CID 让你能验证内容未被篡改，PoRep/PoSt 让存储节点无法偷懒，Blockweave 让矿工必须保存历史。但三者都不解决"谁来付费保证在线"这个根本问题——IPFS 需要 pin，Filecoin 需要合约，Arweave 需要赌成本下降。

落地时不要追求"全去中心化"，而应按数据温度分层：热数据用中心化对象存储保延迟，温数据用 IPFS 做寻址，冷数据用 Filecoin 或 Arweave 保永久。把"存储"与"寻址"、“证明"与"检索"分开看，选型就不会被营销话术带偏。若需要理解分布式文件系统的通用原理（副本、纠删码、一致性哈希），可对照 分布式文件存储 一文补齐基础。

最后提醒一点：去中心化存储改变的是信任模型，不改变运维责任。你依然要监控副本数、要备份钱包私钥、要为固定服务付费——只是这些责任从"信任某台服务器"变成了"信任某套数学与经济机制”。