Fabric系列 - 链码-内部链码的特性

(1)Fabric repo下的案例

Chaincode(1.4的目录结构)

fabric/examples/chaincode/go
├── example02			#一个简单的转账合约
├── eventsender			#发送事件通知
├── passthru			#调用其他链码(或者其他channel的链码)

example02 (转账)

一个简单的转账合约。该链码简单实现了两方的转账功能，很适合初学者上手。

eventsender (发送事件通知)

展示如何在链码中发送事件通知，以进行交易确认或审计

注意: 每笔交易只能发送一个事件

stub.SetEvent("evtsender", []byte(tosend))

passthru (调用其他链码 或 其它channel的链码)

该链码实现了一个简单的链码“网关”，其对外暴露的Invoke接口允许用户调用其他链码（指定ID、方法和参数），并将调用结果返回用户。

调用其他链码需要使用stub.InvokeChaincode方法。该方法用于调用另一个链码中的Invoke方法，格式为：

InvokeChaincode(chaincodeName string,args[][]byte,channel string)pb.Response

其中，chaincodeName为链码ID；args为调用参数；channel为调用的链码所在通道。如果channel为空，则默认为当前通道。

注意，stub.InvokeChaincode方法目前仅限于读操作，同时不会生成新的交易。

(2)fabric-samples下的案例

fabric-samples/chaincode/README.md
├── abac				#基于属性的权限控制
├── marbles02			#资产权属管理 (包含 分页范围查询 的用例)
├── marbles02_private	#私密数据(允许通道内指定若干组织访问特定私密数据)

marbles02 (资产权属管理)

以大理石的权属管理为例，介绍如何在链码中定义资产，以及资产的创建、查询、转移所有权等操作。

abac (基于属性的权限控制)

fabric基于证书属性的权限控制, 官方有使用案例
v1.4.8 https://github.com/hyperledger/fabric-samples/tree/v1.4.8/chaincode/abac
v2.2.1 https://github.com/hyperledger/fabric-samples/tree/v2.2.1/asset-transfer-abac

展示如何在链码中利用证书属性对访问权限进行细粒度控制

链码中进行权限控制需要通过客户端身份库github.com/hyperledger/fabric-chaincode-go/pkg/cid. 该库提供了获取调用者的MSP ID和身份属性的相关方法

通过调用cid.AssertAttributeValue方法，确定调用者是否有abac.init属性。调用者的属性是通过Fabric CA进行添加的

#通过sdk注册时添加属性
fabric-ca-client register ... --id.attrs 'abac.init=true'#合约中检查
cid.AssertAttributeValue(stub, "abac.init", "true")

marbles02_private (私密数据)

fabric支持私密数据的合约功能, 官方有使用案例
v1.4.8 https://github.com/hyperledger/fabric-samples/tree/v1.4.8/chaincode/marbles02_private
v2.2.1 https://github.com/hyperledger/fabric-samples/tree/v2.2.1/chaincode/marbles02_private

Fabric 1.2版本引入了私密数据功能，允许通道内指定若干组织访问特定私密数据。通过示例介绍如何在链码中使用私密数据

定义私密数据 collections_config.json

[{"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}
]

读写私密数据

stub.PutPrivateDatastub.GetPrivateData

(3)链码升级(2.0)

在 chaincode更新代码后，需要把新的代码通过install交易安装到正在运行该 chaincode的 peer 上，安装时需注明比先前版本更高的版本号，接下来向任意一个安装了新代码的 peer 发送 upgrade 交易就能更新 chaincode，chaincode 在更新前的状态也会得到保留。

version与sequence

• **version：**与给定链码包关联的版本号或值。如果升级链码二进制文件，则还需要更改链码版本。
• **Sequence：**链码被定义的次数。该值是一个整数，用于跟踪链码升级。例如，当您第一次安装和批准链码定义时，序列号将为 1。当您下次升级链码时，序列号将增加到 2。
• Fabric 链码生命周期使用链码定义中的Sequence来跟踪升级。所有频道成员都需要将序列号加一并批准新定义以升级链码。version 参数用于跟踪链码二进制文件，只有在升级链码二进制文件时才需要更改。

升级步骤

1. 重新打包链码(升级链码文件情形)
2. 重新安装链码(升级链码文件情形)
3. 组织同意新的链码定义:
   (1) 升级链码文件:需要更新链码定义中的链码版本和package ID
   (2)仅仅更新背书策略:无需执行1,2
   无论哪种情况,每次升级sequence都需要加1
4. 提交链码定义:当足够数量的通道成员批准了新的链码定义时，一个组织可以提交新定义以将链码定义升级到通道。 作为生命周期过程的一部分，没有单独的升级命令
5. 如果您要求在链码定义中执行Init函数，则需要在成功提交新定义后再次调用Init函数来初始化升级的链码
   • 注意：在升级过程中，chaincode的Init函数会被调用以执行数据相关的操作，或者重新初始化数据；所以要多加小心避免在升级chaincode时重设状态信息。

链码的背书策略的升级

基本每个都是痛点。尤其背书策略的升级，这是目前链码管理最为人诟病的地方。背书策略在链码实例化时指定，一旦通道成员发生变化就必须更新背书策略，而更新背书策略又需要所有成员进行链码升级。现在一个默认的背书策略就可以解决所有问题，有特殊背书需求，也可以仅升级背书策略就行。而去中心化的链码部署/升级过程也更加的”区块链“了，不再是一言堂。

---

往期精彩回顾:

区块链知识系列

密码学系列

零知识证明系列

共识系列

公链调研系列

BTC系列

以太坊系列

EOS系列

Filecoin系列

联盟链系列

Fabric系列

智能合约系列

Token系列