在前几期文章中，我们由浅入深地介绍了 GHAST 共识协议的设计思想。
但，对于一个公有链来说，保证所有节点对交易排序达成共识只能算是迈出了第一步，距离成功还相当遥远。
之后的几期文章将着重讨论有了一个好的共识协议之后，在提高 TPS 的这条道路上还有哪些问题需要解决。
社区朋友们经常提到这样一个问题：Conflux 把 TPS 大幅度提高以后，数据怎么存？
以现在 Conflux 的网络参数为例，平均每秒生成 4 个区块，每个区块大小约为 300KB。那么在满载的情况下，一秒的吞吐量为 1.2MB，一天约 100GB，每年新增的交易历史数据可达 30TB。
在企业级和工业级的应用中存储 30TB 数据并不是一件特别困难的事情，按照现在的市场价 3 块 10TB 硬盘只需 5000-7000 元。但是不同于 Hashgraph 那样的“企业级联盟链”，Conflux 要最大程度地保证去中心化，因此就必须尽可能地降低参与共识的成本。
为了降低参与共识的门槛，Conflux在开发时把全节点的最低运行配置限制在 2019 年主流家用台式机的水平。包括同步交易、执行交易、验证交易、维护树图结构等操作在内，全节点消耗的CPU、硬盘、内存等计算资源受到了非常严格的控制。因此，通过要求矿工增加新硬盘以存储新增数据的“简单解决方案”从一开始就不在考虑范围之内。
高吞吐量还带来另外一个问题：新节点加入的时候，需要花多长时间来同步已有的数据？
为了解决高吞吐量带来的存储和同步的问题，Conflux 采用了如下方案：对于足够老的区块，全节点只需存储区块头而不用存储区块内的具体交易信息。Conflux 未来会提供“档案节点”（Archive Node）的代码，允许任何人运行一个档案节点，存储所有历史数据。
上述设计可能与大家直觉中认识的区块链有些出入，所以下面我们解释一下，为什么这样的设计没有丢失区块链基本的属性。
让我们一起来看一下 Conflux的区块头里都包含哪些信息：
首先，区块头包含所有区块引用的信息。这意味着 Conflux 的树图结构是在每个全节点都完整保存的。
其次，工作量证明要求每个区块头的哈希值足够小，需要有足够多的“前导0”。即使不保存区块内的交易，仅从区块头也足以判断区块生成时是否付出了足够的工作量。也就是说，区块头中还保留了工作量证明的信息。
因此，区块之间的结构和区块头中的信息，都是以去中心化和不可篡改的方式，在每一个全节点那里被存下来的。攻击者如果想改写历史，就必须付出与“历史累计工作量”相当的代价。
除了树图结构和工作量证明外，区块头还包含有这个区块交易和交易执行结果的默克尔树根（Merkle Root）。这里的默克尔树根实际上就是一个代表了当前的数据内容的哈希值。Conflux 的每个区块头包含 3 个这样哈希值：
交易哈希根 (Transaction Root)：对应于区块内所有交易内容。
状态哈希根 (State Root)：对应于交易执行后的“世界状态”，包括每个账户地址的余额和所有智能合约的状态。（由于采用了延迟执行的策略，在 Conflux 里区块头里的状态根对应的是执行了之前区块里的交易后的状态，该区块内的交易将延迟到更晚的区块才会执行。）
交易收据哈希根 (Receipt Root)：对应于合约执行过程中产生的收据。包括执行是否成功，执行过程中是否触发了转账等。
如果某个用户想要获得较早的交易数据和执行结果，则他可以从“档案节点”那里查询，并通过比对区块头中的哈希值来判断档案节点提供的数据是否正确。（这里每一个哈希值本质上都是一个 Merkle Tree 的 Root Hash，所以档案节点只需提供被查询数据的默克尔证明 Merkle Proof 就可以了，而不用传输整个区块。）由于哈希函数可以抗碰撞的特点，档案节点无法为一笔不存在的交易伪造一个能通过检测的证明。
对于档案节点来说，唯一的攻击方式是拒绝提供交易数据，由此带来的后果至多也只是影响到历史交易的可查询性。即使没有任何一个诚实的节点保存较早的历史交易，那些交易也只会被遗忘而不会被篡改，交易的不可篡改性依然可以得到保证。
由于档案节点的“作恶”方式非常有限，所以档案节点本身对去中心化要求也没那么高，完全可以由 Conflux 基金会和社区共同维护若干个档案节点。
实际上，因为运行档案节点并不需要任何审核或许可，所以大用户也可以根据业务需要自己运行或委托他人运行档案节点，以此确保查询历史交易数据的性能和可靠性。
对于在 Conflux 上运行的 DApp 来说，如果其本身需要保存和随时访问的数据量不是很大 —— 比如说每年新增 1MB 数据，则这些业务数据完全可以存储在智能合约的内部状态里。存储于合约内部状态的数据会作为世界状态的一部分被每一个全节点保存和同步，无需自己运行档案节点也可以保证最高程度的可用性。
