目录
名词概念
账本Ledger
In Hyperledger Fabric, a ledger consists of two distinct, though related, parts – a world state and a blockchain. Each of these represents a set of facts about a set of business objects.
账本由世界状态和区块链两部分组成。
- 世界状态
Firstly, there’s a world state – a database that holds a cache of the current values of a set of ledger states. The world state makes it easy for a program to directly access the current value of a state rather than having to calculate it by traversing the entire transaction log. Ledger states are, by default, expressed as key-value pairs, and we’ll see later how Hyperledger Fabric provides flexibility in this regard. The world state can change frequently, as states can be created, updated and deleted.
世界状态是一个数据库，存储的是账本当前值。作用是能够快速获取账本最新值而不必根据交易日志从头开始计算。默认情况下，世界状态以键值对的形式表示。
上图是世界状态的一个示例，记录的是两辆车CAR1和CAR2的信息。应用程序可以调用（invoke）智能合约来put和delete状态。
The key design point is that only transactions that are signed by the required set of endorsing organizations will result in an update to the world state. If a transaction is not signed by sufficient endorsers, it will not result in a change of world state. You can read more about how applications use smart contracts, and how to develop applications.
设计的重点是只有当交易被所需的一组背书组织签名后才能更新世界状态。
You’ll also notice that a state has an version number, and in the diagram above, states CAR1 and CAR2 are at their starting versions, 0. The version number for internal use by Hyperledger Fabric, and is incremented every time the state changes. The version is checked whenever the state is updated to make sure the current states matches the version at the time of endorsement. This ensures that the world state is changing as expected; that there has not been a concurrent update.
世界状态中还有一个属性——版本号，版本号从0开始，每当状态更新时版本号就递增。状态更新时会首先检查版本号，以确保当前状态的版本与背书时的版本一致（避免并发更新）。
世界状态可以根据区块链推导出来（区块链记录了所以的操作），因此当创建一个peer节点时，此节点会自动生成世界状态。
Secondly, there’s a blockchain – a transaction log that records all the changes that have resulted in the current the world state. Transactions are collected inside blocks that are appended to the blockchain – enabling you to understand the history of changes that have resulted in the current world state. The blockchain data structure is very different to the world state because once written, it cannot be modified; it is immutable.
区块链是一个交易日志，记录着导致当前世界状态的所有操作（不管交易有没有效，都会记录到区块链中）。区块链的数据结构和世界状态的数据结构非常不同。因为它要保证不可更改。
The blockchain is structured as sequential log of interlinked blocks, where each block contains a sequence of transactions, each transaction representing a query or update to the world state. The exact mechanism by which transactions are ordered is discussed elsewhere; what’s important is that block sequencing, as well as transaction sequencing within blocks, is established when blocks are first created by a Hyperledger Fabric component called the ordering service.
区块链被构造成互连区块的顺序日志，每个区块中包含一系列的交易，每个交易代表着query或update世界状态。交易的排序机制在其他地方讨论。这里的重点是，当区块第一次被ordering service组件创建的时候，区块顺序以及区块内的交易顺序就被确立了。
The blockchain is always implemented as a file, in contrast to the world state, which uses a database. This is a sensible design choice as the blockchain data structure is heavily biased towards a very small set of simple operations. Appending to the end of the blockchain is the primary operation, and query is currently a relatively infrequent operation.
区块链是以文件的方式实现的，这与使用数据库实现的世界状态不同。这种设计非常巧妙，因为区块链数据结构严重偏向于一小组简单操作。 附加到区块链的末尾是主要操作，查询当前是一个相对不频繁的操作。
Finally, as you can see in the diagram, the first block in the blockchain is called the genesis block. It’s the starting point for the ledger, though it does not contain any user transactions. Instead, it contains a configuration transaction containing the initial state of the network channel (not shown). We discuss the genesis block in more detail when we discuss the blockchain network and channels in the documentation.
创始块不包含任何用户交易，只包含配置交易。配置交易用来初始化世界状态。
区块
区块由三个部分组成，分别是区块头、区块数据和区块元数据。
区块头
区块头包含三个属性（区块号、当前区块哈希、前一个区块的哈希），当一个区块被创建时写入。
- 区块链
Block number: An integer starting at 0 (the genesis block), and increased by 1 for every new block appended to the blockchain.
Current Block Hash: The hash of all the transactions contained in the current block.
Previous Block Hash: A copy of the hash from the previous block in the blockchain.
These fields are internally derived by cryptographically hashing the block data. They ensure that each and every block is inextricably linked to its neighbour, leading to an immutable ledger.
区块数据
This section contains a list of transactions arranged in order. It is written when the block is created by the ordering service. These transactions have a rich but straightforward structure, which we describe later in this topic.
区块元数据包含的是排序后的交易列表。当区块被ordering service创建时写入。
区块元数据
This section contains the time when the block was written, as well as the certificate, public key and signature of the block writer. Subsequently, the block committer also adds a valid/invalid indicator for every transaction, though this information is not included in the hash, as that is created when the block is created.
区块元数据包括区块的写入时间，以及区块写入者的证书、公钥和签名。
交易
交易在fabric中指的就是对链代码（即智能合约）的操作，交易分为两种，部署交易（deploy transaction）和调用交易（invoke transaction）。
1. 部署交易
部署交易指的是创建新的链代码，并且用一个程序作为参数，当一个部署交易成功执行时，链代码就被安装到区块链上了。
2. 调用交易
调用交易指的是运行链代码，链代码执行时可能会修改相应的状态，并返回输出。
下图是一个交易的详细结构：
一个交易主要包含交易头、交易签名、交易提案、交易响应以及一个背书列表5个属性（还有其他不重要的属性）。
交易头：包含交易的元数据，如链码名称、版本等
交易签名：包含由客户端应用程序创建的加密签名，作用是判断交易是否被篡改
交易提案：作用是对由应用程序提供给智能合约的输入参数进行编码。当智能合约运行时，提案负责将参数传递过去
交易响应：是智能合约的输出，包含的是世界状态在交易前后的值，以读写集的形式展示。
背书列表：As shown in E4, this is a list of signed transaction responses from each required organization sufficient to satisfy the endorsement policy. You’ll notice that, whereas only one transaction response is included in the transaction, there are multiple endorsements. That’s because each endorsement effectively encodes its organization’s particular transaction response – meaning that there’s no need to include any transaction response that doesn’t match sufficient endorsements as it will be rejected as invalid, and not update the world state.
各种节点
节点（peer）是区块链的通信实体，是一个逻辑概念，不同类型的多个节点可以运行在同一个物理服务器上。节点主要有以下四种：
客户端节点：客户端必须连接到某一个peer节点或排序服务节点上才能与区块链网络进行通信。客户端向背书节点（endorser）提交交易提案（transaction proposal），当收集到足够背书后，向排序服务广播交易提案，进行排序，生成区块。
普通节点peer：peer节点根据所承担的角色又可以分为记账节点（committer）、背书节点（endorser）、主节点（leader）和锚节点（anchor）。
- 记账节点：所有的peer节点都是记账节点（committer），负责验证排序服务节点区块里的交易，维护状态和总账（Ledger）的副本。该节点会定期从orderer节点获取包含交易的区块，在对这些区块进行核发验证之后，会把这些区块加入到区块链中。committer节点无法通过配置文件配置，需要在当前客户端或者命令行发起交易请求的时候手动指定相关的committer节点。记账节点可以有多个。
- 背书节点：部分节点还会执行交易并对结果进行签名背书，充当背书节点（endorser）的角色。背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化的时候都会设置背书策略，指定哪些节点对交易背书后交易才是有效的。并且只有应用程序向它发起交易背书请求的时候才是背书节点，其他时候都是普通的记账节点，只负责验证交易并记账。背书节点也无法通过配置文件指定，而是由发起交易请求的客户端指定。背书节点可以有多个。
- 主节点：peer节点还可以是主节点（leader peer），能与排序服务节点通信，负责从排序服务节点获取最新的区块并在组织内部同步。主节点在整个组织中只能有一个。
- 锚节点：peer节点还可以是锚节点（anchor peer），锚节点主要负责代表组织和其他组织进行信息交换。每个组织都有一个锚节点，锚节点对于组织来说非常重要，如果锚节点出现问题，当前组织就会与其他组织失去联系。锚节点的配置信息是在configtxgen模块的配置文件configtx.yaml中配置的。锚节点只能有一个。
排序服务节点orderer：接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给peer节点。排序服务提供的是原子广播，保证同一个链上的节点接收到相同的信息，并且有相同的逻辑顺序。
CA节点：fabric1.0的证书颁发机构，由服务器和客户端组成。CA节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书。区块链上的所有操作都需要验证用户身份。
参考：https://www.jianshu.com/p/7b8841ef1a1e?from=timeline&isappinstalled=0
fabric1.0典型交易流程
该流程的前提假设是各节点已经提前颁发好证书，且已正常启动，并加入已经创建好的通道。此流程介绍的是在已经实例化了的链码通道上从发起一个调用交易到最终结账的全过程。
1. 提交交易提案
应用程序（客户端节点）构造好交易提案（交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等）请求后，根据背书策略选择背书节点执行交易提案并进行背书签名。背书节点是链代码中背书策略指定的节点。正常情况下背书节点执行后的结果是一致的，只有背书节点对结果的签名不一样。
2. 模拟执行提案并进行背书
背书节点在收到交易提案后会进行一些验证，验证通过后，背书节点会根据当前账本数据模拟执行链代码中的业务逻辑并生成读写集（RwSet）。模拟执行时不会更新账本数据。然后背书节点对这些读写集进行签名生成提案响应（proposal response），然后返回给应用程序。
3. 收集交易的背书（返回模拟执行结果）
应用程序收到proposal response后会对背书节点的签名进行验证（所有节点接收到任何消息时都需要先验证消息的合法性）。如果链码只进行账本查询操作，应用程序只需要检查查询响应，并不会将交易提交给排序服务节点。如果链码对账本进行了invoke操作，则需要提交交易给排序服务进行账本更新（提交前会判断背书策略是否满足）。
4. 构造交易请求并发送给排序服务节点
应用程序接收到所有背书节点的签名后，根据背书签名调用SDK生成交易，并广播给排序服务节点。其中生成交易的过程很简单，只需要确认所有背书节点的执行结果完全一致，再将交易提案、提案响应和背书签名打包生成交易即可。
5. 排序服务节点对交易进行排序并生成区块
排序服务节点接收到网络中所有通道发出的交易信息，读取交易信封获取通道名称，按各个通道上交易的接收时间顺序对交易信息进行排序（多通道隔离），生成区块。（在这个过程中，排序服务节点不会关心交易是否正确，只是负责排序和打包。交易的有效性在第7步进行验证）
6. 排序服务节点广播区块给主节点
排序服务节点生成区块后会广播给通道上不同组织的主节点。
7. 记账节点验证区块内容并写入到账本
所有的peer节点都是记账节点，记录的是节点已加入通道的账本数据。记账节点接收到的排序服务节点生成的区块后，会验证区块交易的有效性，然后提交到本地账本并产生一个生成区块的事件，监听区块事件的应用程序会进行后续的处理。（如果接收的是配置区块，则会更新缓存的配置信息）
8. 主节点在组织内部同步最新的区块
如果交易是无效的，也会更新区块，但不会更新世界状态。（区块存储的是操作语句，而世界状态存储的是被处理的数据）
组织
fabric系统是通过组织来划分的，每个组织内都有承担不同功能的peer节点，同时每个组织都有自己对应的fabric-ca服务器
fabric系统中所有的组织共用一个orderer集群。
fabric中的组织在现实世界中可以是一个公司、一个企业，或者一个协会。
在fabric中，组织是承担着数据信用责任的区块链系统参与方。
在设计一个fabric系统时，第一步就是要确定系统的参与方，然后从这些参与者中选出组织（生成对应的组织编号、域名、证书等），然后再确认组织的管理方式。组织的管理方式是指组织在遇到问题时的协作方式（如新组织的加入）。
fabric系统逻辑结构图
通道channel
fabric的数据存储结构被设计成多账本体系，每个账本在fabric中被称为channel。每个channel中都有一个完全独立的账本。同一个channel中的所有peer节点都保存一份相同的数据。
A Hyperledger Fabric channel is a private “subnet” of communication between two or more specific network members, for the purpose of conducting private and confidential transactions. A channel is defined by members (organizations), anchor peers per member, the shared ledger, chaincode application(s) and the ordering service node(s). Each transaction on the network is executed on a channel, where each party must be authenticated and authorized to transact on that channel. Each peer that joins a channel, has its own identity given by a membership services provider (MSP), which authenticates each peer to its channel peers and services.
通道是两个或多个特定网络成员之间进行通信的专用“子网”，用于进行私有和机密事务。通道由成员（组织）、每个成员的锚节点、账本、链码应用程序和排序服务节点定义。网络上的每个交易都是在一个通道上执行的，在该通道上，每一方都必须经过身份验证和授权才能在该通道上进行交易。加入通道的每一个peer都有其自己的身份，由成员服务提供者（MSP）提供。
The election of a leading peer for each member on a channel determines which peer communicates with the ordering service on behalf of the member. If no leader is identified, an algorithm can be used to identify the leader. The consensus service orders transactions and delivers them, in a block, to each leading peer, which then distributes the block to its member peers, and across the channel, using the gossip protocol.
为通道上的每个成员选择主节点，用于代表该成员与排序服务进行通信。算法会自动选出主节点。共识服务对交易进行排序打包成区块，并把区块它发送给主节点。然后主节点根据gossip协议将区块分发给 通道中的成员。
Although any one anchor peer can belong to multiple channels, and therefore maintain multiple ledgers, no ledger data can pass from one channel to another. This separation of ledgers, by channel, is defined and implemented by configuration chaincode, the identity membership service and the gossip data dissemination protocol. The dissemination of data, which includes information on transactions, ledger state and channel membership, is restricted to peers with verifiable membership on the channel. This isolation of peers and ledger data, by channel, allows network members that require private and confidential transactions to coexist with business competitors and other restricted members, on the same blockchain network.
尽管一个锚节点可以属于多个通道，因此能够维护多个账本，但是任何账本数据都不能从一个通道传递到另一个通道。这种用通道对账本进行隔离的方式是由配置链码、成员身份服务和gossip数据分发协议共同定义和实现的。通道上只有具备验证成员资格功能的节点才有权限进行数据分发。这种将peers和账本数据进行通道隔离的方式使得网络成员能够在同一个区块链中进行私密交易（只有自己通道的成员才知道交易信息）。
各个命令详解
docker compose和peer chaincode install：
You can read more about docker compose here and peer chaincode install command here.
背书策略
背书策略主要限制哪些组织或节点具备调用链码修改世界状态的权利，也就是是否具备调用PutState()或DelState()的权利。背书节点既具备修改权利又具备查询权利，而非背书节点只具备查询权利。
此外，对于AND策略来说，cli的处理方式好像实现不了，需要通道SDK的方式实现。
Fabric1.4
fabric1.4新特性
1. 第一个长期维护的版本
虽然从fabric1.0开始，fabric就已经基本成熟了，但fabric1.4将会是第一个长期维护的版本。在fabric1.4版本发布之日起的一年内，可能会发布一系列的补丁（v1.4.1、v1.4.2,....），但是如果你用的是1.4版本的，可以放心的进行升级，我们会提供相关版本的升级程序。
2. 服务性和操作性得到改善
随着越来越多的fabric网络的部署和生产，fabric的服务性和可操作性变得至关重要。fabric1.4在日志记录、健康检查和操作指标上取得了巨大的进步。推荐在生产中使用fabric1.4版本。
操作服务：新版本的RESTful操作服务为操作员提供了三个服务，以便与监视和管理peer节点和orderer节点
- 日志端点（/logspec）允许操作员动态的获取或设置peer和orderer节点的日志等级
- 健康端点（/healthz）允许操作员和容器编排服务检查peer和orderer节点的活动状态和健康状态
- 指标端点（/metrics）允许操作员通过使用Prometheus从peer和orderer节点处拉取可操作指标，指标也可以被推送到StatsD
3. 程序开发模型得到改善
开发分散化的应用程序变得更简单了。node.js sdk和node.js chaincode中编程模型的改进使分散化应用程序的开发更加直观，使您能够专注于应用程序的逻辑。现有的NPM包仍然可以使用，而新的NPM包提供了一个抽象层，以提高开发人员的生产力和易用性。
新的开发文档通过商业票据业务网络场景帮助你快速全面的了解如何开发分散化应用程序：
- 场景：描述了一个虚拟的业务网络，包含6个组织，他们希望通过一个应用程序使他们能够相互交易。此场景将作为描述编程模型的示例
- 分析：描述了商业票据的结构以及交易是如何影响它的，通过状态和交易来演示这个模型能够提供一种清晰的思路去理解如何开发分布式应用程序
- 程序和数据结构：展示如何设计商业票据程序以及相关的数据结构
- 智能合约设计：展示如何开发一个智能合约，使它能够管理商业票据的发行、购买和赎回等分散化的业务流程
- 应用程序：应用程序将从概念上描述在智能合约设计中提到的智能合约是如何被客户端程序调用的
- 应用程序设计相关元素：详细描述合约命名空间（contract namespaces）、交易环境（transaction context）、交易处理程序（transaction handlers）、连接配置文件（connection profiles）、连接选项（connection options）、钱包（wallets）和网关（gateways）
- 教程：最后，通过一个教程和示例将商业票据场景带到现实中
4. 新教程
- 编写你的第一个应用：本教程已更新，以利用改进的node.js sdk和chaincode编程模型。本教程提供了客户端应用程序和链代码的javascript和typescript示例
- 商业票据教程：如上所述，这是新的开发文档的附带教程
- 升级到最新的fabric版本：通过“Building Your First Network”来演示如何从1.3版本升级到1.4版本。包括一个脚本（可以作为升级的模板）和各个命令，以便您了解升级的每个步骤
5. 私有数据加强
私有数据：私有数据是fabric1.2版本中引入的新特性，此1.4版本新增了两个增强功能
- Reconciliation（对账）：允许向组织中被添加到私有数据集的peer节点授权，使之能够获取未授权之前发生的交易中的数据
- 客户端访问控制： 根据客户端组织集合成员的身份在链码内自动执行访问控制，而不必编写特定的链码逻辑
6. 版本说明
版本说明中有新版本的详细描述，通过以下链接查看：
Fabric1.4应用程序开发文档——链码+SDK
相关学习连接
fabric原理剖析：https://www.jianshu.com/p/8e2fa2b5a0b2
fabric权限管理进阶：https://www.javatree.cn/news/a74a120208ac49c0a457e54e9efed4bb
fabric1.1的搭建：https://www.jianshu.com/p/6ef2e8425087