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相关提案有：
- BIP-37 Peer Service层的Connection filtering
- BIP-157 Peer Service层的Client Side Block Filtering
- BIP-158 Peer Service层的Compact Block Filters for Light Clients
比特币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算法实现可参看：
附录1 布隆过滤器
布隆过滤器（Bloom Filter）是1970年由布隆提出的，它实际上是由一个很长的二进制向量和一系列随意映射函数组成。
布隆过滤器是一种基于概率的数据结构，主要用来判断某个元素是否在集合内，它具有运行速度快（时间效率），占用内存小的优点（空间效率），但是有一定的误识别率和删除困难的问题。它能够告诉你某个元素一定不在集合内或可能在集合内。
关于布隆过滤器知识可参看：
参考资料
[1] Nakamoto: a new Bitcoin light-client
[2] Bitcoin core Running a full node