In Hyperledger Fabric, Chaincode, also known as smart contract (hereinafter we collectively call it chaincode), is a program written in Go,node.js or Java, mainly used to manipulate data on the ledger. The user's application interacts with the Fabric ledger data through chaincode.
Overview
A complete Fabric blockchain application consists of two parts: the user's application and the chaincode written by the user. The user's application calls the chaincode through the Peer node deployed in the blockchain network, and the user chaincode operates the ledger data through the Peer node of the blockchain network. The following figure shows the difference between the routing algorithms.
Peer nodes in Fabric provide interfaces for calling chaincode-related services. The user's application can interact with the Fabric Peer by calling relevant interfaces. The Peer node interacts with the chaincode container to complete the interaction between the application and the chaincode.
The user's application can interact with the Fabric Peer in two ways:
Use the SDK provided by Fabric to interact with Fabric Peers. For more information, see Fabric SDK.
Use the API provided by Alibaba Cloud BaaS to interact with the Fabric Peer.
RLP
After the chaincode is developed and written, it cannot be used directly. A series of operations are required before it can be applied in the Hyperledger Fabric network to process transactions submitted by clients. This series of operations is managed by the lifecycle of the chaincode.
The following commands are used to manage the lifecycle of Chaincode in Fabric 1.x:
package: the operation of packaging the specified chaincode.
The chaincode that has been written is install: installed in the network node.
Instantiate the installed chaincode instantiate:.
upgrade: upgrade existing chaincodes. Chain code can be upgraded after installation as specific requirements change.
The following commands are used to manage the generation cycle of ChainCode in Fabric 2.x:
package: the operation of packaging the specified chaincode.
approveformyorg: propose a written chaincode to the network.
The commit: formally submits the completed chaincode in the network. By default, more than half of the members pass the proposal before it takes effect.
In the Alibaba Cloud BaaS console, you can upload, install, and instantiate chaincodes without relying on the command line.
Chaincode type
In Hyperledger Fabric, chaincodes are generally divided into:
User chaincode
System chaincode
The system chaincode is responsible for the processing logic of the Fabric node itself, including system configuration, endorsement, and verification. System chaincodes only support the Go language. Registration and deployment are automatically completed when the Peer node is started. Therefore, installation, instantiation, and upgrade are not applicable to system chaincodes.
System chaincodes mainly include the following types:
Lifecycle System Chaincode (LSCC): The Lifecycle System Chaincode manages the lifecycle of user chaincodes.
Configuration System Chaincode (CSCC): The Configuration System Chaincode is responsible for the channel configuration on the peer end.
Query system chaincode (QSCC): provides a ledger query API, for Query System Chaincode, to obtain information such as blocks and transactions.
User chaincode
User chaincodes are business processing logic codes written by application developers in Golang, node.js, or Java languages based on business scenario requirements to operate the state of a blockchain distributed ledger. User chaincodes run in a chaincode container and interact with the ledger state through interfaces provided by Fabric.
User chaincode is a very critical link in blockchain applications, which directly accepts calls from user business logic and operates on blockchain distributed ledger data.
The endorsement policy.
Each smart contract has an endorsement strategy associated with it. This endorsement strategy determines which organizations must approve a transaction generated by a smart contract before it can be recognized as a valid transaction. When you upload a chaincode and instantiate a chaincode, you must specify an endorsement policy for the chaincode.
Examples of endorsement policies:
OR ('Org1MSP.peer','Org2MSP.peer')indicates that either of the two organizations in this channel can endorse it;AND ('Org1MSP.peer','Org2MSP.peer')is required to endorse two organizations in this channel.
For more information, see Fabric design> Endorsement policies.
Transaction Execution Process
In Hyperledger Fabric, the execution of a transaction requires the participation of the peer node, orderer node, CA node, and client.
Peer node: This node is the subject of the transaction, can be said to represent each member involved in the chain, it is responsible for storing the complete ledger data, that is, blockchain data, responsible for the implementation of smart contracts in the consensus link, verify blocks and transactions and submit legitimate transactions (commit) to the ledger.
Orderer node: This node accepts transaction requests containing endorsement signatures for sorting and packaging to produce new blocks, and the main function is to sort transactions to ensure data consistency on each Peer node.
CA node: This node is responsible for authorizing and authenticating all nodes in the join chain, including the upper-layer client end. Each node has a certificate issued by it for identification in the transaction process.
Client: Fabric provides SDK for the client side so that developers can more easily connect to the transaction link in the block chain. The transaction is initiated through SDK.
The transaction execution process consists of the following four main steps.
The transaction execution flow chart is from the Fabric community's open source technical documentation, licensed under the Creative Commons Attribution 4.0 International License Agreement.
A transaction request is initiated by the client. The client determines which endorsement peer nodes to send the transaction to according to the endorsement policy of the chaincode. The peer nodes vote, and the client summarizes the results of each endorsement node. The endorsement policy in the preceding figure requires Peer1, Peer2, and Peer3 to participate in the transaction. Therefore, the client sends requests to Pee1, Peer2, and Peer3, respectively.
After receiving the transaction request, the three peer nodes execute the corresponding chaincode, sign the result, and then return the output result to the client.
The client packages and sends all the execution results, together with the endorsements of each peer (including their voting results and endorsement signatures), to the orderer node.
Orderer sorts the received transactions in the transaction pool and combines them to generate a new block, and sends the new block to all Peer nodes. After receiving the new block, each Peer node verifies whether the signature of each transaction result conforms to the endorsement policy, and compares whether the read-write set is the same as the local version. If all conditions are met, the new block is written to the local ledger to complete the transaction.
For more information, see Fabric design > Transaction process.
Usage notes
Inter-chain calls across channels
If the called chaincode is in a different channel than the calling chaincode, only read queries are allowed. In other words, the called chaincode on the other channel is just a query, and it does not participate in the status verification check in the subsequent commit phase.
Inter-chaincode calls under the same channel
If the called chaincode and the calling chaincode are located in the same channel, the read and write set generated by the called chaincode is added to the transaction corresponding to the calling chaincode, that is, the same transaction is shared without generating different transactions.
chaincode shim package dependency
The chaincode needs to rely on the shim package (ChainCodeStub) to communicate with the peer node. Some language shim packages also provide extended interfaces (for example, to process the caller identity). By default, when you instantiate and compile a chaincode, the peer node provides a shim package of the same version as the node. If your chaincode depends on the shim package of another compatible version (v1.4.x), package it in a chaincode file.
The version of nodes created before April 29, 2020 is v1.4.2, and the version of nodes created later is v1.4.5.
Golang dependencies:
Old version: github.com/hyperledger/fabric/core/chaincode/shim, github.com/hyperledger/fabric/protos/peer
New version: github.com/hyperledger/fabric-chaincode-go/shim, github.com/hyperledger/fabric-protos-go/peer
Java dependencies: fabric-chaincode-shim-1.4.x.jar and fabric-chaincode-protos-1.4.x.jar