The New Advanced Society. Группа авторов
Читать онлайн книгу.
are considered as a proposal to update the ledger provided there is no double spend [43].
The UTXO (unspent transaction output) model wherein a transaction can have inputs and outputs ranging from zero to any number is used in Corda [44].
The transactions in Corda are validated by notaries as well as parties related to the transaction instead of a broader pool of unrelated validators.
The consensus in Corda has two aspects, namely: transaction validity, where the contract code that executes the transaction is checked and it is made sure that all the required signatures along with any referenced transactions are valid. The second aspect is transaction uniqueness where it is made sure that the respective transaction doesn’t lead to a double-spend by making sure that there no similar transaction exists [45].
There are certain special nodes in Corda, termed as notaries that can get involved in the transactions for validating them and terminating double-spending.
Multiple notaries are present in a Corda network, preventing a single point of failure.
The ledger is subjective from each peer’s perspective as no transaction is broadcasted to the entire network unless required. Each transaction is visible only in the ledgers of the peers that were involved in the transaction and no one else [46].
A minimum of two peers is always assured to see the same version of any on-ledger facts that they share.
2.3.1 Some Salient Features of Corda
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