BlockChain的轻客户端概念初始源于bitcoin网络,为了在计算资源受限的设备上,也可以验证一笔交易的合法性,研究人员提出了轻客户端的设想;即资源受限的设备上,只存储必要的链上信息,当验证一笔交易的有真实性时,使用密码学证明来为该交易做担保。
Bitcoin Blockchain
在bitcoin早期,个人用户如果需要参与bitcoin网络,它只能通过运行一个full node
, 或者通过一个可信的第三方。
而运行一个full node
需要同步bitcoin网络上所有数据(区块头和所有的交易),对一段时间内的网络带宽有非常大的需求,同时需要耗费比较长的时间;
通过第三方,则存在被欺骗的可能性;同时从根本上抛弃了去中心协议的优势;
在后期,通过引入轻客户端概念,个人用户可以在设备上仅存储bitcoin网络中的区块头数据,当需要验证一笔交易时,让交易提供方提供该交易的密码学证明(即:Merkle Proof);用户的设备首先通过自身存储的数据,验证该交易所在区块的有效性;然后,在通过密码学证明,验证交易肯定存在与该区块中(此处的验证:由两部分数据组成,每个区块头中包含当前区块的所有交易的Merkle树根MerkleRoot
,交易存在于该区块的密码学证明)。
与Ethereum网络不通,因为bitcoin的原生交易,仅用来作为用户之间的转账,并且,bitcoin区块中包含的所有交易,都是有效的交易;因此,只要证明这笔交易包含在区块中,即可认为该交易为有效交易。
代码语言:javascript复制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仍需要同步区块链上的所有区块头,依然是非常大的一笔数据量。
代码语言:javascript复制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