1. 引言

比特币的light client可在不下载并验证所有链上数据的情况下，从链上读取相关交易。
light client应尽可能：

减少对peer的信任
减少带宽数量
减少存储空间
减少所需计算量。

light client的实现方式为：

下载所有区块头：区块头固定为80字节，平均每10分钟产生一个，同步区块头所需的带宽很小。
验证the proofs of work
follow the longest proof-of-work chain。light client并不会check the validity of all blocks in the longest proof-of-work chain，需依赖矿工激励来保障安全。
light client直接从peers下载与其相关的区块数据，并验证该区块数据包含在header chain中。

比特币light client相关提案有：

比特币light client 相关代码实现可参看：

https://github.com/cloudhead/nakamoto（Rust）：已实现了BIP-157/158 中的client side block filtering。仍在开发完善阶段，不建议用于主网真实场景。
https://github.com/lightninglabs/neutrino（Go）：为基于 [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients 提案做的实现。light client仅需同步区块头和a chain of compact block filter headers specifying the correct filters for each block。Filters可load lazily并根据需要存储在数据库中，区块可load lazily并且不需要存储。当前不建议用于主网真实场景。

比特币区块链中的全节点：

fully validates transactions and blocks
几乎所有的全节点都会帮助网络接收来自其他全节点的交易和区块，验证这些交易和区块，然后将这些交易和区块relay给其他全节点。

大多数全节点可支持light client连接：

将light client发起的交易传输至网络；
通知light client会影响其钱包状态的交易。

若没有足够多的全节点来支持light client，则light client将无法通过P2P网络连接，转而使用中心化的服务方式。

当Bitcoin Core启动时，会默认建立与其他全节点的8个outbound connections，使得其可下载最新的区块和交易。
若只想该full node具有钱包功能，8个outbound connection就足够了。但是如果想支持light client和网络中的其他全节点，则还必须配置支持inbound connections。

2. BIP-37 Peer Service层的Connection filtering

BIP-37 Peer Service层的Connection filtering ，使得节点可减少其发送的交易数据量。
在与其它节点完成握手连接后，节点可选择性的设置该连接的bloom filter。

BIP-37提案的动机为：
当前，比特币SPV client需要下载所有区块和交易数据，然后扔掉与其钱包不相关的绝大部分交易。整个下载同步过程会很慢，而且浪费用户的带宽和内存。
为了能让同步更快、更便宜并能运行在内存有限的老手机上，需由remote peers throw away irrelevant transaction before sending them across the network。

BIP-37方案中 light client：

会将其关注的布隆过滤器发送给一个full node peer，然后收到任何匹配该布隆过滤器的新交易或新区块。
然后向该full node peer 请求相关交易及相应的Merkle proof of inclusion in the block。
基于区块头验证该Merkle proof。

BIP-37 light client存在如下问题：【布隆过滤器为probabilistic filter】

布隆过滤器中的数据包含light client地址和unspent output，并需要仔细平衡调整错误率和泄露给peer的信息量，存在隐私泄露问题。
此外，恶意的全节点可能会故意忽略对light client至关重要的数据，而light client不容易探测到该行为。这种情况，对于某些强依赖于链上事件的应用场景来说是无法接受的（如闪电网络中的客户端，需鉴定特定的链上事件）。
支持BIP-37 light client的忠诚的全节点，可能会受恶意构建的布隆过滤器、恶意创建的DOS向量并一致节点继续支持BIP-37协议。

3. BIP-157 Peer Service层的Client Side Block Filtering

基于BIP-37构建的light client存在安全和隐私弱点，同时会对全节点造成DOS攻击问题。

BIP-157 Peer Service层的Client Side Block Filtering，支持light client：

从全节点获取compact probabilistic filters of block content
若filter匹配了相关数据，则下载整个block。

BIP-157使得light client无需依赖a trusted source，即可安全的同步区块。

同时，在BIP-157中定义了a filter header，可作为a commitment to all filters for previous blocks，可探测出提供invalid filters的恶意或错误节点。

BIP-157 light client依赖于至少有一个honest peer可识别出正确的block filters。

与 BIP-37中由light client构建布隆过滤器并将其发送给一个full node peer 相反，BIP-157中由全节点来生成deterministic filters on block data并提供给light client。
若该filter匹配其监视的数据，该light client会下载整个区块。由于filter是deterministic的，当链上有新的区块产生时，其仅需要构建一次并存储在硬盘上。serve deterministic filter所需的计算量很小，并可将一减少I/O的不对称性。I/O的不对称性使得全节点脆弱。
同时light client可确保能看到所有的相关交易，因为该由client来check the validity of filters received form peers。
client端隐私性也得到了提升，其可从任意全节点下载区块，没有哪个全节点可获得client关注的所有信息。

特别关注隐私的light client可借助Private Information Retrieval来匿名获取区块。

4. BIP-158 Peer Service层的Compact Block Filters for Light Clients

BIP-158 Peer Service层的Compact Block Filters for Light Clients，对BIP-157协议中的deterministic filter进行了改进，定义了a structure for compact filters on block data——采用了Golomb-Rice code压缩算法来使filter size最小化，从而减少light client所需的带宽。

Golomb-Rice Coded算法实现可参看：

https://github.com/btcsuite/btcutil/tree/master/gcs

附录1 布隆过滤器

布隆过滤器（Bloom Filter）是1970年由布隆提出的，它实际上是由一个很长的二进制向量和一系列随意映射函数组成。
布隆过滤器是一种基于概率的数据结构，主要用来判断某个元素是否在集合内，它具有运行速度快（时间效率），占用内存小的优点（空间效率），但是有一定的误识别率和删除困难的问题。它能够告诉你某个元素一定不在集合内或可能在集合内。
关于布隆过滤器知识可参看：