Welcome to Hyperledger Fabric 中文文档's documentation!¶

核心概念¶

Fabric 介绍¶

Hyperledger Fabric 是一个模块化架构的分布式账本平台，提供高度的机密性，弹性，灵活性和可扩展性。它旨在支持不同组件的可插拔实现，并且可以容纳生态系统中存在的高度复杂应用。

与别的区块链解决方案不同的是，Hyperledger Fabric 提供了独一无二的可伸缩架构。它也是为了满足未来需要审核的企业级区块链需求，从而在此基础上建立的开源架构。Hyperledger Fabric 将是你的起点。

我们建议首次使用的用户先阅读下面的介绍，以便熟悉区块链的工作方式以及 Hyperledger Fabric 的特定功能和组件。

一旦你感觉良好之后 — 或者说你已经熟悉了区块链以及 Hyperledger Fabric，那就跳到 Getting Started 章节，在那里探索更多的样例，技术规范，以及API等等。

什么是区块链？¶

分布式账本（A Distributed Ledger）

区块链网络的核心是一个分布式账本，用于记录在网络上发生的所有交易。区块链账本通常被描述为去中心化的，因为它被复制到许多网络参与者中，每个参与者都在协作维护。我们将看到，分权和协作是反映企业在现实世界中交换产品和服务方式的强大属性。

除了去中心化和协作之外，记录在区块链中的信息只能追加，使用加密技术可保证一旦交易添加在账本中，便无法对其进行修改。这种无法篡改的特性使得判断信息的来源变得很简单，因为参与者可以肯定信息在事后没有被改变。这就是区块链有时被描述为证明体系的原因。

智能合约（Smart Contracts）

为了支持信息一致性更新 —— 启用一整作用于账本的功能（交易，查询等） —— 区块链网络使用智能合约来提供对账本访问控制。

智能合约不仅是简单的封装信息在整个网络中同步，它们也可以被写入以允许参与者的一些交易能自动执行。例如，可以写一份智能合约，通过物品何时到达来决定传输费用。双方一旦同意该条款并写入账本中，当商品到达时，相应的资金将会自动被转入。

共识（Consensus）

通过网络保持分类账交易同步的过程 — 确保账本只有在交易获得相应的参与者批准时才更新，并且当账本更新时，它们以包含相同的顺序区块来更新账本 — 这个过程就称为共识。

我们将在后面学习更多关于账本、智能合约和共识的知识。就目前而言，将区块链视为共享的、复制的交易系统就足够了，该交易系统通过智能合约进行更新，并通过称为共识的协作过程保持一致同步。

为什么区块链有用？¶

现有的记录系统

今天的交易网络仅仅是对老旧的商业记录保存进行简单的更新。一个商业网络的成员彼此进行交易，但他们各自都维护着一套交易记录 — 无论是16世纪的佛兰芒挂毯还是今天的证券 — 每次出售时都必须确立其出处，以确保出售商品的商家拥有一系列产权。

它看起来像这样的商业网络：

现代技术已经从石板和纸质文件夹的时代过渡到硬盘驱动和云平台了，但是其底层架构是相同的。用于管理网络参与者身份的统一系统不存在，建立起源非常费力，需要数天的时间才能清除证券交易（世界量级是数万亿美元），合同必须手动签名和执行，并且系统中的每个数据库都包含唯一信息，因此意味着单点故障的发生。

交易对可见性和信任体系的需求是明确的，但今天的信息和流程分享方法仍然不可能建立跨越商业网络的记录系统。

区块链的与众不同之处

如果，相对于现在这种低效的交易系统，提供了一种标准体系来建立身份网络、交易自动执行、和数据同步存储会怎样？如果通过查看交易清单，一旦写入就不允许更改，以此来建立资产来源机制会如何？是不是这样，就能够形成信任体系呢？

上图描述了一个区块链网络，每个参与者都有自己的账本副本。除了共享账本信息之外，账本更新的过程也是共享的。与今天的系统不同，今天的系统是私人的程序用来更新私人的账本，而区块链系统则是通过共享程序来更新共享的账本。

凭借通过共享账本协调业务网络的能力，区块链网络可以减少与私人信息处理时间、成本和风险，同时提高相互信任度和信息透明度。

您现在知道区块链是什么以及它为什么有用。区块链还有很多其他重要的细节，但都跟上面所提到的信息和流程共享的基本思想分不开。

什么是 Hyperledger Fabric?¶

Linux 基金会于2015年创立了 Hyperledger，以推进跨行业区块链技术。相对于声明一个的区块链标准，它鼓励通过社区协作流程来开发区块链技术，鼓励开源来开发知识产权并最终采用一套标准。

Hyperledger Fabric 是 Hyperledger 中的区块链项目之一。像其他区块链技术一样，它具有账本，使用智能合约，并且系统是参与者管理其交易的。

Hyperledger Fabric从其他一些区块链系统中脱颖而出的地方在于它是私密的并且是权限化的。相对于允许未知身份参与网络的开放式权限系统（需要工作证明等协议来验证交易和保护网络）。Hyperledger Fabric 网络的成员通过注册可信成员服务提供商（Membership Service Provider 简称 MSP）来保证系统的私密性。

Hyperledger Fabric 还提供多种可热插拔选项。账本数据可以以多种格式来存储，共识机制可以随时切换开关，并支持多种的MSP。

Hyperledger Fabric 还提供了创建频道（channels）的能力，允许一组参与者创建单独的交易账本。对网络参与者中有潜在的竞争对手的情况下，这是一个特别重要的选择 — 例如，他们向某些参与者提供的特殊价格 — 每位参与者都知道。如果两个参与者都在一个频道，那么这些参与者（没有其他人）就拥有该频道的账本副本。

共享账本（Shared Ledger）

Hyperledger Fabric 的账本系统有两个组件：世界状态（world state）和事务日志（transaction log）。每个参与者都将分类帐的副本分配给所属的每个 Hyperledger Fabric 网络。Hyperledger Fabric 中的网络参与者都有一本账本副本。

世界状态组件描述了在特定时间点下账本的状态。这是相当于账本的数据库。交易日志组件记录了构成世界状态的所有交易;由此得出，账本是世界状态数据库和交易日志历史记录的组合。

账本对世界状态有可替换的数据存储。默认情况下，这是一个 LevelDB 键值存储数据库。事务日志不需要是可插拔的。它只记录区块链网络中使用的账本数据库的前后值。

智能合约（Smart Contracts）

Hyperledger Fabric 的智能合约是用 chaincode 实现的，并且被区块链外部应用程序所调用，以此来与账本交互。在大多数情况下，chaincode 仅与账本的数据库组件（世界状态）（例如查询）交互，而不与交易日志交互。

Chaincode 可以用几种编程语言实现。目前支持的 chaincode 的语言是 Go，未来将支持 Java 和其他语言。

私密性（Privacy）

根据网络的需求，企业对企业（B2B）网络的参与者可能对他们共享多少信息非常敏感。对于其他区块链网络而言，隐私不会成为首要问题。

相遇对其他的区块链网络，隐私（使用频道方法）对于 Hyperledger Fabric 是非常关键的要求。

共识（Consensus）

交易必须按照发生的顺序写入账本中，网络中不同的参与者皆是如此。要做到这点，必须建立交易顺序，并且必须实施一种方法，用于拒绝错误（或恶意）插入账本的不良交易。

这是一个老生常谈的计算机科学领域，有很多方法可以实现共识算法，每个方法都有不同的利弊。例如，PBFT（Practical Byzantine Fault Tolerance）可以提供文件副本相互通信的机制，以保持每个副本的一致性，即使在发生损坏的情况下。或者，在比特币中，通过计算加密问题（也被称为挖矿）来实现共识，谁先算出来该区块就算谁的。

Hyperledger Fabric 被设计为允许网络初始者选择最能代表参与者之间存在关系的共识机制。与隐私一样，还有一系列需求;从关系高度结构化的网络到更加点对点的网络。

我们将了解更多的 Hyperledger Fabric 共识机制，其中目前包括 SOLO，Kafka，并且在另一个文档中，会很快将了解到 SBFT（简化的拜占庭容错）。

我在哪里可以学到更多？¶

我们提供了许多教程，将在其中介绍区块链网络中的大多数关键组件，详细了解他们如何与彼此进行交互，然后您将了解相关代码并针对正在运行的区块链网络运行一些简单的交易。我们还为那些想使用 Hyperledger Fabric 来运行区块链网络的人提供教程。

Hyperledger Fabric Model

深入了解本介绍中引入的组件的概念以及其他的几个概念，并描述了它们是如何在样本事务流中一起工作。

Hyperledger Fabric 功能¶

Hyperledger Fabric 是一个实现了分布式账本技术的模块化区块链架构，对此它提供了企业级的安全防护，可扩展性，保密性，以及高性能。

身份管理¶

为了实现权限管控的网络系统，Hyperledger Fabric 提供了包含管理用户 ID 以及对所有网络参与者进行验权的会员身份服务的功能。访问控制列表可以当做额外的权限层，以此来实现不同的用户授权不同的网络操作权限。比如说，一个特定的用户id可以被允许唤起一个 chaincode 应用，但却无法部署新的 chaincode。

隐私与保密¶

Hyperledger Fabric 使相互竞争的商业利益以及任何需要私密交易的群体能够在同一个许可的网络上共存。专用的网络通道（channel）提供一种受限制的消息传输方式，可以向特定的网络成员子集提供事务隐私和机密性。通道上的所有数据（包括交易，成员和频道信息）都是不可见的，任何未明确授予访问该频道的网络成员都无法访问。

高效处理¶

Hyperledger Fabric 按节点类型分配网络角色。为了向网络提供高并发性，事务执行与事务排序及事务广播都是分开的。事务执行的优先级会高于事务排序，这样设计的原因是为了支持多个节点并发的处理事务。这种事务的并发执行特性提高了每个对节点的处理效率，而且也加快了向合约中服务订购者交付的速度。

除了支持并行处理任务外，网络通过劳动分工，分为排序节点（ordering node）与对等节点（peer node），排序节点可以对交易执行进行排序和账本维护，这样一来对等节点也就可以从排序（一致性）工作负载中解脱出来。所有对等节点都不必信任所有的排序节点，反之亦然，因此一个节点上的进程可以独立于另一节点的验证运行。

Chaincode 功能¶

Chaincode 应用程序对由通道上特定类型的事务调用的逻辑进行编码。 chaincode 可以为资产所有权变更指定特定参数，这样一来，就确保所有的更换所有权的交易都遵循同样的规则（同一个参数）。其中 system chaincode 与 chaincode 还有所不同，它定义了整个通道（channel）的操作参数：生命周期和配置类的 system chaincode 定义通道的规则；确认和验证类型的 system chaincode 定义了批准和验证交易的要求。

Hyperledger Fabric 为网络设计者实现了模块化的架构。诸如身份识别、排序（共识）、加密算法都能在 Hyperledger Fabric 网络中选择使用（热插拔特性）。这样的结果是任何行业或公共领域都可以采用通用的区块链体系结构，并保证其网络能够跨市场，监管的进行操作。

Hyperledger Fabric Model¶

本节将讲述 Hyperledger Fabric 中的关键设计特性，它是如何实现全面的，可定制化的企业级区块链解决方案：

资产（Assets）- 资产定义能够在网络上交换几乎所有具有货币价值的东西，就好像现实生活中的食品、古董车、货币期货一样。
Chaincode - Chaincode 的执行与事务排序是分开的，它能够控制不同节点类型的所需信任级别和验证级别，并保障了网络可伸缩性和性能。
账本功能（Ledger Features）- 这种不可修改的、分布式的账本编码了所有的频道（channel）的历史交易记录，并且还包含了类似 SQL 查询功能，来帮助管理员高效的过滤数据和事实证明（数据是不会说谎的）。
私密频道（Privacy through Channels）- 如果存在商业竞争以及监管的行业在通用的区块链网络上运行的话，就使得网络必须提供具有高度隐私和机密性的多边交易，Channel 就是为此而生。
安全 & 会员服务（Security & Membership Services）- 会员授权系统提供了一个可信任的区块链网络，参与者知道所有的交易都可以被授权的监管机构和审计师检测和追踪。
共识（Consensus）- 独特的共识算法可以实现企业所需的灵活性和可扩展性。

资产（Assets）¶

资产可以从有形（不动产和硬件）到无形（合同和知识产权）。 Hyperledger Fabric 提供了使用 chaincode 事务修改资产的功能。

资产在 Hyperledger Fabric 中被表示为键值对的集合，资产状态更改记录为 Channel 分类帐中的事务。资产可以用二进制或 JSON 格式表示。

在 Hyperledger Fabric 中，你可以使用 Hyperledger Composer 工具来轻松定义和使用资产。

Chaincode¶

Chaincode 是定义一个或多个资产的软件，以及用于修改资产的交易指令（类似智能合约）。换句话说，其实就是商业逻辑。chaincode 定义了一系列的规则来读取过滤键值对或者其他数据状态信息，它是在开始交易时初始化的，一旦收到指令会在当前最新账本状态下执行相关代码。chaincode 执行的结果将是键值对（key - value）对象信息，它将会提交到网络中，并被网络中其他的对等节点（peer node）所同步。

账本功能（Ledger Features）¶

在 fabric 中，账本是有序的、无法篡改的包含所有交易状态记录的集合。状态转换可以由网络参与者调用 chaincode 代码而改变，每笔交易都会生成一组资产键值对（key - value），并将其作为创建，更新或删除提交给账本。

账本由区块链（'链'）组成，以便将不可变的、有序的记录存储在块中，就好像一个用于维护当前结构状态的状态数据库（合约中包含各种状态）。每个频道（channel）都有一个账本。每个频道下的对等节点（peer）都会维护一份复制的账本。

使用基于 key 的查找、范围查询和组合键查询来查询和更新账本
可以用多种查询语言做只读查询（如果使用CouchDB作为状态数据库）
只读历史记录查询 - 使用 key 来查询历史记录，以此来实现数据查询方案
交易是由 chaincode 通过 key/value 写入跟读取的方式构成
交易是通过有顺序的排列放入区块中，并且会分发给频道中的其他节点
对等节点（peers）会再次校验该事务并执行相关流程
在附加块之前，节点会执行版本检查机制以确保 chaincode 在读取资产期间，资产状态未发生变化
交易一旦被验证并提交后是无法更改的
在频道账本中包含了一个配置块（configuration block），里面有政策定义、访问控制列表和其他相关信息
频道包含会员服务提供商实例，允许从不同的授权成员发送加密资料

查看 Ledger 章节，深入了解数据库，存储结构和“查询能力”。

私密频道（Privacy through Channels）¶

Hyperledger Fabric 在每个频道都使用了不可篡改账本，同时，chaincode 也能操作修改当前资产状态（例如更新 key/value 键值对）。账本存在于频道范围内 - 也可以在整个网络上共享（假设每个参与者都在共同频道上运作） - 或者也可以将其私有化，包含特定的一组参与者。

在后一种场景下，这些参与者将创建一个单独的频道，从而隔离其交易和账本信息。为了解决想要缩小信息透明度和隐私之间差距的场景，chaincode 只能安装在需要访问资产状态的对等节点上，来执行读取和写入（换句话说，如果节点上 chaincode 未被安装，那么它将无法正确地与账本连接）。

为了进一步混淆数据（隐私性），可以在事务发送到订购服务者之前，或是将块附加到账本之前，使用常用的加密算法（如AES）对 chaincode 中的值进行加密（部分或全部）。一旦加密数据写入了账本中，它就只能由拥有阴私的用户解密。关于更多 chaincode 加密相关的信息，可以移步到 Chaincode for Developers 章节。

安全性 & 会员服务（Security & Membership Services）¶

在 Hyperledger Fabric 交易网络中，所有的参与者身份都是已知的。公钥用于生成组织、网络组件、终端用户、客户端应用程序所需的加密证书。因此，数据访问控制可以在更广泛的网络和频道级别上进行操纵和管理。 Hyperledger Fabric的这种“权限”概念，再加上频道的存在，有助于解决高度关注隐私和机密性的场景。

共识（Consensus）¶

在分布式账本技术中，共识似乎就象征着特定算法，单一功能。然而，共识不仅包括就交易顺序需要达成一致，在 Hyperledger Fabric 中，共识需要经交易提出，交易被认可，到排序，确认和提交。简而言之，共识被定义为对包含区块的一组交易的正确性进行全面验证。

当区块交易的顺序和结果都通过检查时才能达成共识。这些步骤是在交易的生命周期中进行的，并且包括使用政策来规定哪些特定成员必须认可某个交易类别，system chaincode 会确保这些策略得到执行和维护。在写入账本之前，对等节点（peer node）将使用这些 system chaincode 来确保有足够的认可，并且它们来源于正确的实体。在任何包含交易的块被追加到账本之前，将会进行版本检查。此最终检查可防止双重支出操作和消除其他可能危及数据完整性的威胁，并允许针对非静态变量执行功能。

除了多重确认，有效性和版本检查之外，还有交易流程各个阶段上进行的身份验证。访问控制列表在网络的分层结构上实现（订购服务会下发到频道），并且承载的数据会被重复签名，通过不同的架构组件来验证交易请求合法性。总而言之，共识不仅限于对交易排序，而是从交易提出到写入账本的交易过程中，持续不断的检测机制。

可以通过交易流程（Transaction Flow）图表来查看共识可视化的表述。

身份系统 Identity¶

什么是身份系统¶

区块链网络中的角色包括对等节点（peer），订购着，客户端应用程序，管理员等等。这些参与者的身份都封装在X.509数字证书中。这些身份信息真的非常重要，因为他们决定了在网络中参与者具体的权限。 Hyperledger Fabric 在身份中使用 principal 属性来决定他们的相关权限。principal 就像用户 ID 或组 ID 一样，但又更灵活一点，因为他们可以包含更多的参与者身份属性。当我们提到 principal 的时候，其实也就是讲到了系统里参与者身份属性的权限。这些属性通常是参与者的组织单位，组织单元，角色或参与者的特定身份。

更重要的，一个身份必须要是可验证的（也就是说得是真实的身份），因此，身份授权必须来自于最受信赖的系统了。Hyperledger Fabric 中的会员服务提供者（ membership service provider 下文简称MSP）干的就是这个活儿。进一步来说，MSP 代表着组织中决定成员规则的组件，就这样，它管理着组织中成员有效的身份。Fabric 中默认的 MSP 实现使用 X.509 证书作为身份，并采用传统的公钥基础结构（PKI）分层模型。

一个简单的场景来描述身份系统¶

假设你去超市买些杂货，在结账时你注意到商家只支持银联付款。如果你使用支付宝付款，那将不被接受，尽管你的支付宝里有钱并且实名认证过了。

所以，有一个有效的支付方式（如支付宝）并不够，它必须要被商家所接受！PKI 和 MSP 在一起就代表着这种场景，PKI 提供了一系列的身份（银联、万事达、微信、支付宝等等），MSP 决定哪些才是参与网络组织的成员（那种支付能被接受）。

PKI 证书颁发机构和 MSP 提供了相似功能的结合。PKI 就像一个名片提供者 — 它颁发许多不同类型的可验证身份。另一方面，MSP 就像商店接受的银行卡提供商列表 — 决定了商店支付网络中哪些参与者（支付方式）是被信任的。MSP 将可验证身份转变为区块链网络的成员。

让我们深入了解下这些概念吧。

什么是 PKIs?¶

公钥基础设施（PKI）是一组提供网络安全通信的互联网技术。是 PKI 才有了 HTTPS 中的S - 如果您在Web浏览器上阅读本文档，则可能已经使用了 PKI 来确保它来自可靠源。

*公钥基础设施（PKI）的要素。PKI 由证书颁发机构组成，证书颁发机构向各方（例如，服务的用户，服务提供商）颁发数字证书，然后使用这些证书在他们与其环境交换的消息中对自己进行身份验证。CA 的证书废弃列表（CRL）包含着各种无效证书。证书被废弃的原因可能有多种，例如，与证书关联的私人密码资料已被暴露。

区块链网络不仅仅是一个通信网络，它依赖于 PKI 标准来确保各个网络参与者之间的安全通信，并确保发布在区块链上的消息得到正确的验证。因此，了解 PKI 的基础知识以及 MSP 将会非常重要。

PKI有四个关键要素：

数字证书
公匙跟阴匙
证书颁发机构
废弃证书列表

让我们来快速了解下 PKI 的基础吧，如果你想了解更多这块的知识，维基百科将会是个不错的选择。

数字证书（Digital Certificates）¶

数字证书是包含一堆与当事人相关的属性文档。最常用的证书是符合 X.509 standard 标准的，也就是说他允许对第三方结构中的身份详情进行编码。例如，John Doe 在底特律 FOO 公司的会计部门工作，那么密歇根州可能就有一个数字证书包含 SUBJECT 属性，其值为下：C=US, ST=Michigan, L=Detroit, O=FOO Corporation, OU=Accounting, CN=John Doe /UID=123456。John 的证书跟他的身份证很相似 — 它可以提供关键的信息来证明 John 是 John。除了 SUBJECT 外，X.509 标准里还有很多别的属性，先让我们来集中关心下图的信息吧。

这个数字证书描述了名叫 Mary 的当事人。Mary 是该证书的主语，突出显示的 SUBJECT 文本显示了关于 Mary 的关键事实。如你所见，证书里还有很多别的属性。最重要的是，约翰的公共密钥展示在他的证书中，而他的私人密钥却不是，这个签名密钥必须保密。

需要注意的是，Mary 的所有属性都可以使用称为加密的数学技术（字面意义上的“秘密写作”）进行记录，以防证书被篡改将使证书无效。只要对方信任证书颁发者（称为证书颁发机构（CA）），Mary 就可以向他人展示其证书以证明其身份。只要 CA 保证某些密码信息安全（意思是它自己的私人签名密钥），任何阅读证书的人都可以确定有关约翰的信息没有被篡改 - 它总是具有 Mary 的那些特定属性。将 Mary 的 X.509 证书视为无法更改的数字身份证。

验证 & 公匙 & 阴匙（Authentication & Public keys and Private Keys）¶

验证跟消息完整性在安全通信里是非常重要的概念。身份验证要求交换消息的各方可以确定创建特定消息的对方。完整性要求消息在传输过程中不被修改。例如，你可能想要确保你正在与真正的John Doe进行沟通，而不是假冒者。或者换句话来说，如果 John 给你发了一条消息，你可能想确保它在传输过程中没有被其他人篡改。

传统的认证机制依赖数字签名机制，顾名思义，允许一方对其消息进行数字签名。数字签名还保证签名消息的完整性。

从技术上讲，数字签名机制要求每个参与方拥有两个密码连接的密钥：一个是广泛使用的公钥当做认证人，以及用于在消息上产生数字签名的私钥。数字签名消息的收件人可以通过检查发送人公匙下的附加签名是否有效来验证收到消息来源的可靠性和完整性。

阴钥和相应公钥之间的唯一性是使安全通信成为可能的关键魔法。唯一性是指私钥可用于产生只有相应的公钥才能匹配的签名消息，并且仅在相同的消息上。

在上面的例子中，为了验证他的消息，Marry 使用他的私钥在消息上产生一个签名，然后他将该消息附加到消息上。任何使用John的公钥验证签名信息的人都可以验证签名。

证书颁发机构（Certificate Authorities）¶

正如您所看到的，通过由系统信任的权威机构为其发布的数字身份，参与者可以参与区块链网络中的角色或节点。在大多数情况下，数字身份（或简称身份）具有符合 X.509 标准的加密验证数字证书的形式，并由证书颁发机构（CA）。 CA 是互联网安全协议的常见组成部分，您可能听说过一些比较流行的机构：Symantec（最初是Verisign），GeoTrust，DigiCert，GoDaddy 和 Comodo 等等。

证书颁发机构向不同参与者分发证书。这些证书由 CA 进行数字签名（即使用 CA 的私钥），并将实际参与者与其公钥绑定在一起，并且可选地附带一些可理解的属性。显然，如果信任 CA（并且知道它的公钥），它可以（通过验证 CA 在参与者证书上的签名）相信特定参与者是与其证书中的公钥相关联的，并拥有一些其他的属性。至关重要的证书可以广泛传播，因为它们既不包含参与者私钥也不包含 CA 私钥。因此，它们可以充当认证来自不同参与者消息的角色。

事实上，CA本身也有一个证书，可以广泛获得。这允许由 CA 颁发的证书参与者通过检查 CA 证书（阴匙）来验证对方是合法的。

在区块链设置中，每个想要与网络互动的参与者都需要一个身份。在这种情况下，您可以选择使用一个或多个 CA 来给参与者颁发数字证书。这是 CA 为组织参与者提供可验证数字身份的基础。

根 CA，中间 CA 和信任链（Root CAs, Intermediate CAs and Chains of Trust）¶

CA 有两种：根 CA 和中间 CA。由于根 CA（Symantec，Geotrust等）必须将数以亿计的证书安全地分发给互联网用户，因此将此过程分散到所谓的中间 CA 中是有道理的。这些中间 CA 的证书可以是由根 CA 颁发的，也可以是另一中间机构颁发的，这样链中的任何 CA 颁发的证书相互间就形成了一个“信任链”。这种追溯根 CA 的功能不仅可以让 CA 的功能在提供安全性的同时进行扩展 — 使消费证书的组织可以放心地使用中间CA — 它限制了根 CA 的使用程度，如果其受到影响，它会危及整个信任链。反而言之，如果中间 CA 受到影响，则危害程度要小得多。

信任链建立在根 CA 及一堆中间 CA 之上，只要颁发证书的中间 CA 来源于根 CA 或受根 CA 信任的中间 CA。中间 CA 在跨多组织颁发证书时提供了巨大的灵活性，这对于建立可授权的区块链系统非常有用。例如，您会看到不同的组织可能使用不同的根 CA 或不同中间的 CA 但却有着相同的根CA — 这真的取决于网络的需求。

Fabric CA¶

正是因为 CA 非常重要，Fabric 提供了一个内置的 CA 组件，允许您在您的区块链网络中创建 CA。这个组件 — 被称为 fabric-ca，是一个私有根 CA 提供者，能够管理具有 X.509 证书形式的 Fabric 参与者的数字身份。由于 Fabric-CA 是定制 CA，为的是满足 Fabric 的根 CA 需求，因此它本身无法提供用于浏览器中的一般/自动使用的 SSL 证书。然而，由于必须要用 CA 来管理身份（即使在测试环境中），fabric-ca 可以用来提供和管理 ca。使用公共/商业根或中间CA来提供身份证明也是可以的并合适的。

如果你你 fabric-ca 感兴趣的话，可以通过 CA 文档章节来了解更多。

证书废弃列表（Certificate Revocation Lists）¶

证书废弃列表（CRL）很容易理解 - 它只是一个证书的引用列表，因一个或多个的原因而被 CA 废弃。如果您回想文章开头的商店场景，CRL 就像一张不被支持的信用卡列表。

当第三方想验证另一方的身份时，它首先检查颁发 CA 的 CRL，以确保其证书没有被吊销。验证者不是非得去检查 CRL，但是如果他们不这样做，他们就会冒着接受不明身份的风险。

使用 CRL 去确保证书仍然有效。如果假冒者试图将无效数字证书传递给验证方，可以首先检查颁发CA的CRL，以确保其未被列为不再有效。

请注意，被吊销的证书与证书过期不是一回事。已吊销的证书可能没有过期 — 它们通过其他任何方式表明其是完全有效的证书。这与过期的驾驶执照和吊销的驾驶执照之间的区别类似。更多的关于 CRL 的细节，请点击。

现在您已经看到 PKI 如何通过信任链提供可验证的身份，下一步就是了解如何使用这些身份来表示区块链网络的可信任成员。这就是会员服务提供商（MSP）的作用 —— 它会识别区块链网络中的组织成员。

要了解更多关于成员身份的信息，请查看关于 MSP 的概念性文档。

成员关系¶

如果你已经查看了身份系统章节（Identity），你已经了解了 PKI 是如何在信任链中提供可验证的身份的。现在让我们看看这些身份如何用来表示区块链网络的可信任成员。

这就是会员服务提供商（MSP）的作用 — 它识别哪些根 CA 和中间 CA 被信任以此来定义信任域的中成员，例如一个组织。通过列出其成员的身份，或者通过确定哪些 CA 有权为其成员颁发有效身份，或者，通常的做法是通过两者的组合来实现。

MSP的能力不仅仅在于列出谁是网络参与者或频道成员。 MSP 可以识别参与者可能在范围内或 MSP 所代表的组织（信任域）（例如 MSP 管理员，组织细分成员）中扮演的特定角色，并为网络和频道环境中定义访问权限奠定了基础（例如频道管理员，读者，作者）。MSP的配置将通告给所有频道中相关的组织成员（以频道 MSP 的形式）。对等节点，订购者和客户也会维护本地 MSP 实例（也称为本地 MSP ），以便在通道的上下文之外验证其组织成员的消息。此外， MSP 可以识别已被吊销的身份列表（我们在身份证明章节中讨论过这一点，接下来也会讨论如何将此过程扩展到MSP）。

我们稍后会详细讨论本地和频道 MSP。现在让我们来更多地讨论 MSP 的一般做法。

将MSP映射到组织（Mapping MSPs to Organizations）¶

一个组织是一个受管理的成员集合，它可以像跨国公司那么大或亦可以像花店那么小。最重要的是组织他们是在一个 MSP 下管理其成员。请注意，这与在 X.509 证书规范中定义的组织概念不同，这点我们稍后会讨论。

组织与 MSP 之间的排他性关系使得在组织之后命名 MSP 是明智的，在大多数政策配置中，您会发现这个约定。例如，组织 ORG1 可能有一个名为 ORG1-MSP 的 MSP。在某些情况下，组织可能需要多个成员组 — 例如，频道用于在组织之间执行非常不同的业务职能。在这种情况下，拥有多个 MSP 并相应地命名它们是有意义的，例如，ORG2-MSP-NATIONAL 和 ORG2-MSP-GOVERNMENT 。这代表着在 ORG2 根信任成员下，有着名为 NATIONAL 的销售频道以及 GOVERNMENT 的监管频道。

上图展示了组织的两种不同的 MSP 配置。第一种配置显示 MSP 和组织之间的典型关系 — 单个 MSP 定义了组织成员的列表。在第二种配置中，不同的 MSP 用于代表具有国家，国际和政府关系的不同组织团体。

组织单元和 MSP（Organizational Units and MSPs）¶

一个组织经常被分成多个组织单位（OU），每个组织单位都负责不同的事情。例如，ORG1 组织可能同时具有 ORG1-MANUFACTURING 和 ORG1-DISTRIBUTION OU 以反映这些独立的业务线。当 CA 颁发 X.509 证书时，证书中的 OU 字段将指定该身份所属的业务线。

我们稍后会看到 OU 是控制区块链网络中组织成员的。例如，只有来自 ORG1-MANUFACTURING OU 的身份才能够访问某个频道，而来自 ORG1-DISTRIBUTION 的则不能。

最后，它们有时也可以由联盟中的不同组织用来区分对方，虽然这好像对 OU 有点轻微滥用。在这种情况下，不同的组织为了形成信任链，使用相同的根 CA 和中间 CA ，但适当地分配 OU 域以识别每个组织的成员。我们也会看到如何配置 MSP 来实现这一点。

本地以及频道 MSP¶

MSP 以两种形式出现在区块链网络中：频道配置（频道MSP），以及本地参与者的环境（local MSP）。local MSP 定义了节点（Peer 或排序节点）和成员（使用命令行的管理员或使用 SDK 的客户端应用程序）。每个节点和用户都必须定义一个本地 MSP，因为它定义了谁在该级别和频道的上下文之外具有管理或参与权限（例如，谁是节点组织的管理员）。

相反，频道 MSP 定义了频道级别的管理及参与者权限。参与频道的每个组织都必须为其定义 MSP。频道上的对等节点和订购者将在共享相同的频道 MSP 视图，并且此后能够正确辨别出频道参与者。这意味着如果一个组织希望加入某个频道，那么需要整合该组织下的成员 MSP 信任链包含在渠道配置中。否则来自该组织身份的交易将被拒绝。

本地和频道 MSP 之间的主要区别不在于它们的功能，而在于它们的作用范围。

本地和渠道 MSP。每个对等节点的信任域（例如组织）由对等节点的本地 MSP（例如 ORG1 或 ORG2）定义。组织在频道中的表示通过将组织的 MSP 包含在频道中来实现。例如，该图的频道由 ORG1 和 ORG2 管理。类似的原则适用于网络，订购者和用户，但为简单起见，这里没有显示。

本地 MSP 仅在其应用的节点或用户的文件系统上定义。因此，从物理和逻辑角度上来说，每个节点或用户只有一个本地 MSP。但是，由于频道 MSP 可用于频道中的所有节点，因此它们只会在频道配置中逻辑性的定义一次。此外，频道 MSP 会通过共识算法在频道中的每个节点的文件系统上实例化并保持同步。因此，虽然每个节点的本地文件系统上存在频道 MSP 的副本，但逻辑上，频道 MSP 是由频道或网络维护的。

您可能会发现，通过查看区块链管理员安装并实例化智能合约时发生的事情，对了解本地和频道 MSP 的使用方式很有帮助，如上图所示。

管理员 B 通过 RCA1 办法的身份去连接节点，并存储在本地 MSP 中。当 B 试图在节点上安装智能合约的时候，节点会检查本地 MSP， ORG1-MSP,去证实 B 是否真的是 ORG1 里的成员。成功验证后将允许运行安装命令。接下来，B 希望在频道上实例化智能合约。因为这是频道级别的操作，所以必须频道中的所有节点都同意才行。因此，在提交实例化命令之前，频道中的节点必须自行检查 MSP。

大家可以观察到，频道 MSP 就像频道本身一样是一个逻辑结构。它只有在频道节点里的本地文件系统实例化之后，才会有真正的实体，并且能够进行管理。

MSP 等级¶

频道与本地 MSP 之间的分层反映了组织管理本地资源的需求，如对等或排序者节点及其频道资源（例如在频道或网络级别运营的账本，智能合约和联盟）。将这些 MSP 视为处于不同级别是有帮助的，高级别 MSP 处于与网络管理有关问题，而较低级别的 MSP 处理私有身份资源管理。MSP在每个管理级别都是强制性的 - 它们必须为网络，频道，对等节点，共识节点和用户定义。

MSP 级别。对等和订购者的 MSP 是本地的，而频道的 MSP（包括网络配置频道）在该频道的所有参与者之间共享。在此图中，网络配置频道由 ORG1 管理，但另一个应用程序频道可由 ORG1 和 ORG2 管理。peer 节点是 ORG2 的成员并由其管理着，而 ORG1 管理着 orderer 节点。ORG1 信任来自 RCA1 颁发的身份，而 ORG2 信任来自 RCA2 颁发的身份。请注意，这些是管理身份，反映了谁可以管理这些组件。所以当 ORG1 管理网络时，ORG2.MSP 也可以存在于网络定义中。

网络 MSP（Network MSP）：网络配置 — 通过定义参与者组织 MSP 以及这些成员中哪些成员有权执行管理任务（例如创建频道）来定义网络中的成员。
频道 MSP（Channel MSP）：频道维护其成员的 MSP 是非常重要的。频道提供了一组特定的组织之间的私人通信，这些组织又对其进行管理控制。在该频道的 MSP 上下文中解释频道政策定义了谁能够参与频道上的某些操作，例如新增组织，或实例化 chaincode 。请注意，管理频道的权限与管理网络配置频道（或任何其他频道）的权限之间没有必然的关系。管理权限存在于正在管理的范围内（除非规则另有覆盖 - 请参阅下面关于 ROLE 属性的讨论）。
对等 MSP（Peer MSP）：此本地 MSP 在每个 Peer 的文件系统上定义，并且每个 Peer 都有一个MSP实例。从概念上讲，它执行的功能与频道 MSP 完全相同，限制条件是它仅适用于定义它的 Peer 节点中。一个例子是，如果要在 Peer 节点安装 chaincode 的话，那么这是需要经过 Peer MSP 授权评估的。
Orderer MSP：就像 Peer MSP 一样， orderer MSP 也是定义在本地节点文件系统中的。同样， orderer MSP 也是被单个组织所定义，因此，仅有一个 MSP 来记录参与者或受信任的节点。

MSP 结构（MSP Structure）¶

到目前为止，您已经看到 MSP 中最重要的两个要素是使用 CA 的规范来确定相应组织中的参与者或节点成员资格。但是，有更多的元素与这两个元素结合使用来帮助管理成员关系。

上图显示了本地 MSP 如何存储在本地文件系统中。尽管频道 MSP 的物理结构并不完全如此，但它仍然是一个不错方式来帮助了解它们。

正如你所看到的，MSP 有九个要素。在目录结构中考虑这些元素是最简单的，其中 MSP 名称是根文件夹名称，每个子文件夹代表 MSP 配置的不同元素。

让我们更详细地描述这些文件夹，看看它们为什么重要。

Root CAs：此文件夹包含着被根 CA 信任的代表了其 MSP 关系的 X.509 自签名证书。此 MSP 文件夹中必须至少有一个根 CA X.509 证书。

这是最重要的文件夹，因为它标识所有其他证书必须来自它派生出来的CA，以便被视为相应组织的成员。
中间CA（Intermediate CAs）：该文件夹包含组织信任的中间 CA 的 X.509 证书列表。每个证书都必须由 MSP 中的一个根 CA 签署，或者由受根 CA 信任的中间 CA 签署。

直观地看到相对于相应组织结构使用中间 CA，中间 CA 可能代表组织的不同细分，或组织本身（例如，商业 CA 用于组织的身份管理）。在后一种情况下，可以使用 CA 层次结构中较低的中间 CA 来表示组织细分。在这里您可以找到关于 MSP 配置最佳实践的更多信息。请注意，可能有一个没有任何中间 CA 的功能网络，在这种情况下，此文件夹将为空。

与根 CA 文件夹一样，此文件夹定义了必须从中颁发证书才能被视为组织成员的 CA。
组织单元（Organizational Units (OUs)）：它们列在 $FABRIC_CFG_PATH/msp/config.yaml文件中，并包含一个组织单元列表，其中的成员被认为是该 MSP 所代表的组织的一部分。当您希望将组织的成员限制为持有身份（由MSP指定的CA之一签名）且具有特定 OU 的组织时，这一点尤其有用。

指定 OU 是可选的。如果未列出 OU，那么所有的身份都会是 MSP 中的一员 — 只要身份是被根 CA 或中间 CA 所颁发 — 这将会被视为组织的一员。
管理员（Administrators）：这个文件夹中包含了组织中有管理员权限的证书。对于标准的 MSP 类型，文件夹中应该有一个或多个 X.509 标准的证书。值得注意的是，虽然某个参与者具有管理员的角色，并不意味着他们可以管理特定的资源！真正有身份权利去管理系统资源的，是被政策所决定的（policies）。例如，频道政策可能会赋予 ORG1-MANUFACTURING 的管理员有权添加新的组织到频道中，而 ORG1-DISTRIBUTION 的管理员则没有此权限。

尽管 X.509 证书具有 ROLE 属性（例如，指定参与者是管理员），这也是指参与者在其组织中的角色而不是区块链网络中的角色。这与 OU 属性的用途类似，如果它已被定义 —— 指的是参与者在组织中的位置。

如果频道政策允许任何组织（或特定组织）的管理员有权限执行频道功能的话，那么证书中的 ROLE 角色也会起效（如果是管理员角色的话）。通过这种方式，组织角色可以赋予网络角色。这在概念上类似于美国佛罗里达州颁发的驾驶执照是如何授权某人在美国的每个州开车的。
废弃证书（Revoked Certificates）：如果参与者的身份已被撤销，则会识别有关身份的信息 — 而不是身份本身 — 保存在此文件夹中。对于基于 X.509 标准的身份来说，主体题密钥标识符（Subject Key Identifier SKI）和权限访问标识符（Authority Access Identifier AKI）的字符串对是确认该证书未被吊销的关键凭证。

此列表在概念上与 CA 的证书撤销列表（CRL）相同，但它主要涉及保存的是组织废弃会员信息。因此，本地或频道 MSP 管理员可以通过更新 CRL 中的 CA 来通过广播方式快速撤销组织中的角色或节点。这个“列表清单”是可选的。它只会在证书被撤销时填充。
节点身份（Node Identity）：该文件夹包含节点的身份，即与Keystore的内容相结合的密码材料将允许节点在发送给其频道和网络的其他参与者的消息中对其自身进行认证。如果是基于X.509的身份的话，此文件夹包含一个X.509证书。例如，这是对等方在交易提议响应中的证书，以表明对等方已经认可了它 — 随后可以在验证时根据所得到的交易的认可政策对其进行检查。

该文件夹对于本地 MSP 是必需的，并且该节点必须只有一个 X.509 证书。它不用于频道MSP。
密匙的KeyStore（KeyStore for Private Key）：该文件夹是为对等或排序节点（或客户端的本地 MSP）的本地MSP定义的，并且包含节点的签名密钥。此密钥与 Node Identity 文件夹中包含的节点身份密码匹配，并用于签署数据 — 例如签署交易建议回复，作为认可阶段的一部分。

该文件夹对本地 MSP 是强制性的，并且必须包含一个私钥。很明显，访问这个文件夹只能限制当前身份，对 peer 节点有管理责任的用户。

通道 MSP 的配置不包括此部分，因为通道 MSP 旨在提供纯粹的身份验证功能，而不是签署能力。
TLS 根 CA（TLS Root CA）：此文件夹包含该组织信任的用于 TLS 通信的根 CA 的自签名X.509证书列表。TLS 通信的一个例子是对等节点需要连接到排序节点以便它可以接收账本更新。

MSP TLS 信息涉及网络内的节点，即对等节点和排序节点，而不是那些使用网络的节点 — 应用程序和管理员。

此文件夹中必须至少有一个TLS根CA X.509证书。
TLS 中间 CA（TLS Intermediate CA）：此文件夹包含由此 MSP 代表的组织信任的用于 TLS 通信的列表中间CA证书 CA。当商业 CA 用于组织的 TLS 证书时，此文件夹特别有用。与成员中间 CA 类似，指定中间 TLS CA 是可选的。

有关TLS的更多信息，请单击此处。

如果您已阅读此文档以及关于 Identity 的文档，您应该很好地掌握 Hyperledger Fabric 中身份和成员关系的工作方式。您已经看到 PKI 和 MSP 如何用于识别在区块链网络中合作的参与者。除了 MSP 的物理和逻辑结构分层外，您还了解了证书，公钥/私钥和信任链的工作原理。

Peers¶

一个区块链网络主要包含了一堆对等节点（peer node）。对等节点是网络中最基本的元素，因为它们包含了账本以及智能合约。请记住，账本包含了所有智能合约的交易记录且这些记录都是不可篡改的。智能合同和账本分别用于将共享流程和共享信息封装在网络中。对等节点的这些方面使他们成为了解 Hyperledger Fabric 网络的良好开端。

区块链网络的其他元素当然也很重要：账本和智能合约，共识，政策，频道，应用程序，组织，身份和会员体系，您可以在相关专题中阅读更多关于它们的内容。本主题主要讨论对等节点及节点与 Hyperledger Fabric 区块链网络中其他元素的关系。

区块链网络由对等节点组成，每个节点都可以存放账本副本和智能合约副本。在这个例子中，网络 N 由节点 P1，P2 和 P3 组成。 P1，P2 和 P3 各自维护自己账本 L1 的实例。 P1， P2 和 P3 使用 chaincode S1 来访问他们的账本 L1 的副本。

节点可以创建，启动，停止，重新配置，甚至删除。他们公开了一组允许管理员和应用程序与他们提供的服务进行交互的 API。我们将在本主题中详细了解这些服务。

一个关于术语的词（A word on terminology）¶

Hyperledger Fabric 使用它称之为 chaincode 的技术概念实现智能合约 —— 用支持的编程语言，简单的一段代码就能获取账本。在这个主题中，我们通常会使用术语 chaincode，你可以随意将它作为智能合约阅读。这是同一件事！

账本和 Chaincode（Ledgers and Chaincode）¶

让我们更详细地看看对等节点。我们可以看到，对等节点它承载了账本和 chaincode。更准确地说，节点实际上承载了账本的实例和 chaincode 的实例。请注意，这在 Fabric 网络中提供了故意的冗余 —— 它避免了单点故障。我们将在本主题后面详细了解区块链网络的分布式和分散式特性。

对等节点托管了账本实例和 chaincode 实例。在这个例子中，P1 托管一个账本 L1 的实例和一个 chaincode S1 的实例。可以有许多账本和 chaincode 托管在个人对等体上。

由于对等节点是帐本和 chaincode 的宿主，因此如果要访问这些资源，应用程序和管理员必须与对等节点进行交互。这就是为什么对等节点被视为 Hyperledger Fabric 区块链网络的最基本的构建模块。首次创建对等体时，它既没有账本也没有 chaincode。稍后我们将会看到分类账是如何被创建的，以及 chaincode 是如何安装在同行上的。

多账本（Multiple Ledgers）¶

节点能够托管多个账单，这对系统的灵活性很有帮助。最简单的节点配置是拥有一个单独的帐，但对于需要时可以托管两个或更多的账本，这是绝对合适的。

一个托管多个分类账的节点。节点拥有一个或多个账单，每个账单有零个或多个适用于他们的 chaincodes。在这个例子中，我们可以看到对等体 P1 拥有分类账 L1 和 L2 。使用 chaincode S1 访问 Ledger L1。另一方面，可以使用 chaincode S1 和 S2 访问 Ledger L2

尽管一个对等节点完全可能托管一个账本实例，而没有托管访问它的任何 chaincode，但通过这种方式配置对等项非常罕见。绝大多数节点至少会安装一个 chaincode，可以查询或更新节点账本实例。值得一提的是，用户是否已经安装了供外部应用程序使用的 chaincode，对等节点还有特殊的系统 chaincode，这些 chaincode 始终存在。这些不在本主题中详细讨论。

多个 Chaincode（Multiple Chaincodes）¶

节点所拥有的账本数量与可以访问该账本的 chaincode 的数量之间没有固定的关系。节点可能有许多 chaincode 和许多账本可用。

一个托管多个 chaincode 的对等实例。每个分类帐可以有很多 chaincode 访问它。在这个例子中，我们可以看到节点 P1 拥有账单 L1 和 L2。 L1由 chaincode S1 和 S2 访问，而 L2 由 S3 和 S1 访问。我们可以看到 S1 可以访问 L1 和 L2。

稍后我们会看到为什么 Hyperldeger Fabric 中的频道概念在节点上托管多个分类帐或多个 chaincode 时很重要。

应用程序和节点（Applications and Peers）¶

现在我们将展示应用程序如何与节点进行交互以访问账本。账本查询交互涉及应用程序和节点之间的简单三步对话;账单更新交互涉及更多一点，并且需要两个额外的步骤。我们已经简化了这些步骤以帮助您开始使用 Hyperledger Fabric，但不用担心 —— 要理解最重要的是与账单更新相比，账本查询的应用程序节点交互中的差异。

当他们需要访问分类账和连锁码时，应用程序总是连接到节点。Hyperledger Fabric软件开发工具包（SDK）使程序员可以轻松实现这一点 —— 它的API使应用程序能够连接到节点，调用 chaincode 来生成事务，将交易提交给网络，该网络将对交易进行排序并提交给分布式账本，并在此步骤完成时接收事件通知。

通过节点连接，应用程序可以执行 chaincodes 来查询或更新账单。账本查询事务的结果会立即返回，而账本更新涉及应用程序，对等节点和排序节点之间更复杂的交互。让我们来仔细研究一下。

对等节点和排序节点一起工作来确保账本在每个节点中都保持最新。在这个例子中，应用程序 A 连接到 P1 并调用 chaincode S1 来查询或更新账单 L1。 P1 调用 S1 来生成包含查询结果或建议账本更新的提案响应。应用程序 A 收到提案响应，对于查询，过程现在已完成。 O1 将整个网络中的交易收集到块中，并将这些交易分发给所有节点，包括P1。P1 在处理 L1 之前会先验证交易。一旦 L1 被更新， P1 产生一个由 A 接收的事件来表示完成。

节点可以立即将查询结果返回给应用程序，因为满足查询所需的所有信息都位于节点的账单本地副本中。节点不会咨询其他节点，以便将查询返回给应用程序。但是，应用程序可以连接到一个或多个节点来发出查询 —— 例如以证实多个对等节点之间的结果，或者如果怀疑信息可能过期，则从不同的节点检索更新结果。在图中，您可以看到分类账查询是一个简单的三步过程。

更新事务与查询事务比较相似，但有两个额外的步骤。虽然账本更新应用程序也连接到节点以调用 chaincode，与账单查询应用程序不同，单个节点无法执行账单更新，因为其他节点必须首先同意这种操作 —— 这就是共识的过程。因此，节点向应用程序返回更新提议 —— 这个节点将先获得其他节点的同意。第一个额外的步骤 —— 也即第四步 —— 要求应用程序发送一组适当的更新提议到整个节点网络中，该交易需要被整个网络节点所同意。这是通过应用程序使用排序节点将事务打包进区块来实现的，并将它们分发到节点的整个网络，以便在应用到每个节点的账本副本之前，可以对其进行验证。由于整个共识处理需要一些时间才能完成（秒），因此应用程序会异步通知，如步骤5所示。

在本主题的后面，您将详细了解此共识流程的详细性质 — 有关此流程的详细信息，请参阅 Transaction Flow 主题。

对等节点和排序节点¶

我们已经看到，节点形成区块链网络，托管账本和 chaincode（智能合约），可以通过与对等节点连接来进行应用程序查询和更新合同。然而，应用程序和对等节点之间相互作用以确保每个对等节点帐本保持一致的机制是由称为 orderers 的特殊节点保障的，并且这些节点是我们现接下来要重点讨论的。

更新事务与查询事务完全不同，因为单个对等节点本身不能更新账本 —— 它需要网络其他节点的同意。对等节点需要网络中的其他对等节点批准账本更新，然后才能将其应用于节点的本地账本。这个过程称为共识 —— 并且比查询花费更长的时间来完成。当其他的节点都同意了事务之后，交易才能被提交到账本中，此时连接节点的应用程序会被通知。您将会看到更多有关对等节点和排序节点如何管理本节中的共识流程的详细信息。

具体而言，需要更新账本的应用程序涉及3阶段流程，这可确保区块链网络中的所有对等节点都保持其账本彼此一致。在第一阶段，应用程序与批准节点的一个子集一起工作，每个节点都提供了对应用程序的建议账本更新的认可，但不会将提议的更新应用于其本地账本的副本。在第二阶段，这些单独的认可被作为交易收集在一起并打包成块。在最后阶段，将这些块分发回每个对等节点，每个对等节点在应用到该对等节点的分类账副本之前对每个交易进行验证。

正如您将看到的那样，排序节点对于此流程至关重要 —— 因此让我们稍微详细地调查一下应用程序和对等节点如何使用排序节使得账本更新，这些账本更新可以始终适用于分布式复制分类账。

阶段1：提案¶

交易工作流程的第一阶段涉及应用程序和一组节点之间的交互 —— 它不涉及排序节点。阶段1只涉及一个应用程序，要求不同组织的确认所提议的 Chaincode 调用的结果。

为了启动第一阶段，应用程序生成一个交易提案，并将其发送给每个需要的节点进行确认。然后，每个对等节点使用交易提议独立执行 chaincode，以生成交易提议响应。它不会将此更新应用于账本，而是由对等节点签署并返回给应用程序。一旦应用程序收到足够数量的已签名提议响应，交易流程的第一阶段即告完成。我们来仔细研究一下这个阶段。

交易提案由返回节点独立执行并响应提案回复。在这个例子中，应用程序 A1 生成事务 T1 建议 P，它在频道 C 上发送给对等节点 P1 和对等节点 P2 两者。P1 使用事务 T1 交易提议 P 执行 S1 chaincode，生成事务 T1 响应 R1 并带上 E1 的确认。独立地，P2 使用事务 T1 交易提议 P 执行 S1 chaincode，生成事务 T1 响应 R2 并带上 E2 的确认。应用程序 A1 收到交易 T1 的两笔认可答复，即 E1 和 E2。

最初，应用程序选择一组节点来进行账单更新提议。哪些节点会被应用程序选中呢？这取决于确认政策（被 chaincode 所定义），该政策定义了需要确认账本更改提议以被网络接受的一组组织。这就是共识表面的意思 —— 每个重要的组织都必须已经批准账本更改提议，然后才能将其应用到任何节点的账本中。

节点通过添加其数字签名来支持提案响应，并使用其私钥对整个负载数据进行签名。这种认可可以随后用于证明这个组织的节点确实产生了特定的回应。在我们的例子中，如果节点 P1 由组织 Org1 拥有，则认可结果 E1 对应于数字证明“在分类帐 L1 上的交易 T1 响应 R1 已由 Org1 的节点 P1 提供”。

阶段1在应用程序收到来自足够多的节点签名提议响应时结束。我们注意到，不同的节点可以针对相同的交易提案返回不同的交易响应。也可能响应结果是不同的节点里的状态不一的账本或是不同的时间 —— 在这种情况下，应用程序可以简单地请求更新的提案回复。不太可能，但更严重的是，因为 chaincode 产生的结果是非确定性的，导致响应结果也可能会不同。非确定性对 chaincode 和账本是致命的，如果它出现，则表明交易提案存在严重问题，因为不一致的结果显然不能应用于账本。单独的节点是无法知道交易结果是非确定性的 —— 只有收集交易响应以进行比较，才能检测到非确定性。（严格地说，即使这还不够，我们将在交易章节谈到这点，其中详细讨论了非确定性问题。）

在第一阶段结束时，如果应用程序希望这样做，应用程序可以随意的放弃不一致的事务响应，从而高效的终止事务工作流。稍后我们会看到，如果应用程序尝试使用不一致的事务响应集来更新账本，它将被拒绝。

阶段2：打包¶

交易流程的第二阶段是打包阶段。排序节点是这一过程的关键 —— 它接收来自许多应用程序的包含确认提议响应的交易。它将事务进行排序，并将批量事务打包到块中，以准备分发回与排序节点连接的所有对等节点，包括那些的交易确认节点。

排序节点的首要角色就是打包更新账本提案。在这个例子中，程序 A1 发送被 E1 E2 确认过的事务 T1 给排序节点 O1。同时，应用 A2 也发送被 E1 确认过的事务 T2 给排序节点 O1。 O1 一起把事务 T1 T2 打包进了区块 B2 中。我们可以看到在 B2 中，交易顺序是 T1, T2, T3, T4, T5 —— 这可能并不是按照事务到达排序节点的时间排序！（这个例子显示了一个非常简化的排序者配置）

排序节点在特定频道网络中的不同应用程序中并发的接收账本更新提案。它的工作是将这些更新提案安排到一个明确定义的序列中，并将它们打包成块用于后续分发。这些区块将成为区块链的区块！一旦排序节点生成了确定大小的数据块，或者经过最长时间后，它将被发送到在特定频道上所有已连接的对等节点。我们将看到这个区块如何在阶段 3 中处理。

值得注意的是，一个区块中的交易顺序不一定与事务到达排序节点的顺序相同！事务可以按任意顺序打包到一个块中，并且这个顺序成为执行顺序。重要的是有严格的顺序，而不用管具体的顺序是怎样排列的。

这种块内交易的严格排序使得 Hyperledger Fabric 与其他一些区块链稍有不同，别的区块链可能同一个事务可以打包到多个不同的区块。在 Hyperleger Fabric 中，这是不可能发生的 —— 由一组排序节点生成的数据块被认为是最终固定的，因为一旦事务被写入到一个数据块中，那么它在账本中的位置就是不可变的。这意味着在 Hyperledger Fabric 中，永远不可能发生账本分叉的灾难性事件！一旦在一个区块中存储了事务，那么在未来的任何时间里，该交易事务都不可能被改写。

我们也可以看到，虽然对等节点包含了账本和 chaincode，但排序节点绝对不会。每次到达排序节点的事务都被机械式的打包在区块中 —— 排序节点对交易的价值不作任何判断，只是简单的将其包装。这是 Hyperledger Fabric 的一个重要行为 —— 所有交易都按照严格的顺序编组 —— 交易永远不会被丢弃或取消优先级。

在第二阶段结束时，我们看到排序节点承担了收集交易提案更新的简单但至关重要的过程，对它们进行排序，将它们打包成块，以供分发。

阶段3：验证¶

交易工作流程的最后阶段涉及从排序节点（orderer）到对等节点（peer node）的分发和随后的验证，可以将这些区块更新到账本中。具体来说，在每个对等节点中，块中的每个事务都需要经过验证，以确保它在应用于账本前已被所有相关组织一致认可。失败的事务将保留下来用于之后复查，但不应用于账本中。

排序节点的第二个角色就是分发区块到对等节点。在这个例子中，排序节点 O1 分发了区块 B2 到 P1 以及 P2 节点中。节点 P1 处理了区块 B2，导致了其被添加到节点 P1 的账本 L1 中。同时，节点 P2 处理了区块 B2，导致了其被添加到节点 P2 的账本 L1 中。一旦这个过程处理完成，节点 P1 跟 P2 中的账本 L1 会进行相同的更新，并且都通知连接节点的应用程序该交易已经被处理。

阶段3从排序节点向连接到它的所有对等节点分发区块开始。对等节点连接到频道上的排序节点，以便当生成新的区块时，连接到排序节点的所有对等节点都会收到新区块的副本。频道上的每个对等节点都会以相同的方式处理区块。在这种方式下，我们会看到账本将会保持同步。值得注意的是，不是每个对等节点都需要连接一个排序节点 —— 对等节点可以使用 gossip 协议联动其他对等节点。该方式也可以处理账本同步。关于这点我们下次再讨论。

收到一个块后，对等节点将按照块中出现的顺序处理每个事务。对于每笔交易来说，每位对等节点将根据产生该交易的 chaincode 的认可政策，验证交易是否已获得所需组织的认可。例如，某些交易可能只需要由单个组织认可，而其他交易可能需要多次认可才能被视为有效。验证过程是验证所有相关组织都产生了相同的结果。

在交易被成功确认过后，对等节点将尝试把其应用于账本中。为此，对等节点必须执行账本一致性检查，以验证在更新提案生成时账本的状态与分类账的当前状态是否冲突。即使交易完全得到认可，不一致也是可能发生的事情。例如，另一笔交易也可能更新了账本中的同一资产，因此交易更新不再有效，且不能再应用与于账本中。通过这种方式，每个对等节点的账本副本在整个网络中保持一致，因为他们每个人都遵循相同的验证规则。

在成功验证每笔交易后，对等节点将更新账本。失败的交易不会应用于账本，但它们被保留用于审计目的，及时成功的交易也是如此。这意味着对等节点区块与从排序节点接收到的区块几乎完全相同，除了区块中每个事务的有效或无效指示符外。

我们还注意到，阶段3不需要运行 chaincodes —— 这只在第一阶段完成，这很重要。这意味着 chaincode 只会在确认节点上调用，而不会在整个区块链网络中使用。这通常是有帮助的，因为它将 chaincode 的逻辑保密给认可的组织。这与 chaincode（交易提议响应）的输出形成对比，这些响应共享给频道中的每个对等节点，无论他们是否认参与交易确认。这些被指定的确认节点被设计用来提升网络的可拓展性。

最终，每一次区块被提交到对等节点账本时，节点也会返回响应事件来作为响应（给应用程序）。块事件包括完整的块内容，而块交易事件仅包含摘要信息，例如块中的每个事务是否已被验证或无效。chaincode 执行产生的 Chaincode 事件也可以在这个时候发布。应用程序可以注册这些事件类型，以便它们在发生时得到通知。这些通知结束了交易工作流程的第三个也是最后一个阶段。

总之，在阶段3可以看到排序节点生成的区块，会一致的应用于账本中。交易模块的严格排序保证了对等节点验证网络中的交易事务更新时的一致性。

排序节点与共识¶

整个交易工作流程过程被称为共识，因为所有对等节点都已经在由排序节点的帮助下，就交易的顺序和内容达成一致。共识是一个多步骤的流程，当流程完成时，应用程序只会被通知账本已更新 —— 不同的节点通知的时间可能有微小的差别。

我们将在未来的排序节点主题中更详细地讨论排序节点，现在，将排序节点视为收集和分发来自应用程序的账本更新提议的节点，以便验证并应用在账本中上。

就是这些了，我们现在已经完成了我们的对等节点和其他与 Hyperledger Fabric 相关的组件。我们已经看到，对等节点在许多方面都是最基本的元素 —— 它们形成网络，chaincode 代码和账本，处理交易提议和响应，并通过持续向其应用交易更新来使账本保持最新。

账本¶

账本有序了且防篡改的保存着所有状态转换序记录。状态转换是由参与方提交的 chaincode 调用（“事务”）的结果。每笔交易都会生成一组资产键值对，并将其作为创建，更新或删除提交给账本。

分类账由区块链（“链”）组成，以便将不可变的有序记录存储在块中，以及用于维护当前状态的状态数据库。每个频道有一个账本。每个对等节点为其所属的每个频道维护一份账本副本。

链（Chain）¶

链是一个事务日志，其结构为哈希链接块，其中每个块包含N个事务序列。块头包括块的交易事务的哈希，以及前面块的头部的哈希值。通过这种方式，账上的所有交易都被排序并以加密方式连接在一起。换句话说，在不破坏哈希链接的情况下篡改账本数据是不可能的。最新块的哈希与之前的每个事务都有关系，从而可以确保所有对等点处于一致且可信的状态。

该链存储在对等节点文件系统（本地或附加存储）上，高效支持着区块链追加区块的特性。

状态数据库（State Database）¶

帐本的当前状态数据表示交易链式日志中包含的所有 key 的最新值。由于当前状态代表了该频道已知的所有最新键值，因此有时也将其称为世界状态（World State）。

Chaincode 根据当前数据状态执行事务。为了使这些 chaincode 与数据状态高效交互，所有最新的键值对都存储在状态数据库中。状态数据库仅仅是链中事务日志中的索引视图，因此它可以随时从链中重新生成。在接受交易之前，状态数据库将在对等节点启动时自动恢复（或根据需要生成）。

状态数据库可选项包括 LevelDB 和 CouchDB。LevelDB 是嵌入对等节点进程中的默认状态数据库，并将 chaincode 数据存储为键值对。CouchDB 是一个可选的外部状态数据库，当您的 chaincode 数据建模为JSON时，可以提供附加查询支持，允许对JSON内容进行丰富的查询。有关CouchDB的更多信息，请参阅《CouchDB作为状态数据库》。

交易流程（Transaction Flow）¶

在高层次上，事务流由应用程序客户端发送给特定的对等节点的交易提案组成。对交易认可的对等方验证客户端签名，并执行 chaincode 函数来模拟交易。输出是 chaincode 调用结果，chaincode 中读取的一组键值（读取集合），或者用 chaincode（写集）写入的一组键/值。提案响应会连同确认签名一起发送回客户端。

客户端将所有节点的确认组装成交易数据并将其广播给排序节点。排序节点将排序好的的交易作为区块交付给频道上的所有对等节点。

在写入账本之前，对等节点将验证交易。首先，他们将检查确认条款，以确保指定对等节点是正确的且已签署结果，并且他们将针对交易数据来验证签名是否可靠。

其次，对等节点将对交易读取集执行版本检查，以确保数据完整性并防止双重支出等威胁。Hyperledger Fabric 具有并发控制功能，事务并行执行（由确认者执行）以提高吞吐量，并且一旦提交（由所有对等节点），每个事务都会被验证，以确保没有其他事务修改了它将要读取的数据。换句话说，它确保了在 chaincode 执行期间读取的数据自执行（认可）时以来没有被改变，因此执行结果仍然有效并可以提交给账本状态数据库。如果读取的数据已被另一个事务更改，则该块中的事务被标记为无效，并且不会应用于账本状态数据库中。客户端应用程序会收到报警通知事件，并可以处理错误或根据情况重试。

请参阅事务流，读写集语义和 CouchDB作为状态数据库主题，以深入了解事务结构，并发控制和状态数据库。