Shulou(Shulou.com)06/03 Report--

HyperLeger Fabric development (6)-- HyperLeger Fabric intelligent contract (ChainCode) 1. Chain code (Chaincode) introduction 1. Chain code introduction

In Fabric, intelligent contract is also called chain code (chaincode), which is divided into user chain code and system chain code. The system chain code is used to realize the functions at the system level, including the configuration of the system, the deployment and upgrade of the user chain code, the signature and verification strategy of the user transaction, etc.; the user chain code is used to realize the application function of the user. The developer writes the chain code application program and deploys it to the block chain network, and the end user invokes the chain code through the client application program that interacts with the network node.

The chain code is compiled into a separate application that runs in an isolated Docker container and automatically generates a Docker image of the chain code when the chain code is deployed.

Chain code is the basic method to access the account book, which is generally written in Go and other high-level languages to implement the specified interface. The upper application can initialize and manage the state of the account book by calling the chain code. Chain codes can also call each other as long as they have appropriate permissions.

Chain code (Chaincode) is a program written in Go (supports other programming languages, such as Java,NodeJS) and can implement predefined interfaces. The chain code runs in a protected Docker container, isolated from the operation of the endorsement node. The chain code can initialize and manage the account state through the transaction submitted by the client.

Chain codes usually deal with business logic agreed upon by members of the network. The status created by chain codes is isolated from other chain codes and cannot be accessed directly by other chain codes. If you are in the same Fabric network, the chain code can call other chain codes to access its account book after obtaining the appropriate permission.

The chain code is deployed on the Fabric network node, runs in the Docker container, and interacts with the corresponding Peer node through the gRPC protocol to manipulate the data in the distributed ledger.

2. The endorsement strategy of chain code

Endorsement strategy is a condition for endorsement nodes to decide whether the transaction is legal or not. The endorsement strategy can be specified when the chain code is instantiated, and when the accounting node receives the transaction, it will know the relevant chain code information, and then check the endorsement strategy of the chain code to determine whether the transaction meets the endorsement strategy, and if so, mark the transaction as legal.

Endorsement policy can be divided into two parts: subject Principal (P) and threshold Threshold (T), as follows:

An and Principal specify which members will endorse them.

B and Threshold accept two inputs, which are the threshold T and the set n of several P. as long as the transaction contains the endorsement of t members in n, the transaction is considered legal.

Endorsement policies can specify any membership in several organizations to endorse, or require at least one administrator to endorse, and so on.

T (1,'A','B') needs to be endorsed by any member of A & B.

T (1,'A', T (2,'B','C') requires member A to endorse or member B to endorse it at the same time.

At present, the client has implemented the support for endorsement policy. You can specify the endorsement policy through-P, combine members with AND and OR, and complete the collection of membership (admin, member).

-P OR ('Org1.admin', AND (' Org2.member', 'Org3.member'))

The above endorsement strategy specifies that either the admin of Org1 or the members of Org2 and Org3 endorse at the same time to satisfy the endorsement strategy.

3. System chain code

The system chain code and the user chain code have the same programming model, but the system chain code runs in the Peer node, and the user chain code runs in an isolated container. Therefore, the system chain code built into the executable file of the Peer node does not follow the life cycle of the user chain code, and installation, instantiation and upgrade are not suitable for the system chain code.

The system chain code is used to reduce the cost of gRPC communication between the Peer node and the user chain code, while weighing the flexibility of management. The system chain code can only be upgraded through the binaries of the Peer node and must be registered with a fixed set of parameters, but does not have an endorsement policy.

The chain code of Hyperledger Fabric system implements a series of system functions so that system integrators can modify and replace them according to their needs.

Common system chain codes are as follows:

Lifecycle system chain Code (LSCC): handles lifecycle management.

Configure system chain code (CSCC): handles the channel configuration on the Peer node.

Query system chain code (QSCC): provides a query API for account books, such as obtaining blocks and transactions.

Endorsement system chain code (ESCC): handles the endorsement process by signing the transaction proposal response.

Verification system chain code (VSCC): handles transaction verification, including checking endorsement policies and multi-process concurrency control.

Care must be taken when modifying or replacing system chain codes (LSCC, ESCC, VSCC) because the system chain codes are in the path where the main transaction is executed. Before VSCC submits the block to the account, all Peer nodes in the channel will calculate the same verification to avoid account divergence (uncertainty). You need to be very careful if the VSCC is changed or replaced.

Second, chain code function

The main function of the Peer node is to call the chain code to execute the transaction and accounting, in which the chain code of the endorsement node is responsible for the transaction execution and the accounting node is responsible for the accounting function.

The interaction between the chain code and the Peer node is as follows:

A, the chain code interacts with the Peer node through gRPC. When the Peer node receives the transaction proposal request from the client, it will send a chain code message object (including transaction proposal information, caller information) to the corresponding chain code.

B, the chain code calls the Invoke method to obtain the account status information and send the pre-submission status from the Peer node by sending the get data (GetState) and write data (PutState) messages.

C, the chain code sends the simulation execution result to the Peer node, and the Peer node endorses the transaction proposal and the simulation execution result.

Chain code management 1. Chain code life cycle

Fabric provides four commands, package,install,instantiate and upgrade, to manage the chain code life cycle.

Install the chain code through install, instantiate the chain code through instantiate, and then call and query the chain code through invoke and query.

If you need to upgrade the chain code, you need to install a new version of the chain code on install first and upgrade the chain code through upgrade.

Before install installs the chain code, it can be packaged and signed through package to generate a package file, and then installed through install.

Chain code in the successful install and instantiate, the chain code in the running state, through the Invoke method to deal with the transaction, followed by the chain code can be upgraded.

Hyperledger Fabric API allows interaction with individual nodes (Peer,Order,MSP) in the blockchain network, as well as package, install, instantiate, and upgrade chain codes on endorsement nodes. CLI can access Hyperledger Fabric API directly.

Hyperledger Fabric SDK abstracts the details of Hyperledger Fabric API to assist application development and, of course, can also be used to manage the chain code life cycle.

2. Packing chain code

The chain code package consists of three parts:

A, chain code defined by ChaincodeDeploymentSpec (CDS) format. CDS defines chain code packages based on code and other attributes such as name and version

B. an optional instantiation policy that can be described as an endorsement policy

C. A set of signatures of entities that have chain codes.

Among them, the main purpose of the chain code signature is as follows:

A. establish the ownership of the chain code

B. allow verification of the contents of the chain code package

C. allow detection of whether the chain code package has been tampered with.

The creator of the instantiation transaction of the chain code on the channel can be verified by the instantiation strategy of the chain code.

There are two ways to package chain codes: one is to package chain codes owned by multiple owners, which requires initialization to create a signed chain code package (SignedCDS), and then passes it sequentially to other owners for signature; the other is to package chain codes held by a single owner.

The command to create a signed chain code package is as follows:

Peer chaincode package-n sacc-p chaincodedev/chaincode/sacc-v 0-s-S-I "AND ('OrgA.admin')" ccpack.out

The-s option creates a chain code package that can be signed by multiple owners, rather than simply creating a raw CDS. Once-s is specified, the-S option must be specified if other owners want to sign the CDS. Otherwise, a SignedCDS will be created that includes only the instantiation policy except CDS.

The-S option signs the chain code package with the MSP identified by the value of the localMspid attribute defined in the core.yaml file.

The-S option is optional. If an unsigned chain code package is created, it cannot be signed by other owners using the signpackage command.

The-I option is optional and allows you to specify an instantiation policy for the chain code. The instantiation policy has the same format as the endorsement policy, specifying which identities can instantiate the chain code. In this example, only the admin of OrgA can instantiate the chain code. If no instantiation policy is specified, the default policy will be used and only the chain code can be instantiated as an administrator of the MSP with Peer.

3. Signature chain code

The chain code package that is signed in the creation phase can be checked and signed by other owners, and the chain code can be signed out of band.

ChaincodeDeploymentSpec can optionally be signed by the owner collection to create a SignedChaincodeDeploymentSpec (SignedCDS). SignedCDS consists of three parts:

An and CDS include source code, chain code name and version number

B. the instantiation strategy of chain code, which is expressed as endorsement strategy

C. the list of chain code owners, defined by the endorsement policy.

When chain codes are instantiated on some channels, the endorsement strategy is determined out of band to provide the appropriate MSP body. If no instantiation policy is specified, the default policy is any MSP administrator of the channel.

The owner of each chain code endorses the ChaincodeDeploymentSpec by combining the SignedCDS with the identity of the chain code owner (such as a certificate) and signing the combination result.

The owner of a chain code can sign the signed chain code package he has created, you need to use the following command:

Peer chaincode signpackage ccpack.out signedccpack.out

Ccpack.out and signedccpack.out are input and output packets, respectively. Signedccpack.out includes a signature attached to the chain code package (signed through local msp).

4. Install chain code

The installation transaction packages the source code of the chain code into the format specified by ChaincodeDeploymentSpec (CDS) and then installs it on the endorsement node in the channel.

When the installed chain code package contains only one ChaincodeDeploymentSpec, the default initialization policy is used and an empty list of owners is included.

The chain code should only be installed on the endorsement node of the chain code owner member, which is used to realize that the chain code is logically isolated from other members of the network. The Peer node without the chain code cannot be the endorser of the chain code transaction and cannot execute the chain code, but as an accounting node, it can still verify and submit the transaction to the ledger.

The installation chain code sends a SignedProposal to the lifecycle system chain code (LSCC).

The command to install the sacc chain code using CLI is as follows:

Peer chaincode install-n sacc-v 1.0-p sacc

The-n option specifies the chain code instance name

The-v option specifies the version of the chain code

The-p option specifies the path where the chain code is located, which must be under the GOPATH path

The SignedChaincodeDeploymentSpec of the sacc is created inside CLI and then sent to the local Peer node, which invokes the installation method on the LSCC. In order to install the chain code on the Peer node, the SignedProposal signature must come from one of the local MSP administrators of the Peer node.

5. Instantiate chain code

The instantiated call life cycle system chain code (LSCC) is used to create and initialize the chain code on the channel. Chain codes can be bound to any number of channels, as well as individual operations on each channel. No matter how many channels the chain code is installed and instantiated to, the state of each channel is isolated.

The creator of the instantiation must meet the instantiation policy contained in the chain code within the SignedCDS and must also be a writer of the channel (configured as part of the channel creation). It can prevent rogue entities or fraudsters who deploy chain codes from executing chain codes on unbound channels.

The default instantiation policy is the administrator of any channel MSP, so the creator of the chain code instantiation transaction must be one of the channel administrators. When the transaction proposal reaches the endorsement node, the endorsement node verifies the creator's signature according to the instantiation policy. The operation is completed again during transaction verification before submitting the instantiated transaction to the ledger.

The instantiated transaction also sets the endorsement strategy for the chain code on the channel. The endorsement strategy describes the authentication requirements that the transaction is accepted by the members on the channel.

Use CLI to de-instantiate the chain code of sacc and initialize the state to user1 and 0. The command is as follows:

Peer chaincode instantiate-n sacc-v 1.0-c'{"Args": ["user1", "0"]}'- P "OR ('Org1.member','Org2.member')"

The-n option specifies the chain code instance name

The-v option specifies the version of the chain code

The-c option specifies the calling parameters of the chain code

The-P option specifies the endorsement strategy for the chain code

The endorsement policy indicates that org1.member or org2.member must sign the transaction that invokes using sacc to ensure that the transaction is valid. After successful instantiation, the chain code of the channel is activated and any transaction proposal can be processed. When the transaction reaches the endorsement node, it is processed at the same time.

6. Call chain code

Call chain code:

Peer chaincode invoke-o orderer.example.com:7050-- tls $CORE_PEER_TLS_ENABLED-- cafile $ORDERER_CA-C mychannel-n sacc-c'{"Args": ["invoke", "user1", "user2", "10"]}'

Query chain code

Peer chaincode query-C mychannel-n sacc-c'{"Args": ["query", "user1"]}'

7. Upgrade chain code

The chain code is upgraded by changing its version number (as part of SignedCDS). Other parts of the SignedCDS, such as owner and instantiation policy, are optional. However, the name of the chain code must be consistent, otherwise it will be treated as another new chain code.

Before upgrading, the new version of the chain code must be installed on the required endorsement node. The upgrade is also a transaction that binds the new version of the chain code to the channel. The upgrade can only affect one channel at one point in time, and the other channels are still running the old version of the chain code.

As there may be multiple versions of the chain code at the same time, the upgrade process will not automatically delete the old version of the two horses, the user must manually operate the deletion process.

Upgrading is a little different from instantiating transaction: upgrading transaction through an existing chaincode instantiation policy check rather than a new policy check. This is to ensure that only the members specified in the current instantiation policy can upgrade chaincode.

During the upgrade, the Init function of the chain code is also called to perform data about the upgrade or reinitialize with the data to avoid resetting the state during the chain code upgrade.

Install the new version of the chain code

Peer chaincode install-n sacc-v1-p path/to/my/chaincode/v1

Upgrade upgrade chain code

Peer chaincode upgrade-n sacc-v 1-c'{"Args": ["d", "e", "f"]}'- C mychannel

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.