开通得得号
注册
  • 简体中文
  • English

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

以太坊爱好者
以太坊爱好者 得得号

Jan 26, 2021

该文章已上链

摘要： 为钱包定制化一种好用的轻量客户端

 

大约 5 年前，我们开始构建 Trinity —— 以太坊网络上的新型 “轻量级客户端”。那时候 Geth 刚刚发布了第一版 LES 协议，而我们曾心怀远大的梦想。

远大的梦想往往被现实所击倒。这些年来，我们得到了一些教训：

  • EVM 计算从根本上来说是 “繁重的”。
  • LES 如同茫茫沙漠，客户端就是沙漠中渴求数据的旅人。
  • 同步并维护状态的难度过高。
  • 区块链上的历史记录在绝大多数情况下是无用的，却是必不可少的。
  • 核心以太坊协议在本质上对 “轻量级” 不友好。
  • Python 太慢了。
我们的目标是远大的，方法是有缺陷的。现在是该从头再来的时候了。

 

访问以太坊协议

 

如果你想要与以太坊协议交互，摆在你面前的是两个选择：
  1. 自己运行客户端。
  2. 使用 Infura 等中心化提供商的服务。
上述两个选择可以满足大多数用例的要求，但是它们位于两个极端。以太坊客户端需要消耗大量磁盘空间，花费数小时乃至数天时间进行同步，而且对 CPU 和内存的占用通常很大。中心化提供商是一种简单可靠的方案，但是要以牺牲隐私性、安全性和去中心化原则为代价。
为什么我们不能有介于二者之间的第三种选择？互联网已经证明过很多次了了，在困难模式和简单模式之间，人们往往会选择后者。
  • 自己托管邮件（难） vs. Gmail（易）
  • 购买 DVD 或 CD（难）vs. 盗版（易）
  • 盗版（难）vs. 流媒体（易）
  • 自己运行以太坊节点（难）vs. Infura（易）
我想过采用隐私保护型解决方案。然而，我的所有交易都是通过 MyCrypto 或 Metamask 完成的。这两款钱包都来自中心化提供商。它们都支持用户使用自己的节点，但是就现有的客户端来说，我认为这么做成本太高。如果我们想与这些中心化解决方案争夺市场份额，我们需要为用户提供更好的选择。
我们对客户端的要求是：
  • 能够在资源有限的设备上运行（1 CPU / 1GB RAM / 磁盘占用量 <1GB）
  • 公开标准 “钱包” 应用所需的 API
  • 不需要同步
从用户的角度来说，我希望让客户端时刻保持运行，而不会影响我的设备的性能。我希望在离线一段时间后，再上线时无需等待客户端同步。
这就是我心中的 “圣杯”，是我舍命也要攀登的高峰。

 

钱包

 

我们这里讲的是如何为钱包构建一个完美的客户端。钱包无处不在，而且主要由中心化提供商支持。总的来说，钱包要满足以下需求：
  • 追踪区块链的最新区块
  • 查看账户余额和 nonce
  • 读取合约信息（如代币余额）
  • 估算交易的 gas limit
  • 发送交易
  • 监控需要打包的待处理交易
大多数钱包都采用标准化的 JSON-RPC API。根据上述需求转化成的 JSON-RPC 端点如下所示：
  • eth_blockNumber用来追踪链首块
  • eth_getBalance和eth_getTransactionCount用来查看账户信息
  • eth_call用来读取合约信息
  • eth_estimateGas用来估算 gas limit
  • eth_sendRawTransaction用来发送交易
  • eth_getTransactionReceipt表示交易已经被挖出
如果我们更深入分析该功能的必备条件，就会得到更低一级的需求：
  • 访问账户和合约存储以支持eth_call、eth_estimateGas、eth_getBalance和eth_getTransactionCount
  • 访问gossip网络来追踪链首块和eth_sendRawTransaction
  • 访问链上历史记录来获得eth_getTransactionReceipt
 
因此，如果我们可以满足这些需求，就可以构建一个适合轻量级钱包的客户端，不需要同步，也无需牺牲隐私性和安全性。

 

如今的以太坊网络

 

目前，以太坊客户端可以在以太坊协议和 LES DevP2P 协议之间进行选择。
LES 协议采用服务器/客户端模型。在该模型中，数据会根据要求从服务器流向客户端。该协议不允许客户端通过任何有意义的方式返回数据，这点可以从协议状态看出。根据我的经验来看，LES 协议中的服务器和客户端在数量上严重失衡。运行服务器的成本很高，现有服务器的数量不足。这就导致 LES 变得不可靠，而且经常会变得完全不可用。
以太坊协议则另有缺陷。该协议很好地达到了目的，确保网络中所有的节点都尽可能地复制了完整的历史记录和状态数据。这对客户端的要求很高。网络中的每个节点都必须保存完整的历史记录和状态。没有保存这些数据的节点不太可能保持健康的点对点连接，可能会在无法满足对等节点的数据要求时断开连接。
在本系列文章中，我们想要解构以太坊协议这一 “庞然大物”。该协议包含了我们理想的客户端类型的所必备的一切功能。它的设计适合全节点和矿工，但是不适合我们所概述的轻量级客户端。

 

解构以太坊协议

 

让我们将目光转向以太坊协议……
我们需要解决这个问题。在与以太坊协议交互时，人们可选择的方式有限，而且高度依赖中心化提供商。当前的网络状态就预示了未来可能发生的情况。
我们构想了另一种适用于以太坊钱包的轻量级客户端。这一构想不只是一个想法，而是以实验、原型以及我们对现有协议不断深入的认知为基础的。
我们正在研究的解决方案需要对核心以太坊协议进行一些修改，以便支持该用例。在该系列的下一篇文章中，我将概述需要修改和新增的部分，以及我们计划如何去实现它们。最重要的是，我将讲述我自己对这一新型轻量级客户端的用户体验的期望。

（未完）

（文内有许多超链接，可点击左下 ”阅读原文“ 从 EthFans 网站上获取）

原文链接:

https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/

作者: Piper Merriam

翻译&校对: 闵敏 & 阿剑

链得得仅提供相关信息展示，不构成任何投资建议
本文系作者 以太坊爱好者 授权链得得发表，并经链得得编辑，转载请注明出处、作者和本文链接

更多精彩内容，关注链得得微信号（ID：ChainDD），或者下载链得得App

3069576
得得号 | -
3041712
技术 | -
3042301
以太坊 | -
分享到：

相关推荐

    评论（0）

    Oh! no

    您是否确认要删除该条评论吗？

    分享到微信