介绍
作者：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 =背书。如果客户端没有直接调用排序服务的能力，它可以通过其选择的某个对等体代理广播。这样的对等体必须被客户信任，不要从认可中删除任何消息，否则交易可能被视为无效。请注意，然而，代理对等体可能不会制定有效的认可。
