2.11 System overview.
As seen in Figure 2.11, the Corda powered DLT network consists of several nodes including participants, validating notaries, and non- validating notaries. The smart contract and actual data are saved on the ledgers of the designated nodes only. The off-chain database is used to store only the credential data and it is made sure that no personal data is stored here. Corda has built-in KYC solutions to empower self-ownership, with the help of which, individual participants can log in to a node and control their user data independently. It is observable that there are three main participants, namely the client, the main contractor, and the subcontractor in this scenario. Each of these participants can visit the website through the internet, control personal data, and access the ledger. Although the portal used by these participants is the same, the actions performed by them are different due to the roles they play here. These roles are explained in the next section with the help of a working flowchart.
2.4.2 Working Flowchart
Figure 2.12 Working flowchart of the solution.
The roles of the participants can be described with the help of the flowchart in Figure 2.12.
The Client: This entity can transfer money to the main contractor. This participant is involved in all the possible transactions of the flowchart so that he/she can keep track of how and where the money is being spent.
The Main Contractor: This entity can create new tasks and assign them to the subcontractor, along with a deadline, and then request the client for the money that is required for the completion of the assigned task. This participant can be assumed as the bridge linked to the client and the subcontractor.
The Subcontractor: This entity should update the status of the assigned task so that it can be inspected by the concerned people. This participant should do so before the given deadline so that no strict action can be taken for the delay.
This solution model uses a single notary due to limited participants and all the participants must have an account on the online platform that is provided.
2.4.3 Experimental Demonstration
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
