Super Ledger Discovery Tour (iii): Deep analysis The first Blockchain application __ Blockchain

In the previous article, we queried the fabric network by executing node query.js, and returned 10 vehicles of information:

#node Query.js

The output from the command line is as follows:

This is 10 cars. The black Tesla model owned by Adriana, the red Ford Mustang owned by Brad, was owned by the man named Pari violet Fiat Punto and so on. The ledger is based on key/value, and in this implementation, the key values are from CAR0 to CAR9. This will become particularly important.

Query the implementation of the ledger

Now let's take a look at the underlying implementation. Use the editor (such as Atom or Visual Studio) and open the Query.js program.

The initial part of the application defines certain variables, such as the chain code, the channel name, and the network endpoint:

The following code constructs a query for the car, note the previous comment, which indicates that if you call Querycar, the parameter args will be passed to the key of the car, that is, CAR0, and so on; In this example, the queryallcars is used to return all car objects

In the Request object above, specify the Chaincode to be called by Chaincodeid, as shown above, Chaincode is Fabcar.

So what does this chaincode, named Fabcar, look like? Take a look at the code. First of all, this chaincode is placed under this directory:

Open this chaincode source file, is written in the go language, the top defines the smartcontract and car two classes, wherein car is the main model object, there are several properties Make,model.

The following two methods are related to the fabric network, mainly through the shim object interaction.

The first method is init, in which the Init method is executed when Chaincode is instantiated. Note also mentions a best practice, which is to suggest not to store any business logic, but rather to place business logic such as initialization data in a separate method called, here is the Initledger method.

The second method is invoke, which is the application's access to the Blockchain network, which is accessed using Invoke. Inside the method, the function methods and parameters to be called are first obtained through the Getfunctionandparameters method. As can be seen here, the go language and JavaScript language, variables can not be defined directly, the go language compiler will infer the type of variables according to the context, but also can return multiple variables.

The 1th thing to note in this is that for those of you who do not know the go language, the part (S *smartcontract) in front of the function name Init is difficult to understand, and you can actually think of this as the class method of the go language, remembering the first smartcontract. In the preceding Smartcontract code block, Smartcontract is empty:

Define the SMART contract structure

Type smartcontract struct {

}

This is actually one of the features of the go language, the dynamic addition of the class method; Here you add init and invoke two methods to Smartcontract, and when the Invoke method is called, it is based on the parameters passed in. There are ways to execute Querycar and Queryallcars.

The following business methods are Initledger,querycar,queryallcars,createcar and Changecarowner. Let's take a closer look at the Queryallcars function and see how it interacts with the fabric.

The function uses the Shim interface function Getstatebyrange to return the ledger data between Startkey and EndKey args. These keys are defined as CAR0 and CAR999, respectively. Therefore, we can theoretically create 1,000 cars (assuming the keys are correctly labeled), and a queryallcars will show each one. The lower half of this method is converted back into JSON format.

Here is a schematic diagram of the application calling different Chaincode methods and blockchain networks for trading:

Before we saw the invocation example of the Queryallcars method, let's try the other methods below.

find a specific vehicle

Return to the Query.js program and edit the constructor request to query for a specific car. We will change the function from Queryallcars to Querycar and the specific "Key" to the args parameter. We use the CAR4 here. So the Query.js program we're editing should now contain the following:

Then perform the following:

#node Query.js

The results are as follows:

You can see the bottom-most output:

So we query all cars to only one, Adriana's black Tesla Model S. Using the Querycar function, we can query any keyword (e.g. CAR0) and get any code, model, color, and owner corresponding to that car.

You should now be comfortable with the basic query functionality in the chain code and a few parameters in the query program. It's time to update the ledger ...

Update Ledger

Now that we have completed several ledger queries and added some code, we are ready to update the ledger. Let's start a new car for the novice.

The work of the ledger update begins with the application generating a trading proposal (transaction proposal). Just like a query, a request object needs to be constructed to determine the channel ID, the method, and a specific only contract to specify a transaction (transaction). This application will next call

Channel. Sendtransactionproposal

This API is to send the transaction proposal to the peer node to perform an endorsement (endorsement).

A blockchain network (such as an endorsement node, endorsing peer) returns a proposal response (proposal response) that the application uses to build and sign a transaction request (transaction request).  This transaction request is sent to the ordering service node by invoking the Channel.sendtransction API. The ordering service packs the transaction into a chunk and sends the chunk to all nodes in the channel to perform the validation (in this case there is only one endorsement node).

Finally, the app invokes the EH.SETPEERADDR API to connect to the peer node's event listener port and then registers the event associated with the specific transaction ID by calling Eh.registertxevent. This API allows the app to know the final state of a particular transaction (such as a successful commit or failure). Imagining this process as a notification mechanism would be more conducive to understanding.

There is no intention to explain the life cycle of the transaction more, and more will be introduced later.

In this initial invoke call, we are simply creating a new asset: the car. In the Fabcar directory, there is a separate JavaScript file--invoke.js We will use this file to perform the transaction.

Open a text editor and see the following code:

You will see that we can call one of two functions-createcar or Changecarowner. Let's create a red Chevrolet Volt and give it to a landlord named Nick. We use CAR9 on the ledger, so we will use CAR10 as the identification key. The updated code block should resemble the following:

Save and execute the code:

#node Invoke.js

The result will be a lot of output:

We then focus on this line:

The Peer node sends an event notification, and our app receives a notification via the Eh.registertxevent API.

Now, we return to query.js and change the code to query the car information for key ' CAR11 ':

And then execute

#node Query.js

Looking at the results, we found that our Mercedes-Benz C200 has been shown:

Vehicle Transfer

There is also a Changecarowner smart contract is not used, now, you can implement this feature yourself.