Читать книгу The New Advanced Society - Группа авторов - Страница 47

It can be seen from Figure 2.12 that the proposed solution model involves a multi-step process. Hence, for the sake of simplicity and understanding of the working, we will be demonstrating the first step which involves the creation of a task by the main contractor. The execution of this step involves creating four files:

 TaskState.java—the file containing the code with the specifics of the state; the initialization of the parameters

 CATContract.java—the file containing the code with the rules for the inputs and outputs, required conditions, and checking for the signatures of the required signers.

 CATInitiatorFlow.java—the file containing the code that starts the flow, makes sure that only the main contractor can initiate the transaction, gathers the required signatures, and gets the notary node to verify the provided signatures to approve or disapprove the transaction.

 CATResponderFlow.java—the file containing the code that takes care of the flow session from the counterparties i.e., the client and the subcontractor.

After finishing the code in the respective files, the next step is to deploy the four nodes for the client, the main contractor, the subcontractor, and the notary.

The following command is to be typed in the terminal for deploying these nodes, as in Figure 2.13: gradlew.bat deployNodes.

Figure 2.13 Upon executing gradlew.bat deployNodes.

The next step is to run the nodes, which can be achieved by the following command as in Figure 2.14: build\nodes\runnodes.bat.

Figure 2.14 Upon executing build\nodes\runnodes.bat.

Upon successfully executing the previous commands, four new terminals will appear on the screen, as displayed in Figures 2.15, 2.16, 2.17 and 2.18:

Figure 2.15 The ‘Client’ node.

Figure 2.16 The ‘MainContractor’ node.

Figure 2.17 The ‘SubContractor’ node.

Figure 2.18 The ‘Notary’ node.

As the nodes have been deployed and are running successfully, we can now check to see that the client, the main contractor and the subcontractor nodes are having an empty vault. We can check this by executing run vaultQuery contractStateType: com.Task.states. TaskState in every node. Figures 2.19, 2.20 and 2.21 depict the result of the above command

Figure 2.19 The ‘Client’ node.

Figure 2.20 The ‘MainContractor’ node.

Figure 2.21 The ‘SubContractor’ node.

Now, the node of the main contractor will execute the following command to initiate the flow in which a task is created and assigned, as in Figure 2.22: flow start CATInitiatorFlow Client: Client, sub-Contractor: SubContractor, taskID: 01, taskDesc: “Bricks should be laid out”, amount: 100, assignee: “SubContractor”, deadline: “2020-10-23T10:12:35Z”.

Figure 2.22 The output on the MainContractor’s node.

This command will return a transaction id/hash after verifying the collected signatures and broadcasting this transaction to other participants which results in the completion of the flow. To check whether this transaction has been broadcasted, we need to see the vaults of the three nodes. Therefore executing run vaultQuery contractStateType: com.Task.states.TaskState in every node once again returns the same output in all the three nodes, as in Figure 2.23.

Figure 2.23 The output on all the nodes.

This output shows all the information regarding the transaction that has been carried out. There are two sections of the output here:

 states—this section shows the data and values stored in the parameters mentioned in Figure 2.1. It also contains information about the contract, notary, constraint, key, etc., and the transaction hash and index by which this transaction can be referenced.

 statesMetadata—this section shows the information about the transaction hash, index, recorded time, consumed time, status, notary, etc.

The transaction hash from both the sections of this output is similar to the transaction hash in the output represented in Figure 2.22. Whenever new transactions will be carried out, they will be appended to this transaction in the respective vaults and the timestamp will be recorded. Hence, nobody can tamper with the information stored in the vaults and every participant in the transaction is answerable in case of any mishap as the transactions contain their digital signatures. The advantage of using Corda in this scenario is that if there were more participants in this network, this transaction would only be stored in the vaults of the participants who were involved in the transaction that took place. Therefore, all the participants will act responsibly and the client will have information about the expenditure at every step and cannot be deceived by anyone.