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

介绍

此页面记录了区块链基础架构的体系结构，其中区块链节点的角色分为对等(维护状态/分类帐)和分类器(根据分类帐中包含的交易顺序协议)。在通用区块链体系结构(包括Hyperledger结构v0.6和更早版本)中，这些角色是统一的(请参见Hyperledger结构v0.6中的身份验证对等方)。该体系结构还引入了一个经批准的对等体(签名者)，作为一种特殊类型的对等体，负责模拟执行和批准事务(大致对应于HL Fabric 0.6中执行的事务)。

与对等/统计/签名者统一设计(例如HL Fabric v0.6)相比，这种架构具有以下优势。

链码信任的灵活性。该架构将链码(区块链应用)的信任假设与信任假设进行分类。换句话说，订阅服务可以由一组节点(订购者)提供，其中一些节点可以失败或行为不正确，每个链代码的支持者可能不同。

可扩展性。因为负责特定链码的支持者节点与用户正交，所以系统可以比同一节点更好地执行这些功能。特别是，当不同的链码指定不相交的支持者时，会出现这种结果。该代码引入了支持者之间链码的划分，允许并行链码执行(背书)。此外，从代码订阅服务的关键路径中删除了代价高昂的链代码执行。

保密。该体系结构有助于部署对交易内容和状态更新有保密要求的链码。

共识模块化。该架构是模块化的，允许实现可插拔一致性(即订阅服务)。

该架构促进了Hyper-v6.6的开发。如下所述，Hyperledger Fabric v1将包含一些方面，而其他方面将推迟到Hyperledger Fabric的v1后版本。

第1部分:与Hyperledger结构v1相关的模式元素

系统结构

交易背书的基本工作流程

认可政策

第二部分:后v1建筑元素

分类帐检查点(修剪)

1.系统架构(系统架构)

区块链是一个由许多节点组成的分布式系统，这些节点相互通信。区块链运行一个名为chaincode的程序，保存状态和分类账数据，并执行交易。链码是中间元素，因为事务是对链码进行的操作。交易必须“已批准”，只有已批准的交易才能影响状态。可能有一个或多个用于管理功能和参数的特殊链码，它们统称为系统链码。

1.1。贸易

可能有两种类型的交易:

部署事务使用程序作为参数创建一个新的链代码。当部署事务成功执行时，链代码已经安装在块上。

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

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

注意:本文档当前假设事务创建一个新的链代码或调用一个由已部署的链代码提供的操作。本文档没有描述:a)查询(只读)事务的优化(包含在v1中)，b)交叉链接代码事务的支持(后v1功能)。

1.2。区块链数据结构

1.2.1。条件

块的最新状态(或简单状态)被建模为版本化的键/值存储(KVS)，其中键是一个名称，值是一个任意的blob。这些条目通过在区块链运行的链码(应用程序)进行操作，并获得KVS操作。状态被持久存储，并且状态的更新被记录。请注意，版本化的KVS被用作状态模型，实现可能使用实际的KVS、关系数据库管理系统或任何其他解决方案。

更正式地说，状态被建模为映射k->:的元素，其中:

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的运作模式如下:

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

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

分区(订阅服务通道)。订阅服务可以支持多种渠道，类似于发布/订阅(发布/订阅)消息系统的主题。客户端可以连接到给定的通道，然后他们可以发送消息并获取到达的消息。通道可以被视为分区-连接到一个通道的客户端不知道其他通道的存在，但是客户端可以连接到多个通道。尽管Hyperledger Fabric v1中包含的一些订阅服务实现将支持多个频道，但为了简单起见，在本文的其余部分，我们假设订阅服务由一个频道/主题组成。

订阅服务的对应API通过订阅服务提供的接口连接到订阅服务提供的通道。订阅服务应用编程接口由两个基本操作组成(更常见的是异步事件):

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

广播(blob):客户端调用这个广播任意消息blob来通过信道传播。向服务发送请求时，这也称为BFT上下文(blob)中的请求。

传递(seqno，prevhash，blob):排序服务在对等方上调用此命令，传递带有指定非负整数序列号(seqno)和最近传输的blob(prevhash)的哈希的消息blob。换句话说，它是订阅服务的输出事件。在发布-订阅系统中，Delivery()有时称为notify()，在BFT系统中称为commit()。

分类账和区块形成。分类账(见第1.2.2节)包含订阅服务输出的所有数据。简而言之，它是一个传递序列(seqno，prevhash，blob)事件，根据上述prevhash计算形成一个散列链。

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

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

订阅服务属性

订阅服务(或原子广播信道)的保证规定了广播消息时会发生什么以及传输的消息之间存在什么关系。这些保证如下:

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

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

生命力(交付保证):订阅服务的生命力保证由订阅服务的实现来规定。确切的保证可能取决于网络和节点故障模型。

原则上，如果提交客户端没有失败，订阅服务应该确保连接到订阅服务的每个正确的对等体最终都会提交每个提交的事务。

总而言之，订阅服务确保以下属性:

同意。任意两个正确对等体的事件传递(seqno，prev hashp，blob0)和传递(seqno，prev hashp，blob1)与seqno，prevhash0 = = prevhasp，blob0 == blob1相同；

哈希完整性。对于正确对等体的任何两个事件传递(seqno-1，prevhash0，blob0)和传递(seqno，prevhash，blob)，prev hash = hash(seq no-1 | | prev hash 0 | | blob 0)。

如果排序服务在正确的对等p上输出一个传递(seqno，prevhash，blob)，那么seqno >: 0，那么p已经传递了一个事件传递(seqno-1，prevhash0，blob0)。

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

无重复(可选，但可取)。关于任何两个事件广播(blob)和广播(blob ')，当两个事件传递(seqno0，prevhas0，blob)和传递(seqno1，prevhasp，blob ')发生在正确的对等点并且blob == blob '，seqno0 = = seqno1和prevhash0 = = prevhasp。

活动。如果正确的客户端调用事件广播(blob)，那么每个正确的对等体“最终”发出事件传递(*、*、blob)，其中*表示任何值。

2.交易背书的基本工作流程

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

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

2.1。客户端创建一个事务，并将其发送给选定的对等方

为了调用一个事务，客户机向一组选定的支持对等体发送一个“提议”消息(可能不同时——见第2.1.2和2.3节)。给定链码的一组被识别的对等体可以通过对等体提供给客户，并且后者通过识别策略知道一组被识别的对等体(参见第3节)。例如，一个事务可以发送给给定链码的所有支持者。也就是说，有的支持者可能会下线，有的可能会反对，选择不批准交易。提交客户端试图用可用的支持者来满足策略表达式。

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

2.1.1。提议消息格式

PROPOSE消息的格式为，其中tx是强制参数，而anchor是可选参数，解释如下。

Tx =，其中

客户端标识是提交客户端的标识。

ChaincodeID指交易中涉及的链码。

TxPayload是包含提交的事务本身的负载，

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

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

在调用事务和部署事务(即调用涉及特定于部署的系统链代码的事务)之间，txPayload的细节会有所不同。TxPayload将由两个用于调用事务的字段组成

TxPayload =，其中

操作手段链码功能和参数，

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

TxPayload将由三个部署事务字段组成

TxPayload =，其中

Source表示链代码的源代码。

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

策略包括与所有对等体都可以访问的链码相关的策略，例如识别策略。请注意，部署事务中没有提供TxCapload的提交策略，但是部署的TxCapload包含提交策略标识及其参数(参见第3节)。

锚包含读取版本依赖性，或者更具体地，密钥版本对(即锚是KxN的子集)，其将提议请求绑定或“锚定”到KVS的指定版本的密钥(参见1.2节)。如果客户指定锚参数，代理将仅在其本地KVS匹配锚中的相应密钥的读取版本号上批准交易(详见第2.2节)。

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

2.1.2。报文方式

客户决定与支持者互动的顺序。例如，客户端通常向单个代码发送(即没有锚参数)，然后生成一个版本依赖(anchor)，客户端可以在以后将其作为其PROPOSE消息的参数提供给其他支持者。又如，客户端可以直接发送给所有选中的支持者(没有锚点)。不同的通信模式是可能的，客户可以自由决定这些模式(另见第2.3节)。

2.2。识别对方的模拟交易并生成签名

收到

模拟事务包括通过调用事务引用的链码(chaincodeID)和验证对等体本地保存的状态副本来授权对等体临时执行事务(txPayload)。

作为执行的结果，对等体被支持来计算读取版本依赖性(读取集)和状态更新(写入集)，也称为数据库语言的MVCC+后图像信息。

回想一下，一个状态由一个键/值(k/v)组成。所有k/v条目都是版本化的，也就是说，每个条目都包含有序的版本信息，每当存储在密钥下的值更新时，该信息就会增加。说明事务的对等体记录了链代码访问的所有k/v对，用于读取或写入，但对等体没有更新其状态。进一步:

识别对等体被给予执行事务之前的状态，并且对于事务读取的每个密钥k，对(k，s(k))。版本)添加到读取集中。

此外，对于由事务修改的新值v′的每个密钥k，一对(k，v′)被添加到写入集。或者，v '可以是新值相对于前一个值(s(k))的增量。值)。

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

然后，对等方在内部(可能还有tx)将建议转发给其批准事务的(对等方)逻辑部分，称为批准逻辑。默认情况下，对等审批逻辑接受转账方案，只需签署转账方案即可。然而，支持逻辑可以解释任何功能，例如，以转发建议和tx作为输入与传统系统交互，以达成是否支持交易的决定。

如果批准逻辑决定批准交易，它将向提交客户端(tx.clientID)发送一条消息，其中:

trans-proposal:=(EpID，tid，chaincodeID，txContentBlob，readset，writeset)，

其中txContentBlob是链码/事务特定信息。目的是使用txcontentlob作为tx的某种表示(例如，txContentBlob = tx.txPayload)。

EpSig是一种支持对等体的传输签名

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

请注意，在这一步中，代理不会改变其状态，因此背书上下文中交易模拟生成的更新不会影响状态！

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

提交的客户等待，直到它在(TRANSACTION-SUPPORTED，tid，*)语句中收到“足够”的消息和签名，以便获得交易建议被批准。如第2.1.2节所述，这可能涉及与支持者的一次或多次往返互动。

“足够”的确切数量取决于链码认证政策(另见第3节)。如果符合确认政策，则交易已被批准；注意还没有答应。由签署交易并确认交易被批准的交易所发布的交易信息的集合被称为背书，并由背书表示。

如果提交客户不尝试收集交易提案的背书，它将放弃交易并提供稍后重试的选项。

对于有效的交易，我们现在使用订阅服务。提交客户端使用广播(blob)调用排序服务，其中blob =背书。如果客户端不能直接调用排序服务，它可以通过自己选择的对等代理进行广播。此类同行必须得到客户的信任，并且不要从批准中删除任何消息，否则交易可能被视为无效。但是，请注意，代理对等方可能不会做出有效的背书。

2.4。订阅服务向对等方交付交易

当事件传递(seqno，prevhash，blob)发生并且对等方将所有状态更新应用到序列号低于seqno的blob时，对等方执行以下操作:

它根据所引用的链代码(blob . tran-proposition . chain codeid)的策略检查blob .背书是否有效。

在一个典型的例子中，它还验证依赖关系(blob .背书. tran-proposition . readset)没有被违反。在更复杂的用例中，背书转让方案可能会有所不同。在这种情况下，承认政策(第3节)规定了国家如何演变。

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

如果所有这些检查都通过，则交易被视为有效或已交易。在这种情况下，对等体在对等体的位掩码中将事务标记为1，并将blob .背书. tran-proposition . write set应用于块状态(如果转发方案相同，否则，识别策略逻辑定义获取Blob的功能。背书)。

如果blob .背书的背书策略验证失败，则该事务无效，对等方在对等机的位掩码中将该事务标记为0。请注意，无效事务不会改变状态。

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

图1。可能的事务流程图(常见案例路径)。

3.认可政策

3.1。政策规范的认可

批准政策是同意交易的条件。区块链对等方有一组预先指定的批准策略，这些策略由安装特定链代码的部署事务引用。背书策略可以参数化，这些参数可以由部署事务指定。

为了保证封锁和安全属性，一套审批策略应该是一套功能有限的成熟策略，以保证有限的执行时间(终止)、确定性、性能和安全性。

就有限的策略评估时间(终止)、确定性、性能和安全保证而言，动态添加识别策略(例如，通过在链代码部署时部署事务)非常敏感。所以不允许动态添加识别策略，但以后可以支持。

3.2。背书政策的交易评估

只有根据政策获得批准，交易才被宣布为有效。链码的调用交易必须先经过审批，符合链码政策，否则不提交。这是通过提交客户和批准同行之间的互动来完成的，如第2节所述。

在形式上，背书政策是背书的一个谓词，并可能进一步表明评估为真或假。对于部署事务，根据系统范围的策略获得批准(例如，从系统链代码)。

识别策略谓词引用某些变量。这可能意味着:

与链码相关联的密钥或身份(在链码的元数据中找到)，例如一组签名者；

链码的进一步元数据；

背书要素和背书提案；

可能更多。

上面的列表是按照表达性和复杂性的增加排序的，也就是说，只涉及节点的密钥和身份的支持策略会相对简单一些。

识别策略谓词的评估必须是确定性的。每个对等体应该在本地评估识别，这样对等体就不需要与其他对等体交互，但是所有正确的对等体都以相同的方式评估识别策略。

3.3。认证政策示例

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

假设chaincode指定了一个支持者集合E = {Alice，Bob，Charlie，Dave，Eve，Frank，George}。一些示例策略:

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

任何单个成员的有效签名

根据条件(爱丽丝或鲍勃)和(任意两个:查理、戴夫、伊芙、弗兰克、乔治)，同意转让方案的签名有效。

七个支持者中的任何一个都有相同转发方案的有效签名。(更一般地说，对于n >:3f个签名者的链码，n个签名者中的任意2f+1个有效签名，或任意多于(n+f)/ 2个签名者的群)。

假设对于支持者，如{爱丽丝= 49，鲍勃= 15，查理= 15，戴夫= 10，夏娃= 7，弗兰克= 3，乔治= 1}，总股本为100的有一个“是”或“权重”:政策要求一个拥有多数股权的集合(即合并后的股份严格超过50股)。等等。

前面示例条件中的份额分配可以是静态的(固定在链代码的元数据中)，也可以是动态的(例如，取决于链代码的状态，并在执行过程中进行修改)。

4.1。验证分类帐(VLedger)

为了保持分类账的抽象性，只包括有效且已提交的交易(如比特币中出现的交易)，除了状态和分类账外，对等方还可以维护验证分类账(或VLedger)。这是一个哈希链，通过过滤无效交易从分类帐中派生出来。

VLedger块(此处称为vBlock)的构造如下。由于对等块可能包含无效事务(即，无效的已批准事务或无效的版本依赖关系)，来自该块的这些事务在被添加到vBlock之前被对等体过滤掉。每个对等体自己执行该操作(例如，通过使用与对等体相关联的位掩码)。vBlock被定义为没有无效事务的块，并且已经被过滤掉。vBlock本质上是动态的，可以是空。下图显示了vBlock构造的描述

图2。从挖泥船区块验证的分类账区块的形成图。

每个对等体将vBlock链接到一个哈希链。更具体地说，经核实的分类账的每一部分包括:

上一个vBlock的哈希。

vBlock编号。

计算自上次vBlock以来由另一方提交的所有有效事务的有序列表(即，相应块中的有效事务列表)。

导出当前vBlock的相应块的哈希(在对等分类帐中)。

所有这些信息都由对等方连接和散列，并生成一个散列值来验证分类帐中的vBlock。

4.2。皮尔勒杰检查站

分类账包含无效交易，可能无法永久记录。然而，对等体不能简单地丢弃对等体块，从而在建立相应的vBlock时修剪对等体。也就是说，在这种情况下，如果新的对等体加入网络，其他对等体不能将丢弃的块(与对等体相关)转移到加入对等体，并且不能说服加入对等体其vBlock的有效性。

为了方便地删除对等机，本文引入了检查点机制。该机制通过对等网络建立vBlock的有效性，并允许检查点的vBlock替换被丢弃的PeerLedger块。这又减少了存储空的数量，因为不需要存储无效的事务。它还减少了为加入网络的新对等方重新建立状态的工作(因为他们在通过重放对等机来重新建立状态时不需要确定每个事务的有效性，而是可以简单地重放包含在已验证分类帐中的状态更新)。

#### 4.2.1。检查点协议

检查点由对等点的每个CHK块定期执行，其中CHK是一个可配置的参数。为了启动一个检查点，对等体向其他对等体广播(例如，流言)消息，其中blockno是当前的块号，blocknohash是其对应的散列，stateHash是最新状态的散列(例如，由Merkle散列生成)，这是在验证blockno和peerSig期间对等体的签名(CHECKPOINT、blocknohash、blockno、stateHash)。

对等方收集检查点消息，直到获得足够多的与blockno、blocknohash和stateHash匹配的正确签名的消息，以建立有效的检查点(参见第4.2.2节)。

使用块号哈希为块号块号建立有效检查点时，对等方:

如果blockno >:latestvalidcheckpoint . blockno，则对等方被分配latestvalidcheckpoint =(blocknohash，blockno)。

构成有效检查点的每个对等体的签名集合被存储在set latestValidCheckpointProof中，

并将状态哈希对应的状态存储在latestValidCheckpointedState中，

(可选)将其PeerLedger修剪为blockno(包含)。

#### 4.2.2。有效检查点

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

本地(特定于对象)检查点有效性策略(LCVP)。给定对等体p的本地策略可以指定一组对等体，这些对等体是可信的，并且其CHECKTUM消息足以建立有效的检查点。例如，对等爱丽丝的LCVP可以定义爱丽丝需要从鲍勃或查理和戴夫接收检查点消息。

全球检查站有效性政策(GCVP)。可以全局指定检查点有效性策略。这类似于本地对等策略，但仅在系统(区块链)粒度上指定，而不是对等粒度上指定。例如，GCVP可以指定:

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

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