## 3 Blockchain
### Corda  
The first application analyzed in this article uses Corda to implement a smart contract for financial transactions, as financial transactions are one of Corda's strengths. Figure 2 is a UML-like diagram of the most important classes involved in the creation of a Corda smart contract. Elements of Figure 2 will be used throughout this subsection to analyze the implementation of a Corda blockchain application. Contract is the key interface of any transaction involving Corda smart contracts. It is the interface implemented by all contracts, and while it does not have any direct subclasses, it provides a key method to all of the classes that implement it: the verify method. This is the main method of the Contract interface, and it contains the contract verification logic that is executed when a transaction is validated by a node. The verify method takes two parameters: a LedgerTransaction object, which represents the transaction being verified, and a ServiceHub object, which provides access to various services provided by the node, such as the vault and the network map. An application handling financial transactions would use the verify method to check things such as the following: single transactionality per verification, uniqueness of payer and payee, checking the participants' keys, single states for financial transaction, and more. Figure 2: Basic classes and interfaces involved in a Corda smart contract implementation. The class composition of this sample financial transaction would also implement ContractState, the interface implemented by all state objects that are used as part of a contract. In ContractState, contract is a reference to the contract that governs this state, while linearId is an instance of Uniqueldentifier which is the unique identifier of a particular instance of a state. Participants, on the other hand, is a method that returns a List<AbstractParty>, where AbstractParty is an abstract class that represents a party on the Corda network. The list contains all parties that have some sort of right or interest in the state, such as the current owner or the regulator overseeing the contract. There are multiple types of states agreements can have, all derived from ContractState, including OwnableState and LinearState, all of which work within the framework of a Corda smart contract to achieve different results when managing a transaction. OwnableState is an interface that extends ContractState and adds the functionality of keeping track of the current owner of the state. This means that an OwnableState object contains an owner field, which is an instance of a Party object representing the current owner of the state. The purpose of OwnableState is to provide a simple way to track ownership of assets on the Corda network. By implementing the OwnableState interface, developers can easily create assets that can be owned and transferred between parties on the network. When the ownership of an asset changes, the withNewOwner method is called to create a new instance of the state with the new owner information. OwnableState is often used in conjunction with other Corda features, such as the TokenSDK, to create digital assets that can be traded on the network. LinearState is another type of ContractState that represents a state which evolves over time and can be uniquely identified using a linear ID. The linear ID is a unique identifier that remains constant throughout the life of the state, even if the contents of the state change. This allows transactions to refer to the state unambiguously and ensures that the state can only be consumed once. LinearState is used in scenarios where a state is expected to represent an ongoing agreement between parties that evolves over time. Examples include loans, insurance policies, and supply chain contracts. By using a linear ID to uniquely identify a state, parties can track the evolution of the agreement over time and ensure that all parties agree on the current state of the agreement.