背书策略（Endorsement policies）

blockchain › Hyperledger-Fabric › HOW-TO
, ,

背书策略

官方文档：Endorsement policies

。。。省略部分

Setting chaincode-level endorsement policies(设置链码级别的背书策略)

Chaincode-level endorsement policies are agreed to by channel members when they approve a chaincode definition for their organization. A sufficient number of channel members need to approve a chaincode definition to meet the Channel/Application/LifecycleEndorsement policy, which by default is set to a majority of channel members, before the definition can be committed to the channel. Once the definition has been committed, the chaincode is ready to use. Any invoke of the chaincode that writes data to the ledger will need to be validated by enough channel members to meet the endorsement policy.

通道成员在为其组织批准链码定义时，会同意链码级认可策略。需要足够数量的通道成员批准链码定义才能满足Channel / Application / LifecycleEndorsement策略，该策略默认情况下设置为大多数通道成员，然后才能将链码定义提交给通道。提交定义后，便可以使用链码了。任何将数据写入账本的链码的调用都需要由足够的通道成员来验证，以满足背书策略。

You can specify an endorsement policy for a chaincode using the Fabric SDKs. For an example, visit the How to install and start your chaincode in the Node.js SDK documentation. You can also create an endorsement policy from your CLI when you approve and commit a chaincode definition with the Fabric peer binaries by using the --signature-policy flag.

你可以使用Fabric SDKs来为链码指定背书策略，访问How to install and start your chaincode来查看使用Node.js SDK的文档。你也可以通过CLI在批准和提交链码定义时来创建背书策略，使用Fabric的peer可执行程序时使用 --signature-policy 标志来实现这个功能。

For example：

1
peer lifecycle chaincode approveformyorg --channelID mychannel --signature-policy "AND('Org1.member', 'Org2.member')" --name mycc --version 1.0 --package-id mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173 --sequence 1 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent

The above command approves the chaincode definition of mycc with the policy AND('Org1.member', 'Org2.member') which would require that a member of both Org1 and Org2 sign the transaction. After a sufficient number of channel members approve a chaincode definition for mycc, the definition and endorsement policy can be committed to the channel using the command below:

上面的命令使用 AND('Org1.member', 'Org2.member') 策略来批准mycc的链码定义，这个策略要求Org1和Org2的成员都需要对一笔交易进行签名。在有足够的通道成员批准了mycc的链码定义之后，这个定义和背书策略就可以使用下面的命令被提交到通道了：

1
peer lifecycle chaincode commit -o orderer.example.com:7050 --channelID mychannel --signature-policy "AND('Org1.member', 'Org2.member')" --name mycc --version 1.0 --sequence 1 --init-required --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:9051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

Notice that, if the identity classification is enabled (see Membership Service Providers (MSP)), one can use the PEER role to restrict endorsement to only peers.

请注意，如果启用了身份分类（请参阅 Membership Service Providers (MSP)），则可以使用PEER角色将背书限制为仅peer节点。

For example:

1
peer lifecycle chaincode approveformyorg --channelID mychannel --signature-policy "AND('Org1.peer', 'Org2.peer')" --name mycc --version 1.0 --package-id mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173 --sequence 1 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent

In addition to the specifying an endorsement policy from the CLI or SDK, a chaincode can also use policies in the channel configuration as endorsement policies. You can use the --channel-config-policy flag to select a channel policy with format used by the channel configuration and by ACLs.

除了从CLI或SDK中指定背书策略以外，链码还可以使用通道配置中的策略作为背书策略。你可以使用--channel-config-policy标志来选择一个通道策略，其格式由通道配置和ACL使用。

For example:

1
peer lifecycle chaincode approveformyorg --channelID mychannel --channel-config-policy Channel/Application/Admins --name mycc --version 1.0 --package-id mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173 --sequence 1 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent

If you do not specify a policy, the chaincode definition will use the Channel/Application/Endorsement policy by default, which requires that a transaction be validated by a majority of channel members. This policy depends on the membership of the channel, so it will be updated automatically when organizations are added or removed from a channel. One advantage of using channel policies is that they can be written to be updated automatically with channel membership.

如果你不指定背书策略，链码定义会使用默认的 Channel/Application/Endorsement策略，这个策略要求交易必须经过大多数通道成员的验证。该策略取决于通道成员，因此从通道中添加或删除组织时，它将自动更新。使用通道策略的一个优势是，可以将其编写为根据通道成员数量自动更新。

If you specify an endorsement policy using the --signature-policy flag or the SDK, you will need to update the policy when organizations join or leave the channel. A new organization added to the channel after the chaincode has been defined will be able to query a chaincode (provided the query has appropriate authorization as defined by channel policies and any application level checks enforced by the chaincode) but will not be able to execute or endorse the chaincode. Only organizations listed in the endorsement policy syntax will be able sign transactions.

如果你使用 --signature-policy 标志或者SDK指定了背书策略，你需要在组织加入或者离开通道时更新这个策略。一个新的组织在链码被定义好之后加入这个通道，这个组织可以查询这个链码（提供查询具有通道策略和链码强制执行的任何应用程序级别检查所定义的适当授权），但是不能够执行或认可链码。只有组织在认可策略语法的列表中之后，组织才能签署交易。

个人验证

chaincode如果不设置背书策略，则默认的背书策略是： /Channel/Application/Endorsement

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apple$ peer lifecycle chaincode querycommitted --channelID alljoinchannel --name secured_supply --output json
{
	"sequence": 6,
	"version": "3.0",
	"endorsement_plugin": "escc",
	"validation_plugin": "vscc",
	"validation_parameter": "EiAvQ2hhbm5lbC9BcHBsaWNhdGlvbi9FbmRvcnNlbWVudA==",
	"collections": {},
	"approvals": {
		"GylCoreOrg1MSP": true,
		"GylFOrg1MSP": true,
		"GylSOrg1MSP": true,
		"GylSOrg2MSP": true
	}
}

设置背书策略为--signature-policy "OR('GylCoreOrg1MSP.peer','GylFOrg1MSP.peer','GylSOrg1MSP.peer','GylSOrg2MSP.peer')"，再次查询链码定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apple$ peer lifecycle chaincode querycommitted --channelID alljoinchannel --name secured_supply --output json
{
	"sequence": 7,
	"version": "3.0",
	"endorsement_plugin": "escc",
	"validation_plugin": "vscc",
	"validation_parameter": "CmUSFBISCAESAggAEgIIARICCAISAggDGhQSEgoOR3lsQ29yZU9yZzFNU1AQAxoREg8KC0d5bEZPcmcxTVNQEAMaERIPCgtHeWxTT3JnMU1TUBADGhESDwoLR3lsU09yZzJNU1AQAw==",
	"collections": {},
	"approvals": {
		"GylCoreOrg1MSP": true,
		"GylFOrg1MSP": true,
		"GylSOrg1MSP": true,
		"GylSOrg2MSP": true
	}
}

解码之后：

1
2
3
4
5
e
GylCoreOrg1MSP
GylFOrg1MSP
GylSOrg1MSP
GylSOrg2MSP

Endorsement policy syntax（背书策略的语法）

As you can see above, policies are expressed in terms of principals (“principals” are identities matched to a role). Principals are described as 'MSP.ROLE', where MSP represents the required MSP ID and ROLE represents one of the four accepted roles: member, admin, client, and peer.

正如您在上面看到的那样，策略是根据主体表达的（“主体”是与角色匹配的身份）。主体被描述为'MSP.ROLE'，其中MSP代表所需的MSP ID,ROLE 代表四个公认的角色之一：member, admin, client，和 peer。

Here are a few examples of valid principals:

  • 'Org0.admin': any administrator of the Org0 MSP
  • 'Org1.member': any member of the Org1 MSP
  • 'Org1.client': any client of the Org1 MSP
  • 'Org1.peer': any peer of the Org1 MSP

The syntax of the language is:

1
EXPR(E[, E...])

Where EXPR is either AND, OR, or OutOf, and E is either a principal (with the syntax described above) or another nested call to EXPR.

EXPR 可以为AND, OR, or OutOf，E可以是一个具有上面语法的主体，也可以是对另一个EXPR的嵌套调用。

For example:

  • AND('Org1.member', 'Org2.member', 'Org3.member') requests one signature from each of the three principals.

  • OR('Org1.member', 'Org2.member') requests one signature from either one of the two principals.

  • OR('Org1.member', AND('Org2.member', 'Org3.member')) requests either one signature from a member of the Org1 MSP or one signature from a member of the Org2 MSP and one signature from a member of the Org3 MSP.

  • OutOf(1, 'Org1.member', 'Org2.member'), which resolves to the same thing as OR('Org1.member', 'Org2.member').

  • Similarly, OutOf(2, 'Org1.member', 'Org2.member') is equivalent to AND('Org1.member', 'Org2.member'), and OutOf(2, 'Org1.member', 'Org2.member', 'Org3.member') is equivalent to OR(AND('Org1.member', 'Org2.member'), AND('Org1.member', 'Org3.member'), AND('Org2.member', 'Org3.member')).

例如：

  • AND('Org1.member', 'Org2.member', 'Org3.member') 三个主体都需要进行签名。

  • OR('Org1.member', 'Org2.member') 只需要两个主体的其中一个提供签名。

  • OR('Org1.member', AND('Org2.member', 'Org3.member')) 需要Org1提供签名，或者需要Org2和Org3同时提供签名。

  • OutOf(1, 'Org1.member', 'Org2.member'), 和 OR('Org1.member', 'Org2.member')做的事情一样。

  • 相似的, OutOf(2, 'Org1.member', 'Org2.member') 与 AND('Org1.member', 'Org2.member')相同

  • OutOf(2, 'Org1.member', 'Org2.member', 'Org3.member') 与 OR(AND('Org1.member', 'Org2.member'), AND('Org1.member', 'Org3.member'), AND('Org2.member', 'Org3.member'))相同。