Fabric记录

Fabric记录

[TOC]

Architecture

系统架构

Transactions

1. 部署合约的交易
2. 调用合约的交易
3. 纯查询的交易
4. 合约交叉调用的

Blockchain datastructures

State

区块链的状态是经过带版本的键值对进行存储的，链码经过put和get这两种 KVS 操做进行读写。

状态s由K->(V,N)的映射组成，其中：

• K是键的集合
• V是值的集合
• N是有序版本号的集合

V和N有一个⊥的元素，表明空类型

对于任意k，咱们有：s(k)=(v,ver)。两种KVS 操做以下：

• put(k,v)，以 s 做为初始撞死，以 s'做为结束状态，知足：

  1.s'(k)=(v,next(s(k).version))

  2.对于k'!=k，有s'(k')=s(k')

• get(k) 返回 s(k)

Ledger

• PeerLedger

  与 OrdererLedger 的区别是，还维护了一个区别是否有效 transaction 的 bitmask

• OrdererLedger

Nodes

Client

Peer

特殊的接收 client 提案的 peer，叫作__endorser__

Orderer

排序服务对 clients 和 peers 提供一个共享的通讯频道(channel)，channel 提供消息投递的原子性。

Partitioning。Orderer 提供多个 channel，clients 能够按需订阅。

Ordering service API。Peers 经过 API 链接到 orderer 提供的 channel，两个基础的 API 以下：

1. broadcast(blob)，client 调用
2. deliver(seqno, prevhash, blob)，orderer 调用用来通知 peer

排序服务特性

1. 安全性（一致性保证）。广播的消息是一个一个块deliver(seqno, prevhash, blob)，后一个块有前一个的 hash，即区块链。
2. 活性（投递保证）。

交易背书工做流

client 建立交易并发送到 endorser

问题：endorser 是如何肯定的？一个 org 只有一个 endorser 么？这个 endorser 和 leader peer 是同一个么？

endorser 是合约维度的，一个合约在配置背书策略的时候，会配置 endorser，好比：

peer chaincode instantiate -C <channelid> -n mycc -P "AND('Org1.member', 'Org2.member')"

其中 Org1.member, Org2.member就是 endorser，这里的 endorser 表示的是哪一个 org，但 org 里面还有多个 peer。另外一种说法，实例化合约的 peer 就是 endorser。合约必须只被安装在 endorser 上以保证合约代码的机密性。

PROPOSE消息格式

<PROPOSE,tx,[anchor]>，其中：

• tx=<clientID,chaincodeID,txPayload,timestamp,clientSig>

  对于不一样的交易类型，txPayload有所不一样

  • 调用合约交易
    txPayload = <operation, metadata>

    • operation：调用的函数及参数
    • metadata：相关的属性

  • 部署合约交易
    txPayload = <source, metadata, policies>

    • source：链码
    • metadata：相关的属性
    • policies：背书策略，须要注意的是，这里只给出背书策略的 ID 以及对应的参数
• anchor
  版本号，若是有这个字段，那么 endorser 在背书的时候会检查对应的 key 是否是等于指定的 version

client 会将tid=HASH(tx)保存在内存中，等待 endorser 的反馈

endorser 模拟交易并签名

endorser 收到请求后进行以下操做：

1. 验证 clientSig
2. 若是指定了anchor则先检查 version
3. 模拟交易，获取 readset 和 writeset
4. 生成tran-proposal发往背书模块（endorsing logic）
   默认直接接受并进行签名，可是也能够进行任意操做，将tran-proposal和tx做为输入发往相关系统得到断定是否要进行背书。背书逻辑调用的是系统默认的合约 ESCC，固然也能够本身编写背书合约，可是这始终是一个同步调用操做，不用也不能由人工介入。
5. 若是决定背书，则向提交请求的 client 发送：
   <TRANSACTION-ENDORSED, tid, tran-proposal,epSig>，这个大概就是endorsement吧？

   tran-proposal := (epID,tid,chaincodeID,txContentBlob,readset,writeset)，txContentBlob是与链码/交易有关系的信息（例如：txContentBlob=tx.txPayload）

   epSig是 endorser 对tran-proposal的签名

6. 若是背书失败，则发送(TRANSACTION-INVALID, tid, REJECTED)

client 收集背书结果并经过排序服务广播

根据背书策略，在收到足够的背书响应后，client 向 orderer 发起broadcast(blob)

orderer 发送交易到 peer

orderer 向 peer 发送 deliver(seqno, prevhash, blob)，peer 收到后，作以下处理：

1. 根据blob.tran-proposal.chaincodeID对应的合约检查blob.endorsement有效性
2. 检查blob.endorsement.tran-proposal.readset的版本检查，默认使用串行的隔离级别
3. 在PeerLedger的 bitmask 中标记该交易为有效，并应用结果集blob.endorsement.tran-proposal.writeset
4. 若是背书策略检查失败，则在PeerLedger的 bitmask 中标记该交易为无效

Gossip

gossip主要起到如下几个做用：

1. 检测可用的 peer 以及监测 peer 是否存活
2. 同步帐本数据
3. 将新链接上的 peer 数据更新

领头选举

每一个 org 会选举出一个 leader peer（实际上能够存在多个），负责链接到 orderer。leader peer从orderer 拿到新块的信息后分发给其余 peer。

静态选主

能够在core.yaml中配置：

peer:
    # Gossip related configuration
    gossip:
        useLeaderElection: false
        orgLeader: true

也可使用环境变量：

export CORE_PEER_GOSSIP_USELEADERELECTION=false
export CORE_PEER_GOSSIP_ORGLEADER=true

须要注意的是：

1. 若是都配置为 false，那么 peer 不会尝试变成一个 leader
2. 若是都配置为 true，会引起异常
3. 静态配置的方式，须要自行保证 leader 的可用性

动态选主

选主具体算法不明，相似 raft选主，leader 须要向从节点发送心跳，动态选主只能产生1个主节点

能够在core.yaml中配置：

peer:
    # Gossip related configuration
    gossip:
        useLeaderElection: true
        orgLeader: false
        # 心跳频率
        election:
            leaderAliveThreshold: 10s

也可使用环境变量：

export CORE_PEER_GOSSIP_USELEADERELECTION=true
export CORE_PEER_GOSSIP_ORGLEADER=false

Gossip 消息

点对点通讯的安全性是由TLS保证的，不须要签名，这里会不会有什么问题？