数据瀑布流

​

背景

作为一个具备高吞吐量并频繁出块的区块链,Monad 会产生大量数据 — 既包括交易数据(区块、交易、收据、日志和跟踪),也包括状态数据(每个区块结束时的完整状态树)。 全节点和验证者会将两类数据尽可能多地存储在 MonadDB 中,当存储容量达到 80% 时会覆盖最旧的数据。如果 RPC 调用请求的数据早于本地可用的数据,节点必须引用外部数据源。 对于交易数据,瀑布流为:

1. 链状态缓冲区(内存缓存)
2. MonadDb
3. 归档服务器(如已配置)
4. 对象存储(如已配置)

​

MonadDB

MonadDB(也称为 TrieDB)是每个全节点和验证者本地运行的状态数据库。它维护最新的状态树,以及对应的交易数据。 当 MonadDB 的存储容量达到 80% 时,节点开始覆盖最旧的数据。由于该机制,以及频繁出块和高链吞吐量,大多数 MonadDB 实例并不会存储完整的区块链历史。

​

归档服务器(MongoDB)

归档服务器是一个独立的服务器,它将历史交易数据存储在 MongoDB 中。请注意,归档服务器不存储状态数据 — 相关讨论请参阅此处。 归档服务器由一个运行额外进程(称为 Archive Writer)的普通全节点向其推送数据。

Monad 归档服务器架构

多个全节点和验证者可以指向同一个归档服务器。 有关运行归档服务器的说明,请参阅运行归档服务器。 归档服务器存储以下类型的数据:

• 区块
• 交易
• 收据
• 日志
• 跟踪

注意:我们称其为”归档服务器”而非”归档节点”,以减少混淆。归档服务器通常并不承载 Monad 全节点(共识和执行)。

​

对象存储

归档数据也可以存储在对象存储服务中(例如 AWS S3)。 虽然出于性能与查询效率的考虑更倾向于使用 MongoDB,但对于偏好异地或基于云的数据保留方案的用户,对象存储也是一个可行的备选方案。 与 ArchiveDB 类似,对象存储也可以作为历史数据的来源在 RPC 客户端中进行配置。 对象存储保存以下类型的数据:

• 区块
• 交易
• 收据
• 日志
• 跟踪