Gary Rong：以太坊的轻节点协议

2019年6月29日，由CSDN、灵台科技主办，区块链大本营、联时网、ETHPLANET、以太坊爱好者社区、火星财经协办的“2019第二届以太坊技术与应用大会”在北京长城酒店隆重举行隆重举行。

会议围绕以太坊生态全景、以太坊未来发展、以太坊发展实战、优质项目案例等内容，邀请了以太坊创始人及核心技术开发者、国内外知名项目负责人、行业领袖和以太坊生态精英专家齐聚于此，共同助力中国以太坊技术深度交流和社区发展。

作为本次大会的重要嘉宾之一，Go-Ethereum核心开发者Gary Rong在上午的会议上分享了题为“深入以太坊轻客户端协议”的主题演讲。

以下为Gary Rong演讲实录：

今天给大家带来的内容是《以太坊的轻节点协议》。 第一个是轻节点协议的基本概念，第二个是Merkle Trie和Merkle Proof，第三个是算法，第四个是用户可以用轻节点做什么，第五个是流量控制和流量管理模型。

轻节点协议基本概念

以太坊设计的轻节点协议有两个目标。 首先，资源需求低，可以运行在物联网或手机等小型终端设备上。 其次，它必须能够验证从网络接收到的证据的正确性。 在我们的协议中，轻节点设计了垃圾回收机制，始终只需要维护最新的Block headers，存储压力很小，我们只同步Block headers。 此外，它不会同步状态变化的正确性，否则你必须在本地维护完整的账本，这对于轻节点来说显然是不能接受的。

该工具可能会在一段时间内推送一些对应状态错误的header。 只要最后能连上全时，分享最新的Block header，工具就可以自动检测，保证自身安全。

整体来说，它是根据Block头请求和验证其他部分的数据（比如交易或者返回值），只有在实际使用的时候才会把P2P数据库当成自己的数据库。

目前有两种，一种是Les端实现的，一种是PIP客户端实现的。 我们主要介绍第一类协议。

目前以太坊中的节点按照类别主要分为三类。 第一类是Archive节点，用于维护区块链数据的全量，维护每个版本的状态数据，已经超过两个T。第二类节点是Full节点，对中间版本进行垃圾回收或过期，并且有超过 100 GB。

我们对其进行了优化，目前以太坊的同步最快可以在40分钟内完成。 最后一个是轻客户端，它有垃圾回收机制，可以把本地数据库控制到一个很小的值，只有50兆左右。 它可以选择从一个可信点同步，而不是每次都从区块同步，它可以同步最新的几万个header，1分钟内完成区块链的工作。

Merkle Tries 和 Merkle 证明

接下来介绍Merkle Trie。 左下角的leaf1节点用来存放key=000。 第二个特点是每个二级节点都会存储一个hash，比如3会存储1的hash。子节点本身的hash是通过所有节点的hash内容经过另一轮hash计算得到的，所以最终的 Merkle Trie 节点哈希值包含了整棵树中所有节点的哈希信息。

什么是默克尔证明？ 这意味着当它有一个正确的根时，它可以验证任何节点的正确性。 当需要校验时，首先需要请求服务器，根据目标节点从根节点开始收集树上的所有节点，然后返回。

Merkle Proof 的安全性使得攻击者很难构造假树节点。 本地维护的正确根可以用来验证第一个节点的内容是否正确。 如果第一个节点的哈希内容等于本地，我们就可以证明第一个节点的内容是正确的，第二个节点的哈希可以从第一个节点的链表中得到。

同理，我们可以通过这个hash来验证第二个内容是否正确，以此类推，可以验证最后一个目标节点的正确性。

检查点同步

检查点同步必须满足两个条件。 首先，它必须是可信的； 其次，它必须能够利用这些信息来验证历史数据，这样才能真正做到不同步所有历史区块头。

同步时从网络接收大量的Block header，同时进行PoW验证。 假设我们验证全量的Block header，我们会发现本地节点的计算带宽远大于网络带宽，恰好运行在相对较弱的能力下。 ，所以我们选择以1%的概率抽取一些Block header进行验证，每个待验证的Block header确认之前所有的Block header。

然后再详细说说Checkpoint。 它是能够真正完成同步过程的最关键因素。 Checkpoint由sever或full提升，处理32768blocks后产生的元数据。 元数据包括几个内容。

CHT根，全节点将最强区块链链的每个区块的hash作为数据项插入到本地。 这是其中包含的 CHT 根目录。 假设这是正确的，您可以使用此 CHT 来验证该点所涵盖的任何正确的哈希值。 有了正确的hash，就可以得到正确的Blockheader，就可以验证历史数据。

处理完 32768 个块后，可以在本地生成下一个 CHT 根。 一旦生成的历史信息被汇总到新树中，那么历史区块头就可以被垃圾收集。

至此我们对Checkpoint有一个很强的假设，认为使用的那个是正确的，但是在刚入网的时候没有数据的情况下，很难验证是否正确。

我们暂时使用两种方法来解决这个问题。 一种是开发者通过编码确认代码中最新的Checkpoint。 要更新，用于同步的Checkpoint是过期信息，所以还是需要下载很多Block header才能完全同步。

为了解决更新问题，第二种方案是在区块链上部署一个智能合约，通过这个智能合约完成Checkpoint更新操作。 这样，只要区块链产生一个新的Checkpoint，就可以对智能合约进行多重签名。 注入合约，以便始终使用最新的检查点。

这仍然没有解决中心化的问题。 我个人认为中心化在一定程度上是可以接受的。 假设开发者不受信任，理论上开发者不会被用来交付软件。 PoW本身并没有和Pos一样的认知，所以这并不是一件特别简单的事情。

轻客户端能做什么？

用户可以用轻客户端做什么？ 首先，它可以帮助您转移交易。 当它收到本地交易时，它可以将交易传输到服务器并不断地从服务器查询状态。 一旦确认，服务器会向其发送响应，以便通过本地维护进行验证。 检查是否正确。 其次，它可以查询账本服务，本质上是一个M to M，用于目标账户的状态查询。

然后，轻客户端可以让用户在本地调用智能合约，将合约二进制代码所需的状态数据和调用放入其中执行，并等待其输出。 不同的是对于轻客户端，没有合约以太坊全节点，二进制代码中也没有需要用到的状态数据，缺失的数据通过网络请求。

目前还存在缺失数据状态只能在运行时知道缺失了哪些数据的问题，所以我们发现一个合约执行过程可能会涉及到很多网络请求，而这个智能合约的整体执行效率受本地节点的网络带宽。 限制。

未来，我们会将智能合约的执行过程移至服务器端，收集状态数据和相应的证明，以网络数据包的形式返回，通过网络请求获取所有状态数据，大大提高本地执行的效率。

轻客户端也可以让用户订阅智能合约事件，但它本身并不同步所有收据。 为了完成这个功能，它只能通过每次同步猜测是否包含用户感兴趣的区块头。 事件。

我们在其中添加了一个布隆过滤器以包含关键信息。 Lightclient通过同步获取到新区块后，可以根据本地用户通过过滤器获取到的关键词进行匹配。 一旦匹配通过，就意味着该块可能包含目标事件。 ，然后在本地进行精准过滤返回给用户。

最后，轻客户端使用户能够搜索历史智能合约事件。 搜索和订阅的复杂度是完全不同的。 最简单的就是遍历Block headers，效率很低，但是为了提高效率，我们优化了filter的存储。

本次优化是同时获取30000个Block header，将对应的filter同时旋转90度，将第0、1、2047位作为一个整体存储。 这样做的好处是假设查找关键字为a的事件，对其进行hash，假设一个block filter满足这三个位同时为“1”，说明这个block可能包含这样一个目标事件.

但是我们发现整体只使用了这3条信息，剩下的2045位都是无效数据。 90度旋转很好的解决了这个问题。 我们可以有针对性地获取这3个过滤器的信息，同时验证30000个区块头中哪些包含目标，提高合约搜索效率。 当然，Light client数据命中是通过网络请求的，效率稍低。

流量控制和容量管理

最后一点是关于协议中的流量控制和容量管理的一些事情。 首先，对于流量控制问题，我们采用了比较传统的流量控制技术。 不同的是，在集中式架构下，客户端需要向单点发送请求，服务端为其做负载均衡和流量控制。 但是在去中心化的情况下，没有这种单点要求你的客户端做负载均衡。

因此，这里采用了一种叫做“镜像令牌桶”的特殊机制。 服务器发送一些参数，最慢的恢复速度和一个MaxCostTable。 客户端也在本地维护令牌桶，然后判断本地令牌中是否有这个东西。 多个令牌让它发送一个请求，如果没有，它不应该向服务器发送这个请求。 在服务端就比较复杂了，因为服务端给了客户端最小的配置参数，比如最慢的恢复速度。

服务器有更精确的处理请求的计算公式，我们保证公式的结果不会大于查询得到的结果。 另外，当服务端发现自己的资源空闲时，会给客户端更快的令牌速度，所以同时维护了两个令牌桶。

服务器处理完请求后，会根据本地的值调整本地镜像令牌桶的容量值，并返回缓冲区。 一般一个客户端在本地有多个服务器，每个服务器都会建立一个token。 客户端倾向于将请求传递给令牌较多的服务器，服务器也对令牌较多的客户端的请求进行优先级排序。 实现资源的平等分配。

这样以太坊全节点，客户端可以使用本地令牌信息更好地管理和分发其请求，避免低处理优先级或高响应延迟。

然后是服务器端的容量管理。 我们提供4个参数让服务器运维限制服务器资源的使用。 第一个是Light server，表示服务器在1秒内可以处理客户端请求的时间百分比，后台有多个权限同时处理客户端请求。 同时，网络带宽有两个参数属性。 如果服务器网络带宽是宝贵的网络资源，可以通过这两个参数进行限制。 最后一个是Light peers，表示连接服务器的最大客户端数。

服务器处理请求有更精确的计算公式，同时考虑了两个方面。 首先是时间开销，也就是处理这个请求所花费的时间； 其次，考虑网络带宽的因素，会考虑本次请求对应的根包的大小； 最后取这三个上限，假设服务器特别慢，这个时间开销应该是最大的。 如果你的服务器网络带宽被限制在一个很小的值，那么网络数据包的开销是最大的。

然后是Buffer充电。 服务器可能同时有多个客户端。 总恢复速度在服务器上有一个上限叫做充值，代表服务器可以服务的请求能力，服务器运营商可以通过这个限制来使用。

为了最大化服务端对客户端服务的数量，规定当服务端资源空闲时，服务端会给服务端更快的令牌回收速度。 当服务端发现过去一段时间内自己处理的客户端请求的累计时间开销加上本地缓存预估的时间开销之和超过了恢复能力，说明服务端超载了，请求某个优先级被频繁发送 客户端冻结以这种方式最大限度地利用服务器端资源，并且有严格的机制来限制这些资源的使用。

最后还有Free client和Priority client，不参与区块的验证，不参与其他用户发起的交易。 它需要服务器为其提供免费的请求服务。 但是客户端在用户体验方面确实有一定的优势。 它对资源的要求非常低，可以在很短的时间内完成。 所以我们提出了付费节点的概念。 轻客户端可以通过小额支付的方式向服务器支付费用，让服务器给它更高的容量，这样它就可以发送更多的请求，而这些请求的响应延迟更低。

此时我们的Server全节点已经获得了相应的奖励，目前其运行没有任何经济激励，但是全节点对于网络安全来说是一个非常重要的决策，我们希望在一定程度上改善现状以这种方式进行。