Architecture for CorDapp Developers

This section describes Corda 5 from the perspective of a CorDapp Developer. Corda is an application host for CorDapps Corda Distributed Application. A Java (or any JVM targeting language) application built using the Corda build toolchain and CorDapp API to solve some problem that is best solved in a decentralized manner. . These are pieces of code, workflows, and contracts, executed on behalf of the members of an application network The set of all possible entities onboarded according to the rules of the network. Application networks enable people and businesses to interact with each other on Corda. , usually as part of an interaction or transaction A transaction is a proposal to update the ledger. between peers on the network. CorDapp Developers are responsible for designing and writing this code.

A CorDapp is distributed because parts of the application can be, or may need to be, executed on a Corda instance that is operated by another party that is a member of the same Corda application network The set of all possible entities onboarded according to the rules of the network. Application networks enable people and businesses to interact with each other on Corda. . This is not the same as an application that has multiple instances, hosted on different environments.

The following diagram shows a centralized application. This is a single application that always executes within a single execution environment, regardless of the number of deployments:

Similarly, centralized applications often use a services architecture, meaning different parts of the applications interact with each other. This could be inside an entity’s network, or different parts may be operated by different parties.

However, distributed applications in Corda, while being deployed by different parties in the network, are unique in that parts of the application execute in the different environments as part of the same execution context.

Workflows, Contracts, and States

CorDapps are usually composed of workflows, contracts, and states An immutable object representing a fact known by one or more participants at a specific point in time. You can use states to represent any type of data, and any kind of fact. . This section illustrates that contracts and states are optional, but a CorDapp must always define at least one workflow, often referred to simply as a flow.

Flows support the orchestration layer, are written in a JVM compatible language, and are hosted by Corda. Typically, flows create or transfer states on behalf of a member of the application network (a virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. ) who seeks to form consensus with their peer nodes with the help of the notary Corda’s uniqueness consensus service. The notary’s primary role is to prevent double-spends by ensuring each transaction contains only unique unconsumed input states. .

Taking the IOU Sample App as an example of a distributed app, all members of this fictional network can be lenders or borrowers issuing, transferring, or settling loans directly to each other. There is no central ledger of loans, and consensus is achieved between the participating parties, not a central entity.

The sample app contains three flows:

• Issue
• Transfer
• Settle

Each flow handles an IOUState that represents the loan amount, lender, and borrower. IOUContract is a contract that verifies transactions that are part of the given flows, using the given state. In this example, transactions are between borrower and lender, which means each party, members of the application network (virtual nodes), interact with each other to reach consensus.

Participants and a Distributed Ledger

Corda flows usually involve multiple parties or participants, where each participant must be a member of the application network, or a virtual node, and is generally identified by an X.500 A series of international standards defining a global directory service protocol for computer networks. It provides a structured framework for storing, accessing, and managing information about network resources and users in a hierarchical and distributed manner. name.

In flow terms, the initiating flow is the code that is executed on the initiating participant, and the responder flow as the code that is executed as a response on the counter party (or parties). The initiating flow is generally initiated using the REST API, as described in the Introducing the Corda APIs section.

In the IOU example, the borrower and lender are both participants in the IOU issue flow, with the borrower on the initiating side and the lender on the responder side.

When the flow shown in the diagram completes successfully, both participants have stored the state (IOUState) in their respective vault A database containing all data from the ledger relevant to a participant. The database tracks spent and unspent (consumed and unconsumed) states. databases. In an example with multiple borrowers in the network, this could result in the following state:

As shown, the lender’s vault contains all loans, but borrowers Alice and Bob can only see the loans related to them. This is referred to as a Distributed Ledger A database of facts that is replicated, shared, and synchronized across multiple participants on a network. .

While flows usually involve multiple parties, they do not have to. Sometimes flows that only involve the initiating party are required. Examples of this are minting tokens or providing a read API for states already in the vault.

The IOU example records transactions in the vault. However, it is possible to create flows that do not use the vault, but only use the orchestration (flow) layer.