世纪金融网Lodestar 是 ChainSafe 的 Eth2 客户端，用 Typescript 构建。Lodestar 提供高度可访问的工具库，使整个 Eth2 生态系统受益。我们的工具库用流畅的 TypeScript 编写，这使得它们可以被广大的开发者所用。另外，Lodestar 的工作重点将是在 Eth2 生态系统里作为可部署的轻客户端。请参阅我们最新的博客文章，这个演讲和这些幻灯片来了解我们。
本文由 Cayman Nava 和 Dapplion 合写，由 Timothy Hao Chi Ho 编辑，图片由 Phil Ngo 提供。
为什么 Eth2 需要轻客户端
以太坊由成千上万的节点构成，这些节点运行着不同的客户端。客户端主要在实现语言和软件规模两方面不一样。在 Eth2 上运行一个全节点客户端意味着你必须下载整条 Eth2 区块链的数据。这对许多环境来说是令人望而却步的，且对某些用例来说是没有必要的。例如，一个全节点无法在一个安装了信任最小化钱包的移动设备上运行。还有很多用例只想读取链上某小段数据，例如获取最新的验证者余额，或为一个区块链桥接实例 (例如 ChainBridge) 存储一个计量虚拟机。在这些实例里，一个轻量级客户端就足够了，比一个全节点客户端更合适。
为了检索最新的状态，以太坊全节点必须下载创世 (或其他) 信标状态，并从头到尾下载且按顺序处理每个权威区块。而使用轻客户端的话，所需的带宽和处理负荷可以减少约 99%。
Eth2 协议是如何支持轻客户端的？
最近 Altair 的升级增加了一个关键功能，是专门为支持轻客户端同步而设计的——同步委员会 (sync committee)。同步委员会及其相关的基础设施可以让一个轻客户端以低成本保持与链头保持同步。
广义上讲，一个轻客户端有两个主要组成部分——首先是同步数据，然后是链数据检索。
同步数据如字面意思：它使得客户端同步到区块链的最新部分。为了与链保持同步，一个轻客户端会以更新信息 (update) 的形式下载区块链的部分数据，这包括一个区块头、一些默克尔证明 (merkle proof)，和当前同步委员会的签名。由于证明和签名都是经过验证的，这使得对这些一个接一个的更新信息的信任得以构建。一旦同步了，轻客户端就可以从区块链检索到最新数据。
链数据检索通过广泛使用默克尔证明来实现。当最新区块头得到验证和信任，轻客户端服务器就可以以默克尔证明的形式给轻客户端提供链数据。这些证明可以根据区块头的状态根生成和验证。
由于同步协议对轻客户端起着如此重要的作用，很值得深入了解它的工作原理：
Altair 创建的同步委员会是一个特殊且长期存在的委员会，它大概每 1.1 天轮换一次。更短的周期会增加轻客户端的数据负荷，因为它们需要更频繁地同步，而更长的周期会给发现和贿赂委员会成员留下太多的机会；1.1 天是两个维度都兼顾到的一个中间值 (参考规范)。
同步委员会是从现有的以太坊验证者中选出来的子集。Altair 升级启动后，参与同步委员会将成为验证者一个新的职责。
同步委员会的规模是 512 名验证者，在撰写本文时，当前主网的验证者数约为 138,000。这是为了确保安全的一个相对大且保守的规模了 (相较于做证明的验证者集和以后的分片提议委员而言)(参考规范)。
同步委员会使得轻客户端更易于与信标链同步数据和保持更新。
信标状态会追踪当前和下一个同步委员会的参与者。我们将在下文介绍为什么这很重要。
同步委员会参与者对区块链的当前状态，特别是前一个区块做证明 (attest)，这些证明会被聚合到一个单一签名，然后被打包到每一个新区块里。
现在，每个区块都包含一个验证了它前一个区块的签名。
这个特别的同步委员会证明被命名为 “SyncAggregate” (以与信标委员会放到链上的“Attestation" 区分)。
上文回顾
(相对) 小的验证者子集在每个区块 N 对区块 N-1 做证明
(相对) 小的验证者子集仅每大约 27 小时轮换一次
(相对) 小的验证者子集 (当前的和下一个) 的信息会被打包到链上
轻客户端同步协议现在可以制作了。它依赖于同步委员会对链状态的认证。
不同于用整个信标状态 (即创世状态) 来初始化节点，轻客户端下载一个历史区块头和在该区块的当前和下一个同步委员会的数据。
不同于下载和追踪整个验证者集 (20 万验证者，且数字还在上升！)，轻客户端可以只下载和追踪当前和下一个同步委员会。
不同于通过下载和按顺序处理每个历史区块来处理区块链，轻客户端可以只下载一个同步委员会的最后一个 SyncAggregate (确保 2/3 的委员会都签名了) 和给下一个同步委员会的默克尔证明。
实质上，轻客户端通过一直追踪每个同步委员会来实现同步，一个接一个委员会地同步，确保每个委员会的交接都有一个得到 2/3 投票的聚合证明，用以验证下一个委员会。
我们是如何实现的？
在 Scaling Ethereum Hackathon 期间，Lodestar 团队决定要大力推动我们在轻客户端上的工作，并在活动结束前展示一个原型和进行演示。当时的轻客户端原型连接到一个后端，该后端使用的是没有验证者共识创建的区块来更新状态。这使得我们可以以低资源消耗对消费者层做测试。
黑客松之后，我们把全部功能迁移到我们的信标节点，这样轻客户端就使用网络上的真实数据。随着区块链的发展和通过新的 ‘lightclient’ API 命名空间为信标节点提供服务，信标节点现在可以高效地给初始证明提供更新信息了。我们已经可以连接到 Altair 开发者测试网 0、1 和 2 ，并成功处理数据了。
为了这次黑客松的目的和作出简化版的 demo，我们为轻客户端创建了一个 REST API 来获取更新信息和请求证明。在这个过程里有三个终端：
获取历史同步更新信息
获取最新的同步更新信息
获取一个信标状态的多重证明
这些终端其实也揭示了底层功能——创建来自信标状态的同步更新对象和多重证明。我们将寻求围绕此 REST API 构建共识，使其成为 Eth2 里轻客户端的新标准。
轻客户端的初始化有两种方式——在轻客户端的初次启动时从一个可信的状态根进行初始化，或在客户端启动后从一个可信的快照进行初始化。轻客户端被初始化后，它会请求从当前同步的位置到被最终确定的状态的更新信息。
轻客户端也有请求证明的功能，通过当前同步的状态根进行验证。
我们的网站展示什么？
我们的网站展示了在浏览器中运行的轻客户端的基本功能。浏览器轻客户端与一个有多个客户端参与的小型 Altair 测试网上的信标节点连接。我们展示了网络时钟、同步状态，和一个证明请求/响应交互部分。请看我们的 demo，了解更多信息！
网络始终显示的是测试网当前的 slot/epoch。这部分纯粹是信息，现在并没有展示任何轻客户端的功能。
同步状态部分显示的是轻客户端当前的同步状态。轻客户端是被配置来更新最新的最终确定状态的。在页面加载时，你会发现同步会快速更新到当前的 slot。
证明请求/响应部分允许用户以交互的方式执行证明请求和接收响应。证明请求作为进入信标状态的“path (路径)”列表。响应则显示为反序列化结果和底层证明。
需要注意的一个特点是，对进入状态多个“path"的每个请求返回的是单个多重证明，而不是每个 path 一个证明。这种结果的批量处理可以节省额外的带宽。
接下来的工作
我们为在 Eth2 轻客户端上取得的所有进展感到高兴，但我们还只是刚刚起步。我们未来工作之一是把我们在构建原型时学到的东西反馈到 Eth2 规范库。请看我们的第一个 issue。
展望未来，我们将确保与规范的更新保持同步。我们目前处于 1.1.0-beta-2 阶段。这将确保我们的信标节点和轻客户端保持更新，且与生态其他部分保持同步。我们还将继续参与 Altair 开发者测试网/测试网，并关注 Pyrmont 测试网的情况。
Lodestar 团队的另一个目标时创建一个能够与链头同步的、能重组 (reorg) 的轻客户端。这是因为轻客户端现在只能与最新最终确定的检查点 (checkpoint) 同步，比在健康网络的链头慢大约 6 分钟。为了支持与链头同步，我们需要支持在网络动荡时会自然发生的“重组“。最后，我们计划进行持续的研究，探索使用从共识层扩展到执行层，到合并后的可用用户数据。现在的轻客户端只使用在信标链上的数据。这包括验证者余额、randao 值和之前的信标区块。但关键是，它并不包括执行相关的数据 (之前称为 Eth1)，例如 ETH 余额或 Dapp 的状态。
合并 (The Merge) 把执行层与共识层 (之前称为 Eth2) 连接起来。这构成通过轻客户端使用执行层数据的基础，但还有很多实操问题有待解决。
我们很高兴能继续在 Lodestar 的 Eth2 轻客户端上工作，并将在未来继续更新我们的工作进度！
来源 | medium.com/chainsafe-systems
作者 | Colin Schwarz
