背书策略主要是针对定义交易是否合法的判断条件。
一般的策略以主体形式进行呈现。在hyperledger fabric中共有四种合法角色：member, admin, client, peer
一般使用的背书策略语法：Expression(E[, E...])
基于键值的背书策略
shim包提供了一些函数可以设置背书策略，其具体如下所示。
SetStateValidationParameter(key string, ep []byte) error
GetStateValidationParameter(key string)([]byte, error)
以上是针对函数键值的背书策略（什么是函数设置或者恢复键对应的背书策略？）
同时还有设置交易中私有信息里面的键级别的背书策略。
SetPrivateDataValidationParameter(collection, key string, ep []byte) error
GetPrivateDataValidationParameter(collection, key string) ([]byte, error)
举个例子:
首先使用query函数查询a账户的余额
函数命令：peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
假设此时查询到的结果是0
接着调用修改函数向a账户转入10元
函数命令 peer chaincode invoke -o orderer.example.com:7050 -C mychannel -n mycc --peerAddresses peer0.org1.example.com:7051 --peerAddresses peer1.org2.example.com:7051 -c '{"Args":["revise","a","10"]}'
注：此处使用了--peerAdrresses参数指定背书方。如果没有输入则会通过默认策略进行背书提交。
如果尝试只使用org1的peer0进行背书，那么就会导致失败。
接着修改策略，将策略修改为只需要org1进行背书
函数命令 peer chaincode invoke -o orderer.example.com:7050 -C mychannel -n mycc --peerAddresses peer0.org1.example.com:7051 --peerAddresses peer0.org2.example.com:7051 -c '{"Args":["endorsement","a","Org1MSP"]}'
那么上述失败的命令便可以执行。
demo
使用下述命令查询时，会发生报错。
chaincode_invoke 3 0 "3%0" ${CHANNEL_ID_ARR[0]} "trade_chaincode" '{"Args":["invoke","cross_set","sum","'${CHANNEL_ID_ARR[1]}'","train_chaincode"]}'
注：在测试过程中，记得使用sleep进行停顿，不然容易出现如下报错：
stateBasedValidator.Validate failed, err validation parameters for key [sum] in namespace [trade_chaincode:] have been changed in transaction 1 of block 9
这个意思是在区块交易中的某个键的确认参数发生了变动，猜测是因为当前修改交易并未完全置入导致。
而如果在修改了背书策略之后，获取了错误的背书签名，那么背书就会不通过，会出现如下报错：
2024-03-02 07:01:05.901 UTC 00fb ERRO [committer.txvalidator] validateTx -> Dispatch for transaction txId = ba12027658e97050ab53e9296152e310dc2590a0427150e537506c8e82affe53 returned error: validation of key sum (coll'':ns'trade_chaincode') in tx 10:0 failed: signature set did not satisfy policy