实质上，轻客户端通过一直追踪每个同步委员会来实现同步，一个接一个委员会地同步，确保每个委员会的交接都有一个得到 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 一个证明。这种结果的批量处理可以节省额外的带宽。 (责任编辑：admin)