fabric入门
fabric逻辑框架
首先是身份管理
用户身份:
1.orderer节点 - 排序节点,矿工
2.peer节点 - 账本,存储数据
3.客户端程序 - 访问orderer,peer
fabric会针对这些不同的角色,颁发不同的证书
然后是账本管理
账本是在peer节点上,账本由两部分组成
1.区块链 - 所有的交易记录
2.世界状态 - 数据库,键值对
里面存着最新的记录
默认的数据库是levelDB,可以使用couchDB
然后是交易管理
部署交易
1.编写链码,业务逻辑,智能合约
2.将链码安装到peer节点上
调用交易
1.对链码中的业务逻辑进行调用
2.链码中有对应的接口
现在fabric只支持两种语言
1.golang
2.nodejs
fabric基础概念
节点
peer, ledger, chaincode
节点分为三种
1.客户端 - client
连接peer节点
连接orderer节点
2.peer节点 - 账本
交易记录-区块链
世界状态
在整个分布式网络中,分布着很多的peer节点
每个peer节点的数据相同
对一个节点进行操作,数据会被同步到网络中的其他节点上
职责:
1.背书节点
2.提交节点
3.主节点
4.锚节点
3.orderer节点
orderer节点没有账本
客户端client也没有账本
orderer节点相当于矿工
对数据排序,打包,变成区块
orderer节点将打包的区块发送给peer节点
再由peer节点写入到账本中
排序是为了解决作弊的情况
实际上是orderer节点调用排序服务器
排序算法有2种:
1.solo,测试用的,确实很慢
2.kafka,分布式排序服务器,企业级
假设在一个fabric区块链网络中
有三个peer节点
P1, P2, P3
然后账本和智能合约都在peer节点上
账本是每个peer节点默认都有的
但是智能合约不是默认就有的
智能合约是由程序员编写好之后,安装到peer节点上
智能合约和账本是什么关系
编写完智能合约之后,对这个合约进行调用
然后就会写入账本,这时候账本发生了改变
客户端调用链码,链码修改账本
在一个peer节点上:
1.一个peer节点上可以有几个不同的账本
2.一个账本上可以有几份不同的合约,也就是有几种不同的业务逻辑
通道channel
通道是用来隔离数据的,
用户在不同的通道中,使用的数据是不同的,而且数据不共享,理解为群
通道是由共识服务(ordering)提供的一种通信机制
将peer和orderer连接在一起,
形成一个个具有保密性的通讯链路
实现了业务隔离的要求
假设现在有两个peer节点P1和P2
这两个peer属于同一个通道channel
P1和P2上账本的内容是一样的
P1和P2上安装的智能合约可以一样,也可以不一样
1.节点在同一个通道中才能通信
2.多个peer节点在同一个通道中,那么数据共享
3.一个节点可以同时加入到多个通道中
组织
1.组织1中有2个peer节点,没有部署在同一个通道,在同一个组织中职责相同
2.组织1中要存储数据,数据存储在peer1和peer2中
3.修改账本数据,需要客户端a1
a1的作用是连接peer1或者peer2
4.同一个组织节点上安装的智能合约是相同的
5.不同的组织安装的智能合约不同
6.如果多个组织属于同一个通道,那么这些组织中节点上的账本数据相同
fabric交易过程
背书策略:
交易被执行的流程(操作步骤)
比如当前网络中有两个组织
org1: peer1,peer2
org2: peer1,peer2
交易策略:
1.组织1中的peer1同意并且组织2中的peer1同意
2.两个组织的所有节点都同意
注意: 背书策略执行的结果并不会写入账本,这是一个模拟交易
交易过程
1.客户端向peer节点发起交易请求
2.peer节点收到请求,进行模拟交易,得到结果
3.peer节点将模拟结果发送给客户端
4.客户端连接orderer节点,将交易请求和模拟交易的结果发送
5.orderer节点接收数据,先排序再打包,发送给peer
6.peer节点接收数据,校验模拟交易的结果,如果没问题,写入账本
7.给客户端发送结果
账本
1.世界状态
保存在默认的levelDB数据库中,以键值对方式存储,可以修改
2.区块链
所有的交易记录
数据不可修改,只能添加
世界状态的值是通过区块链数据确定的
区块链中的数据:
1.一个区块链中有n条数据,以链状结构连接
2.fabric创始区块不存储交易数据
存储网络信息
1.通道
2.组织
3.第二个区块才开始存储交易数据
4.区块分三部分
1.区块头
当前区块的哈希值
前区块哈希值
2.区块数据
用户的交易记录
3.区块的元数据
fabric的网络组件
1.账本
2.智能合约
3.peer节点
4.排序服务器
5.通道
6.fabric证书颁发机构
搭建fabric网络的步骤
1.生成证书,相当于账号
1.组织的,节点的,用户的
2.需要写yaml配置文件
2.创建用来生成创始区块和通道的文件
1.yaml配置文件
3.启动节点
orderer,peer,客户端
都运行在docker中
为了方便管理,编写docker-compose配置文件,批量启动节点
4.通过当前组织的客户端,依次连接到当前组织的peer节点上
1.创建通道
2.加入通道
每个节点都需要加入
安装链码
对链码进行初始化,只需要一次,在任意节点做
测试-链码调用(客户端)
生成fabric证书
命令
cryptogen --help
证书文件的生成-yaml
配置文件
一般叫crypto-config.yaml
配置组织信息-访问组织的域名
1.peer节点-
访问peer节点的域名,peer节点名字
peer节点的个数
2.用户
用户的个数
我们打开fabric文件夹
找到fabric-samples
然后找到first-network
然后找到bin
现在我们的目录是
.../fabric-samples/first-network
我们看一下这个目录 ls
我们可以找到 crypto-config.yaml
我们可以在这个文件修改配置
然后我们进入
.../fabric-samples/bin
我们可以看到
cryptogen
我们可以导出一下模板
cryptogen showtemplate > template.yaml
然后我们可以
vi template.yaml
看一下这个模板
# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: example.com
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org1
# ---------------------------------------------------------------------------
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: false
# ---------------------------------------------------------------------------
# "CA"
# ---------------------------------------------------------------------------
# Uncomment this section to enable the explicit definition of the CA for this
# organization. This entry is a Spec. See "Specs" section below for details.
# ---------------------------------------------------------------------------
# CA:
# Hostname: ca # implicitly ca.org1.example.com
# Country: US
# Province: California
# Locality: San Francisco
# OrganizationalUnit: Hyperledger Fabric
# StreetAddress: address for org # default nil
# PostalCode: postalCode for org # default nil
# ---------------------------------------------------------------------------
# "Specs"
# ---------------------------------------------------------------------------
# Uncomment this section to enable the explicit definition of hosts in your
# configuration. Most users will want to use Template, below
#
# Specs is an array of Spec entries. Each Spec entry consists of two fields:
# - Hostname: (Required) The desired hostname, sans the domain.
# - CommonName: (Optional) Specifies the template or explicit override for
# the CN. By default, this is the template:
#
# "{{.Hostname}}.{{.Domain}}"
#
# which obtains its values from the Spec.Hostname and
# Org.Domain, respectively.
# - SANS: (Optional) Specifies one or more Subject Alternative Names
# to be set in the resulting x509. Accepts template
# variables {{.Hostname}}, {{.Domain}}, {{.CommonName}}. IP
# addresses provided here will be properly recognized. Other
# values will be taken as DNS names.
# NOTE: Two implicit entries are created for you:
# - {{ .CommonName }}
# - {{ .Hostname }}
# ---------------------------------------------------------------------------
# Specs:
# - Hostname: foo # implicitly "foo.org1.example.com"
# CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
# SANS:
# - "bar.{{.Domain}}"
# - "altfoo.{{.Domain}}"
# - "{{.Hostname}}.org6.net"
# - 172.16.10.31
# - Hostname: bar
# - Hostname: baz
# ---------------------------------------------------------------------------
# "Template"
# ---------------------------------------------------------------------------
# Allows for the definition of 1 or more hosts that are created sequentially
# from a template. By default, this looks like "peer%d" from 0 to Count-1.
# You may override the number of nodes (Count), the starting index (Start)
# or the template used to construct the name (Hostname).
#
# Note: Template and Specs are not mutually exclusive. You may define both
# sections and the aggregate nodes will be created for you. Take care with
# name collisions
# ---------------------------------------------------------------------------
Template:
Count: 1
# Start: 5
# Hostname: {{.Prefix}}{{.Index}} # default
# SANS:
# - "{{.Hostname}}.alt.{{.Domain}}"
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: The number of user accounts _in addition_ to Admin
# ---------------------------------------------------------------------------
Users:
Count: 1
# ---------------------------------------------------------------------------
# Org2: See "Org1" for full specification
# ---------------------------------------------------------------------------
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: false
Template:
Count: 1
Users:
Count: 1
这就是我们获取配置文件的两种方式
1.修改crypto-config.yaml
2.根据template模板修改
接下来我们介绍一下这个模板里面的一些关键字
1.OrderOrgs 不能改,排序节点的信息
Name: Orderer 排序节点的名字
Domain: abc.com 排序节点组织的域名
Specs:
-Hostname: orderer01 其中的orderer节点的名字
得到了访问这个orderer节点的地址
也就是orderer01.abc.com
-Hostname: orderer02
这样,就有了两个orderer节点
所以,orderer01.abc.com以及
orderer02.abc.com是2个节点
然后来看一下peer节点
PeerOrgs: 配置peer组织,peer组织根据职能划分
- Name: Org1 当前组织的名字
Domain: org1.abc.com 当前组织的根域名
EnableNodeOUs:true 在msp目录中生成config.yaml配置文件,false就不生成
Template: 使用模板去生成peer节点证书
Count: 2 生成2个peer节点证书
生成的两个是:
peer1.org1.abc.com
peer2.org1.abc.com
Users:
Count: 3
生成3个用户账号,都是普通用户
管理员会自动默认生成
# -------------------------
- Name: Org2
Domain: org2.abc.com
EnableNodeOUs:true
Template:
Count: 2
Users:
Count: 3
那么现在,我们来用这个template.yaml模板
来生成证书
我们执行
cryptogen generate --config=template.yaml
执行完输出了
org1.example.com
org2.example.com
那么我们ls一下,发现当前目录
crypto-config template.yaml
一个是模板文件,生成了一个crypto-config文件夹
然后我们进入crypto-config文件夹
发现
ordererOrganizations peerOrganizations
有这2个文件夹
然后我们来tree一下整个crypto-config文件夹
看一下生成了哪些东西
test/crypto-config$ tree
.
├── ordererOrganizations
│ └── example.com
│ ├── ca
│ │ ├── ae700bbde961a0fe3ab7a323d5a1d2f830553a1ca32f1bb2e7a7715a155a2e41_sk
│ │ └── ca.example.com-cert.pem
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.example.com-cert.pem
│ ├── orderers
│ │ └── orderer.example.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ │ └── Admin@example.com-cert.pem
│ │ │ ├── cacerts
│ │ │ │ └── ca.example.com-cert.pem
│ │ │ ├── keystore
│ │ │ │ └── c4494dd04fd4be4caf7a57cb08db04d47872bfa00ddc61c659ff3836ebb18112_sk
│ │ │ ├── signcerts
│ │ │ │ └── orderer.example.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.example.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ ├── tlsca
│ │ ├── 7e583662849c125581e42e3baf41acdaeeb62ec10532f14f3c70c4743c2bb428_sk
│ │ └── tlsca.example.com-cert.pem
│ └── users
│ └── Admin@example.com
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── 5e2c6c2f93557b43957f42efd769ba29e5123c8c9077330d6b54b9689a8de641_sk
│ │ ├── signcerts
│ │ │ └── Admin@example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── peerOrganizations
├── org1.example.com
│ ├── ca
│ │ ├── 521284a451c7fcd3fbedfb37bf72c813c90c2c097fd27efa8ff166a643695bc3_sk
│ │ └── ca.org1.example.com-cert.pem
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@org1.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org1.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org1.example.com-cert.pem
│ ├── peers
│ │ └── peer0.org1.example.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ │ └── Admin@org1.example.com-cert.pem
│ │ │ ├── cacerts
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── keystore
│ │ │ │ └── 5e67e9b1dd0b150a24729000960c7a521384295a81002579938ddca6f71432c2_sk
│ │ │ ├── signcerts
│ │ │ │ └── peer0.org1.example.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ ├── tlsca
│ │ ├── 9933d925b9551865ff6e7e2f1df605e8b9e935fcf67562cf006233cd98d099f6_sk
│ │ └── tlsca.org1.example.com-cert.pem
│ └── users
│ ├── Admin@org1.example.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ │ └── Admin@org1.example.com-cert.pem
│ │ │ ├── cacerts
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── keystore
│ │ │ │ └── 14f4d1a1652c83fed2dc4d3f42922ee947833a1db7c2a0b2ca0befc2f38c1dcf_sk
│ │ │ ├── signcerts
│ │ │ │ └── Admin@org1.example.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── client.crt
│ │ └── client.key
│ └── User1@org1.example.com
│ ├── msp
│ │ ├── admincerts
│ │ │ └── User1@org1.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── 814a522226f970ecb6d092c0d42140980840300f35ae90d494608fc19931ba6b_sk
│ │ ├── signcerts
│ │ │ └── User1@org1.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── org2.example.com
├── ca
│ ├── 0b4377e9d7e7615fcff03ea6e7e0268d05aff3b57a27907f48dcc9c30bd7bd48_sk
│ └── ca.org2.example.com-cert.pem
├── msp
│ ├── admincerts
│ │ └── Admin@org2.example.com-cert.pem
│ ├── cacerts
│ │ └── ca.org2.example.com-cert.pem
│ └── tlscacerts
│ └── tlsca.org2.example.com-cert.pem
├── peers
│ └── peer0.org2.example.com
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@org2.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org2.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── 896052db00e55556ffdbc60ac89104dc159cdd754341347880e60b8d895be3e1_sk
│ │ ├── signcerts
│ │ │ └── peer0.org2.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org2.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── server.crt
│ └── server.key
├── tlsca
│ ├── 040013bb7592309c7685ade0e74041ba848bc059f360928175847280e4f82e0d_sk
│ └── tlsca.org2.example.com-cert.pem
└── users
├── Admin@org2.example.com
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@org2.example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.org2.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── 886c89ef243ce0c7de3dc94427e45590168201de58fb90d0ee807593bcc1902f_sk
│ │ ├── signcerts
│ │ │ └── Admin@org2.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.org2.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── User1@org2.example.com
├── msp
│ ├── admincerts
│ │ └── User1@org2.example.com-cert.pem
│ ├── cacerts
│ │ └── ca.org2.example.com-cert.pem
│ ├── keystore
│ │ └── b1738f0d5ed76557ee5d9ba45eea74bf369d85c8def595c65b26e4bfed0e03f3_sk
│ ├── signcerts
│ │ └── User1@org2.example.com-cert.pem
│ └── tlscacerts
│ └── tlsca.org2.example.com-cert.pem
└── tls
├── ca.crt
├── client.crt
└── client.key
93 directories, 85 files
我们发现了很多的证书文件
有:
组织证书
用户证书
peer节点证书
orderer节点证书
1471
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
