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。

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，然后又随机丢失，从而无法保持同步状态。