BlockChain的轻客户端演进
BlockChain的轻客户端概念初始源于bitcoin网络，为了在计算资源受限的设备上，也可以验证一笔交易的合法性，研究人员提出了轻客户端的设想；即资源受限的设备上，只存储必要的链上信息，当验证一笔交易的有真实性时，使用密码学证明来为该交易做担保。
Bitcoin Blockchain
在bitcoin早期，个人用户如果需要参与bitcoin网络，它只能通过运行一个full node, 或者通过一个可信的第三方。
而运行一个full node需要同步bitcoin网络上所有数据(区块头和所有的交易)，对一段时间内的网络带宽有非常大的需求，同时需要耗费比较长的时间；
通过第三方，则存在被欺骗的可能性；同时从根本上抛弃了去中心协议的优势；
在后期，通过引入轻客户端概念，个人用户可以在设备上仅存储bitcoin网络中的区块头数据，当需要验证一笔交易时，让交易提供方提供该交易的密码学证明(即：Merkle Proof)；用户的设备首先通过自身存储的数据，验证该交易所在区块的有效性；然后，在通过密码学证明，验证交易肯定存在与该区块中(此处的验证：由两部分数据组成，每个区块头中包含当前区块的所有交易的Merkle树根MerkleRoot，交易存在于该区块的密码学证明)。
与Ethereum网络不通，因为bitcoin的原生交易，仅用来作为用户之间的转账，并且，bitcoin区块中包含的所有交易，都是有效的交易；因此，只要证明这笔交易包含在区块中，即可认为该交易为有效交易。
type BlockHeader struct{
Version int
PrevHash [32]byte //上个区块头的哈希
MerkleRoot [32]byte //当前区块中所有交易的哈希
Bits uint
Nonce uint
TimeStamps uint
}Ethereum Blockchain
以太坊网络中交易，可以认为大致分为两种：普通的账户间转账交易，合约调用交易；而存在于以太坊区块中的交易，仅能保证交易共识的有效性，并无法保证交易一定执行成功(如：合约调用时，EVM执行处错)。因此，以太坊对区块头进行了优化，来提供轻客户端支持。
以太坊通过在区块头中提供三棵树，来给轻客户端提供各种支持；如以太坊通过使用TransactionRoot和交易的密码学证明，来证明该交易存在于区块链上；然后使用StateRoot和相关Key值的密码学证明，来证明指定指定Key上的Value值的有效性。因此用户只需要下载以太坊的所有区块头，即可验证各种消息。
缺点：以太坊和Bitcoin仍需要同步区块链上的所有区块头，依然是非常大的一笔数据量。
type BlockHeader struct{
....
PrevHash [32]byte
StateRoot [32]byte
TransactionRoot [32]byte
ReceiptRoot [32]byte
}Tendermint Blockchain
而Tendermint使用特有的共识协议，又进一步简化了轻客户端所需要存储的数据量。Tendermint共识协议要求每个区块必须被2/3以上的验证者签名，来提供逐块最终化的特性；而实际在Tendermint网络中，验证者的变动一般不会经常发生，因此通过追踪验证者集合，可以验证任意区块的有效性，从而验证区块中任意key-value状态的有效性。
并且tendermint与ethereum类似，在区块头中存储了AppHash来提供状态证明；唯一不同是，提供可证明的数据结构不同：tendermint使用了iavl+, ethereum使用了Patricia Tree;
因为Tendermint使用了即时最终性拜占庭共识算法，只要区块被已知的大于2/3的验证者签名，light client 就可以认为该区块是有效的。下面描述了验证者集合的状态变化：
- 如果验证者集合在区块链运行过程中不产生变化，则可以从创始文件中加载验证者集合，然后验证区块链中的任意区块；
- 如果验证者集合运行过程中发生变化，且区块头中验证者集合的变动小于1/3，则认为该区块是有效的，同时更新本地的验证者集合至当前区块的状态。 如果验证者集合变化很大，则可以通过查询中间状态的区块，直到查询到一个验证者集合变动小于1/3变动的区块，更新本地验证者集合，然后再接着向后验证所需要的区块。采用这种算法，可以减少当light client长时间不上线时，同步至最新状态所需要的数据量。 同时tendermint引入了解绑周期的概念(3周)，来避免Pos中的长程攻击的问题；只要light client每次短线的时长小与这个解绑周期，就可以保证所同步状态的有效性。
Sequential model: uses the headers hashes and the validator sets to verify each adjacent header until it reaches the target header.
Bisection model: finds the middle header between a trusted and new header, reiterating the action until it verifies a header.
- 不可信的区块头在满足下面的几个条件后，被认为是有效的区块
- 1/3的可信验证者集合正确签署了新区块头
- 2/3的新验证者集合签署了新区块头
light_client_bisection_alg.png