2019年6月29日，由CSDN、灵钛科技主办，区块链大本营、Unitimes、ETHPLANET、以太坊爱好者社区、火星财经协办的“2019第二届以太坊技术及应用大会”在北京·长城饭店隆重举行。
本次大会围绕以太坊生态全景、以太坊未来发展、以太坊开发实战、优质项目案例等多方面展开，邀请以太坊创始人及核心技术开发者、海内外知名项目负责人、行业领军人物及以太坊生态精英专家齐聚于此，共同助力中国以太坊技术深度交流和社区发展。
作为本届大会的重要嘉宾之一，Go-Ethereum核心开发者GaryRong在上午的会议中分享了题为《Deepintoethereumlightclientprotocol》的主题演讲。
以下为GaryRong的演讲实录：
今天我为大家带来的内容是《以太坊的轻节点协议》。第一是轻节点协议基本概念，第二是MerkleTrie和MerkleProof，第三是算法，第四是用户用轻节点能做哪些事情，第五是关于流量控制和流量管理模型。
轻节点协议基本概念
以太坊设计的轻节点协议有两个目标，首先，对资源要求足够低，必须能够运行在IoT或者手机这种小型终端设备，其次，它必须有能力验证从网络中收取到证据的正确性。在我们的协议里轻节点设计了垃圾回收机制，始终只需要维护最近的Blockheaders，存储压力非常小，而且我们只同步Blockheaders。此外，它不会同步去做状态变更的正确性，否则你必须要在本地维护全量账本，这显然不是轻节点能接受的。
工具有可能在一段时间之内推送一些对应状态是错误的Header，只要能够最终连接到全时并且分享最新的Blockheader，就能够自动检测出工具，保证它自身的安全性。
综合来看，它是在Blockheader基础上对其他部分的数据，在真正使用到时才会向网络进行请求并且进行验证，它把P2P数据库当成它自己的数据库。
目前有两类，一类是Les端实现的，第二类是PIP客户端进行实现，我们主要介绍第一类协议。
目前以太坊中的节点根据类别主要分为三类，第一类是Archivenode，用来维护全量区块链数据，同时维护每个版本状态数据，它已经超过两个T。第二类节点是Fullnode，对中间版本或过期进行垃圾回收，有100多个GB。
我们进行了优化，目前最快可以在40分钟之内完成以太坊的同步。最后一个是lightclient，有垃圾回收机制，可以将本地数据库控制在很小值，大约只有50兆左右。它可以选择从可信的点同步，而不必要每次都从block进行同步，同步最新的几万个header就可以同步，1分钟之内就可以完成区块链的工作。
MerkleTrie和MerkleProof
接下来介绍MerkleTrie，左下角leaf1节点用来存储key=000。第二个特点是每个副节点都会存储哈希，比如3会存储1的哈希。副节点本身的哈希又是通过所有节点的哈希内容再进行一轮哈希计算得到的，所以最终MerkleTrie节点哈希值包含整颗树中所有节点的哈希信息。
什么是MerkleProof？指它拥有一个正确的root时就可以校验任意节点的正确性，当需要验证时，首先需要向服务器请求，根据目标节点从根节点开始收集树上所有节点，然后返回。
MerkleProof的安全性使攻击者很难构造假树节点，完全可以利用本地维护的正确的root校验第一个节点内容是否正确，假如第一个节点哈希内容等于本地，我们可以证明第一个节点内容是正确的，可以从第一个节点的列表中拿到第二个节点的哈
同理，可以用这个哈希校验第二个内容是否正确，以此类推，我们可以校验最后一个目标节点的正确性。
Checkpoint同步
Checkpoint同步必须满足两个条件。首先，它一定是可信的；其次，必须要能够去利用这个信息去做历史数据的校验，这样它才能够真正不去同步所有历史的Blockheaders。
在同步时收到来自网络的大量Blockheaders，还会进行PoW校验，假设我们对全量的Blockheaders进行校验，会发现本地节点的计算带宽远远大于网络带宽，恰巧运行比较弱的能力下，所以我们选择以1%的概率抽取一些Blockheaders校验，被校验的每一个Blockheaders确认所有之前的Blockheaders。
然后详细讲一下Checkpoint，它是能够真正完成同步过程的最关键因素，Checkpoint由sever或全推动，处理32768blocks以后产生的元数据，元数据包含几个内容，首先是Sectionsindex保证新旧程度。
CHTroot，全节点将区块链最强链的每个区块哈希作为数据项插入到本地中。这是包含在里面的CHTroot，假设这是正确的，就能够借助这个CHT去校验任何一个被点覆盖的正确的哈希值，有了正确的哈希就能够获得正确的Blockheader，就能够对历史数据进行校验。
处理了32768blocks以后可以在本地生成下一个CHTroot，一旦产生了的历史信息已经被归纳到新的树当中，这时就可以对历史的Blockheaders进行垃圾回收。
到目前为止我们对Checkpoint有很强的假设，认为用到的这个是正确的，但是当刚进入网络时没有任何数据，很难校验是否正确。
我们暂时用两种方法解决这个问题，一是开发者通过编码方式在代码中确认最新Checkpoint，是较为中心化解决方案，用户限定为开发者给定的解决方案，通常开发者发布新版本才会去更新，同步时用到的Checkpoint是过期的信息，所以依然需要下载很多Blockheaders才能够完全同步。
为了解决更新问题，第二种方案是在区块链部署一个智能合约，把Checkpoint更新操作通过这个智能合约完成，这种方式只要区块链产生一个新的Checkpoint，智能合约可以通过多签签名方式注入到合约里，这样始终用的都是最新的Checkpoint。
这依然没有解决中心化的问题，我个人认为这里中心化一定程度可以被接受，假设不信任开发者，理论上也就不会使用开发者交付软件。PoW本身并没有像Pos那样的认知，所以这并不是一个特别简单的事情。
Lightclient能做什么？
用户能够用Lightclient做哪些事情？首先，它能够帮你做交易转积，当它收到本地交易可以把交易转积到server，不断向server查询状态，一旦被确认，server就给它发送响应，这样就可以通过本地维护去校验是否正确。其次，它能够查询账本服务，对于目标帐户的状态查询本质来说是对M的一次M。
然后，Lightclient能够让用户在本地进行智能合约调用，把合约的二进制码需要用到的状态数据以及调入放到里面执行，等待它的输出。区别在于对于Lightclient来说，没有合约，二进制码也没有需要用到的状态数据，缺失的数据都是通过网络进行请求。
目前还有一个问题是缺失数据的状态在运行时才能够知道到底缺失哪些数据，所以我们发现一次合约执行过程中可能会涉及很多次网络的请求，这个智能合约整体执行效率就受到本地节点网络带宽的限制。
我们今后会把智能合约执行过程挪到server端，收集状态数据以及对应的proof，在一个网络包进行返回，通过一次网络请求获取到所有状态数据，大幅度提高在本地执行的效率。
Lightclient还能够让用户进行智能合约事件的订阅，但是它本身并不会去同步所有的receipts，为了完成这个功能，它只能通过每次同步得到的Blockheader去猜测里面是否包含用户感兴趣的事件。
我们在里面加了bloom过滤器，把关键信息收录进来，Lightclient通过同步得到一个新的Block之后可以通过过滤器根据本地用户得到的关键字进行匹配，一旦匹配通过，说明这个Block有可能包含目标事件，然后在本地实现精确过滤返回给用户。
最后一点，Lightclient能够让用户进行历史智能合约事件的搜索功能。搜索跟订阅的复杂度完全不同，最简单的是遍历Blockheaders，这样非常低效，但为了提高效率，我们对过滤器的存储进行了优化。
这样的优化是同时拿到3万个Blockheaders，把对应的过滤器同时进行90度旋转，分别将第0位、第1位、第2047位进行整体存储。这样的好处是假设搜索关键字为a的事件，把它进行散列，假设一个区块过滤器满足这三位同时为“1”，表明这个区块有可能包含这样一个目标事件。
但是我们发现整体只用到这3个信息，剩余的2045位都是无效的数据，90度旋转很好地解决了这个问题，我们可以有针对性的获取这3个过滤器的信息，同时一次验证3万个Blockheaders有哪些包含目标，提高合约搜索效率。当然，Lightclient数据命中是通过网络进行请求的，所以它的效率稍微低一些。
流量控制和容量管理
最后一点是关于协议中的流量控制和容量管理的一些内容。首先，流控问题，我们采取比较传统的流控技术，有所区别的是在中心化架构下，client需要往一个单点发送请求，server为它进行负载均衡、流量控制。但在非中心化情况下没有这样的单点问你的client做负载均衡。
所以这里采取了比较特殊的机制叫“镜像令牌桶”，server发送一些参数，最慢的恢复速度和一张MaxCostTablle，client在本地同样维护令牌桶，然后去判断本地令牌里面有没有这么多令牌让它发送请求，如果没有的话就不应该向server发送这个请求。在server端显得更为复杂，因为server给client都是最低配置参数，比如最慢恢复速度。
server处理请求有较为精确的计算公式，我们保证公式结果不会大于查询得到的结果。此外，当server发现它的资源被闲置时会给client更快令牌速度，所以同时维护两个令牌桶。
server处理完这笔请求后会根据本地的值对本地镜像令牌桶调整容量值，同样会把buffer返回。一般一个client在本地有多个server，为每个server都构建一个令牌同，client倾向于把请求转积给更多令牌的server，server也优先处理拥有更多令牌的client的请求，以实现资源的均等划分。
通过这种方式client能够借助本地令牌信息更好管理和分发它的请求，避免很低的处理优先级或者很高的响应延时。
然后是server端的容量管理，我们提供4个参数让server运维限制server资源使用。第一个是Lightserver，它表示1秒中有多少百分比时间server可以用来处理client的请求，后台有多个限权同时处理client的请求。同时，有两个网络带宽的参数性质，server网络带宽如果是珍贵的网络资源，可以通过这两个参数进行限制。最后一个是Lightpeers，表示server连接最多client的数目。
server处理请求有一个较为精确的计算公式，同时考虑两方面内容。首先是时间开销，也就是说处理这笔请求对应花费的时间；其次考虑网络带宽的因素，它会考虑这个请求对应的root包大小；最后取这三个上限值，假设server特别慢，这时时间开销应该是最大的，如果你的server网络带宽被限到很小值，这时网络包的开销是最大的。
然后是Bufferrecharging，server端可能同时有多个client，恢复速度总和在server端有一个上限叫recharge，代表这个server所能服务的请求能力，以及server运维者可以通过这个限制进行使用。
为了最大提高server对client的服务数量，规定server端资源闲置时会给server更快令牌恢复速度。当server发现它在过去一段时间内处理的client请求累积的时间开销，加上本地缓存的预估时间开销的之和超过了恢复能力，这时表明server已经过载，一定的优先级请求发送频繁的client进行冻结，通过这个方式最大程度利用server端资源，同时有严格机制限制这些资源的使用。
最后是Freeclient和Prioriityclient，它不会去参与区块的验证，不会参与其他用户发起的交易，它需要server为它免费提供请求服务。但是client在用户体验上确实有一定优势，它对资源要求非常低，非常短的时间内完成。所以我们提出了付费节点的概念，Lightclient可以通过微支付向server进行付费，让server给它赋予更高的容量，这样它能够发送更多请求，并且这些请求有更低的响应延时。
这时我们的Serverfullnode收到了对应的报酬，目前运行没有任何经济激励，但是fullnode对网络安全是非常重要的决策，我们希望通过这种方式对现状进行一定程度的改善。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。