Chaincode is also called smart contract, which is the service logic of interaction between parties in a blockchain network. A chaincode encapsulates service transaction data into code, which runs in a Docker container. Currently, HUAWEI CLOUD BCS supports only Golang for programming.
Each chaincode is a Golang file. After creating such a file, you can perform operations such as function development. For more information about chaincode development, see Chaincode Tutorials of Hyperledger Fabric.
- Import package shim into your chaincode.
Package shim provides APIs to enable your chaincode to interact with the underlying blockchain network to access status variables, transaction contexts, invoker certificates and attributes, and perform other operations such as invoking other chaincodes.
The following figure shows an example of package shim.
- Compile the main function.
All Golang programs start with the main function, which is used to start a chaincode. When a chaincode instance is deployed on a peer, the main function is executed.
The following figure shows an example of the main function.
- Implement the init method.
The init method is called when a chaincode is deployed on a blockchain network for the first time and is executed by each peer where instances of this chaincode are deployed. This method can be used for all initialization, boot, or configuration tasks.
The following figure shows an example of the init method.
- Implement the invoke method.
The invoke method is invoked if the status of a blockchain is to be changed. All creation, update, and deletion operations must be encapsulated in the invoke method. This method changes the blockchain status. Therefore, the Fabric code of a blockchain automatically creates a transaction context for this method to be executed. Each invocation of this method is recorded as a transaction in a block.
The following figure shows an example of the invoke method.
The following chaincode is taken as an example, which is used to open an interbank category II account supported by blockchain-based identity sharing.
A customer has submitted identity information (the name, ID card number, bank account name, and mobile number) to open a category I account of bank A. Bank A stores the information in a blockchain. Then, the customer applies for a category II account of bank B. Since the two banks reside in the same blockchain network, bank B only needs to query the identity chain to open the account, and the customer does not need to provide the identity information again.
The procedure for invoking the application and chaincode is as follows:
Bank B uses the bank login mode to log in to the blockchain system (for interbank account opening) and import all the customer data of bank A (identity information of the category I account, that is, the name, ID card number, bank account name, and mobile number) on the frontend console. The backend interface FeedAccountInfo is invoked. After parameters pass verification, the Fabric SDK is used to call the chaincode API invoke and obtain the function name creditAccountInfo and customer parameters. The chaincode function creditAccountInfo is then executed, and the hash algorithm is used to encrypt non-sharing information. After that, the customer data is stored in a block.
The customer uses the customer login mode to log in to the blockchain system and enters parameter values on the frontend console to apply for a category II account of bank B. The backend API CreateType2Account is invoked. After parameters pass verification, the Fabric SDK is used to call the chaincode API invoke, obtain the function name authAccount and account parameters, execute the chaincode function authAccount, generate a hash based on the identity information, query the identity chain, and send an SMS confirmation code (this step is skipped in the example) to open the account.
- Scenario Analysis
This scenario involves the following tasks:
(1) Customer information verification: The initial verification of the bank is completed off the chain by a banking app.
(2) Creation of a category I account: The customer information is stored in the blockchain.
(3) Checking whether the customer already has a category I account of another bank based on the customer information
(4) Creation of a category II account based on the verification result
Whether the category II account needs to be stored in the chaincode mainly depends on the necessity of consensus on the account data among multiple parties. In this example, the category II account exists only in bank B and is not stored in the blockchain. Therefore, tasks (2) and (3) can be performed by the chaincode, and the other tasks are implemented by an app.