科普 | 如何开发出好用的轻客户端，Part-1

科普 | 如何开发出好用的轻客户端，Part-2

大多数钱包软件都依赖于 Infura 等中心化提供商。如果我们想要别出心裁一些，就需要开发一个可以在低资源设备上运行的新型轻客户端。

在本文中，我们将介绍以太坊状态是什么，以及如何让轻客户端轻而易举地获得它。

以太坊状态

当我们提到 “状态” 时，我们指的是所有账户信息（如 ETH 余额）以及所有存储在智能合约中的数据。目前，状态包括：

我们先来看一下客户端目前是如何访问状态的。

同步

以太坊节点需要访问完整的状态才能处理新挖出的区块。我们可以通过执行从创世块开始到链首块的每个区块来从头计算出状态。通常情况下，我们不会采用这个方法，因为计算成本太高。

客户端倾向于直接从其它完全同步的客户端那里获取完整的状态副本。虽然不同的客户端执行该操作的具体方式不同，但无论是哪种客户端，在首次上线或离线一段时间后再次上线的情况下，通常都要花费一段时间同步至最新区块。

同步可能需要花费很多时间。如果你使用自己的节点与区块链交互，这会是一大缺陷。要让客户端一直保持同步状态，你不仅需要花时间等待客户端同步，还需要消耗计算机的计算和存储资源。

我们的解决方案是专门针对资源受限的设备而设计的，可以一举解决上述两个问题。我们的轻客户端在运行时只需消耗最少的 CPU/RAM/HDD/带宽资源，而且可以保证永远在线。

当然了，不同的设备之间存在差异，甚至有可能出现无法承受基础负载的情况。为了应对这一情况，我们正在努力免去完全同步的需求。在我们设计的模型下，客户端只需要准确获得链首块的信息即可。

我们的最终目标是构建一个在首次安装或离线一段时间后再次上线能够立即使用的客户端。这个客户端只需能访问正确的数据即可。

按需状态可得性

在如今的 DevP2P 以太坊协议中，有一个名为 GetNodeData 的消息。它可以用来检索以太坊状态的任意部分。我们已经在 Trinity 中使用该网络消息来开发 “Beam” 同步模式并证明了其可行性。这是我们进行的基础研究之一，旨在证明这种新型轻客户端是可以实现的。

遗憾的是，当前的 DevP2P 以太坊网络并不合适用于轻客户端用例，因为它需要每个节点都能存储超过 40 GB 的状态数据，并提供状态的任意部分。无法响应这些状态数据请求的节点不太可能维持健康的对等连接。

按需状态访问模式

当前网络的设计是同步完整状态。GetNodeData 消息适合我们的按需状态检索实验只是一个巧合。为了让客户端能够同步完整的状态，高效的访问模式是按顺序遍历数据，获得连续的大数据块。然而，在钱包用例以及我们的新型轻节点用例中，访问状态的需要需要很大程度上是随机的。 (责任编辑：admin)