科普 | 如何开发出好用的轻客户端（二）

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

现在是 2021 年，以太坊区块链已经运行 5 年多了。但目前还没有不使用中心化提供者就能与以太坊协议交互的可靠的轻量级方式。各种研究表明，只要你能够访问必要的数据，就可以构建这一功能。在本文中，我们将介绍什么是区块链历史记录，以及需要解决哪些问题才能让轻量级客户端轻松获得这些历史记录。

区块链历史记录

“区块链历史记录” 指的是所有区块头、区块体和收据的历史记录。在当前所有以太坊客户端用来通信的以太坊协议中，节点可以使用以下消息对来互相请求区块链历史记录：

GetBlockHeaders > BlockHeaders

GetBlockBodies > BlockBodies

GetReceipts > Receipts

点击此处，查看以太坊协议的完整规范。

区块链历史记录是一个相对简单的数据集。你可以把它当成是一个只能添加的文件。矿工每挖出一个新的区块，这个区块的区块头、交易、叔块和收据都会被添加到文件中。

以太坊协议已经为这部分需要而优化过，所以一个新加入网络的节点可以高效地检索区块链的所有历史记录。一旦客户端实现完全同步，除了响应 JSON-RPC 请求之外无需使用这些数据。客户端自己也不会频繁用到这些数据，因为它们会通过 gossip 消息获取新的区块和区块头。作为区块执行的一部分，收据会在本地生成。尽管如此，协议还是强迫客户端要保留完整的历史记录。

因此，我们需要的数据在以太坊节点所组成的网络中其实都有，只不过网络的架构没有考虑过我们的用例。在以太坊协议上构建轻量级客户端需要解决三大问题：

A：我们需要对正统链有一个简明的了解

B：我们需要使用索引，便于按区块号查找区块，并按哈希值查找交易

C：我们需要减少单个节点存储的总数据量

A：正统区块头链

要找到区块链最新区块，最免信任的方式是从头开始构建一条完整的区块头链（由区块头组成的链条）。为此，我们需要获取大约 1100 万个区块头，并为其提供大约 6GB 的存储空间。

如果没有完整的区块头链，客户端就无法辨别区块头是属于正统链还是叔块的。对于手机和树莓派等低资源设备来说，6GB 的存储成本过于高昂。如果用户要先获得 1100 万个区块头才能发出第一个请求的话，那就违反了客户端无需同步的要求。

幸好我们可以借鉴信标链的机制来解决这一问题。我们只需在以太坊协议上添加一个 “双倍批量默克尔 log 累加器（double-batched merkle log accumulator）”，就可以构建一个简单易懂的机制来提供某个区块头是否包含在正统链上的证明。客户端只需准确掌握最新区块头的信息，并通过累加器生成的简单默克尔证明来证明历史区块头包含在正统链上。

同步问题是一个可以在客户端层面解决的用户体验问题。有两种解决方案：1. 设置区块头“检查点”；2. 信任观察到的链首块，并执行实际的工作来获取该链首块，然后对其进行异步验证。我们可以将这些作为功能标志（feature flag）提供给用户，让用户在安全性和便捷性方面自行权衡取舍。

B：数据索引

有一些 RPC 端点很难直接构建在现有网络架构上。客户端目前可以通过在区块链历史记录上创建索引来服务这些端点。存在问题的端点主要有：

eth_getBlockByNumber

eth_getTransactionByHash

eth_getBlockByNumber端点的难点在于叔块。任意区块高度都有可能出现无限个有效区块，但是只有其中一个区块在正统链上。因此，客户端在拼凑正统链时也会构建自己的索引来将 block_number 映射到 block_hash 上。当客户端通过 JSON-RPC 请求某个区块号的区块时，该索引会将这一请求转化为请求某个哈希值的区块。

eth_getTransactionByHash也存在同样的问题。如果我们将叔块纳入考虑，一笔交易可能存在于多个不同的区块中。但是，单就正统链而言，一笔交易只存在于一个区块内。客户端在处理正统链时会创建一个索引来将 transaction_hash 映射到 (block_hash, transaction_index) 上。当客户端收到对某笔交易的数据请求时，该索引会将这一请求转化为允许查找该交易以及包含该交易的正统区块。交易和区块都必须包含在 JSON-RPC 响应内。

因此，我们需要一个机制来显示这些索引。

区块头累加器为我们提供了一种机制，可以让索引数据成为正统链的一部分。

C：降低个体存储要求

以太坊协议自设计之始，就将 DevP2P 以太坊网络中的节点设想为能够响应任何关于查找区块链历史记录的请求 —— 无论是最新的区块、很老的区块还是介于二者之间的区块。以太坊网络没有机制可以让节点仅存储区块链历史记录的子集。从根本上来说，整个网络都依赖于所有节点都存储所有数据这一假设。网络本身无法强制节点存储所有数据，但是客户端会与无法响应其请求数据的对等节点断开连接。这在一定程度上保障了安全性，因为无法响应请求的客户端不太可能会维护健康的对等连接。

因此，首先需要解决的问题是，创建一种机制让单个节点可以仅存储区块链历史记录的子集，同时让网络为节点提供一种机制，以便节点快速找到拥有它们所需数据的节点。

事实证明，这是 Kademlia DHT 网络的新兴属性。该网络拓扑自身的系统就可以在任意大的密钥集中进行 O(log(N)) 查找。假设我们要查找区块哈希和交易哈希之类的数据。我们可以通过 DHT 查找它们，使用对应区块头对其进行验证，并使用区块头累加器来证明它们在正统链上。

Alexandria DHT

“Alexandria” 是Kademlia DHT 网络的暂定名称。该网络旨在按需提供区块链历史记录的访问权限。该网络本身构建在 Discovery v5 协议上（信标链和以太坊网络也是基于该协议构建的）。这就意味着，绝大部分（乃至所有）语言编写的客户端都会有可用的实现。

虽然我们没有严格要求修改核心协议来添加区块头累加器，但是这样做确实可以大幅改善这一情况。即使没有Alexandria，使用累加器也会让核心协议如虎添翼。

我们还需要解决可扩展性问题。将区块号映射到的正统区块哈希值的正统区块头索引相对较小，仅包含一个条目（每个区块头对应一个条目）。然而，交易索引很大，包含近十亿个条目（每发送一笔交易都会有一个条目）。相比之下，广泛使用的 BitTorrent DHT 包含大约 2600 万个不同的种子。以太坊主网需要在我们的 DHT 上存储大约 50 倍的数据。

构建 Alexandria DHT 并为其制定规范是一个持续性的研究主题，目前已经有了一个还在不断完善中的大致规范和概念证明客户端。我们还在继续进行开发，之后会公布新的进展。

（未完）

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

原文链接:

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

作者:Piper Merriam

翻译&校对: 闵敏 &阿剑