将这些数字放在一起，我们很容易得出一个结论，这是大多数普通配置计算机将 无法承受的要求！

　　优化

　　为了优化存储成本，我们必须将限制放宽为兼容 EVM 而不是兼容以太坊。即，我们必须构建/运行另一个支持 EVM 的链，而不是高度优化的以太坊客户端。

　　状态存储优化

　　我们提出的第一个优化是使用普通的 KV 而不是 MPT。当 MPT 很大时，MPT 中的所有内部节点可能非常昂贵。而我们的优化将去掉 MPT 中的所有内部节点。假设每个账户的数据大约是 50 字节（20 个地址 + 2 个nonce + 12 个账户 + 其他），我们可以节省下100亿账户的数据为：

• 　　~ 10B * 50 + 100GB（代码）= 600 GB，大约是MPT版本的1/10！

　　虽然使用普通 KV 会带来巨大的好处，但一个主要问题是我们无法在如此短的区块间隔内计算每个区块的状态后哈希，这意味着我们将失去以太坊的以下好处：

• 　　快速同步：下载任何区块的状态并通过重放剩余的区块来快速同步网络

• 　　分叉检测（或拜占庭检测）：来自对等方新创建的区块是否会导致与本地执行区块的状态不同。

　　为了启用快速同步，我们有一个周期性的快照区块（快照间隔 = epoch = 例如，14 周）。一个快照区块包含前状态哈希这一附加信息，即前一个快照区块的后状态哈希（执行交易之后的状态哈希）：

• 　　非快照区块不维护状态哈希，而是具有增量哈希，其中包含该区块的所有交易事务的原始数据库操作（删除、更新）的哈希。这使得分叉检测成为可能！

• 　　我们使用交易前状态哈希来代替以太坊中区块的交易后状态哈希。原因是节点不能立即计算状交易后的状态哈希，但是通过使用交易前状态哈希，节点可以使用整个epoch间隔来计算哈希。例如，假设状态哈希计算每秒处理 10M 的状态数据，那么计算 600 GB 的整个状态将需要 600 GB 10 M ~ 16.67 小时（vs. epoch = 14 周）

　　计算状态前哈希的流程如下：

　　1. 当一个快照区块被接收并最终确定时，它的 KV 状态被快照，并创建一个后台线程来迭代所有 KV 条目（地址 => 帐户）并计算哈希。

　　2. 当下一个快照区块被创建时，计算出的状态前哈希值将存储在该区块中。同样，节点将创建 KV 的另一个快照并在后台计算其哈希。 (责任编辑：admin)