1. 引言

以太坊有3种节点：

Full node
Light node
Archive node

其中light node为：

Stores the header chain and requests everything else.
Can verify the validity of the data against the state roots in the block headers.
Useful for low capacity devices, such as embedded devices or mobile phones, which can’t afford to store gigabytes of blockchain data.

当前Geth已支持light client，最新消息可参与 ethereum light client官方群。

根据 Light Ethereum Subprotocol (LES) 可知，light client仅下载区块头，不挖矿也不参与共识。

2. Canonical Hash Trie

LES使用Canonical Hash Trie (CHT) structure 来快速initial syncing and secure on-demand retrieval of canonical hash mappings, block headers and total difficulty (TD) values。

A CHT为a Merkle trie（以太坊state 使用Merkle Patricia Trie）。
CHT中包含了blockNumber->[blockHash, TD] mappings，其中keys为binary big endian encoded 64 bit integers，values为RLP-encoded [hash, number] pairs。

CHT由LES servers每隔32768个区块生成。CHT[i]中包含了0..(i+1)*322768-1 区块数据。若client知道CHT[i]的root hash，且想fetch header number N（其中N< (i+1)*32768），client可获取该header，并通过GetHelperTrieProofs请求来获取相应的Merkle proof of the CHT。

CHT仅在2048个确认之后才会生成，这样才可保证chain不会被reorg。当前版本的light client实现中将主网和测试网的[chtNumber, chtRoot]写死了。未来，计划将实现trustless validation algorithm。

3. BloomBits

BloomBits优化了log search，采用的方法为：
通过bitwise transformation，使得retrieve bloom filter data relevant to a specific filter的成本更低。

当 search in a long section of the block history时，需要check three specific bits of each bloom filter per queried address/topic。为此，LES必须retrieve a ~550 byte block header per filtered block。

通过a “bitwise 90 degree rotation” of the bloom filters，BloomBits结构可优化bloom filter lookups。
会将固定数量的区块打包（LES BloomBits Trie的size为32768 blocks）。
BloomBits[bitIdx][sectionIdx] is a 32768 bit (4096 byte) long bit vector that contains a single bit of each bloom filter from the block range sectionIdx*SectionSize ... (sectionIdx+1)*SectionSize-1。
由于bloom filters通常是系数的，可采用压缩算法进一步压缩，效率会更高。
通过read并binary-add three BloomBits sections，可一次性filter an address/topic in 32768 blocks（“1” bits in the binary AND result mean bloom matches）。

3.1 压缩算法

BloomBits数据是以压缩形式存在的。该压缩算法对具有很多zero bytes的稀疏数据进行了优化。
解压缩时需要知道the decompressed data length。

压缩算法的伪代码表示为：

if data only contains zeroes,
    CompressBytes(data) == nil
otherwise if len(data) <= 1,
    CompressBytes(data) == data
otherwise:
    CompressBytes(data) == append(CompressBytes(nonZeroBitset(data)), nonZeroBytes(data)...)
    where
      nonZeroBitset(data) is a bit vector with len(data) bits (MSB first):
          nonZeroBitset(data)[i/8] && (1 << (7-i%8)) != 0  if data[i] != 0
          len(nonZeroBitset(data)) == (len(data)+7)/8
      nonZeroBytes(data) contains the non-zero bytes of data in the same order

3.2 BloomBits Trie

为了满足light client要求，将BloomBits以trie展示，可通过GetHelperTrieProofs来获取该trie中的部分信息。
当前BloomBits Trie中的trie root是trusted syncing checkpoint，未来计划将其开发为trustless validation。 【Currently, light clients have a trusted blockchain checkpoint built into their code. Thanks to this, the client only needs to download the latest headers, allowing it to achieve a sync in a matter of seconds. Light client users are trusting the client developers to integrate a valid checkpoint. This tradeoff is considered acceptable as users already need to trust the developers for the client implementation. 】

The trie consists of the compressed bit vectors as values stored at keys constructed from the the bloom bit index encoded as a 2-byte big endian, followed by the section index encoded as an 8-byte big endian. Since all-zero bit vectors have a zero length when compressed, these vectors are not added to the trie at all.

BloomBits tries are generated for each new section of transformed bloom filter data by adding the vectors belonging to the latest section index to the previous trie.

4. Client Side Flow Control

LES protocol中承担server角色的node需要能控制在特定时间内其为每个client peer所提供的工作量。

5. 以太坊light client现状

当前，运行light client仅需约300MB RAM，CPU utilization仅为a few cycles to verify block headers every 15 seconds or so when new blocks come out。

Light client通常不从genesis开始同步，Each build of the client ships with a checkpoint for the network, and it only has to sync forward from that checkpoint。Geth builds come out once or twice a month, so if you keep up to date you won’t have to sync more than a few weeks, which even on a mobile device shouldn’t take more than a few minutes if you have adequate peers.

当前light client最大的问题是找到full node来peer with。 light client需完全依赖full nodes将其接收为peers。很多full node根本不接收light client peers。而接收light client peers的full node通常处于满负荷状态。
通常，启动一个light client需要约20分钟才能找到一个full node将其接收为peer，然后又随机丢失，从而无法保持同步状态。

如 Parity团队成员2018年博客 What is a light client and why you should care? 中所述：
light client符合主流应用诉求，如发送交易，并验证账户余额。
当前对light client的主要批判在于：light client对整个区块链网络无益。light client：

不会验证除其自身交易之外的其他交易
不会给网络中的其他节serve 或 relay信息。
需要使用全节点的资源，但是没有任何回报。

相比于全节点，在保证终端用户以去中心化和安全的方式访问区块链的前提下，light client提供了更好的用户体验。
当前的关键，是要激励运行全节点的个人或机构，提供light node支持，同时惩罚提供bad data的作恶全节点。

还有一种方案是允许全节点提供关于the latest known header的零知识证明（如 zk-STARK），这样light client可verify该proof，并sync with the top of the chain without prior knowledge of the blockchain state。

参考资料

[1] What’s the status of Ethereum Light Client?
[2] 以太坊 Light Client Protocol
[3] Light Ethereum Subprotocol (LES)
[4] Client Side Flow Control model for the LES protocol
[5] 以太坊 Nodes and Clients
[6] Geth Light Client

Ethereum light client