Polkadot Bulletin Chain 解析：用“临时存储“破解区块链状态膨胀困局

devmoon

122人浏览 · 2026-03-25 16:17:48

devmoon · 2026-03-25 16:17:48 发布

作者：PaperMoon团队

区块链有一个很少被公开讨论但所有开发者都绕不开的问题：你写进链上的数据，真的都需要永远存在吗？

答案显然是否定的。

一条社交媒体动态、一张用户上传的头像、一次 DeFi 交易的临时状态——这些数据需要在链上存在足够长的时间供验证和使用，但让它们占据链上存储直到区块链消亡的那一天，既不经济也不必要。然而传统区块链的设计前提就是"一切皆永久"——数据一旦写入，便成为全网每一个全节点必须永远维护的负担。

这就是状态膨胀（state bloat）问题的核心：区块链越成功、使用越频繁，链上状态就越庞大，运行全节点的成本越高，参与验证的门槛越高，去中心化程度反而在下降。以太坊上大量部署后再无人访问的**智能合约**——部署在区块链上的自动执行程序——永远占据着链上状态，就是这个问题最直观的体现。

Parity Technologies 给出的答案是 Bulletin Chain：一条专为 Polkadot 生态设计的临时存储链。

Bulletin Chain 是什么？

Bulletin Chain 是 Polkadot 生态中一条定制化的系统链，核心功能只有一个：存储有时效性的数据。

数据通过 `transactionStorage.store` 外部调用（extrinsic）写入链上，在链上保留大约**两周**（201,600 个区块，每个区块 6 秒），供任何人查询、验证和使用。两周后，数据自动从链上移除，节点不再需要为这些历史数据买单。

这不是数据的"丢失"，而是一种有意设计的生命周期管理——数据在它被需要的时候可用，在它不再被需要的时候消失。

技术架构一览

Bulletin Chain 的技术栈并不复杂，但每个选择都有明确的目的：

- **共识机制**：BaBE（出块）+ GRANDPA（最终性确认），与 Polkadot 中继链一致
- **存储后端**：集成 IPFS 协议，节点同时充当 IPFS 服务器，通过 Bitswap 协议向外部 IPFS 客户端提供数据
- **DHT 发现**：通过 Kademlia DHT 发布内容提供者记录，让外部应用可以通过标准 IPFS 方式发现和获取链上数据
- **网络层**：基于 litep2p（**Substrate** 默认网络后端），将空闲连接超时从默认的 10 秒延长到 1 小时，以适应 IPFS 客户端的查询模式

简单来说：Bulletin Chain 既是一条区块链，也是一个去中心化的 IPFS 节点网络。数据既可以通过链上交易索引查询，也可以通过 IPFS 哈希直接获取。

存储容量

按照设计规格，Bulletin Chain 的理论最大存储容量为：

- 每个区块可容纳 8–10 MiB 数据
- 两周窗口内理论总容量约 1,575–1,968 GiB

当然，实际使用量会远低于理论上限。但这个容量对于富媒体应用来说已经足够宽裕——这也是 Bulletin Chain 存在的意义：让开发者可以在链上处理图片、视频元数据、用户动态等此前根本不敢放到链上的内容。

为什么 Polkadot 需要一条"短命"的链？

这个问题需要从 Polkadot 的多链架构说起。

在 Polkadot 的设计中，每条平行链（parachain）维护自己的状态，中继链（relay chain）只存储各平行链的状态根哈希。这意味着单条平行链的状态膨胀不会直接拖累整个网络——但这不意味着问题不存在，它只是被隔离到了每条链内部。

Bulletin Chain 的处理方式更加彻底：它从设计之初就接受数据的有限生命周期。与其让开发者在"上链"和"不上链"之间做痛苦的取舍，不如提供一个中间地带——**数据上链，但不永久**。

这种设计解锁了一类全新的应用场景：

- **全链上社交应用**：用户发布的动态、评论可以上链验证，两周后自动清除，不会让链越来越臃肿
- **富媒体 DApp**：图片、音频、视频元数据可以临时上链，提供与传统 App 相当的用户体验
- **临时凭证与验证**：身份验证数据只需在验证窗口内可用，之后无需保留
- **链上数据可用性层**：为 Rollup 或其他需要短期数据可用性保证的方案提供基础设施

与 Proof of Personhood 的深度集成

Bulletin Chain 目前最重要的实际用例是与 Polkadot 的**人格证明**（Proof of Personhood）链深度集成。

两条链之间建立了直接桥接：人格证明链可以通过 `transactionStorage.authorize_preimage` 调用来授权数据的预映像存储，允许经过身份验证的账户在 Bulletin Chain 上存储数据。这种授权机制确保了不是任何人都能随意向链上写入数据——要么签名者账户被授权，要么数据的预映像被预先批准。

这个设计的意义在于：人格证明系统需要存储用户的身份验证数据，但这些数据既敏感又有时效性。Bulletin Chain 提供了一个"用完即焚"的存储层，验证数据在需要时可用，过期后自动消失，不会在链上留下隐私隐患。

从 Bulletin Chain 到 JAM：更远的路线图

Parity 在 2025 年底将 Bulletin Chain 从原型推进到了生产环境，目前已被多个产品团队作为默认存储方案使用，替代了对中心化 IPFS Pinning 服务的依赖。

但 Bulletin Chain 并非终局方案。根据 Parity 的路线图，Bulletin Chain 的功能预计将在 2026 年进一步扩展，最终由 **JAM**（Join-Accumulate Machine）——Polkadot 下一代核心协议，旨在进一步提升网络性能与灵活性——的数据湖（Data Lake）直接承接。

换句话说，Bulletin Chain 是 Polkadot 在临时数据存储领域的"先行者"，验证了这条路径的可行性，而 JAM 的数据湖将是这一理念的最终形态——更大规模、更深层集成、更灵活的数据生命周期管理。