Fabric-02Peer、Orderer以及CA

最新推荐文章于 2023-07-01 13:16:51 发布

又菜又爱玩٩( ö̆ ) و

最新推荐文章于 2023-07-01 13:16:51 发布

阅读量7.1k

点赞数 2

分类专栏： BlockChain

本文链接：https://blog.csdn.net/a972669015/article/details/118653519

版权

BlockChain 专栏收录该内容

17 篇文章 6 订阅

订阅专栏

五、Peer

5.1Fabric Peer

特点

联盟链中，peer节点代表各个企业和组织。

区块链网络主要是由一系列peer节点组成，peer节点是整个区块链网络的基础，因为它是账本和智能合约的载体，通过智能合约，账本以不可篡改的方式记录了交易的全过程；

每个节点可以加入一个或多个channel；
每个channel维护自己的一个或多个账本，账本之间是隔离的；
每个peer可以安装不同的智能合约；
交易完成后，peer会发送event事件给client端；
每个channel都有local MSP，提供身份认证。

种类

Committing Peer

维护账本和状态
验证和提交交易

Endorsing Peer

为接收到的交易进行背书，并给客户端响应
持有智能合约

背书策略

每个链码在部署的时候都会指定背书策略；

在背书节点中，当模拟执行完结果以后，会通过ESCC (Endorsement System ChainCode)对执行结果进行签名；

在记账节点中，会通过VSCC (Validation System ChainCode) 根据背书策略验证交易是否正确。

背书策略是在实例化链码时指定，如图就是指：在mychannel上实例化链码mycc，并指定背书策略为AND(‘Org1MSP.member’) ，就是说只要org1中的成员签名，就认为交易是合理的。

5.2Fabric Ledger and State DB

Fabric账本是有序的，不可修改的历史交易记录，由两部分组成：

区块：维护channel的配置信息、历史交易记录

世界状态：维护账本当前状态，方便进行快速查询

区块

分为三个部分：

区块头
- 区块编号
- 当前区块hash
- 前一区块hash
区块数据
- 交易数据
  - 头部：包含链码名字、version等信息
  - 签名：Client端用户的签名，谁发起的请求就是谁的签名
  - 交易：用户端给背书节点的proposal，主要是input参数
  - 响应：智能合约执行的结果，执行前的数据和执行后的数据
  - 背书：每个背书节点返回的结果，是个list
区块元数据
- 区块写入时间
- 区块写入人
- 签名

状态

维护账本的当前信息，k-v形式，如{key=balance，value=100} version=1。

账本样例：

5.3Smart Contract

Smart Contract & chaincode

Smart Contract
- 区块链的核心
- 定义不同组织之间的业务规则或规范
- 产生交易transaction记录在账本ledger中
- 打包到链码Chaincode中，一个Chaincode可以包含多个智能合约Smart Contract
Chaincode
- 可以打包多个智能合约Smart Contract
- 链码Chaincode部署之后，智能合约Smart Contract就可以给用户端使用

smart contract interact with the ledger

智能合约由开发人员根据业务逻辑进行开发，同时还会开发Client端
当客户端发送请求时，可以通过智能合约调用API去操作World state。get操作直接返回数据，不会在区块链中增加新的交易；put、delete在修改World state同时还会在区块链上增加新的交易记录，增加新的区块；qi中delete只会删除World state中的数据，不会删除区块中的账本数据，会增加新的记录
Blockchain提供API可以让客户端去访问
交易完成时通过智能合约发送event事件给用户端

Chaincode Lifecycle

Package --> Install --> Instantiate --> Running --> Upgrade

Package

生成ChaincodeDeploymentSpec (CDS)，包括源代码、名字和链码版本号
指定初始化策略，即由谁来进行初始化，表达式与背书策略相同
由拥有chaincode的实体进行签名

peer chaincode package -n mycc -p github.com/hyperledger/fabric-samples/
chaincode/abstore/go -v 1.0 -s -S -i "AND('OrgA.admin')" ccpack.out

peer chaincode signpackage ccpack.out signedccpack.out

Install

安装在peer节点上
一个peer节点可以安装多个不同的chaincode
必须安装在channel所有的背书节点上

peer chaincode install ccpack.out

Instantiate

在通道上实例化一个chaincode
实例化期间设置背书策略

peer chaincode instantiate -n mycc -v 1.0 -c '{"Args":[“a”,“100”, “b”, “200”]}' -P "AND ('Org1.member','Org2.member')"

Running

Client端可以发送交易请求
智能合约处理交易、更新账本、返回响应
Client端接收响应

peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}’ 
peer chaincode invoke -o order-url -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'

Upgrade

可随时更新升级
更新之前，最新版本的chaincode必须已经安装在所有的背书节点上
和实例化类似，每次只能影响一个channel

peer chaincode upgrade -C mychannel -n mycc -v 1.0 -c '{"Args":["a","100","b","200"]}'

System Chaincode

在Fabric系统中有一些System Chaincode，它运行在peer进程上，而不是像我们开发的合约运行在一个单独的容器中。它实现了一些系统的行为。

5.4Gossip Protocol

功能

维护管理channel中的peer成员以及peer节点的发现
不断传播账本数据给channel中的所有节点
对新加入的peer，通过点对点(peer-to-peer)的状态传播来更新账本数据

数据传输

线上的peer节点通过不断向周围广播存活消息来证明它们的可用性
peer通过收集他们的存活信息维护channel成员
当leader节点从order服务拿到交易信息后，会传播给其他节点。当一个peer收到消息后，还会散发给其他peer
每个peer会不断询问周围的peer两者的状态是否匹配，如果不匹配就会从其他节点拉取最新的区块，通过P2P的方式使账本信息保持一致
一个channel上的peer节点不能传播数据给其他channel

Leader Peer & Anchor Peer

在Gossip中，根据不同的功能，可以分为Leader Peer和Anchor Peer 。

Leader Peer
- 与orderer节点联系并拉取新的区块
- 把交易传播给组织中其他记账节点，其他记账节点收到消息后还会继续散播
- 在一个组织中允许存在一个或者多个Leader Peer
- Leader Peer 选举
  - 静态Static
    - 系统管理员在配置的时候手动进行指定当前节点成为leader peer
```
peer: 
 # Gossip related configuration 
 gossip: useLeaderElection: false 
 orgLeader: true
```
  - 动态Dynamic
    - peer节点通过执行leader选举程序来选举一个leader
    - 动态选举的leader节点会不断发送心跳给其他peer节点证明其存活，leaderAliveThreshold指定间隔时间
```
peer: 
 # Gossip related configuration 
 gossip: 
 useLeaderElection: true 
 orgLeader: false 
 election: 
 leaderAliveThreshold: 10s
```
Anchor Peer
- 使用Gossip协议，确保channel上不同组织的peer节点都是互相认识的。
- 比如OrgA中的peer节点想要传播数据到OrgB中的peer节点，但是两者之间不认识，那么OrgA的节点就要先联系OrgA的Anchor Peer，OrgA的Anchor Peer联系OrgB的Anchor Peer，OrgB的Anchor Peer联系OrgB的节点，然后就可以相互通信，之后就可以直接联系。

5.5Private Data

隐私数据存储在每个授权的peer节点（authorized peer）上的隐私数据库（private database）中
隐私数据集合策略（Private data collection policy ）会定义授权的peer节点
排序服务（Ordering service）不能看到隐私数据
隐私数据的传播是通过Gossip协议

Tx flow with private data

隐私数据在交易流程中的传递：

用户端提交的请求中包括隐私数据
背书节点模拟执行交易时，会存储隐私数据在一个临时数据库中，同时向其他有权限的peer节点传播
背书节点返回背书结果给用户端时，不会返回隐私数据，只有隐私数据k-v的hash值
记账节点验证时，会验证隐私数据的hash值，并和临时数据库中的数据进行比较，看是否有被修改
验证通过，记账节点会把隐私数据从临时数据库正式移到隐私数据库中

private data collection

[ 
    {
    	"name": "collectionMarbles",
    	"policy": "OR('Org1MSP.member', 'Org2MSP.member')", 
        "requiredPeerCount": 0, 
        "maxPeerCount": 3,
    	"blockToLive":1000000, 
        "memberOnlyRead": true
    },
	{
        "name": "collectionMarblePrivateDetails",
        "policy": "OR('Org1MSP.member')", 
        "requiredPeerCount": 0, 
        "maxPeerCount": 3,
        "blockToLive":3, 
        "memberOnlyRead": true
	} 
]

一份private data collection示例，包含两个collection，分别是collectionMarbles、collectionMarblePrivateDetails。其中以collectionMarbles为例，policy指Org1MSP.member, Org2MSP.member可以访问隐私数据；requiredPeerCount指背书节点返回执行结果之前，为了保证私有数据已经传播给其他节点，必须传播给几个peer节点；maxPeerCount指最多传播给几个节点；blockToLive指隐私数据在在DB中保存多久，超过时间自动销毁。

六、Orderer

6.1Atomic Broadcast(Total Order)

Orderer节点在流程中的作用：Orderer作为一个集群服务，会从各个Orderer节点接收transaction，并且把接收到的所有的transaction进行全排序，并根据一定的规则打包成区块。

Fabric作为联盟链，并不是所有的人都可以出块，都可以参与排序过程，Orderer是由允许的几个组织来进行排序工作。

Identical：产生完全相同的块，最终每一个Orderer产生的块都必须一致；
Crash：CFT，当集群中的节点挂掉了，剩下的节点依然可以完成排序功能，明确最多容错几个节点；
Partition：当网络隔离之后，隔离的节点应该有拒绝写或者拒绝读等措施；
Strong Consistency：不同于某些公有链的最终一致性（比如比特币的最长合法链，6个节点确认机制等），Fabric中需要有强一致性，不能有临时分叉，当一笔交易提交之后，是绝对不能被覆写的；
BFT：拜占庭容错，即允许作恶节点存在。Orderer本身不是拜占庭容错，而是CFT容错（无论是Kafka还是Raft）。但是即使Orderer节点是CFT，并不代表这个Fabric是CFT，Fabric依然是BFT，因为Fabric中还有peer的背书和验证环节。由于Orderer节点是CFT容错，所以有些攻击无法防范，比如恶意节点运行Orderer，会使得Orderer网络本身拒绝出块，这样用户提交的交易可能无法写入到账本中，但是这种攻击是可探查的，而且不会造成数据的丢失和篡改，即可作恶的严重程度是有限的。

6.2Block Cutting

如果交易已经排序完成，之后需要对其生成区块，那么生成区块的规则有以下几种：

BatchSize
- MaxMessageCount：一个块中最多有多少个交易
- AbsoluteMaxBytes：一个块最大的绝对大小
- PreferredMaxBytes：期待一个块的大小是多大
规则就是，当交易大小的总和达到了PreferredMaxBytes，或者交易个数达到了MaxMessageCount，就会打包一个区块。

但是要注意的是，块的大小不可能永远小于PreferredMaxBytes，比如PreferredMaxBytes是800，前9个交易大小是700，第10个交易就是200，那么加一起大于800，这种情况下第10个交易也会随着前9个一起打包到区块中。

AbsoluteMaxBytes相当于限制了单个交易transaction的大小，超过这个的交易会被拒绝。
BatchTimeout
- Timeout：即使区块没有足够的交易，在一定时间后也会把已有的交易打包到块中

6.3Channel

Fabric中有System Channel，是系统默认的channel，作用就是管理用户的channel。

Orderer启动需要有Genises Block，该区块规定了所有关于System Channel的配置，那么所有的Orderer都必须用同样的Genises Block来启动。启动之后系统会默认存在一个System Channel，当创建一个用户channel的时候，其实是向System Channel发送了一个创建的交易transaction，交易中包括channel名字，配置信息，包括哪几个组织等属性。System Channel拿到交易后，发现是创建channel的请求，就会创建一个channel，并把交易中包括的新channel的配置信息，作为用户channel的Genises Block放在系统中，这样一个channel就创建完成。

当要修改channel的配置时，就是向channel发送一个配置的交易，配置交易是不遵循出块规则的，永远是自己一个块，因为配置信息需要尽快生效，那么当去修改一个channel的属性时，也是需要共识的，共识之后提交到orderer的账本中，完成属性更新。

6.4Consensus

Solo

Kafka

Raft

七、MSP_CA

7.1CA

CA 是 Hyperledger Fabric 的证书颁发机构（CA），是Hyperledger Fabric内一个可选的 MemberService 组件，对网络内各个实体的身份证书进行管理，主要实现：

负责 Fabric 网络内所有实体（Identity）身份的注册。
负责对数字证书的签发，包括 ECerts（身份证书）、TCerts（交易证书）。
证书的续签或吊销。

Fabric CA 在Fabric网络中的作用：

访问 Fabric CA 服务器可以通过 Hyperledger Fabric CA 客户端或通过其中一个 Fabric SDK 来实现，与 Hyperledger Fabric CA 服务器的所有通信都是通过API 进行。

Hyperledger Fabric CA 客户端或 SDK 可以连接到 Hyperledger Fabric CA 服务器集群，集群由 HA Proxy 等实现负载均衡。服务器可能包含多个CA，每个CA都是根CA或中间CA，每个中间CA都有一个父CA。

Hyperledger Fabric CA 的身份信息保存在数据库或LDAP中。目前 Fabric CA 支持的数据库有 MySQL、PostgreSQL、SQLite；默认使用 SQLite 数据库。如果配置了 LDAP，则身份信息将保留在 LDAP 而不是数据库中。

Fabric CA Server

配置设置：

命令行
环境变量
配置文件

Fabric CA Server 参数：

start
init
params
- -b (bootstrap identity)
- -n (ca name)
- -u (intermediate CA)
- -d (debug)
- -H (home directory)
- …
version
…

初始化：

fabric-ca-server init 会对CA进行初始化，生成Fabric CA Server目录，目录中大概包含：

ca-cert.pem
ca-chain.pem
tls-cert.pem
fabric-ca-server.db：数据库
fabric-ca-server-config.yaml：默认配置文件
IssuerPublicKey
IssuerRevocati
onPublicKey
MSP

Intermedia CA：

避免root CA暴露，降低风险
为跨更多的组织提供更大的灵活性
Intermedia CA需要通过root CA签发证书之后才能使用
Certificate Chain在root CA和一系列Intermedia CA之间信任

Fabric CA Client

Fabric CA Client参数：

7.2PKI

PKI（Public Key Infrastructure）：公钥基础结构。由向各方（如服务的用户，服务提供商）发布数字证书的证书颁发机构组成，然后他们使用它们在与其环境交换的消息中对自己进行身份验证。

Digital Certificates：数字证书，包含与证书持有者相关的一组属性的文档
Public and Private keys：公钥和私钥
Certificate Authorities：证书颁发机构，证书颁发机构向不同的参与者分发证书，这些证书由CA进行数字签名。CA是为组织的参与者提供可验证的数字身份的基础
Certificate Revocation List：证书撤销列表，某种原因而被撤销的证书的引用列表

7.3MSP

八、Fabric network

Configure & Start Ordering Service

首先启动Ordering Service

$ docker-compose [-f orderer.yml] ...

Configure & Start Peer Nodes

Ordering Service启动之后，需要配置各个节点。定义好联盟链中有哪些组织，每个组织有多少个节点，其中多少个背书节点，多少个记账节点（通常会把背书和记账放在一个节点上）

$ peer node start ...

Install Chaincode

在每个背书节点上安装chaincode

$ peer chaincode install ...

Create Channels

根据业务需求，来创建不同的channe

$ peer channel create –o [orderer] ...

Join Channels

判定哪些peer加入哪些channel

$ peer channel join ...

Instantiate Chaincode

对chaincode进行实例化，同时指定背书策略

$ peer chaincode instantiate ... –P ‘policy’

包含多个组织、通道的网络示例：

示例中包含：

4个organization，每个organization都有自己的CA

org4提供orderer节点，其他org提供peer节点

channel1包含peer1、peer2、orderer4节点，安装的chaincode是cc1，安装的Smart Contract是s5，维护的账本是L1

channel2包含peer2、peer3、orderer4节点，安装的chaincode是cc2，安装的Smart Contract是s6，维护的账本是L2

peer2节点安装了两个不同的chaincode，维护两套不同的账本

A是客户端，其中A1和A2都可以访问channel1，A2和A3都可以访问channel2

又菜又爱玩٩( ö̆ ) و

关注

2
点赞
踩
11

收藏

觉得还不错? 一键收藏
1
评论
Fabric-02Peer、Orderer以及CA

五、Peer5.1Fabric Peer特点联盟链中，peer节点代表各个企业和组织。区块链网络主要是由一系列peer节点组成，peer节点是整个区块链网络的基础，因为它是账本和智能合约的载体，通过智能合约，账本以不可篡改的方式记录了交易的全过程；每个节点可以加入一个或多个channel；每个channel维护自己的一个或多个账本，账本之间是隔离的；每个peer可以安装不同的智能合约；交易完成后，peer会发送event事件给client端；每个channel都有local MSP，提
复制链接

扫一扫