前言

由IBM贡献的超级账本框架。它是一个利用现有成熟的技术来组合而成的一个区块链技术的实现。它是一种允许可插拔实现各种功能的的模块化架构。它具有强大的容器技术，来承载各种主流语言来编写的智能合约。
Fabric 是一个 Python (2.5-2.7) 的库和命令行工具，用来提高基于 SSH 的应用部署和系统管理效率
- 一个让你通过 命令行 执行 无参数 Python 函数 的工具；
- 一个让通过 SSH 执行 Shell 命令更加容易、 更符合 Python 风格 的命令库（建立于一个更低层次的库）。

fabric和比特币与以太坊的最大的区别在于其身份识别能力，fabric是权限区块链，而后两者是匿名的非权限区块链

基本概念

基本结构：

资产 Assets

理解为任何具有货币价值的东西，它们都可以通过网络进行交易，无论是有形资产还是无形资产都属于资产，Hyperledger Fabric提供了使用链码交易修改资产的功能。
资产在Fabric中以键-值对集合的形式存在，在通道（Channel）中各本地账本可以对其状态提交变更
资产可以用二进制或JSON形式表示

账本 ledger

Hyperledger Fabric具有一个账本子系统，该子系统包括两个组件：世界状态和事务日志。
每个参与者都有一份账本到他们所属的每个Hyperledger Fabric网络的副本。
分类帐是世界状态数据库和事务日志历史记录的组合。

世界状态

版本号：从0开始，每当状态更新时版本号就递增。状态更新时会首先检查版本号，以确保当前状态的版本与背书时的版本一致（避免并发更新）
描述分类帐在给定时间点的状态。这是分类帐的数据库。

事务日志

记录所有导致当前世界状态值的事务；这是世界状态的更新历史。

分类账功能

分类帐是结构中所有状态转换的有序，防篡改记录。状态转换是参与方提交的链码调用（“交易”）的结果。每笔交易都会产生一组资产键值对，这些键值对会在创建，更新或删除时提交到分类账。
分类帐由一个区块链（“ chain”）和一个状态数据库组成，该区块链将不可变的顺序记录存储在块中，该状态数据库用于维护当前的结构状态。每个频道有一个分类帐。每个对等方都为其所属的每个通道维护一个分类帐的副本。

Fabric分类帐的一些功能：

使用基于键的查找，范围查询和组合键查询来查询和更新分类帐
使用丰富查询语言的只读查询（如果使用CouchDB作为状态数据库）
只读历史记录查询—查询密钥的分类帐历史记录，从而启用数据出处场景
事务包括以链码（读集）读取的键/值的版本和以链码（写集）写入的键/值的版本。
交易包含每个背书对等方的签名，并提交给订购服务
交易被分为几大块，并从订购服务“交付”到渠道上的对等方
对等方根据背书政策验证交易并执行政策
在附加块之前，执行版本检查，以确保自链码执行以来，已读取资产的状态未发生变化。
交易一旦经过验证并提交，便具有不变性
通道的分类帐包含一个配置块，用于定义策略，访问控制列表和其他相关信息
通道包含成员资格服务提供程序实例，允许从不同的证书颁发机构派生加密材料

区块结构

区块头：包含三个属性（区块号、当前区块哈希、前一个区块的哈希），当一个区块被创建时写入。
区块数据：包含的是排序后的交易列表。当区块被ordering service创建时写入。
区块元数据：包括区块的写入时间，以及区块写入者的证书、公钥和签名。

状态

整个区块链的状态可以看作是一个 versioned KVS（带有版本的 key-value store，类似于git仓库），这些kv通过chaincode（智能合约）进行更新，它只提供了put和get方法，所有的状态变更都有日志记录。

交易

在fabric中指的就是对链代码（即智能合约）的操作，交易分为两种

部署交易（deploy transaction）：
- 指的是创建新的链代码（chaincode），并且用一个程序作为参数，当一个部署交易成功执行时，链代码就被安装到区块链上了。
调用交易（invoke transaction）：
- 指的是运行链代码，链代码执行时可能会修改相应的状态并返回输出。下图是一个交易的详细结构：
  - 交易头 H4：包含交易的元数据，如链码名称、版本等
  - 交易签名 S4：包含由客户端应用程序创建的加密签名，作用是判断交易是否被篡改
  - 交易提案 P4：作用是对由应用程序提供给智能合约的输入参数进行编码。当智能合约运行时，提案负责将参数传递过去
  - 交易响应 R4：是智能合约的输出，包含的是世界状态在交易前后的值，以读写集的形式展示。
其实还可能存在query transaction（v1版本加入）和cross-chaincode transaction（v1之后的版本会加入），此处不做讨论

交易流程

前提假设是各节点已经提前颁发好证书，且已正常启动，并加入已经创建好的通道。此流程介绍的是在已经实例化了的链码通道上从发起一个调用交易到最终结账的全过程。

提交交易提案
- 应用程序（客户端节点）构造好交易提案（交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等）请求后，根据背书策略选择背书节点（多个）执行交易提案并进行背书签名。
- 背书节点是链代码中背书策略指定的节点。正常情况下背书节点执行后的结果是一致的，只有背书节点对结果的签名不一样。
模拟执行提案并进行背书
- 背书节点在收到交易提案后会进行一些验证，验证通过后，背书节点会根据当前账本数据模拟执行链码中的业务逻辑并生成读写集（RwSet）。
- 模拟执行时不会更新账本数据。然后背书节点对这些读写集进行签名生成提案响应（proposal response），然后返回给应用程序。
收集交易的背书（返回模拟执行结果）
- 应用程序收到proposal response后会对背书节点的签名进行验证（所有节点接收到任何消息时都需要先验证消息的合法性）。如果链码只进行账本查询操作，应用程序只需要检查查询响应，并不会将交易提交给排序服务节点。如果链码对账本进行了invoke操作，则需要提交交易给排序服务进行账本更新（提交前会判断背书策略是否满足）。
构造交易请求并发送给排序服务节点
- 应用程序接收到所有背书节点的签名后，根据背书签名调用SDK生成交易，并广播给排序服务节点。其中生成交易的过程很简单，只需要确认所有背书节点的执行结果完全一致，再将交易提案、提案响应和背书签名打包生成交易即可。
排序服务节点对交易进行排序并生成区块
- 排序服务节点接收到网络中所有通道发出的交易信息，读取交易信封获取通道名称，按各个通道上交易的接收时间顺序对交易信息进行排序（多通道隔离），生成区块。（在这个过程中，排序服务节点不会关心交易是否正确，只是负责排序和打包。交易的有效性在第7步进行验证）
排序服务节点广播区块给主节点
- 排序服务节点生成区块后会广播给通道上不同组织的主节点。
记账节点验证区块内容并写入到账本
- 所有的peer节点都是记账节点，记录的是节点已加入通道的账本数据。记账节点接收到的排序服务节点生成的区块后，会验证区块交易的有效性，然后提交到本地账本并产生一个生成区块的事件，监听区块事件的应用程序会进行后续的处理。（如果接收的是配置区块，则会更新缓存的配置信息）
主节点在组织内部同步最新的区块
- 如果交易是无效的，也会更新区块，但不会更新世界状态。（区块存储的是操作语句，而世界状态存储的是被处理的数据）

节点

区块链的通信实体，是一个逻辑概念，不同类型的多个节点可以运行在同一个物理服务器上。

客户端节点 client
- 客户端必须连接到某一个peer节点或排序服务节点上才能与区块链网络进行通信。
- 客户端向背书节点（endorser）提交交易提案（transaction proposal），当收集到足够背书后，向排序服务节点广播交易提案，进行排序，生成区块。
排序服务节点 orderer
- 接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给peer节点。
- 排序服务提供的是原子广播，保证同一个链上的节点接收到相同的信息，并且有相同的逻辑顺序。
orderer特性：
1. 一致性：经过orderer deliver的交易，seqno一定时，blob和prevhash都一样
2. hash链的完整性：对于deliver(seqno, hash0, blob0)和deliver(seqno-1, hash1, blob1)，HASH(seqno-1, hash1, blob1) == hash0
3. 不会凭空创造交易：每一次deliver，都是由于一次boardcast产生的。
4. 不会缺失交易：如果一个deliver(seqno, hash, blob)已经发生，那么一定有deliver(seqno-1, hash0, blob0) … deliver(0, default-hash, blob)
5. 不会重复交易：如果产生了两次 boardcast(blob)，boardcast(blob1)，则deliver(seqno1, hash, blob1)和deliver(seqno, hash0, blob)中，seqno1==seqno，
  hash==hash0，blob==blob1
CA节点：
- fabric1.0的证书颁发机构，由服务器和客户端组成。
- CA节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书。
- 区块链上的所有操作都需要验证用户身份。
普通节点 peer：peer节点根据所承担的角色又可以分为记账节点（committer）、背书节点（endorser）、主节点（leader）和锚节点（anchor）。
- 记账节点 Committer
  - 所有的peer节点都是记账节点（committer）
  - 负责验证排序服务节点区块里的交易，维护状态和总账（Ledger）的副本。
  - 该节点会定期从orderer节点获取包含交易的区块，在对这些区块进行核发验证之后，会把这些区块加入到区块链中。
  - 记账节点无法通过配置文件配置，需要在当前客户端或者命令行发起交易请求的时候手动指定相关的committer节点。
  - 记账节点可以有多个。
- 背书节点 endorser
  - 部分节点还会执行交易并对结果进行签名背书，充当背书节点（endorser）的角色。
  - 背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化的时候都会设置背书策略，指定哪些节点对交易背书后交易才是有效的。
  - 并且只有应用程序向它发起交易背书请求的时候才是背书节点，其他时候都是普通的记账节点，只负责验证交易并记账。
  - 背书节点也无法通过配置文件指定，而是由发起交易请求的客户端指定。
  - 背书节点可以有多个。
- 锚节点 anchor
  - 锚节点主要负责代表组织和其他组织进行信息交换。每个组织都有一个锚节点，锚节点对于组织来说非常重要，如果锚节点出现问题，当前组织就会与其他组织失去联系。
  - 锚节点的配置信息是在configtxgen模块的配置文件configtx.yaml中配置的。
  - 锚节点只能有一个。
- 主节点 leader
  - 能与排序服务节点通信，负责从排序服务节点获取最新的区块并在组织内部同步。
  - 主节点在整个组织中只能有一个。

数据设计

分类账状态

状态键 state key

多种状态

使用DNS命名法则：org.papernet.paper

逻辑状态：维护一个paper list，将发行交易结果产生的新文件放进去

物理状态：使用org.papernet.paper、Issuer和paper的特性串行形成key值
- org.papernet.MagnetoCorp0001 + value（properties）
- 使得状态从标量变成向量

系统逻辑结构

org

fabric系统是通过组织来划分的，每个组织内都有承担不同功能的peer节点，同时每个组织都有自己对应的fabric-ca服务器，fabric系统中所有的组织共用一个orderer集群。
fabric中的组织在现实世界中可以是一个公司、一个企业，或者一个协会。在fabric中，组织是承担着数据信用责任的区块链系统参与方。
在设计一个fabric系统时，第一步就是要确定系统的参与方，然后从这些参与者中选出组织（生成对应的组织编号、域名、证书等），然后再确认组织的管理方式。组织的管理方式是指组织在遇到问题时的协作方式（如新组织的加入）。

channel

fabric的数据存储结构被设计成多账本体系，每个账本在fabric中被称为channel。每个channel中都有一个完全独立的账本。同一个channel中的所有peer节点都保存一份相同的数据。
通道由成员（组织）、每个成员的锚节点、账本、链码应用程序和排序服务节点定义。
- 基本上，一个链由1个通道+ 1个账本+ N个成员组成
网络上的每个交易都是在一个通道上执行的，在该通道上，每一方都必须经过身份验证和授权才能在该通道上进行交易。加入通道的每一个peer都有其自己的身份，由成员服务提供者（MSP）提供。

chaincode

链代码是一个按照一定规范实现的应用程序，运行于容器中，chaincode可以被安装到peer上，应用程序（客户端）通过发起交易请求，endsorer peer执行chaincode并进行签名，经过orderer的验证后，下发到对应的channel中，对账本进行更新。

PKI

Public Key Infrastructure，公钥基础结构

Internet技术的集合，这些技术在网络中提供安全的通信。注意是PKI将 s 放入 https 中的
一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。
底层采用P2P网络和gRPC协议实现对分布式账本结构的连通。通过Gossip协议进行状态同步、数据分发和成员探测。

公钥基础结构（PKI）的元素。PKI由证书颁发机构组成，证书颁发机构向各方（例如，服务的用户，服务提供商）颁发数字证书，然后由他们使用它们在环境中交换的消息中对自己进行身份验证。CA的证书吊销列表（CRL）构成了不再有效的证书的参考。吊销证书的原因有很多。例如，由于与证书关联的加密专用材料已被暴露，因此证书可能被吊销。

尽管区块链网络不只是通信网络，但它依赖于PKI标准来确保各种网络参与者之间的安全通信，并确保对发布在区块链上的消息进行正确的身份验证。因此，重要的是要了解PKI的基础知识，然后理解MSP为何如此重要。

PKI有四个关键要素：

数字证书：最常见的证书类型是符合X.509标准的证书，该证书允许在其结构中对参与方的标识详细信息进行编码。
- 只要CA安全地保存某些密码信息（即其自己的专用签名密钥），任何阅读证书的人都可以确保有关证书所有人的信息未被篡改 - 它始终具有证书所有人的那些特定属性。
- 即可视证书为无法更改的数字身份证
公钥和私钥：份验证和消息完整性是安全通信中的重要概念
证书颁发机构：为组织的参与者提供了可验证的数字身份提供了基础。
- CA的有两种形式：根CA和中间CA。
- 由于根CA（赛门铁克，Geotrust等）必须安全地向互联网用户分发数亿个证书，因此有必要将此过程分散到所谓的中间CA中。这些中间CA的证书由根CA或其他中间机构颁发，从而可以为链中任何CA颁发的任何证书建立“信任链”。
- 追溯到根CA的能力不仅可以扩展CA的功能，同时仍提供安全性-允许使用证书的组织放心地使用中间CA-它限制了根CA的暴露，如果受到损害，这将使根CA暴露危害整个信任链。另一方面，如果中级CA受到威胁，则风险会小得多。
证书吊销列表：只是CA已知由于某种原因而吊销的证书引用列表。CRL就像一张被盗信用卡的清单。

CA

Enrollment CA
- 用于（通过称为“注册”的过程）生成组织管理员，该组织的MSP和任何节点的证书仅为该组织所拥有。
- 此CA还将为任何其他用户生成证书。由于其在“注册”身份中的作用，因此有时将CA称为“注册CA”或“证书CA”。

另一个CA生成用于保护传输层安全性（TLS）上的通信的证书。因此，该CA通常被称为“ TLS CA”。

TLS CA
- 用于保护传输层安全性（TLS）上的通信的证书
- 将这些TLS证书附加到操作中，以防止“中间人”攻击。请注意，TLS CA仅用于为节点颁发证书，并且在该活动完成后可以将其关闭。
- 用户可以选择使用一种方式（仅客户端）TLS以及两种方式（服务器和客户端）TLS，后者也称为“相互TLS”。
- 由于应在部署“注册” CA（确定此CA的配置的YAML文件具有用于启用TLS的字段）之前确定指定网络将使用TLS（建议），因此，应首先部署TLS CA，在引导注册CA时使用TLS CA的证书。这个TLS证书也会在为用户和节点连接到注册CA注册身份时被 fabric-ca client 使用

MSP

Membership Service Provider

负责联盟链成员的证书管理，它定义了哪些RCA以及ICA在链里是可信任的，包括定义了channel上的合作者。
每个组织都有自己的证书管理（CA）及MSP，CA给每个peer颁发证书，MSP授权，赋予相应权限策略。
对于peer和client来说，对于交易的结果和交易本身，都需要进行授权
Peer ，applications，end users, administrators orders 必须拥有CA和MSP才能访问链网。

数据库

Hyperledger Fabric 项目中，目前可以支持的状态数据库有两种：

LevelDB：LevelDB 是嵌入在 Peer 中的默认键值对（key-value）状态数据库。
CouchDB：CouchDB 是一种可选的替代 levelDB 的状态数据库。与 LevelDB 键值存储一样，CouchDB 不仅可以根据 key 进行相应的查询，还可以根据不同的应用场景需求实现复杂查询。

服务

fabric的底层主要由四种服务构成，分别是：身份服务、策略服务、区块链服务、智能合约服务。在这些基础服务之上，通过一些API、SDK、CLI为上层业务应用提供一些可以编程的接口服务。

20180523213138295

身份服务

首先明确一点，fabric和比特币与以太坊的最大的区别在于其身份识别能力，fabric是权限区块链，而后两者是匿名的非权限区块链。明确这一点后，fabric的身份识别主要表现在fabric的账本中的各类事件个交易中，参与者和对象都具有明确的身份信息。这些信息主要包括参与者的组织、验证者、交易者，账本中的资产和智能合约，以及系统组件包括网络和服务器、运行环境等等这些信息。验证者在fabric网络建立的时候就可以确定参加交易的权限级别。

参考: https://tech.lock-in.cn/news/a74a120208ac49c0a457e54e9efed4bb

cacerts

文件夹放置的用于身份识别的ca根证书, 回忆下基础篇的会员身份使用PKI等数字签名技术用于识别客户身份(这里特指可连接到peer节点的客户端)。

一个组织对一个根CA(不考虑中间CA情况), 所以组织org1下的peer0和peer1实际配置的是同一个 ca.org1.example.com-cert.pem，所以这个文件夹应该放的是对应组织的CA根证书

config.yaml

主要配置的可采访的组织单元，也就是说X.509 PEM证书里面的OU(组织单元)要么是client或者peer才能采访当前节点。

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.org1.example.com-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.org1.example.com-cert.pem
    OrganizationalUnitIdentifier: peer

对于这里的Certification配置也有一些疑惑, cacerts文件夹使用根CA证书确定了连接客户身份，这里的config.yaml算是第二层过滤吧, 每个不同类型的组织单元OUIdentifier的Certificate应该不能对应其它的CA根证书，应该只能是同一个CA根证书或者不同的中间CA证书。
OU=client的证书实际上后面会看到admincerts是OU=client, org1下的
User1@org1.example.com用户也是OU=client, 貌似外部接入peer节点的用户都归到OU=client.
OU=peer的证书暂时只有peer节点自身的证书，例如peer0,peer1都是OU=peer /mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/signcerts/peer0.org1.example.com-cert.pem
实际OU=client和peer的有什么不同权限，笔者估计是peer是标记不同peer节点的调用，或者是在链码安装的时候可以指定不同的OU
config.yaml的配置是可选的, 它是通过crypto-config.yaml下org设置了 EnableNodeOUs: true 才默认会生成MSP模板。

keystore

存放的peer0节点的私钥，可以用于数字签名。

signcerts

存放的是peer0被ca.org1.example.com签名的证书。注意到蓝色部分, OU=peer

tlscacerts

如果peer0启用了TLS保证安全和校验，就必须指定tlscacerts证书了，一般使用与cacerts不同的ca证书会安全些。证书内容如下：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7a:fa:31:77:69:bb:28:fc:b9:3d:81:98:7b:f3:83:64
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=tlsca.org1.example.com
        Validity
            Not Before: Sep 29 02:27:16 2018 GMT
            Not After : Sep 26 02:27:16 2028 GMT
        Subject: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=tlsca.org1.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
                    04:92:79:62:41:43:06:7d:30:65:ef:2c:ae:87:8e:
                    41:f6:12:27:f0:9f:a0:c1:3d:f1:03:3d:ee:e7:45:
                    87:58:72:f7:a0:24:85:d8:3d:01:42:d2:01:15:fc:
                    e1:8a:d8:6b:56:0c:25:e2:98:8d:09:fb:0e:a5:65:
                    ea:4a:ec:a0:06
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                Any Extended Key Usage
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                25:41:EA:7D:4B:4F:14:0B:13:6D:E1:EE:09:AA:00:A6:90:66:B4:2B:2F:90:6B:DF:E2:EF:D6:59:AE:17:40:4B
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:cd:3b:23:ed:fb:2b:de:bf:64:87:f0:af:f6:
         0a:02:5f:26:83:ff:32:08:58:16:23:ba:30:36:b5:ee:aa:c9:
         55:02:20:4b:40:a8:89:c7:2d:0c:8f:c0:b6:34:9a:72:f0:47:
         0e:66:8a:85:7b:d6:51:d6:1f:75:1e:e6:03:40:95:09:c9

参考peer-base.yaml是开启了TLS的: CORE_PEER_TLS_ENABLED=true

admincerts

这里存放的是整个组织org1的管理员证书, 和
/mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com下的签名证书是一致的， peer1.org1.example.com节点也是如此。

就是说执行 cryptogen generate —config=./crypto-config.yaml 默认就是让org1下的所有peer都有相同的admin.
如果peer0和peer1的admincerts不一样，应该会有问题,第二个问题我们会查看下创世块的具体内容，里面指定的是组织的admin而不会有节点的admin。
话说这个admin的权限就比较大了，可以把peer节点加入到channel, 可以安装和实例化chaincode。BYFN里面容器里面执行的peer命令实际对应的都是admin的msp.

组织管理员证书的内容, OU=client

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            48:15:46:a1:6c:25:63:98:c7:e9:c5:26:b8:67:f9:53
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
        Validity
            Not Before: Sep 29 02:27:16 2018 GMT
            Not After : Sep 26 02:27:16 2028 GMT
        Subject: C=US, ST=California, L=San Francisco, OU=client, CN=Admin@org1.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
                    04:59:01:48:99:af:c8:30:17:e2:5a:b4:ee:5a:1c:
                    c6:79:a7:c5:3a:14:20:d1:a0:39:de:13:5e:99:c6:
                    d1:4e:9c:cd:63:fb:73:96:9f:b4:48:60:4f:8e:72:
                    10:ee:54:19:33:5f:dc:29:e2:94:39:b3:4e:f2:d3:
                    cd:1f:3d:0a:54
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:F3:40:31:60:A2:2B:B9:CB:B5:FD:10:24:E1:BA:65:D9:8D:2C:E4:E1:AB:51:FB:55:6B:17:35:E1:11:CF:6E:82

    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:0c:be:41:5b:58:1e:df:7e:78:5d:77:00:44:c7:
         a1:c8:2f:e1:6b:bb:8a:ac:b2:26:aa:ab:35:f6:f5:4b:66:6d:
         02:20:46:b7:32:c2:4f:a1:d0:89:20:32:42:35:50:80:8e:9e:
         ba:66:d6:b2:6b:55:1f:e0:b5:5f:2c:04:be:b0:6c:1e

PEER作为接入点, 主要也是靠本地的MSP去识别用户身份，判断用户是否是所信任的CA颁发证书，再结合组织单元等确定用户是否可采访节点。

策略服务

策略是Fabric工作方式的基础，因为策略允许将与请求相关联的身份（或一组身份）与与满足请求所需的资源相关联的策略进行检查。

背书策略用于确定交易是否已得到适当背书。
通道配置中定义的策略以及访问控制都称为修改策略，并且在通道配置本身中定义。

构造

Signature策略

表明需要得到那些特定用户的签名才能采用

Policies:
  MyPolicy:
    Type: Signature
    Rule: "OR('Org1.peer', 'Org2.peer')"

一个名叫 MyPolicy 的策略。只能通过具有“ Org1的对等方”或“ Org2的对等方”角色的身份签名来满足所命名的策略
签名政策支持任意组合 AND，OR 以及 NOutOf
- 允许极其强大的规则建设：“组织A的管理员和其他两名管理员，或20组织的管理员11”。

ImplicitMeta策略

ImplicitMeta 策略聚合配置层次结构中更深层次的策略结果，这些策略最终由签名策略定义。

他们支持默认规则，比如“组织中大多数管理员”。
这些策略使用的语法和 Signature 策略不同但是依旧很简单： <ALL|ANY|MAJORITY> <sub_policy> 。比如： ANY Readers 或者 MAJORITY Admins 。
注意默认策略配置中：
- Admins 具有操作角色。指定仅管理员（或管理员的某些子集）有权访问资源的策略往往是针对网络的敏感或可操作方面（例如，实例化通道上的链码）。
- Writers 能够提交账本更新（例如交易），但没有管理权限。
- Readers 拥有被动角色。他们可以访问信息，但没有权利提交账本更新，也不能执行管理任务。
- 这些默认策略可以被添加，编辑或补充，例如通过新的 peer 和 client 角色（如果您有 NodeOU 支持）。

Policies:
  AnotherPolicy:
    Type: ImplicitMeta
    Rule: "MAJORITY Admins"

名为 AnotherPolicy 的策略，表明可以通过 MAJORITY Admins（大多数管理员同意）的方式来满足
其中 Admins 是通过 Signature 策略来满足的。

背书策略

区块链服务

智能合约服务

系统链码

链码中定义的智能合约为一群区块链组织共同认可的业务流程编码了领域相关规则。然而，链码还可以定义低级别程序代码，这些代码符合无关于领域的系统交互，但与业务流程的智能合约无关。

以下是不同类型的系统链码及其相关缩写：

_lifecycle：在所有 Peer 节点上运行，它负责管理节点上的链码安装、批准组织的链码定义、将链码定义提交到通道上。
- 你可以在这里阅读更多关于 _lifecycle 如何实现 Fabric 链码生命周期的内容。
生命周期系统链码（LSCC）：负责为1.x版本的 Fabric 管理链码生命周期。
- 该版本的生命周期要求在通道上实例化或升级链码。你可以阅读更多关于LSCC如何实现这一过程。
- 如果你的 V1_4_x 或更低版本设有通道应用程序的功能，那么你也可以使用LSCC来管理链码。
配置系统链码（CSCC）：在所有 Peer 节点上运行，以处理通道配置的变化，比如策略更新。
- 你可以在这里阅读更多 CSCC 实现的内容。
查询系统链码（QSCC）：在所有 Peer 节点上运行，以提供账本 API（应用程序编码接口），其中包括区块查询、交易查询等。
- 你可以在交易场景主题中查阅更多这些账本 API 的信息。
背书系统链码（ESCC）：在背书节点上运行，对一个交易响应进行密码签名。
- 你可以在这里阅读更多 ESCC 实现的内容。
验证系统链码（VSCC）验证一个交易，包括检查背书策略和读写集版本。
- 你可以在这里阅读更多 LSCC 实现的内容。

智能合约

smart contract：智能合约，定义业务对象的不同状态，并控制在这些不同状态之间移动对象的流程。
- 智能合约之所以重要，是因为它们使架构师和智能合约开发人员能够定义关键业务流程和数据，这些关键业务流程和数据是在区块链网络中进行协作的不同组织之间共享的。

chaincode： 链码，Fabric的智能合约写在链码里并在区块链外部应用程序要和账本发生交易的时候被外部应用程序调用。
- 在大多数情况下，链码只和账本的数据库组件（世界状态）交互，而不和交易日志交互。

链码与智能合约的区别：
链码 - chaincode：是一种用于部署代码到 Hyperledger Fabric 区块链网络中的通用容器。链码中定义一个或多个相关联的智能合约。每个智能合约在链码中有一个唯一的标识名。应用程序通过合约名称去访问链码容器内的指定的智能合约
通常在构造类时分配名称，如果没有明确指明合约名，则会分配一个默认的名字–类名。建议使用显式的 DNS 样式命名方法，对组织清晰、有意义的名称有帮助；
例如：peer0.org1.example.com
智能合约 - contract：是一种高级编程抽象的例子，可以在链码容器中定义智能合约。当一个链码被安装和实例化时，则链码内所有的智能合约对于相关联的通道（Channel）来说都是可用的

账本：Fabric有一个账本子系统包含两个组件：世界状态和交易日志。每一个参与者有一份他们参与的每个Fabric网络的账本的副本。
- 世界状态组件描述了一个给定时间点的账本状态。它是账本的数据库，存储的是账本当前值。
- 交易日志组件记录所有导致世界状态当前值的交易。它是世界状态的更新历史。这样，账本就是世界状态数据库和交易日志历史的组合体。

共识机制

Fabric区块链的网络节点本质上是互相复制的状态机，节点之间需要保持相同的账本状态。为了实现分布式节点的一致性，各个节点需要通过共识过程，对账本状态的变化达成一致性的认同。

共识过程

背书（endorsement）阶段
- 背书节点对客户端发来的交易提案进行合法性校验，然后模拟执行链码得到交易结果，最后根据设定的背书逻辑判断是否支持该交易提案。如果背书逻辑决定支持交易提案，会把交易提案签名后发回给客户端。
- 客户端通常需要根据链码的背书策略，向一个或者多个成员的背书节点发出背书请求。背书策略会定义需要哪些节点背书交易才有效，例如需要5个成员的背书节点中至少3个同意；或者某个特殊身份的成员支持等。
- 客户端只有在收集足够多的背书节点的交易提案签名，交易才能被视为有效。
排序（ordering）阶段
- 由排序服务节点对交易进行排序，确定交易之间的时序关系。排序服务把一段时间内收到的交易进行排序，然后把排序后的批量交易打包成数据块（区块），再把区块广播给通道中的成员。
- 采用排序共识方式，各个成员收到的是一组发生顺序相同的交易，从而保证了所有节点的数据一致性。目前，Hyperledger Fabric有三种交易排序算法：Solo、Kafka、SBFT。
  1. Solo：只有一个排序服务节点负责接收交易信息并排序，是最简单的一种排序算法，一般用于开发测试环境中。Solo共识模式属于中心化的处理方式，不支持拜占庭容错。
  2. Kafka：Kafka是Apache的一个开源项目，主要提供分布式的消息处理／分发服务，每个Kafka集群由多个服务节点组成。Hyperledger Fabric利用Kafka对交易信息进行排序处理，提供高吞吐、低延时的处理能力，并且在集群内部支持节点故障容错，但不支持拜占庭容错。
  3. SBFT：简单拜占庭算法，支持拜占庭容错的可靠排序算法，包括容忍节点故障以及一定数量的恶意节点。
  4. 排序服务是共识机制中重要的一环，所有交易都要通过排序服务的排序才可以达成全网共识，因此排序服务要避免成为网络上的性能瓶颈。
校验（Validation）阶段
- 节点对排序后的交易进行一系列的检验，包括交易数据的完整性检查、是否重复交易、背书签名是否符合背书策略的要求、交易的读写集是否符合MVCC（Multiversion Concurrency Control，多版本并发控制）的校验等。
- 当交易通过了所有校验后，将被标注为合法并写入账本中。因为所有的确认节点都按照相同的顺序检验交易，并且把合法的交易依次写入账本中，因此不同确认节点的状态能够始终保持一致。

solo

kafka

Kafka共识模块是可以用于生产环境的，它可以支持崩溃容错，但无法对抗恶意攻击。

多个排序节点通过Kafka实现同步，而Kafka本身并不是排序节点，它只是将排序节点通过流连接起来

Kafka本质上是一个消息处理系统，它使用的是经典的发布-订阅模型。消息的消费者订阅特定的主题，以便收到新消息的通知，生产者则负责消息的发布。

在fabric中的运行逻辑：

对于每一条链，都有一个对应的分区
每个链对应一个单一的分区主题
排序节点负责将来自特定链的交易（通过广播RPC接收）中继到对应的分区
排序节点可以读取分区并获得在所有排序节点间达成一致的排序交易列表
一个链中的交易是定时分批处理的，也就是说当一个新的批次的第一个交易进来时，开始计时
当交易达到最大数量时或超时后进行批次切分，生成新的区块
定时交易是另一个交易，由上面描述的定时器生成
每个排序节点为每个链维护一个本地日志，生成的区块保存在本地账本中
交易区块通过分发RPC返回客户端
当发生崩溃时，可以利用不同的排序节点分发区块，因为所有的排序节点都维护有本地日志

崩溃容错

崩溃容错机制：通过在多个Kafka代理之间复制分区来实现的。因此如果一个代理由于软件或硬件故障挂掉，数据也不会丢失。

领导-跟随机制：领导者持有分区，跟随者则进行分区的复制。当领导者挂掉后，会有某个跟随者转变为新的领导者。

注意：虽然在Hyperledger Fabric中Kafka被称为共识（Consensus），但是其核心是交易排序服务以及额外的崩溃容错能力。

zookeeper

zookeeper是一个分布式key-value存储库，通常用于存储元数据及集群机制的实现。

zookeeper 允许服务（Kafka代理）的客户端订阅变化并获得实时通知。这就是代理如何确定应当使用哪个分区领导者的原因。

zookeeper有超强的故障容错能力，因此Kafka的运行严重依赖于它。

在zookeeper中存储的元数据包括：

消费者分组在每个分区的读取偏移量
访问控制清单，用于访问授权与限制
生产者及消费者配额，每秒最多消息数量
分区领导者及健康信息

前言