fabric区块链设计
fabric区块链设计
个人思路：
一个交易就是一个org，用channel通道联系在一起，数据拥有方和访问方都是一个peer节点，因为peer节点可以属于多个组织，所以应该可以访问多个订单（也就是交易）里的数据
一个订单的数据应该是写在peer下面的ledger账本里面的，在我们的东西里面，应该是存的经过web服务器或者也就是说微信小程序客户端对数据分层加密之后的 密钥，应该指的是解密密钥
订单的具体内容还要拿解密密钥去下载数据库里的数据进行解密得到
区块链上要做的的事情，主要是，第一，把客户端分层加密得到的不同层的密钥以及得到这些密钥需要的属性集保存下来，第二，验证 客户端发送下来的请求，核对属性集，返回相对应的密钥，交给客户端再解密，结合数据库数据，递交给数据访问方的是明文的信息
架构
-
成员服务：注册 管理 审核
-
区块链服务：共识管理 分布式账本实现 账本存储 网络中节点之间的通信
区块链 ：peer节点从order service节点接受交易区块 确认有效后追加到peer文件系统中的Hash Chain上
交易：链码的部署和调用
部署交易：在Peer上启动链码容器 交易成功说明链码安装在区块链上
调用交易：使用链码提供的一个函数 调用成功链码特定函数对账本数据进行操作，返回结果 -
链码服务：链码部署以及运行环境
-
事件：技术实现 组件之间的异步通信
大多数现存的支持智能合约的区块链平台都遵循排序执行架构，在该架构中，通过共识协议验证交易并将交易排序，接着将这些交易广播到所有对等节点中，然后每个对等节点依次执行这些交易。
我们的运行架构
Client 节点（客户端节点）
代表用户操作的实体，它必须连接到某一个 peer 节点或者orderer 节点上才能与区块链网络进行通信。一般意义上，client 节点对应一个客户。而在本作品中，为了方便建立自动化的流程和可视化页面，我们将 client 节点抽象为网站服务器，而用户是网站服务器上的用户。 因此，我们的网络中只有一个 client 节点，由网站服务器扮演，网站服务器处理用户提交的 http 请求信息，并转化为智能合约请求信息，并发送到与之连接的 peer 节点
Orderer 节点（排序节点）
Orderer 节点负责接收包含背书签名的交易，将交易按照某种规则排序并打包成区块，然后广播给 Peer 节点。在我们的项目中，网络中只有一个排序节点（solo模式）。
Peer 节点（对等节点）
在Hyperledger fabric中，peer节点分为记账节点（committer），主节点（leader），背书节点（endorser）和锚节点（anchor）。在我们的项目中，由于节点个数少，所有节点都承担记账和背书工作，每个节点都保存一份账本，并且所有节点之间的账本都是一致的。
锚节点是在一个通道上可以被所有其它节点发现的节点，每个 Peer 节点至少连接一个锚节点。
一个网络中的 Peer 节点可能隶属于不同的组织
通道（channel） 通道是一个逻辑结构，它为网络中的 peer 节点、client 节点提供了私有的沟
通与交易渠道。加入通道后，这些模块可以共享或管理通道内的所有账本。
数据存储
数据拥有者的隐私数据经过对称加密后上传至云数据库，实现数据持久化，然后将该对称密钥经过CP-ABE 加密后上传至区块链
Hyperledger Fabric 内，每一数据块内包含的信息如图
区块内的所有交易被组织为一颗默克尔树，在区块头内存储该树根节点内的哈希值。区块内的区块数据部分主要包括该区块内的交易信息，在每一交易内，存有交易头，签名，交易发起，交易响应以及背书。交易头内包括了该交易的元数据，签名用来验证交易未被篡改。交易发起内包含利用智能合约发起交易时指定的参数，交易响应为执行智能合约的输出值，交易是否合法需要判断该交易是否满足背书策略，背书为背书节点对该交易进行签名证明该交易的合法性。
智能合约的实现
智能合约需要在区块链系统中每个节点上执行就要求了系统需要采取复杂的措施来保证整个系统免受潜在的恶意合约的攻击，以此来保证整个系统的弹性。
优势：成本低 处理速度块 可靠 自治
网络结构和相关配置文件
OrdererOrgs:
- Name: WuliuOrderer
Domain: wuliu.com
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
- Hostname: orderer2
- Hostname: orderer3
- Hostname: orderer4
- Hostname: orderer5
PeerOrgs:
- Name: WuliuOrg1
Domain: wuliuorg1.wuliu.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
- Name: WuliuOrg2
Domain: wuliuorg2.wuliu.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
一个orderer节点 域名
两个peer的组织 域名 每个组织2个节点，目前有一个用户
合成peer节点的完整域名
生成组织和身份证书
证书密钥的MSP材料在 crypto-config文件夹
msp目录下包括各种证书文件，随后分发到对应orderer节点和peer节点上
为区块链创建一个GenesisBlock创世区块和Channel通道，通过配置定义相关信息
configtx.yaml中配置 主要配置
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- orderer.example.com:7050
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org1MSP.peer')"
AnchorPeers:
- Host: peer0.org1.example.com
Port: 7051
- &Org2
Name: Org2MSP
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
Policies:
Readers:
Type: Signature
Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org2MSP.admin', 'Org2MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org2MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org2MSP.peer')"
AnchorPeers:
- Host: peer0.org2.example.com
Port: 9051
每个org的锚节点：peer0.org1.example.com peer0.orgs.example.com
在first-network目录下channel-artifacts文件夹
每个org的锚节点：peer0.org1.example.com peer0.orgs.example.com
在first-network目录下channel-artifacts文件夹
生成应用通道交易配置文件：
# ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID mychannel
2020-08-11 15:36:52.561 CST [common.tools.configtxgen] main -> INFO 001 Loading configuration
2020-08-11 15:36:52.600 CST [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /root/gopath/hyperledger/fabric/scripts/fabric-samples/first-network/configtx.yaml
2020-08-11 15:36:52.600 CST [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 003 Generating new channel configtx
2020-08-11 15:36:52.603 CST [common.tools.configtxgen] doOutputChannelCreateTx -> INFO 004 Writing new channel tx
生成锚节点更新配置
../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSP
2020-08-11 15:40:53.034 CST [common.tools.configtxgen] main -> INFO 001 Loading configuration
2020-08-11 15:40:53.069 CST [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /root/gopath/hyperledger/fabric/scripts/fabric-samples/first-network/configtx.yaml
2020-08-11 15:40:53.069 CST [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 003 Generating anchor peer update
2020-08-11 15:40:53.071 CST [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 004 Writing anchor peer update
../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID mychannel -asOrg Org2MSP
2020-08-11 15:42:18.621 CST [common.tools.configtxgen] main -> INFO 001 Loading configuration
2020-08-11 15:42:18.657 CST [common.tools.configtxgen.localconfig] Load -> INFO 002 Loaded configuration: /root/gopath/hyperledger/fabric/scripts/fabric-samples/first-network/configtx.yaml
2020-08-11 15:42:18.657 CST [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 003 Generating anchor peer update
2020-08-11 15:42:18.660 CST [common.tools.configtxgen] doOutputAnchorPeersUpdate -> INFO 004 Writing anchor peer update
