作者：PaperMoon 团队
2015 年 Juan Benet 提出 IPFS（InterPlanetary File System，星际文件系统）时，用的是一个相当浪漫的命题：“让信息不再依附于某一台服务器”。Web2 的文件通过location（在哪台机器上）来寻址，IPFS 通过content hash（内容本身的指纹）来寻址。只要内容还在网络中某处存在，它就永远可以被找到。
十年过去了，IPFS 确实已经成为 Web3 开发的默认拼图之一，几乎每一个 NFT 项目、每一个去中心化前端、每一个链上内容协议，都会在某个环节用到它。但几乎每一个 Web3 开发者也都用过 Pinata。
Pinata 是一家专门做 IPFS “pinning” 的中心化服务商。你在 IPFS 上发了一张图，如果没有人"pin"（钉住）它，这张图很可能几天后就在网络里消失了，因为 IPFS 默认节点有权随时回收自己的存储。去中心化的内容寻址加上完全自愿的存储经济，结果就是数据在理论上永不丢失，在实践中却随时可能消失。
于是十年来，大多数 Web3 项目用的都是这样一个变形 IPFS，内容寻址是去中心化的，但数据持久化，其实是靠一两家中心化公司兜底的。
2026 年，Polkadot 上线的Bulletin Chain给了这个老问题一个新答案：把 IPFS 塞进一条链，让"谁来存、存多久、凭什么存"这三件事全部变成链上可验证的参数。这不是又一个 IPFS 前端，也不是和 Filecoin、Arweave 的正面竞争——它的定位更锋利，是 Polkadot 身份基础设施的专用存储底座。
这篇文章想聊清楚三件事：IPFS 十年没解决的结构性问题是什么；Bulletin Chain 到底怎么把 IPFS “装进链里”；以及为什么这条链恰恰是 Polkadot 身份基础设施（DID + Proof of Personhood）的关键一块拼图。
一、IPFS 的十年尴尬：去中心化寻址，中心化持久
要看懂 Bulletin Chain，先得看懂 IPFS 一直没能靠自己解决的那个结构性问题。
IPFS 的技术设计其实非常优雅。它把网络上的任意一块内容——文本、图片、视频——哈希成一个叫CID（Content Identifier）的字符串，任何人只要持有这个 CID，就能向 IPFS 网络请求这块内容，而不用关心它具体存在哪台机器上。这种"内容即地址"的范式，绕开了 HTTP 那种"必须知道服务器在哪"的旧模式。
但它留了一个致命的开放题没解：凭什么让某个节点愿意长期为你存储这份内容？
IPFS 本身没有给出答案。它的协议层只定义了"如何发现和传输内容"，没有定义"谁有义务保存内容"。默认情况下，每个节点只保存自己下载过、并且没过期的数据，节点可以随时清理本地缓存。这就导致了一个很戏剧性的结果：只要没人"钉住"你的数据，它在 IPFS 网络里的生存时间，可能比一条微信朋友圈还短。
过去十年，这个问题催生了两种主流解决思路：
路线一：中心化 pinning 服务商。代表是 Pinata、Infura、Cloudflare IPFS。它们的本质是"我替你付钱在我的服务器上保留一份"。方便、便宜、开发体验好——但 Web3 项目用了它，等于把"永不丢失"的承诺压在了一家公司的商业续航上。
路线二：专门的去中心化存储协议。代表是Filecoin（在 IPFS 之上加一套代币激励和存储证明）和Arweave（用一次性付费买"永久存储"）。它们都在尝试用原生代币激励来取代中心化 pinning。但这两条路线都偏向"长期、大容量、档案级"的场景，对于"只需要两周、一周甚至一天"的数据，成本效率并不理想。
Bulletin Chain 的切入点恰恰就在这两条路线都没覆盖的灰色地带——短期的、可过期的、和身份强相关的链上数据。
二、Bulletin Chain 做了什么：把 IPFS 的经济缺口嵌进链里
Bulletin Chain 是 Polkadot 生态里的一条系统链（system chain），但和通常意义上的业务链不同，它的职责极其单一——只做一件事：存储有时效性的数据。
它的设计哲学可以用一句话概括：把 IPFS 作为"数据传输层"，把链作为"经济激励层"，把 TTL（生存时间）变成区块高度上的一个硬编码参数。
具体怎么做到的？几个关键设计：
数据走链上交易进入，但物理存储走 IPFS。开发者通过transactionStorage.store这个 extrinsic 把数据写上链，链会给数据生成一个可查询的索引；底层存储则通过 IPFS 的 Bitswap 协议在节点之间传输和缓存。链提供"这份数据真实存在过"的共识；IPFS 提供"怎么把它传给你"的效率。
每条数据有固定的生命周期。按当前设计，数据写入后大约保留两周（约 201,600 个区块 × 6 秒），到期后自动从链上移除——节点不再有义务保留。这解决了 IPFS 最核心的经济题——"存多久"这件事第一次变成了一个确定性参数，而不是开发者跟 pinning 服务商讨价还价的结果。
节点即 IPFS 服务器。Bulletin Chain 的每一个验证人节点同时也是一个标准的 IPFS 节点，会把链上数据通过 Kademlia DHT 发布到公共 IPFS 网络中。这意味着外部任何 IPFS 客户端——包括完全不了解 Polkadot 的那种——都可以用标准 IPFS 方式读到 Bulletin Chain 上的数据。对现有的 Web3 前端来说，这是一种"无痛迁移"的兼容路径。
网络参数为 IPFS 查询做了针对性优化。比如把底层 libp2p 的空闲连接超时从默认的 10 秒拉长到 1 小时——这是一个很小但很懂场景的细节：IPFS 客户端发起的查询往往是稀疏而长时间的，短超时会把它们挤掉。
如果你愿意用一句直白的话总结——Bulletin Chain 做的，就是把 IPFS 这十年最薄弱的经济层补上了。它不是在重新发明存储协议，而是给 IPFS 装了一个它本该有的"链上结算机制"。
三、为什么偏偏是"两周"：身份数据的生命周期
看到这里你可能会问：为什么 Bulletin Chain 不做"永久存储"，也不做"一小时就删"，偏偏选了两周这样一个不上不下的数字？
答案要回到这条链最核心的服务对象——身份基础设施。
Polkadot 过去一年在身份这一层动作很密集：DID（Decentralized Identifiers，去中心化身份标识）、Proof of Personhood（人格证明）、DotID（新身份注册服务）、以及 OmniAvatar 这类链上身份层项目。这些系统共同构成了 Polkadot 正在搭的"身份底座"。而身份数据和其他数据有一个非常特殊的属性——它需要被验证，但不需要被永久保留。
举几个具体的场景你会理解：
- 人格证明的挑战-应答数据：用户需要在某个验证会话里提交一段语音、一张照片或一个签名挑战。这些数据必须在验证期间被全网验证人可访问、可审计；但验证完成后，它们就变成了一段隐私风险极高的冗余信息，继续留在链上是负担而非价值。
- 一次性凭证（one-time credentials）：比如你用身份证明领取一个 DAO 空投。凭证需要在分发期内可用，发完就应该过期作废。
- 临时 KYC 证据：某些合规场景需要证明"这个用户通过了 KYC"，但具体的 KYC 原始材料没必要永久上链。
传统的做法是把这些数据扔到中心化服务器或者 Pinata 上，然后靠"我们承诺会删"来安慰用户。这个承诺的可验证性是零。Bulletin Chain 把"到期必删"从一个承诺，变成了一个协议层的硬性保证——任何人都可以通过跑节点亲自验证这件事。
两周这个窗口是一个经过权衡的折中值：足够让最复杂的身份验证流程（多方交叉验证、争议期、数据比对）完成，也足够短，保证不会变成又一个"数据一旦上链就永恒"的系统。
换句话说——Bulletin Chain 不是"一条普通的 IPFS 链"，它是 Polkadot 身份基础设施专门需要的那种"可审计、可过期、可公开发现"的存储层。
四、和 Arweave、Filecoin 的关系：不是竞争，是分工
讨论一个新的存储方案，绕不开一个问题——它和现有的去中心化存储明星有什么不同？
简单把三者放一起比较：
- Arweave的定位是永久存储。一次性付费，存完给你一个不会过期的地址。适合档案、历史记录、NFT 元数据这种"刻上石头就别动"的场景。但它不适合身份数据，因为"永远不删"本身就是身份数据的反面。
- Filecoin的定位是可协商的长期存储。通过"存储矿工"和"存储订单"的市场机制，让需求方和供给方匹配。适合大容量、中长期（月/年级）的冷数据。但它的最小单位和成本结构对"我只要存一张人脸两周"这种需求并不友好。
- Bulletin Chain的定位是短期、确定性、身份优先的临时存储。它用两周这个硬编码 TTL 把自己限制在了一个特定生态位里——不做档案、不做大容量冷存储、不和 Arweave 在"永久"上竞争，而是补上 Web3 存储栈里最缺的那一段——"需要上链但不需要永久"的数据。
这是一个非常健康的生态位选择。过去几年 Web3 存储赛道经常陷入"一个协议想解决所有问题"的陷阱；Bulletin Chain 是少见的、从一开始就说清楚"我不做什么"的项目。
更值得注意的是，它和 Arweave/Filecoin 其实可以协同工作：一条完整的身份流水线，完全可以用 Bulletin Chain 存两周的验证数据，把最终的、脱敏后的身份断言存进 Arweave 做永久备案——两种存储协议各司其职。
五、对开发者意味着什么：重新审视你的 Pinata 账单
最后落到最实际的一个问题——如果你是正在 Polkadot 生态里构建应用的开发者，Bulletin Chain 的上线对你意味着什么？
三个具体动作值得考虑：
第一，重新审视你的 Pinata / 第三方 IPFS 账单。如果你的应用里有短生命周期的数据（用户动态、评论、临时凭证、会话元数据），这些数据其实没必要付费 pinning 在第三方服务器上。迁到 Bulletin Chain 既能省下这笔账单，又能把"去中心化前端"这句营销话说得更硬——因为你真的不再依赖任何单一公司来保存这些数据。
第二，重新思考"哪些数据值得上链"。过去你可能出于成本考虑，把本该上链的内容放到了链下。Bulletin Chain 把"上链但不永久"这个中间选项摆到了桌上。用户的头像、一段自我介绍的语音、一段视频签名——这些过去绝对不敢放到中继链上的富媒体内容，现在可以以非常低的成本在链上短期存在，获得区块链级别的可验证性。
第三，如果你在做身份相关应用，优先考虑它。如果你的产品涉及 DID、PoP、KYC、凭证发放等身份相关环节，Bulletin Chain 是目前 Polkadot 生态里最合适的存储层。它的权限模型（通过 PoP 链的authorize_preimage机制授权数据写入）就是为身份类应用设计的，绕过它去找其他存储方案，大概率要自己重复造一部分轮子。
一个经验法则：如果你问自己"这份数据需不需要被保留两周以上"，答案是"不需要"的那部分，基本都可以迁到 Bulletin Chain。这个边界比过去想得要宽得多。
小结
去中心化这件事最难的，从来不是"在技术上能否去中心化"，而是"在经济上能否可持续地去中心化"。IPFS 十年来给 Web3 留下的最大教训，就是一个协议如果只定义了"怎么传数据"而没定义"谁付钱存数据"，它最终一定会被中心化 pinning 服务收编。
Bulletin Chain 的价值不在于它发明了什么新的存储技术，而在于它把 IPFS 这十年一直缺的那个激励层，用 Polkadot 区块链补上了。更聪明的是，它没有去做一条"全能存储链"，而是瞄准了一个非常具体的生态位——Polkadot 身份基础设施需要的那种"可验证、可过期、可公开发现"的存储层。
对开发者来说，这是 Polkadot 生态里第一次可以真正说出"我们的 dApp 里没有 Pinata"这句话的一条链。对整个 Web3 来说，它可能给出了一个关于"IPFS 到底应该怎么用"的迟到了十年的答案——不是把它当成一个独立协议，而是把它当成一条链的存储后端。
Web3 存储赛道从来不缺宏大叙事——“永远不灭的图书馆”"去中心化版 AWS S3"“人类所有知识的备份”。Bulletin Chain 是一个相反的故事：它承认数据有生命周期，承认去中心化需要代价，承认一个协议不能解决所有问题。这种"小而锋利"的设计哲学，也许比任何宏大叙事，都更像 Web3 真正该走的路。
