HyperLedger Fabric 1.4的SDK侧交易签名源
hyperledger fabric 1.4中所涉及到的实体包括如下：
fabric-ca：主要负责对网络中实体的证书进行维护；
peer：主要负责智能合约的执行、记录账簿；
Order：主要负责对记账内容进行共识。
1.4架构可以根据实际需求通过证书对网络进行安全域划分管理，即通过证书形成一个个独立的channel，对智能合约以及账簿进行分割管理，继而实现多链结构（每一个channel维护一条私有/联盟链）。
1.4中的一条交易流程如下所示
①由客户端发起交易请求；
②网络中的peer节点选择提交节点SP（可以固定、轮询或者随机），SP将相应的交易请求发送给各个智能合约确认节点EP；
签名重点来了，这里查询调用流程
evaluateTransaction(ContractImpl.java)->evaluate(TransactionImpl.java)->evaluate(SingleQueryHandler.java);->evaluate(QueryImpl.java)->queryByChaincode(Channel.java)->sendProposal()(Channel.java)->getSignedProposal(Channel.java)->signByteString(TransactionContext.java)->sign(TransactionContext.java)
public byte[] sign(byte[] b) throws CryptoException, InvalidArgumentException {
return signingIdentity.sign(b);
}
签名重点来了，这里交易调用流程
submitTransaction(ContractImpl.java)->submit(TransactionImpl.java)->sendTransactionProposal(TransactionImpl.java);->sendTransactionProposalToEndorsers(Channel.java)->getSignedProposal(Channel.java)->signByteString(TransactionContext.java)->sign(TransactionContext.java)
@Override
public byte[] sign(byte[] msg) throws CryptoException {
return cryptoSuite.sign(super.user.getEnrollment().getKey(), msg); //私钥和签名内容
}
③各个智能合约确认节点EP将相应的执行结果签名并返回给提交节点SP，SP收集确认结果；
④提交节点SP将收集到的结果发送给共识服务机构（由Order节点组成的，执行共识算法，确认是否记链）；
⑤共识服务机构对结果进行确认，并将相应的结果返回给peer节点，由peer节点根据返回结果决定是否记链。
