Bupt3分享19——以太坊客户端拆解

Dora Dōjo
1

Dora Dōjo Workshop
资助金额：100 USDT
分享者：北邮在读硕士 Syshems
本项目由Dora Dōjo资助，文章转载请联系
Telegram: @DoraDojo0
WeChat: @DoraDojo0

区块链其实是基于不同的软件客户端运行的。如果我们想了解以太坊的原理，那么必须理解以太坊的客户端是怎么协作的。当这些客户端工作良好时，区块链正常运行；但是如果客户端有漏洞或遭到恶意攻击，它们对链的不同看法可能会导致对利益相关者遭受 slashing 惩罚，甚至破坏以太坊链本身。本课题旨在探究不同类型的以太坊客户端是如何协作的，不同类型的节点各自需要运行客户端的类型，以及客户端多样性缺失可能造成的问题。

一、以太坊节点

1、节点和客户端

“节点”是运行以太坊客户端软件的任何实体，不同节点连接在一起形成网络。

“客户端”是以太坊执行具体功能的软件，根据协议规则验证数据并保持网络安全。

以太坊节点必须运行两个客户端：执行客户端和共识客户端。

  • 执行客户端：EL，也称为 Eth1 客户端，负责监听和广播网络中的交易，并在 EVM 中执行，在本地维护/保存最新的以太坊状态和数据库。
  • 共识客户端：CL，也称为 Eth2 客户端，负责权益证明共识算法，接收执行客户端验证后的数据并达成共识。
  • 验证客户端：以太坊还有第三个客户端，质押 32 ETH 后激活后可以添加到共识客户端中，允许节点参与网络验证。

image
image960×630 48.8 KB

Source: https://ethereum.org/

2、节点类型

image
image2000×908 168 KB

2.1 Full node

全节点对区块链进行逐块验证，包括下载和验证每个块的 block body 和状态数据。网络中存在着不同类别的全节点：

  • 一些全节点从创世区块开始，逐个区块地去验证，遍历整条区块链的历史。
  • 另一些节点从他相信正确的区块 (例如 Geth 的 “snap sync” ) 开始验证，跳过验证之前的区块。

不论验证从哪里开始，全节点只保留相对较新的数据（通常是最近的 128 个块）的本地副本，允许删除较旧的数据以节省磁盘空间。旧数据可以在需要时重新生成。整体概括为：

  • 存储完整的区块数据，但由于全节点允许删除历史较久远的数据，所以全节点并不保存所有的从创世区块开始的数据。
  • 参与区块验证，验证所有区块和状态。
  • 所有状态数据都可以从本地检索，或通过“快照”由全节点重新生成。
  • 负责服务于网络，并根据请求提供数据。

2.2 Archive node

存档节点是特殊的全节点，需要从创世块开始验证每一个区块，并且永不删除任何下载的数据。

  • 需要保留全节点中的所有数据，并建立历史状态存档。例如查询 #4,000,000 区块的帐户余额。
  • 存档节点的数据以 TB 为单位，这使得存档节点对普通用户没有吸引力，但对于区块浏览器、钱包供应商和链分析等服务来说却是必须的。

2.3 Light node

轻节点只下载区块头，并不下载完整的区块信息。区块头包含了有关块的概要信息，因此轻节点可以根据块头中的「状态根」独立验证接收的数据，所需的任何其他信息都可以向全节点请求。

  • 轻节点使得普通用户也能够参与以太坊网络，且无需运行全节点所需的强大硬件或高带宽。在未来，轻节点可能会在手机或嵌入式设备上运行。
  • 轻节点不参与共识（即它们不能成为矿工/验证者），但可以访问以太坊区块链，具有与全节点相同的功能和安全保证。
  • 轻客户端是以太坊积极探索的领域，预计我们很快就会看到共识层和执行层的轻客户端。

二、执行/共识客户端

image
image2000×781 207 KB

1、执行客户端

  • 执行客户端负责交易处理、交易传播、状态管理和支持以太坊虚拟机（EVM），负责维护以太坊虚拟机、以太坊状态和交易池。它不负责区块的构建、区块传播和区块共识。
  • 执行客户端负责创建执行负载 (Execution payloads，本质是一个交易的集合)，负责更新的状态树和其他与执行数据。交易在称为 EVM 的嵌入式计算机上执行和重新执行。
  • 共识客户端在每个块中都包含执行负载。执行客户端还负责重新执行新区块中的交易，以确保它们有效。
  • 通过 RPC 访问以太坊的用户网关，查询以太坊区块链，提交交易并部署智能合约

image
image770×388 53.4 KB

2、共识客户端

  • 共识客户端处理共识逻辑，包括接收网络中的区块、运行分叉选择算法等，使节点与以太坊网络保持同步，确保节点始终遵循具有最大证明积累的链（由验证者的有效权益加权）。
  • 但注意，没有运行验证客户端的共识客户端只能同步链头，不负责出块和断言(attestation)。
    • 验证客户端作为共识客户端的可选附加组件，需要存入 32 ETH 到 deposit contract 后激活。
    • 验证客户端负责出块和断言，使节点能够产生验证奖励或惩罚(Slashing)。
  • 与执行客户端类似，共识客户端拥有自己的 P2P 网络，通过该网络传播区块和断言。

image
image770×394 24.6 KB

3、执行、共识客户端协作

image
image770×594 80.8 KB

  1. tx was sent to the execution client to verify its validity (signature & balance)
  2. In every slot (12 seconds), one validator and committee is randomly chosen. Once the validator is selected as proposer pseudo-randomly using RANDAO, the execution client bundles transactions from the local mempool into an “execution payload” and executes them locally to generate a state change.
  3. Execution client passes the execution payload to the consensus client, so that the consensus layer can agree on the sequence of blocks at the head of the chain.
  4. Other nodes receive the new beacon block on the consensus layer gossip network. They pass it to their execution client where the transactions are re-executed locally to ensure the proposed state change is valid.
  5. The validator client then attests that the block is valid and is the logical next block in their view of the chain
  6. The block is added to the local database in each node that attests to it.

image
image2000×695 154 KB

三、分布式验证器的优势

2023 年 5 月，区块链网络发生“无法确认最终性”事件，部分客户端遇到 bug，导致无法生成断言，多个 epoch 内无法确认最终性。最终性是 PoS 以太坊的一种关键状态，可确保交易一旦确认就无法更改。一旦超过 4 个 epoch 仍未最终确定，其间未进行断言的验证者就将遭受“泄漏惩罚”并失去部分质押资产。

image
image1060×641 126 KB

Source: clientdiversity.org

1、客户端的多样性

客户端的多样性对于以太坊至关重要，如果多样性消失，客户端的 bug 可能导致数百万 ETH 损失。

  • 超过 66% 验证者使用的客户端可以分叉以太坊；
  • 任何容易遭受攻击的客户端都可能造成 slashing 损失。一旦大规模 slashing 发生，损失会被进一步放大，验证者可能会损失高达 100% 的资金（这个机制本来是为了防止恶意攻击而设定的，但无法避免大规模非恶意的客户端宕机的情况）；
  • 大多数分叉可能无法恢复。

因此，任何一个超过 50% 份额的客户端都会带来系统性风险，设定的目标是所有客户端的份额必须低于 33%。但即便如此，质押者的 ETH 被罚没的风险依然存在。

作为以太坊验证者，可以做的最简单的事情就是选择运行份额低于 33% 的少数客户端软件。当然，如果客户端自身存在错误或可利用的漏洞，则运行在其上的所有验证器都可能被 slashing 。

2、分布式验证器 DVT

随着头部质押项目 (Lido, Binance, Coinbase) 迅速接近临界阈值 33% ，此时 Diva、ssv.network 等一类的项目借助分布式验证技术提供了新的解决思路。

image
image960×420 88.1 KB

对于 Diva 来说，验证器的工作将由 66% 的密钥份额 (Key shares) 去确定执行，而非单一验证客户端。每个验证器对应有 16 个密钥份额，这些份额由不同的客户端组合的节点独立运行。这意味着，当 16 个密钥份额中的 11 个 (66%) 出现故障时，Diva 验证器才会被 slash 。从资金保护上来说，这比没有 DVT 的情况要好几个数量级。

此外，Diva 的分布式验证器技术 (DVT) 提升了网络可靠性。 对比典型的 16 个节点组的 5% 停机时间，Diva 的 DVT 将综合停机时间减少到不到 0.01%。Diva 将 95% 的单个节点正常运行时间转化为 99.99% 的协作正常运行时间，树立了效率的新标准。

参考

Nodes & Clients: Nodes and clients | ethereum.org

Node architecture: Node architecture | ethereum.org

Block creation: Proof-of-stake (PoS) | ethereum.org

Distributed Validator: Ethereum Diversity & How DVT Can Help | by Diva Staking | Medium

Diva Staking: https://divastaking.com/