以太坊轻节点是什么？为什么说轻节点是以太坊的关键参与者？

很多基于区块链，P2P协议的项目都对其中的性能和吞吐量有所担忧。这些项目在研发阶段做了很多创新，但是很多人没有考虑到这些协议其中的真正挑战。

很容易就想象到运行网络的大多数人是处于延迟的可信区间以及计算能力之间，但是很容易忘记大多数用户需要和区块链上的节点进行交互，其实是有障碍的。不幸地是，运行全节点是非常昂贵和缓慢的，所以大多数用户都依赖于“轻”节点，它们可以拥有全节点的安全性，而且不需要过多的资源需求。

以太坊的轻节点模型可以让设备作为轻量化的RaspberryPi来加入网络，下载区块头部作为显示，同时只需要根据用户需求，验证某些部分的状态。特别是在以太坊网络中，很容易就可以和这些拥有全节点的客户端进行渗透，从而通过RaspberryPi会比默克尔树有更快的速度。

数字经济激励并不足以来运行全节点，因为资源消耗能力造成了平衡分布网络的瓶颈。很难去准确预测，网络中全节点和轻节点之间的平衡。现在已经有很多关于如何平衡这些激励的讨论，并且让用户更容易来验证运行全节点。

轻节点背后的主要观点，就是它能够根据需求来获得部分状态，因为它直接考虑用户。假设一个诚实的模型中，矿工正确地符合以太坊的规则，而且至少系统中的全节点是完全诚实的。

他们基本的功能是下载区块头部作为网络中的存在，然后根据被客户端使用的某些状态的默克尔证明来进行发布。以太坊上的轻节点不会使用本地存储，而是使用分布式哈希表格来跟踪Trie节点。

假设以太坊状态是通过大型默克尔树来代表的，很容易使用默克尔根部，还有书上分支路径的节点，来作为轻量化证明这部分信息的完整性。这就完全依赖于默克尔根部提供的信息是正确的。

轻量化客户端的信息包含其中的，但是不限于检查账户余额，验证转账确认，从网络中部署的部分合约中的事件簿等等。所有这些都可以通过默克尔证明验证来减少为次线性的复杂程度。当区块链上的数据已经不可用了，或者证明在验证状态转账因子的时候，证明不能够合格。客户端被允许给P2P网络中的其他用户提供报警。

目前的轻客户端协议使用的是工作量证明共识算法，通过全节点在主链运行。在工作量证明中，通过数学公式就可以验证区块头部是否有效。这个算法就很难计算，但是很容易去验证。

轻量化客户端一旦启动，就会寻找最长区块头部的链，攻击者通过产生错误头部进行欺诈的成本几乎是不可能实现的。

底层算法会通过消耗电力的方式，来进行工作量证明，从而保证网络的安全，虽然验证区块头部是很高效的。

轻量化客户端被用在工作量证明，因为区块头部是一直进行验证的，但是我们并不会在权益证明中获得同样的保证。权益证明的轻客户端：工作量证明真的需要吗？

在权益证明中，轻客户端的简单化问题是区块头部并没有和一定数量的“真实”区块生产者联系。那也就是说，这个共识协议的清楚是在于对成员的惩罚震慑，而不是通过消耗电力来给他们奖励。在权益证明中，如果想运行错误的主链，会受到惩罚，但是在工作量证明中，如果挖错误的链，就会产生分叉，而且没办法获得主链的奖励。

权益证明提供协议内置的机制，从而可以确切地确定区块头部。一旦这些头部被信任了，他们所包含的数据就会呈现很复杂的对数，也就是说，要从默克尔树获取节点。尽管如此，区块头部并没有包含我们可以用来验证工作量证明解决方案的数值，使得验证至少是对数，而不是恒定的时间效率。

但是，我们至少可以在轻客户端的同步效率更高。Vitalik曾经说过，友好的轻客户端权益证明可以通过checkpoints 系统来完成。

Checkpoint的定义是一定数量的区块，其中2/3的参与者必须要通过加密签名达成同意，并且这类Checkpoint必须要包含前个Checkpoint的哈希值。在这个新型轻客户端的同步中，只有Checkpoint可以下载，客户端然后会验证参与者的签名。这会降低必须下载单个区块头部的成本，就好像在工作量证明的轻客户端模式中那样。

但是，这个方法不会解决验证区块头部的问题，所以对于权益证明协议会有个潜在方法，来包含一小部分的工作量证明，为了在轻客户端中创建区块头部。

当然，也可以在生成区块头部的时候使用算力，然后再验证的时候使用权益证明，那么验证这些区块头部所需要的能量就会很小。