状态可得性：GetNodeData DHT 方案

我的团队正在验证一个?“状态可得性” 问题的解决方案是否可行。

我们的方向大致如下：

我们将这个方案称为方案，因为它与快速同步方案（fast sync）获取状态的方式差不多。

我们选择将数据存储在各个 trie 节点中，因为这样比较简单。

另一种方法是仅存储叶子节点的值和附带的证明。这个方法比较复杂，因为证明需要不断更新。更新证明可以在本地完成，但是需要进行 EVM 计算并广播完整的区块见证消息。EVM 计算成本很高，而完整的区块见证消息很大。

通过将数据存储在各个 trie 节点中，网络节点只需存储这些 trie 数据，并验证新数据的默克尔证明即可。

预期延迟

基于 DiscV5 DHT 的经验，我们预期网络查询时间约为 100 毫秒。

每笔交易的 Trie 节点

Nick Gheorghita 一直在研究常见交易类型所涉及的 trie 节点的数量。在样本数量较少的情况下，他得到的初步结果是：

如果延迟为 100 毫秒，则执行和需要的时间上限分别为 3 秒和 5 秒。我们还可以通过一些基础的优化（如同时查找交易的发送方和接收方）来降低延迟。

我们正在进行更深入的实验，来测量大型主网交易区块的延迟情况。

垃圾回收和冷状态

Brian Cloutier 已经对冷状态访问模式进行了一些调查。

关于冷状态的定义，请参见这张术语表。

（冷状态：指的是在较长一段时间内无人接触（读取或修改）的那部分状态。）

Brian 的发现是，大多数区块都会触及之前 100 万个区块都没有触及的状态（关于这一发现，Brian 可以给出详细论证）。

这就涉及到垃圾回收。

重复数据删除和垃圾收集

存储 trie 相同的两个合约拥有同样的 trie 节点。

同样地，余额、nonce、代码和状态相同的两个账户的账户数据也存储在同样的叶节点上。如果我们使用节点哈希作为键来存储节点，必须通过引用计数（reference counting）来实现垃圾收集，否则就无法知道从一个 trie 中移除的节点有没有在另一个 trie 中使用。

一种解决方法是，将节点在 trie 中的位置及其节点哈希作为键。这样可以使用排除证明来删除节点，但是会因为需要存储重复数据而造成额外的成本。

一个待解决问题是，这会在多大程度上提高存储需求。

归档 vs 垃圾收集

我们需要想清楚如何实现垃圾回收，或者说，确认网络是否可以成为归档节点。

解决垃圾回收问题的方案：

数据入站

我们需要将新创建的 trie 数据推送到网络中。网络中的节点预期会存储所有区块头的最新快照，从而将证明与最新状态根锚定。

待解决问题有：

原文链接:

https://ethresear.ch/t/state-availability-getnodedata-dht-approach-dev-update/8657

作者:Piper Merriam

翻译&校对:?闵敏 &?阿剑