Corda, being similar to blockchain, is useful for storing data among multiple participants, especially those who are having trust issues but, are in the situation where they have to share information. Corda is one such platform that has been developed using DLT, where the ownership is shared through a network of participating companies, therefore, terminating the need for third-party involvement. This platform provides unique features that complement the usage and application of Corda in a variety of industries. Some of these features are:
Decentralization—There is no central authority or central point of administration in the network [47]. The multiple points of coordination prevent delay and a single point of failure [48].
Immutability—The information stored here can never be changed i.e., a successful transaction can never be undone after the ledger has been updated. One can perform only create and read operations [49].
Security—A variety of cryptographic algorithms are used to verify the information before it is stored and to prevent any possibility of fraud [50, 51].
Auditability—Every transaction is validated and stored in the ledger with a timestamp, enabling participants to trace the previous transactions easily [52].
Trust—Since every participant has to be verified before they enter the network, everybody’s identity is known to each other [53]. This provides a greater amount of trust among the participants.
Consensus—Unlike other blockchains, the consensus is pluggable in Corda via uniqueness consensus and validity consensus [54].
Disintermediation—This feature helps eliminate the third party and their associative fees, thereby increasing the efficiency and overcoming the need to trust these intermediaries in the network [55].
2.3.2 States
A state is an immutable object that represents a fact known by one or more Corda nodes at a particular point in time and these are updated by marking the current state as historic and creating an updated state. Unlike traditional blockchains, each peer is associated with a vault which is a database that tracks all the current data (otherwise known as the unconsumed state) and historic data (otherwise known as the consumed state) that it is aware of, along with the timestamps. Vaults may have different versions of data depicted by state objects, but only one of them is the current data and the remaining are historic data [56]. The states used in this solution are described below.
In this scenario, the state object is the “task” and the state sequence is the “completion of the task”. As mentioned in Figure 2.1, the participants are the client, the main contractor, and the subcontractor. The properties involved here are:
Task ID—the ID of the task
Task description—a detailed description of the task to be completed
Amount—the amount that is required to complete the task
Assignee—the subcontractor assigned by the main contractor to complete the task
Deadline—the date by when the given task is to be completed
The main contractor can create a task and assign it to a subcontractor. The subcontractor can update the state of the task upon completion.
Apart from the state mentioned in Figure 2.1, there is another state in which the state object is the “cash” and the state sequence is the “flow of the cash”. As mentioned in Figure 2.2, the participants are the client, the main contractor, and the subcontractor. The properties involved here are:
Figure 2.1 Representation of the “task” state.
Figure 2.2 Representation of the “cash” state.
From—the participant that sends the cash
To—the participant that receives the cash
Amount—the cash that is being transferred
The client can transfer the amount required to complete the task only to the main contractor, upon request. The main contractor can then transfer this cash to the subcontractor assigned for the completion of the task.
2.3.3 Contract
In Corda, each state must be paired with a contract i.e., a one-to-one relationship exists between states and contracts. A contract contains the code defining the shape, content, and signer rules, along with the verification function. The code in these contracts can be drafted in JVM languages like Java/Kotlin. Contract execution is rigid and the approval of a transaction is dependent on the details of the transaction [57]. Even if a transaction acquires all the required signatures, it is valid only if it is contractually valid. For the appropriate usage of the above-mentioned states, the following four contracts are used in this solution. The contract validates the transaction and if successful, the output can reference this contract for any future verification i.e., in the future, any participant having access can trace back for verification. The additional benefit in Corda is that it allows the smart contract to accommodate legal prose, namely smart legal contracts (implying to Ricardian contracts). The contracts used in this solution are described below.
2.3.3.1 Create and Assign Task (CAT) Contract
According to this contract, the main contractor can create a task and assign it to one of the available subcontractors. Therefore, the main contractor is the only participant who can initiate this contract. The task state is paired with this contract.
Figure 2.3 Representation of the CAT contract.
As mentioned in Figure 2.3, this contract requires zero input states and gives one output state. The signatures of the client, the main contractor, and the subcontractor are mandatory in this contract for a successful transaction. Hence, this transaction is visible to all three participants.
2.3.3.2 Request for Cash (RT) Contract
According to this contract, the main contractor can request the client for the amount required for the completion of the created task. Therefore, the main contractor is the only participant who can initiate this contract. The cash state is paired with this contract.
As
