Fluffy 客户端：以太坊的极轻客户端

我们该如何设计网络，才能让客户端只需为网络贡献少量数据，就让整个网络（这些贡献）具有很大的意义呢？

—— Piper Merriam

我们很高兴地宣布，Nimbus 将加入以太坊基金会的 “门户网络” 团队，作为门户网络的启动客户端之一。

一句话总结：“门户网络” 是一个开发中的跨客户端项目，为的是重新构想以太坊的轻客户端，并开发出一套可用且实用的轻客户端体验。

直接引用这份规范的表述：

“门户网络” 是一个还在开发的项目，为了让资源有限的设备也能轻量地访问协议。

“门户” 一词的含义是，这些网络可以观察到协议运行的现状，但对核心的以太坊协议的运行又无关紧要。

门户网络将由一个或多个去中心化的点对点网络组成，这些网络共同提供暴露标准的 JSON-RPC API 所需的数据和功能.

这些网络是经过专门设计的,为了保证参与这些客户端只需付出最小化的网络带宽、CPU、RAM 和机械硬盘资源即可加入。

“门户网络” 一词也用来描述参与这些网络并暴露标准的 JSPN-PRC API 的软件.

特别地，我们的目标是与 EF 一道，围绕已有的以太坊协议，开发出一组新的以太坊协议，能专门服务于这种获取以太坊数据的新方法。

总体目标是为以太坊提供一个操作模式，能够服务于常见的使用模式，而不是实时追踪完整的状态（当前的客户端就是这么做的）。

我们正在讨论要开发的是一个用于钱包的完美客户端，一个极轻客户端，可以给网络作贡献，但又不要求同步区块链（也即是可以在离线之后重启即用，安装之后立即可用）。

这也没有听起来那么困难。我想象大部分钱包都直接嵌入轻客户端，比如 @ethstatus 将集成一个 @ethnimbus 轻客户端。所以可能出现这样一种情况：大部分用户都在不知不觉中就开始运行轻客户端了。

May 24, 2021

因此，我们的一个最终目标是，将这种客户端直接敲入到 Status app 中。

它有潜力能提升我们用户的安全性和隐私性（我们也不再需要依赖 Infura 了），同时提高以太坊的可靠性，因为更多用户可以为网络的健康作贡献。

背景

门户网络根植于开发者 Piper Merriam 以及 Trinity 团队的初始目标：在现有的网络上开发一个轻量级的客户端。它的诞生是因为他们意识到了，现有的网络对于他们所设想的客户端类型来说不够灵活。

用 Piper 的话来说：

当我们开始开发 Trinity 客户端时，我们的目标是开发一个轻量级的客户端。但花了接近三年时间深入了解协议、探索开发我们所设想的客户端的途径之后，我们最终得出一个结论：它在现有的网络上是做不出来的。

这就是门户网络的初衷。我们要回到我们想要的客户端形态，然后设计出其运行所必需的网络功能。

Trinity 客户端不会再开发下去了，我们正在开发一个独立的门户客户端，叫做 “Trin”，用 Rust 语言编写，将是门户网络的启动客户端之一。

动机（轻客户端视角）

现有的 DevP2P LES 网络在设计上采用了 客户端/服务器 架构，轻客户端作为客户端，而全节点作为服务器端（到今天为止，“轻客户端” 这个术语指的都是现有 DevP2P LES 网络的一个客户端）。

因为这种架构把所有的负载都交给全节点来承担，而全节点的运营成本已经很高了，所以节点运营者就不愿意打开这个功能。

所以，虽然当前的网络设计很好地实现了其初始目标，但从轻客户端的视角来看，它是严重的失败。

我们如何解决这个问题呢？就像 Piper 的 Trinity 团队发现的那样，现实表明这个问题没有简单的解决方案。现有的网络不够灵活，无法做出高效的轻客户端设计。

修复这个问题需要我们回到一张白纸，重新设计协议的核心。

设计

一个轻客户端友好的网络，必须设计得节点只需付出少量存储空间、少许工作量，就能参与网络并为网络做贡献，而不是要求每个节点都必须承担很高的负载（即：在内存里保存区块链的完整历史）。

换句话来说，这样一个网络必须允许轻客户端在实际上为网络做出贡献，使得每当有额外的客户端加入网络，都会增强网络的容量。

具体来说，这意味着要提出一种网络设计，可以减少你的偶发请求的数据的验证开销，并降低在网络中传递消息的基本开销。

门户网络的目标是通过将以太坊协议的整体结构为三个独立的网络：Gossip（事务和区块）状态以及历史，来实现这一点；最开始的开发重心是状态网络。

这些网络将与 ETH 协议共存 —— 但不像 ETH 协议，它们不必是完全无懈可击的，但它们需要能 几乎 不间断工作。

愿望是这些新的网络，可以随着时间的推移，与现有的网络更加紧密地结合在一起。举个例子，我们可以设想这样一个世界：全功能客户端可以使用历史门户网络来为节点运营者提供额外的选择，仅存储他们关心的历史（可能也就 200 MB）而不是整条区块链（大于 200 GB）。状态数据也是如此。

总而言之，这个模块化的架构 —— 其中数据（状态和区块链历史）以 P2P 的模式来分享，而事务和区块则靠 gossip 来传播 —— 使得轻客户端可以自己选择 存储/服务 多少状态数据和历史数据。

当他们需要访问本地没有的数据时，他们可以在相关网络提出 ad hoc 请求（以一种类似于 BitTorrent 的方式，一个 DHT 用来发现这些被请求的数据）。

JSON RPC 备注

借用 Piper 的精彩文章 “设计可用的轻客户端 part 1”（中文译本）：大部分钱包，包括我们的，在 JSON RPC API 上都是标准化的.

Status 钱包的正确运行需要下列 JSON RPC 端点:

eth_blockNumber 用于跟踪链的顶端

eth_getBalance 以及 eth_getTransactionCount用于获得账户信息

eth_call 用于读取合约信息

eth_estimateGas 以及 eth_gasPrice 用于估计 gas 费

eth_sendRawTransaction 用于发送用户的交易

eth_getTransactionReceipt 在交易上链后获取回执

访问账户以及合约存储项（状态），以支持：eth_call、eth_estimateGas、eth_getBalance 以及 eth_getTransactionCount

访问 gossip 网络（Gossip）以跟踪链的顶端以及 eth_sendRawTransaction

访问链的历史（历史），用于 eth_getTransactionReceipt

项目现状

我们已经开始为 Nimbus 开发一种操作模式，一开始命名为 nlpn ，但现在重命名为 fluffy ，会与以太坊 1 的客户端同时存在、运行。

fluffy 将使 nimbus-eth1 客户端可以作为网络中的一个极轻客户端节点来运行。

初步的工作是开发 Portal Wire 协议，这是一个建立在 Node Discovery v5.1 协议基础上的次级协议。

我们已经实现了对该协议的基本支持，并且几周以前，我们就已成功实现了与其它客户端的握手，包括 ddht 客户端（一个用 Python 编写的门户网络客户端原型）和 Trin 客户端。

下一步

下一步是通过 Portal Wire 协议来传输数据。我们正在处理状态数据。

这需要 “桥节点” 为门户网络输入状态数据。当前的措施是使用一个 Nethermind 客户端插件作为定制化 JSON-PRC API 来给愿意充当桥节点的门户节点提供数据。这一工作已经开始（规范草案在此）。

最终我们的极轻客户端将支持以太坊 JSON-PRC API 的一个子集，所以钱包可以直接集成这种客户端。

资源

Nimbus 门户网络客户端（nlpn）可以在我们的 nimbus-eth1 代码库中找到： https://github.com/status-im/nimbus-eth1/tree/master/fluffy

Portal Wire 协议已加入 nim-eth 代码库，作为节点发现协议 v5.1 的次级协议：https://github.com/status-im/nim-eth

规范：https://github.com/ethereum/stateless-ethereum-specs/

网站：https://www.ethportal.net/

一些有关与 ddht 和 trin 的第一次 Portal Wire 协议测试的资料：https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53

Piper Merriam 撰写的系列博文：The winding road to functional light clients

有关这个主题的一个视频演讲