如何设计好用的以太坊轻客户端？

原标题：《科普|如何开发易用的轻量级客户端，上篇》

作者：派珀·梅里亚姆

翻译校对：敏敏、阿健

大约 5 年前以太坊交易软件，我们开始构建 Trinity——以太坊网络上的一个新的“轻客户端”。 那时 Geth 刚刚发布第一版 LES 协议，我们怀揣着远大的梦想。

远大的梦想往往被现实击倒。 多年来，我们吸取了一些教训：

我们的目标雄心勃勃，我们的方法有缺陷。 现在是重新开始的时候了。

访问以太坊协议

如果你想与以太坊协议交互，你有两个选择：

自己运行客户端。 使用 Infura 等集中式提供商的服务。

上面的两个选项将满足大多数用例，但它们处于极端。 以太坊客户端消耗大量磁盘空间，同步需要数小时或数天，而且通常是 CPU 和内存密集型。 中心化提供商是一种简单可靠的解决方案，但以隐私、安全和去中心化原则为代价。

为什么我们之间不能有第三种选择？ 互联网已经多次证明，在困难模式和简单模式之间，人们倾向于选择后者。

我想到了一个保护隐私的解决方案。 然而以太坊交易软件，我所有的交易都是通过 MyCrypto 或 Metamask 完成的。 这两个钱包都来自中心化提供商。 它们都允许用户使用自己的节点，但对于现有客户来说，我认为这太昂贵了。 如果我们想与这些中心化解决方案竞争市场份额，我们需要为用户提供更好的选择。

我们对客户的要求是：

从用户的角度来看，我想让客户端一直运行而不影响我的设备性能。 我想在离线一段时间后不必等待客户端同步就可以上线。

这是我心中的“圣杯”，是我要冒着生命危险去攀登的高峰。

钱包

我们这里说的是如何为钱包打造一个完美的客户端。 钱包无处不在，主要由中心化提供商提供支持。 一般来说，钱包应该满足以下要求：

大多数钱包使用标准化的 JSON-RPC API。 根据上述要求转换后的JSON-RPC端点如下：

如果我们更深入地分析这个功能的先决条件，我们得到一个较低层次的需求：

因此，如果我们能够满足这些要求，我们就可以构建一个适合轻量级钱包的客户端，不需要同步，也不需要牺牲隐私和安全。

今天的以太坊网络

目前，以太坊客户端可以在以太坊协议和 LES DevP2P 协议之间进行选择。

LES 协议采用服务器/客户端模型。 在此模型中，数据应请求从服务器流向客户端。 从协议状态可以看出，该协议不允许客户端以任何有意义的方式返回数据。 根据我的经验，LES 协议中服务器和客户端的数量严重不平衡。 运行服务器成本高，现有服务器数量不足。 这使得 LES 不可靠，并且通常完全不可用。

以太坊协议还有其他缺陷。 该协议很好地实现了它的目的，确保网络中的所有节点都尽可能地复制完整的历史和状态数据。 这对客户提出了很高的要求。 网络中的每个节点都必须保持完整的历史和状态。 不保存此数据的节点不太可能维持健康的对等连接，并且在无法满足对等方的数据请求时可能会断开连接。

在本系列文章中，我们要解构以太坊协议这个“庞然大物”。 该协议包含我们理想的客户端类型所需的所有功能。 它旨在适用于全节点和矿工，但不适用于我们概述的轻型客户端。

解构以太坊协议

让我们把注意力转向以太坊协议......

我们需要解决这个问题。 人们在与以太坊协议交互时的选择有限，并且高度依赖中心化提供商。 网络的当前状态预示着未来可能发生的事情。

我们为以太坊钱包构想了另一个轻量级客户端。 这一愿景不仅仅是一个想法，而是基于实验、原型和我们对现有协议不断增长的了解。

我们正在研究的解决方案需要对核心以太坊协议进行一些修改，以支持此用例。 在本系列的下一篇文章中，我将概述需要更改的内容和添加的内容，以及我们计划如何实施它们。 最重要的是，我将描述我自己对这个新的轻量级客户端的用户体验的期望。