这个方法的缺陷在于效率和速度。存储由单个节点哈希哈希作为键的 Trie 数据需要存储大量中介 Trie 节点，这会导致网络需要存储的数据总量翻倍。

这个方法也会让数据检索变得低效。通过该结构查找数据时，你必须从状态根开始遍历 Trie 节点。对于账户Trie 来说，这平均需要 7 次查询，才能获得实际的账户数据。

这个方法确实具有很大的优势。它彻底避开了合约存储失衡问题，因为各个 Trie 节点的哈希值是随机的，因此数据会自动呈随机分布。再进一步来看，如果网络大到足以存储完整的 6TB 存档历史，这个网络最终将变成一个归档节点。

这个方法的另一个主要优势是，可以免去对证明的需求。我们直接构建 Trie 和所有中间节点，因此无需相关的默克尔证明。

目前，我们正在努力确定这个方法是否能够达到性能要求。

叶子节点和证明

另一个方法是将 Trie 的叶子节点组成共享同一条基础路径的连续的块。各个节点会存储 Kademlia DHT 网络中离自己最近的 Trie 路径 “周围” 的所有叶子节点。对于高度平衡的账户 Trie 来说，这个方法非常有吸引力。

通过 Trie 路径处理数据，我们无需遍历 Trie，访问叶子数据的复杂度将下降到 O(1)。如果你还记得的话，GetNodeData 风格的原生方法平均需要 7 次网络往返，才能访问存储在 Trie 叶子节点中的数据。然而，本节所介绍的方法在性能上的优势非常重要，而且是实现网络可用性必不可少的。

这个方法的优势也是有代价的。确保数据是最新的会极大提高复杂性。有很多方法可以做到这点，但是每个方法都有权衡取舍。虽然数据可以就地更新，但是这需要每个节点都进行昂贵的计算。或者，每次挖出一个新的区块后，更新后的证明都会广播至全网节点。这些方法都在计算和带宽之间进行了权衡取舍。但无论是计算还是带宽，这两个在我们眼中都是稀缺资源。

我们的研究结果将指明我们的新网络要采取的发展方向。

本系列的下一篇文章应该是最后一篇介绍性的材料。我们将检视这种新型的客户端实际长什么样，以及我们如何理解它的使用方式。我们将提供概要的路线图，说明我们将如何实现它；以及，我们所做的一切与 “无状态以太坊” 有何关联。

（未完）

原文链接: https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients-part-3/作者: Piper Merriam翻译&校对: 闵敏 & 阿剑