首页| 股票|财经|基金|理财|商业|区块链

当前位置:财经中国 > 区块链 >

HyperLedger的共识之状态传输和检查点(五)

2019-08-28 09:35       来源:区块网 | 大东

5.状态传输和检查点

通常情况下,正常运行时,Peer节点会从共识服务收到一系列的deliver()事件(包含批块交易),然后把这些批块追加到原始总账中,并相应地更新区块状态、已验证总账。

然而,由于网络划分或者Peer节点临时停电等原因,一个Peer节点可能错过原始总账的多个批块。这时,Peer节点就必须从其他Peer节点那里传输状态才能和网络中的其他Peer节点保存同步。本节就来看一个实现方法。

5.1.原始总账状态传输(批量传输)

为了解释清楚基本的状态传输怎么实现的,假定Peer节点p原始总账的本地拷贝里最后一个批块序号是25(也就是,最后收到的deliver()事件的seqno等于25)。过了一段时间后,Peer节点p收到共识服务的deliver(seqno=54,hash53,blob)事件。

这个时候,Peer节点p发现它的原始总账副本里缺少26-53号批块。p采用p2p通信从其他节点获取缺失的批块。它呼叫其他Peer节点传给它缺失的区块。在传输缺失批块过程中,p继续监听来自共识服务的新批块。

注意p不需要信任任何通过状态传输从那里获取缺失批块的Peer节点。因为Peer节点p有批块53的哈希(就是,hash53),这是直接从共识服务那里获取到的,是p信任的,当收到了所有的批块,p就可以验证缺失区块的完整性。验证过程会检查他们是否是一个完整的哈希链。

当p获取到了所有的缺失批块并验证了缺失的批块号26-53,它就可以按照第2.5部分的步骤处理26-54的每一个批块,然后构造区块链状态和已验证总账。

注意即使p缺失一些序号比较大的批块,它仍然可以在收到序号小的区块的时候就开始重建区块链状态和已验证总账。但是,在保存状态和提交区块到已验证总账之前,Peer节点p还需要完成缺失区块的状态传输(我们给的例子里,要包含53号批块),还要处理第2.5部分描述的单独传输的批块。

5.2.检查点

原始总账里包含了无效的交易,它们不需要永久保存。但是,Peer节点不能在建立了相应的已验证区块后就简单的丢弃原始总账批块,进而精简原始总账。就是说,这个时候,如果有新的Peer节点加入网络,其他Peer节点不能给它传输被丢弃的批块(在原始总账里),也不能让新加入的Peer节点相信传输给它的(已验证)区块的有效性。

为了便于精简原始总账,本文介绍一种检查点机制。它是在Peer节点网络之间建立已验证总账区块的有效性,允许建立了检查点的已验证总账区块替换丢弃的原始总账批块。这就减少了存储空间,因为没有必要存储单个的交易了。它还减少了新加入Peer节点重建状态的工作(因为它们不需要从原始总账中重构状态的时候构建单个交易的有效性了,只需要简单的重放已验证总账里的状态更新)。

注意检查点有利于精简原始总账,同时,它也只是一种性能优化,对于正确的设计来说检查点并不是必须的。

5.2.1.检查点协议

Peer节点每CHK个区块就周期性的执行检查点操作,CHK是可以配置的参数。开始的时候,Peer节点会给其他Peer节点广播<CHECKPOINT,blocknohash,blockno,peerSig>消息,其中,blockno是当前的区块号,blocknohash是它的哈希值,peerSig是Peer节点对(CHECKPOINT,blocknohash,blockno)的签名,这里的区块都是已验证总账里的。

一个Peer节点收集CHECKPOINT消息,直到它有足够正确的和blockno、blocknohash匹配的签名信息,就开始构建有效的检查点(看第5.2.2部分)。

给区块号为blockno、哈希为blocknohash的区块建立检查点的时候,一个Peer节点:

如果blockno>latestValidCheckpoint.blockno,则它设置latestValidCheckpoint=(blocknohash,blockno);

保存构成一个有效检查点的Peer节点签名到集合latestValidCheckpointProof中;

(可选)精简批块号小于等于blockno的原始总账。

5.2.2.有效检查点

显然,检查点协议抛了这个问题:什么时候精简原始总账?多少CHECKPOINT消息是“足够多”?。这是检查点有效性策略里面定义的,(至少)有两种可能的方法,也可能一起用:

本地检查点有效性策略(Local(peer-specific)checkpointvalidity策略(LCVP),每个Peer节点相关的)。本地策略就是给Peer节点p指定一个Peer节点集合,这个集合里的Peer节点都是p信任的,它们的CHECKPOINT信息就足够构建一个有效的检查点。比如,Peer节点Alice的LCVP定义的是,需要从Bob或者同时收到Charlie和Dave收到CHECKPOINT消息。

全局检查点有效性策略(Globalcheckpointvaliditypolicy(GCVP))。检查点有效性策略可以全局指定。GCVP和LCVP非常相似,不同的地方在于GCVP是在系统层面(区块链)定义的,而LCVP是在Peer节点层面定义的。举个例子,GCVP可能会这么设置:

每个Peer节点可以信任有7个不同Peer节点确认过的检查点;

有这么一个部署环境,每个投票节点都是一个Peer节点,有f个投票节点可能是(拜占庭)故障的,每个Peer节点可以信任有f+1个不同Peer节点确认过的检查点。

5.2.3.已验证总账状态传输(区块传输)

除了能帮助精简原始总账外,检查点可以在已验证总账区块传输的时候传输状态。这可以部分替代原始总账的批块传输。

从概念上来说,区块传输机制和批块传输是类似的。前面有一个例子,Peer节点p丢失了序号为26-53的批块,从已经给50号区块建立了有效检查点的Peer节点q那里获取了状态。状态传输分为2步:

首先,Peer节点p尝试从Peer节点q那里获取检查点已经更新到第50区块的已验证总账。为此,q给p发送它本地的(latestValidCheckpoint,latestValidCheckpointProof),我们这个例子是latestValidCheckpoint=(hash50,block50)。如果latestValidCheckpointProof满足p的检查点有效性策略,就可以传输26-50区块了。否则,p不会相信q的本地检查点是有效的。p可能选择传输原始总账(第5.1部分)。

如果26-50区块的传输都成功了,p还需要获取已验证总账51-53区块或者原始总账51-53批块的状态传输。为此,p可以简单的按照原始总账批量传输协议(第5.1部分),从q或者其他Peer节点获取这些信息。注意已验证总账区块包含各自原始总账批块的哈希(第4.2部分)。因而,即使Peer节点p在其原始总账中没有包含第50批块,原始总账的批量传输依然可以完成,因为第50区块是包含第50批块的。


声明:本文由入驻区块网专栏作者撰写,观点仅代表作者本人,绝不代表区块网赞同其观点或证实其描述。


相关报道:

    相关新闻

    网友热议