Hyperledger Fabric 架构解析

Hyperledger Fabric架构提供以下优点：

链码信任的灵活性。该架构将链码（块链应用）的信任假设与信任假设的排序进行分解。换句话说，排序服务可以由一组节点（orderers）提供，并且容许其中的一些节点失败或行为不正，并且支持者对于每个链码可以是不同的。

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

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

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

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

系统架构

交易背书的基本工作流程

认可政策

第二部分：Post-v1元素的架构

1.分类帐检查点（修剪）

系统架构

块链是由许多节点组成的分布式系统，它们彼此通信。 块链运行称为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）.value表示v，通过s（k）表示v。

KVS操作的建模如下：

（k，v），对于K中的k’，V中的v’取块状态，并将其改为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）。 此外，同行可以有一个特别的支持者角色。

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

下面更详细地解释节点的类型。

1.3.1。客户

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

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

1.3.2。对等体

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

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

1.3.3。订购服务节点（Orderers）

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

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

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

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

分类帐和块形成。分类帐（参见第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（）事件的参数的加密哈希值。这将在交付（）事件中建立一个散列链，用于帮助验证订单服务输出的完整性，稍后将在第4节和第5节中讨论。在第一个deliver（）事件的特殊情况下，prevhash具有默认值。

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

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

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

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

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