区块链超级记帐本架构概览

介绍

作者：Elli Androulaki，Christian Cachin，Konstantinos Christidis，Chet Murthy，Binh Nguyen和MarkoVukolić

该页面记录了块链基础架构的架构，其中块链节点的角色分为对等体（维护状态/分类帐）和排序者（根据分类帐中包含的事务顺序的同意）角色。在通用的块链体系结构（包括Hyperledger Fabric v0.6及更早版本）中，这些角色是统一的（参见Hyperledger Fabric v0.6中的验证对等体）。该体系结构还引入了认可的对等体（签名者），作为负责模拟执行和批准事务的特殊类型的对等体（大致对应于HL Fabric 0.6中执行的事务）。

与对等体/统计者/签名者统一的设计（例如，HL Fabric v0.6）相比，该架构具有以下优点。

链码信任的灵活性。该架构将链码（块链应用）的信任假设与信任假设进行排序。换句话说，订购服务可以由一组节点（订单者）提供，并且容许他们中的一些节点出现故障或不正当行为，并且支持者对于每个链码可能是不同的。

可扩展性。由于负责特定链码的支持者节点与订户正交，所以系统可能比这些功能由相同节点完成的更好。特别地，当不同的链码指定不相交的支持者时，会产生这种结果，该代码引入了支持者之间的链式代码的划分，并允许并行的链码执行（背书）。此外，从代码订购服务的关键路径中删除可能成本高昂的链码执行。

保密。该架构便于部署具有关于其事务的内容和状态更新的机密性要求的链码。

共识模块化。该架构是模块化的，并允许可插拔的一致性（即订购服务）实现。

这种架构推动了Hyper-v6.6后发展。如下所述，其中的一些方面将被包含在Hyperledger Fabric v1中，而其他方面则被推迟到Post-v1版本的Hyperledger Fabric。

目录

第一部分：与Hyperledger Fabric v1相关的架构元素

• 系统架构
• 交易背书的基本工作流程
• 认可政策 第二部分：架构的Post-v1元素
• 分类帐检查点（修剪）

1.系统架构(System architecture)

块链是由许多节点组成的分布式系统，它们彼此通信。块链运行称为chaincode的程序，保存状态和分类帐数据，并执行事务。链码是中间元素，因为事务是在链码上调用的操作。交易必须“认可”，只有认可的交易可能会对状态产生影响。可能存在用于管理功能和参数的一个或多个特殊链码，统称为系统链码。

1.1。交易

交易可能有两种类型：

部署事务创建新的链码，并以程序为参数。当部署事务成功执行时，链码已被安装在块上。

调用事务在先前部署的链码的上下文中执行操作。调用事务是指链码及其提供的一个功能。当成功时，链码执行指定的功能 - 这可能涉及修改相应的状态，并返回一个输出。

如后所述，部署事务是调用事务的特殊情况，其中创建新链码的部署事务对应于系统链码上的调用事务。

备注：本文档目前假设事务创建新的链码或调用一个已经部署的链码提供的操作。本文档还没有描述：a）查询（只读）交易的优化（包含在v1中），b）支持交链代码交易（post-v1功能）。

1.2。块链数据结构

1.2.1。状态

块（或简单的状态）的最新状态被建模为版本化键/值存储（KVS），其中键是名称，值是任意的blob。这些条目由通过放置运行在块链上的链码（应用程序）进行操作，并获得KVS操作。状态被持久存储，并且状态的更新被记录。注意，版本化KVS被采用为状态模型，实现可能使用实际的KVS，也可以使用RDBMS或任何其他解决方案。

更正式地，状态被建模为映射K - >（V X N）的元素，其中：

K是一组键

V是一组值

N是版本号的无限有序集合。注入函数next：N - > N取N的元素并返回下一个版本号。

V和N都包含一个特殊元素\ bot，这在N是最低元素的情况下。最初所有的键映射到（\ bot，\ bot）。对于s（k）=（v，ver），我们用s（k），vue表示v，由s（k）表示v。

KVS操作模型如下：

（k，v），对于k中的k和V中的k，获取块状态，并将其改变为s'，使得s'（k）=（v，next（s（k）.version））对于所有k'！= k，s'（k'）= s（k'）。

get（k）返回s（k）。

国家由同行维护，但不由订单人和客户维护。

状态分区。 KVS中的密钥可以从其名称中识别为属于特定的链码，因为只有特定链码的事务可以修改属于该链码的密钥。原则上，任何链码都可以读取属于其他链码的密钥。支持交链代码交易，修改属于两个或更多链码的状态是一个post-v1功能。

1.2.2分类帐

分类帐提供了所有成功的状态变化（我们谈论有效的交易）和在系统运行期间发生的改变状态（我们谈论无效的交易）的尝试的成功的历史。

分类帐由订购服务构建（见第1.3.3节），作为（有效或无效）交易块的完全有序的散列。散列链将块的总顺序施加在分类帐中，每个块包含完全有序事务的数组。这对所有交易都施加了整个订单。

分类帐被保留在所有同伴，并且可选地在一些订户的子集。在订阅者的上下文中，我们将分类帐称为OrdererLedger，而在对等体的上下文中，我们将分类帐称为PeerLedger。 PeerLedger与OrdererLedger不同之处在于，对等体本地保留了一个位掩码，它将有效的事务从无效的事务中分离出来（详见第XX部分）。

Peer可以修剪PeerLedger，如第XX部分（post-v1功能）中所述。 Orderers维护OrdererLedger的容错和可用性（PeerLedger），并可以决定随时修剪它，只要订购服务的属性（见第1.3.3节）得到维护。

分类帐允许对等体重播所有交易的历史记录并重建状态。因此，第1.2.1节所述的状态是可选的数据结构。

1.3。节点

节点是块链的通信实体。在不同类型的多个节点可以在同一物理服务器上运行的意义上，“节点”只是逻辑功能。重要的是如何将节点分组在“信任域”中并与控制它们的逻辑实体相关联。

有三种类型的节点：

客户端或提交客户端：向代理人提交实际交易调用的客户端，并向订购服务广播交易提案。

对等：提交交易并维护状态的节点和分类帐的副本（请参见Sec，1.2）。此外，同龄人可以担任特别代言人的角色。

订购 - 服务节点或订单：运行实现传递保证的通信服务的节点，例如原子或总订单广播。

接下来将更详细地解释节点的类型。

1.3.1。客户

客户端代表代表最终用户的实体。它必须连接到对等体以与块链通信。客户端可以连接到所选择的任何对等体。客户创建并从而调用事务。

如第2节所述，客户端与对等体和订购服务器进行通信。

1.3.2。窥视

对等体以订单服务的块形式接收有序状态更新，并维护状态和分类帐。

同行可以另外担任支持同行或代理人的特殊角色。支持对等体的特殊功能发生在特定的链码方面，包括在提交事务之前批准事务。每个链码都可以指定可以参考一组认可对等体的认可策略。该政策为有效的交易签注（通常为一组签名人的签名）定义了必要和充分的条件，如第2节和第3节所述。在安装新的链码的部署事务的特殊情况下，（部署）认可政策是指定为系统链码的认可政策。

1.3.3。订购服务节点（Orderers）

订户形成订购服务，即提供交付保证的通信结构。订购服务可以以不同的方式实现：从集中式服务（例如，在开发和测试中使用）到针对不同网络和节点故障模型的分布式协议。

订购服务为客户端和对等体提供共享通信通道，为包含事务的消息提供广播服务。客户端连接到通道，并可以在通道上广播消息，然后传送给所有对等体。该通道支持所有消息的原子传递，即具有全面订单传送和（具体实现）可靠性的消息通信。换句话说，信道向所有连接的对等体输出相同的消息，并以相同的逻辑顺序将它们输出到所有对等体。这种原子通信保证在分布式系统的上下文中也称为总命令广播，原子广播或共识。所传送的消息是包含在块状态中的候选事务。

分区（订购服务渠道）。订购服务可以支持与发布/订阅（pub / sub）消息系统的主题相似的多个渠道。客户端可以连接到给定的通道，然后可以发送消息并获取到达的消息。通道可以被认为是分区 - 连接到一个通道的客户端不知道其他通道的存在，但是客户端可以连接到多个通道。即使Hyperledger Fabric v1中包含的一些订购服务实现将支持多个通道，为了简单的呈现，在本文的其余部分中，我们假设订购服务由单个通道/主题组成。

订购服务API对等人通过订购服务提供的接口连接到订购服务提供的通道。订购服务API由两个基本操作（更通常的异步事件）组成：

TODO添加了用于在客户端/对等体指定的序列号下获取特定块的API的一部分。

广播（blob）：客户端呼叫这个广播任意消息blob以通过频道传播。当向服务发送请求时，这也称为BFT上下文中的请求（blob）。

传递（seqno，prevhash，blob）：排序服务在对等体上调用此命令，以指定的非负整数序列号（seqno）和最近传送的blob（prevhash）的散列来传递消息blob。换句话说，它是来自订购服务的输出事件。 delivery（）有时在pub-sub系统中称为notify（），或者在BFT系统中称为commit（）。

分类帐和块形成。分类帐（参见第1.2.2节）包含订购服务输出的所有数据。简而言之，它是一个递送序列（seqno，prevhash，blob）事件，它们根据前面描述的prevhash的计算形成一个哈希链。

大多数情况下，出于效率原因，订单服务不会输出单个交易（blob），而是在单个交付事件中分组（批处理）blob和输出块。在这种情况下，排序服务必须强制并传达每个块内的斑点的确定性排序。可以通过排序服务实现动态地选择块中的块的数量。

在下文中，为了方便介绍，我们定义了订单服务属性（本小节的其余部分），并解释了交易背书的工作流程（第2节），假设每个交付事件有一个blob。这些容易地扩展到块，假设块的递送事件对应于块内每个块的单个递送事件的序列，根据上述块内的团块的确定性排序。

订购服务属性

订购服务（或原子广播频道）的保证规定广播消息会发生什么以及传递的消息之间存在什么关系。这些保证如下：

安全（一致性保证）：只要对等体连接足够长的时间到通道（他们可以断开或崩溃，但将重新启动和重新连接），他们将看到相同的一系列交付（seqno，prevhash，blob）消息。这意味着输出（传递（）事件）在所有对等体上以相同的顺序发生，并根据序列号进行，并为相同序列号携带相同的内容（blob和prevhash）。请注意，这只是一个逻辑顺序，一个对等体上的传递（seqno，prevhash，blob）不需要发生在任何实时关系中，以传递（seqno，prevhash，blob），在另一个对等体上输出相同的消息。换句话说，给定一个特定的seqno，没有两个正确的对等体提供不同的prevhash或blob值。此外，除非某些客户端（对等体）实际上被称为广播（blob），而且优选地，每个广播的Blob仅被传送一次，否则不传送值blob。

此外，deliver（）事件包含先前的deliver（）事件（prevhash）中的数据的加密散列。当排序服务实现原子广播保证时，prevhash是来自具有序列号为seqno-1的deliver（）事件的参数的加密散列。这将在delivery（）事件中建立一个哈希链，用于帮助验证订单服务输出的完整性，稍后将在第4和5节中讨论。在第一个deliver（）事件的特殊情况下，prevhash具有默认值。

活力（交付保证）：订购服务的活力保证由订购服务实施指定。确切的保证可能取决于网络和节点故障模型。

原则上，如果提交的客户端没有出现故障，则订购服务应保证连接到订购服务的每个正确的对等端最终都会提交每个提交的交易。

总而言之，订购服务确保以下属性：

协议。对于正确的对等体的任何两个事件传递（seqno，prevhash0，blob0）和传递（seqno，prevhash1，blob1）与相同的seqno，prevhash0 == prevhash1和blob0 == blob1;

哈希诚信。对于正确对等体的任何两个事件传递（seqno-1，prevhash0，blob0）和传递（seqno，prevhash，blob），prevhash = HASH（seqno-1 || prevhash0 || blob0）。

没跳如果排序服务在正确的对等体p上输出传递（seqno，prevhash，blob），使得seqno> 0，则p已经传递了一个事件传递（seqno-1，prevhash0，blob0）。

没有创作。任何事件传递（seqno，prevhash，blob）在正确的对等体必须在一些（可能不同）的对等体之前的广播（blob）事件之前;

没有重复（可选，但可取）。对于任何两个事件广播（blob）和广播（blob'），当两个事件传递（seqno0，prevhash0，blob）和传递（seqno1，prevhash1，blob'）发生在正确的对等体和blob == blob'时，seqno0 = = seqno1和prevhash0 == prevhash1。

活跃度。如果正确的客户端调用事件广播（blob），则每个正确的对等体“最终”发出事件传递（*，*，blob），其中*表示任意值。

2.交易背书的基本工作流程（Basic workflow of transaction endorsement）

在下面我们概述一个事务的高级请求流程。

注意：请注意，以下协议并不认为所有交易都是确定性的，即允许非确定性交易。

2.1。 客户端创建一个交易，并将其发送给所选择的同行

为了调用一个事务，客户端会向所选择的一组支持对等体发送一个PROPOSE消息（可能不是同时 - 见2.1.2节和2.3节）。给定的chaincodeID的一组认可的同伴可以通过对等体向客户提供，而后者又通过认可策略知道一组认可对等体（见第3节）。例如，交易可以发送给给定chaincodeID的所有支持者。也就是说，一些支持者可能离线，其他人可能会反对并选择不批准交易。提交客户端尝试通过可用的支持者来满足策略表达式。

在下文中，我们首先详细说明PROPOSE消息格式，然后讨论提交客户端和代理人之间可能的交互模式。

2.1.1。 PROPOSE消息格式

PROPOSE消息的格式为<PROPOSE，tx，[anchor]>，其中tx是以下解释的强制和锚可选参数。

tx = <clientID，chaincodeID，txPayload，timestamp，clientSig>，其中

clientID是提交客户端的ID，

chaincodeID是指交易所涉及的链码，

txPayload是包含提交的事务本身的有效载荷，

时间戳是由客户端维护的整数单调递增（对于每个新事务）

clientSig是tx的其他字段的客户端的签名。

txPayload的细节将在调用事务和部署事务之间不同（即，调用涉及特定于部署的系统链码的事务）。对于调用事务，txPayload将由两个字段组成

txPayload = <operation，metadata>，其中

操作表示链码操作（function）和参数，

元数据表示与调用有关的属性。

对于部署事务，txPayload将由三个字段组成

txPayload = <source，metadata，policies>，其中

source表示链码的源代码，

元数据表示与链码和应用相关的属性，

政策包含与所有同行可访问的链码相关的政策，如认可政策。请注意，部署事务中不提供txPayload的认可策略，但是adeploy的txPayload包含认可策略ID及其参数（参见第3节）。

锚包含阅读版本依赖关系，或者更具体地说，键版本对（即，锚是KxN的子集），其将PROPOSE请求绑定或“锚定”到KVS中的指定版本的密钥（参见第1.2节）。如果客户端指定了锚参数，则代理人仅在其本地KVS匹配锚中的相应键的读取版本号上才会认可交易（有关详细信息，请参阅第2.2节）。

tx的加密散列由所有节点用作唯一事务标识符tid（即，tid = HASH（tx））。客户端将内存中的tid存储在内存中，并等待来自同意的同行的响应。

2.1.2。留言模式

客户决定与支持者的互动顺序。例如，客户端通常会将<PROPOSE，tx>（即，没有锚点参数）发送到单个代码，然后产生版本相关性（锚），客户端可以稍后将其用作其PROPOSE消息的参数给其他支持者。另一个例子，客户端可以直接向所选的所有支持者发送<PROPOSE，tx>（无锚点）。不同的沟通模式是可能的，客户可以自由决定这些（另见第2.3节）。

2.2。 认可对等人模拟交易并产生签名签名

在接收来自客户端的<PROPOSE，tx，[anchor]]消息时，认证对等体epID首先验证客户端的签名客户端，然后模拟事务。如果客户端指定锚点，那么只有在其本地KVS中的相应密钥的读取版本号（即，如下所定义的读取集合）匹配由锚指定的版本号时，才支持对等体模拟事务。

模拟交易涉及通过调用事务引用的链码（chaincodeID）和认证对等体本地保存的状态的副本来批准对等体暂时执行事务（txPayload）。

作为执行的结果，支持对等体计算读取版本依赖性（readset）和状态更新（writeset），也称为DB语言的MVCC + postimage信息。

回想一下，状态由键/值（k / v）组成。所有k / v条目都进行版本控制，也就是说，每个条目都包含有序版本信息，每当更新存储在密钥下面的值时，它们会增加。解释事务的对等体记录链码访问的所有k / v对，用于读取或写入，但对等体尚未更新其状态。进一步来说：

给予认可对等方执行事务之前的状态，对于由事务读取的每个关键字k，将对（k，s（k）.version）添加到读取集。

另外，对于由事务修改的每个关键字k到新值v'，对（k，v'）被添加到写入集。或者，v'可以是新值到先前值（s（k）.value）的增量。

如果客户端在PROPOSE消息中指定了锚点，则客户端指定的锚点必须等于在模拟事务时由支持对等方产生的读取集。

然后，对等体向内部转发建议（并且可能的tx）转发到其认可交易的（对等体）逻辑部分，称为认可逻辑。默认情况下，同行的认可逻辑接受转交方案，只需签署转交方案。然而，支持逻辑可以解释任意功能，例如，与具有转发提议和tx的传统系统交互作为输入以达成是否支持交易的决定。

如果认可逻辑决定认可交易，则会向提交客户端（tx.clientID）发送<TRANSACTION-ENDORSED，tid，tran-proposal，epSig>消息，其中：

tran-proposal：=（epID，tid，chaincodeID，txContentBlob，readset，writeset），

其中txContentBlob是链码/事务特定信息。意图是将txContentBlob用作tx的一些表示（例如，txContentBlob = tx.txPayload）。

epSig是支持同行的转交签名

否则，如果认可逻辑拒绝批准交易，则代理人可以向提交客户端发送消息（TRANSACTION-INVALID，tid，REJECTED）。

请注意，在此步骤中，代理人不会更改其状态，因此在签注的背景下通过交易模拟生成的更新不会影响状态！

2.3。 提交客户收集交易的背书，并通过订购服务进行广播

提交客户端等待，直到它收到（TRANSACTION-ENDORSED，tid，*，*）语句中的“足够”消息和签名，以得出交易提案被认可。如2.1.2节所述，这可能涉及到一个或多个与支持者的往返交往。

“足够”的确切数量取决于链码认证政策（另见第3节）。如果认可政策得到满足，交易已获得批准;注意它还没有承诺。签署交易签署的交易所签发的交易信息的收集，确认交易被认可，称为背书，并由背书代表。

如果提交的客户端没有设法收集交易提案的背书，则会放弃此交易，并提供稍后重试的选项。

对于有效认可的交易，我们现在开始使用订购服务。提交客户端使用广播（blob）调用排序服务，其中blob =背书。如果客户端没有直接调用排序服务的能力，它可以通过其选择的某个对等体代理广播。这样的对等体必须被客户信任，不要从认可中删除任何消息，否则交易可能被视为无效。请注意，然而，代理对等体可能不会制定有效的认可。

2.4。 订购服务将交易交付给同行

当发生事件传递（seqno，prevhash，blob）并且对等体对序列号低于seqno的blob应用了所有状态更新时，对等体执行以下操作：

它根据其引用的链码（blob.tran-proposal.chaincodeID）的策略来检查blob.endorsement是否有效。

在一个典型的情况下，它还验证了依赖关系（blob.endorsement.tran-proposal.readset）没有被违反。在更复杂的使用案例中，签注的转交方案可能不同，在这种情况下，认可政策（第3节）规定了国家如何演变。

根据为状态更新选择的一致性属性或“隔离保证”，可以以不同的方式实现依赖关系的验证。 Serializable是默认隔离保证，除非链码认证策略指定了不同的保护。可以通过要求与读取集中的每个关键字相关联的版本等于该状态下的密钥版本，并拒绝不满足此要求的事务来提供可序列化。

如果所有这些支票通过，交易被视为有效或已交易。在这种情况下，对等体在PeerLedger的位掩码中将事务标记为1，将blob.endorsement.tran-proposal.writeset应用于块状态（如果转发方案相同，否则认可策略逻辑定义了获取Blob的函数。背书）。

如果blob.endorsement的认可策略验证失败，则该事务无效，并且对等体在PeerLedger的位掩码中将事务标记为0。重要的是要注意，无效的交易不会改变状态。

请注意，这足以使所有（正确的）对等体在处理具有给定序列号的传递事件（块）之后具有相同的状态。也就是说，通过订购服务的保证，所有正确的对等体将接收到相同的递送顺序（seqno，prevhash，blob）事件。由于对注册策略的评估和读取集中的版本依赖性的评估是确定性的，所以正确的对等体也将得出相同的结论，无论一个blob中包含的事务是否有效。因此，所有对等方提交并应用相同的事务序列，并以相同的方式更新其状态。

图1.一个可能的事务流（普通案例路径）的图示。

3.认可政策

3.1。 认可政策规范

一个认可政策，是什么赞成交易的条件。 Blockchain对等体具有一组预先指定的认可策略，这些策略由安装特定链码的部署事务引用。 认可策略可以参数化，这些参数可以由部署事务指定。

为了保证封锁和安全属性，一套认可政策应该是一套具有有限功能的成熟策略，以确保有限的执行时间（终止），确定性，性能和安全性保证。

在有限政策评估时间（终止），确定性，绩效和安全保证方面，动态添加认可政策（例如通过在链代码部署时间部署事务）非常敏感。 因此，不允许动态添加认可政策，但将来可以支持。

3.2。 对背书政策的交易评估

交易只有在根据政策被认可的情况下才被宣告为有效。链码的调用交易首先必须获得满足链码政策的认可，否则将不会被提交。这是通过提交客户和认可对等体之间的交互进行的，如第2节所述。

正式地，背书政策是对背书的一个谓词，并且可能进一步说明评估为TRUE或FALSE。对于部署事务，根据系统范围的策略（例如，从系统链码）获得认可。

认可策略谓词是指某些变量。潜在地可能是指：

与链码相关的密钥或身份（在链码的元数据中找到），例如一组签名者;

链码的进一步元数据;

背书和背书提案的要素;

并可能更多。

上面的列表是通过增加表现力和复杂性来排序的，也就是说，支持仅涉及节点的密钥和身份的策略将比较简单。

认可政策谓词的评估必须是确定性的。每个对等体应当在当地评估认可，以便对等体不需要与其他同伴进行交互，但所有正确的对等体以相同的方式评估认可策略。

3.3。 示例认可政策

谓词可能包含逻辑表达式，并且计算结果为TRUE或FALSE。通常，条件将使用数字签名对由链接代码签名的对等方发出的事务调用。

假设chaincode指定了支持者集合E = {爱丽丝，鲍勃，查理，戴夫，夏娃，弗兰克，乔治}。一些示例政策：

来自E的所有成员的相同转发方案的有效签名

任何单一成员的有效签名

根据条件（Alice OR Bob）和（任何两个：查理，戴夫，夏娃，弗兰克，乔治），同意转交方案的签名有效。

七位支持者中的任何一位的同一个转发方案都有有效的签名。 （更一般地说，对于n> 3f签名者的链码，n个签名者中的任何2f + 1的有效签名，或任何超过（n + f）/ 2个签名者的组）。

假设对于支持者，如{Alice = 49，Bob = 15，Charlie = 15，Dave = 10，Eve = 7，Frank = 3，George = 1}有一个“赞成”或“权重”总股本为100：该政策要求具有多数股权的集合（即，一个合并股份严格超过50个的股份）的有效签名，例如与Alice不同的{Alice，X}，或{大家一起除了爱丽丝}。等等。

先前示例条件中的股份的分配可以是静态的（固定在链码的元数据中）或动态的（例如，取决于链码的状态并且在执行期间被修改）。

（Alice OR Bob）对于tran-proposal1的有效签名以及来自（Charlie，Dave，Eve，Frank，George的任何两个）的有效签名，其中tran-proposal1和tran-proposal2仅在其认可的对等方和状态更新。

这些政策将如何有效地取决于应用程序，解决方案针对代理人的失败或不当行为以及各种其他属性的所需弹性。

4（Post-v1）。 验证分类帐和对账检查点（修剪）

4.1。 验证分类帐（VLedger）

为了保持分类帐的抽象，只包含有效和已承诺的交易（例如在比特币出现），除了状态和分类帐之外，对等方可以维护验证分类帐（或VLedger）。 这是通过过滤掉无效事务从分类帐派生的哈希链。

VLedger块（这里称为vBlock）的构造如下进行。 由于PeerLedger块可能包含无效的交易（即无效认可的交易或具有无效的版本相关性），所以在将来自块的事务添加到vBlock之前，此类事务被对等体过滤掉。 每个对等体本身（例如，通过使用与PeerLedger相关联的位掩码）执行此操作。 vBlock被定义为没有无效事务的块，已被过滤掉。 这样的vBlock在本质上是动态的，可能是空的。 vBlock构造的说明如下图所示

图2.从分类帐（PeerLedger）块中验证的分类帐块（vBlock）的形成图。

每个对等体都将vBlock链接到一个哈希链。 更具体地说，一个经过验证的分类帐的每个块都包含：

以前的vBlock的散列。

vBlock号码。

计算自上一个vBlock以来对方提交的所有有效事务的有序列表（即相应块中的有效事务列表）。

派生当前vBlock的相应块（在PeerLedger中）的散列。

所有这些信息被对等体连接和散列，产生验证分类帐中的vBlock的哈希值。

4.2。 PeerLedger检查点

分类帐包含无效的交易，可能不一定会永久记录。但是，对等体不能简单地丢弃PeerLedger块，从而在建立对应的vBlock时修剪PeerLedger。也就是说，在这种情况下，如果新的对等体加入网络，则其他对等体不能将丢弃的块（与PeerLedger相关）传送给加入的对等体，也不能说服加入对等体其vBlock的有效性。

为了方便修剪PeerLedger，本文档介绍了一个检查点机制。该机制通过对等网络建立vBlock的有效性，并允许检查点的vBlocks替换丢弃的PeerLedger块。这反过来又减少了存储空间，因为不需要存储无效的事务。它还减少了为加入网络的新对等体重建状态的工作（因为他们不需要通过重播PeerLedger来重建状态时确定各个事务的有效性，而是可以简单地重放验证的分类帐中包含的状态更新）。

#### 4.2.1。检查点协议

检查点由对等体每个CHK块定期执行，其中CHK是可配置参数。要启动一个检查点，对等体向其他对等体广播（例如，八卦）消息<CHECKPOINT，blocknohash，blockno，stateHash，peerSig>，其中blockno是当前块号，blocknohash是其相应的散列，stateHash是最新状态的哈希（由例如Merkle哈希生成）在块blockno和peerSig的验证时，是（CHECKPOINT，blocknohash，blockno，stateHash）上的对等体签名，参考验证的分类帐。

对等体收集CHECKPOINT消息，直到获得足够的具有匹配blockno，blocknohash和stateHash的正确签名消息，以建立有效的检查点（参见第4.2.2节）。

在使用blocknohash建立块号blockno的有效检查点时，对等体：

如果blockno> latestValidCheckpoint.blockno，则对等体分配latestValidCheckpoint =（blocknohash，blockno），

将组成有效检查点的各个对等体签名的集合存储到set latestValidCheckpointProof中，

将stateHash对应的状态存储到latestValidCheckpointedState中，

（可选）将其PeerLedger修剪成阻止号码blockno（包括）。

#### 4.2.2。有效检查点

显然，检查点协议提出了以下问题：对等体何时可以修剪其PeerLedger？ CHECKPOINT消息有多少“足够多”？这是由检查点有效性策略定义的，至少有两种可能的方法，它们也可以组合起来：

本地（特定于对象）检查点有效性策略（LCVP）。给定对等体p的本地策略可以指定一组对等体，对等体p信任，并且其CHECKPOINT消息足以建立有效的检查点。例如，对等体Alice的LCVP可以定义Alice需要从Bob或者Charlie和Dave两者接收CHECKPOINT消息。

全球检查点有效性政策（GCVP）。全局可以指定检查点有效性策略。这与本地对等策略相似，只是在系统（块链）粒度上规定，而不是对等粒度。例如，GCVP可以指定：

如果由11个不同的对等体确认，每个对等体可以信任检查点。

在特定部署中，每个订户与同一机器（即信任域）中的对等方并置，并且最多可能是（拜占庭）可能（拜占庭））故障，每个对等体可以信任检查点，如果f + 1不同对等体确认与定居者并列。