fabric-基于状态的背书(sbe)

fabric-基于状态的背书(sbe)

1.背书

“背书”这个词源来自银行票据业务，传统意义上的背书是指请具有一定公信力的人在票据背面签字以表达对信用的加强和支持，就是让别人提供信誉以及影响力进行支持，让被背书（endorsed）人或者事物提升可信度，更加具有公信力。

在区块链中背书可以理解为承担背书任务的节点为区块链交易进行交易信息验证，对验证通过的交易声明此交易合法的过程和机制。

2.背书节点（endorsement、endorsor）

在区块链中承担背书任务的节点即是背书节点。背书节点必须通过有效证书的预期信息的有效签名来证明其合法性。

3.背书策略（endorsement policy）

可以理解为是对交易进行背书必须满足的条件，即要得到背书成功的结论，必须满足背书策略中给出的条件。

区块链节点有预先指定的背书策略集，这些背书的条件判断在链码（chaincode）中实现，所有的交易都必须依据背书策略进行交易，因为只有经过背书处理的交易才是合法、被认可的交易。因此背书策略也可以说就是用来指导被选中的节点（背书节点）如何决策交易是否正确的条件。

4.背书验证过程

Fabric交易需要首先通过节点的背书，然后再进行交易排序，最后才利用有序交易进行账本的更新。

下面是Fabric背书策略验证过程：

1. 发起交易的时候，发起端应用一般调用SDK指定交易提议发给一个或多个背书节点进行背书验证，接收提议的背书节点在SDK的交易提议请求中指定，如果未指定，则会将交易提议请求发送给加入该通道的所有节点，发送后客户端应用等待背书节点的返回
2. 背书节点收到提议后，首先进行一些检查和签名的验证，包括用客户端（SDK）的公钥验证它的签名、核实客户端是否可以在该channel进行操作、交易是否已被提交、交易提议组织是否正确。验证通过后模拟执行chaincode（不会将结果写入到账本里），生成一个提议结果，并对结果进行背书，即在结果中添加数字签名并利用私钥对结果进行签名
3. 客户端（SDK）收到足够多（背书策略要求）的背书节点的结果后，表示这个交易已经正确背书，然后将交易提议、模拟结果和背书信息打包发给orderer排序节点；如果客户端没有收集到足够多的背书节点反馈的背书信息，这个交易就会被舍弃
4. orderer节点对来自客户端（SDK）的信息进行排序，并创建区块，然后在通道channel上进行广播；
5. channel上的peer节点接收到交易区块后，验证背书策略是否满足，然后更新账本，至此，背书策略的验证过程完成。

5.基于状态的背书(SBE)

基于状态的背书 (SBE) 资产转移示例演示了如何使用关键级别的背书策略来确保资产仅由资产所有者背书。

将使用智能合约完成以下转账场景：

（1）将 SBE 智能合约部署到使用 Fabric 测试网络创建的通道。该频道将有两个成员 Org1 和 Org2，他们将参与资产转移。每个组织都运行一个加入通道的对等点。

• 将SBE部署到Fabric测试网络

# 部署java链码要提前编译一下
# 编译的步骤只需要执行一次，在将网络down之后，不需要重复执行
cd /home/fabric-samples/asset-transfer-sbe/chaincode-java
./gradlew installDist

cd /home/fabric-samples/test-network
./network.sh up createChannel

# 部署java版本的链码
./network.sh deployCC -ccn sbe -ccp ../asset-transfer-sbe/chaincode-java/ -ccl java

• 创建两个成员Org1和Org2的两个对等点

• 使用链码背书策略创建资产。

链码级背书策略要求通道上的大多数组织对交易进行背书。这意味着创建资产的交易需要得到属于 Org1 和 Org2 的对等方的背书。创建资产时，智能合约会创建一个基于状态的背书策略，指定只有拥有该资产的组织才能背书更新交易。

由org1创建资产，创建资产的时候需要org1和org2两个组织的背书，创建完成后因为org1是资产所有者，之后就只需要得到org1这个组织的背书就可以。

未来对资产的任何更新，都需要得到 Org1 对等方的背书。

• 可以通过这个命令查询资产：

peer chaincode query -C mychannel -n sbe -c '{"Args":["ReadAsset","asset1"]}'

查询结果如下所示：显示资产1的拥有者是org1,价值是100

（2）仅通过 Org1 背书来更新资产，这将使用链码创建资产时应用于资产的基于状态的背书策略。

通过组织org1进行资产的更新。

查询资产状态，结果如下所示：显示资产1的拥有者是org1,价值是200

而当org2这个组织希望更新资产时，下面有两种情况进行对比：

1. 同时向两个组织发起请求提交，不指定背书组织，即没有setEndorsingOrganizations 这行代码，如下所示：

这项由org2发起的更新请求，它能够获得来自org1的背书，所以更新请求顺利完成。

2. 只向org2这个组织发起更新请求,含有**setEndorsingOrganizations(org2)**这条代码。

运行结果如下所示：（实际情况下一般默认第二种，所以由org2发起的对资产的更新请求会失败）

（3）交替验证，将资产转移到 Org2。在转移交易执行期间，链码将创建一个新的基于状态的背书策略，以反映资产的新资产所有者。

源代码如下，首先由org1这个组织发起转移资产的请求，然后获得org1的背书，实现将资产转移到org2的请求。

命令行指令如下：

peer chaincode invoke -o localhost:7050 --waitForEvent --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n sbe --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt -c '{"function":"TransferAsset","Args":["asset1","Org2User1","Org2MSP"]}'

查询资产状态：可以看见资产的拥有者现在变为org2。

（4）再次更新资产，这次以 Org2 作为所有者。因为基于状态的背书策略已经更新，所以这个交易只需要Org2背书即可。

结果如下所示：可以看见资产被成功更新。

而当指定背书组织是org1时，就会报错：

结果如下所示：

总结

基于状态的背书(sbe）可以认为任何对资产的操作，只有资产的所有者的背书才能被执行。资产的所有者发生改变时，需要请求获得背书的对象也发生改变。