钱包访问状态的主要方式是通过以下 JSON-RPC 方法：

eth_getBalance 和 eth_getTransactionCount 仅从主要账户 Trie 中读取值。因此，可以通过调用该方法获得Trie 上现有的 1 亿多个账户中任意一个地址的情况。

eth_call 和 eth_estimateGas 都涉及实际的 EVM 执行。EVM 执行可以从 1 亿多个账户中的任意一个及其底层合约存储 Trie 中读取数据。

我们发现，钱包只需读取少量数据，而且读取的需要是随机的。这在根本上与同步完整状态不同，因此这两个用例不太可能通过同一个解决方案来解决。

我们需要解决的问题

新的网络需要解决当前网络存在的一些缺陷。

如何分担并降低存储压力

这个网络上的节点要能为存储完整状态贡献少量存储空间。我们想让网络中的每个节点存储一小部分状态，而非完全复制所有状态。有了足够多的节点，整个网络就可以轻而易举地以极高的复制因子存储所有状态。

如何找到你需要的状态

由于每个节点只需存储小部分状态，我们再也不能盲目地向网络中的任意节点请求数据。因此，网络需要一个节点发现机制，以便节点获取所需数据。

如何确保数据永远是最新的

不同于可以构建成只能添加型文件的区块链历史记录，以太坊状态是持续变化的。每个交易都会导致账户余额和合约存储发生变化，这些更新需要在网络中广播。

如何从网络中读取数据

重要的是，客户端要能高效地从网络中读取数据。调用 eth_estimateGas 将根据最新的状态根预测执行交易，来确定交易需要消耗的 gas。如果是一个只涉及两个账号的简单转账交易，所需的数据量相对较小。然而，如果是与智能合约交互并且需要用到合约存储的复杂交易，客户端需要从数据库读取的数据量则大得多。

假设一次网络往返需要 100 ms，那么一笔需要 100 个状态部分的交易需要花费大约 10 秒时间来估算 gas 使用量。如果延迟太久，一些操作可能需要花费过多时间才能完成，这会大幅降低网络的可用性。

如何解决合约存储失衡问题

账户 Trie 在设计上是平衡的，但合约存储不是。这就导致合约存储很难处理。

潜在解决方案

人们正在积极研究按需状态可得性。目前，我们还不清楚该研究的未来方向，但是我们目前主要聚焦于两个不同的方法。

GetNodeData 风格的原生 Kademlia DHT

我们可以采用的最简单的解决方案之一就是，采用与 GetNodeData 相同的运作方式，但是仅要求每个节点存储距离自己最近的数据，而非所有数据。Trie 上的每个节点都有一个哈希值，我们可以使用这些哈希值将 Trie 数据与DHT 键空间（keyspace）关联起来。你可能还记得，Kademlia DHT 网络有一个新特性：遍历键空间只需 O(log(N))。 (责任编辑：admin)