Corda R3 — Starting a New Corda R3 Project

This article is the first of a series of articles about Corda R3 (Corda from now on).

In the first one, we will learn what a distributed ledger is and how Corda can help us implement a DApp (distributed application), and an initial setup of the framework using IntelliJ as our main IDE.

But before we start, first we need to understand what our goal is, what we are trying to build here and why Corda can help us build our project.

What Are We Building?

We are going to build a simple proof of concept project I call, DBanking. DBanking is a distributed application for the bank industry.

That being said, the following requirements are to be met.

  • A node must represent a bank in the system.
  • A node must be able to transfer digital assets between nodes.
  • A node must be able to require a digital asset from another node.
  • A node must be able to accept or deny a requested transfer.
  • Digital assets, i mean any form of exchangeable value ( money, bonds, tokens, digital coins…) the system must be able easily support an entry of new assets.
  • The system must provide an API so the bank who owns the node can use the system.

Sounds simple enough…so let’s see what Corda is and how it can help us build a DBanking app.

What Is Corda R3?

To understand what Corda is, we first need to understand what a distributed ledger is.

In simple terms, a distributed ledger is a set of peers distributed throughout the network and connected to each other without the need of a central authority. Hence a distributed ledger is decentralised and distributed in nature.

Each peer has an internal storage and is responsible for saving and reading data from that storage. This way creating a network of distributed ledgers.

This type of network is usually associated with the public distributed ledger type of networks, such as the Bitcoin network, where trust is a paramount issue. But it should be noted that these technologies can and should be used as well by parties that have a trust in each other.

Obviously trust is an issue in any type of DLT (public or consortio) making it singularly problematic to achieve consensus on what each node is saving into its own ledger, is this data valid? Is everyone seeing the same information? Who has interest in this data is storing in the same manner? And in the same order?

To solve these questions the network needs to have a consensus algorithm, to validate and verify the data and maintain order in the network of the shared information.

So how does Corda achieve consensus?

It uses a particular node called Notary, this node executes a consensus algorithm. It is responsible for the verification and to validate the information being shared. This implies as well the solving of the double spending problem associated with this type of systems. There are pros and cons of using a Notary node to solve this problem, such as creating a new point of failure or centralizing the network at the notary.

Corda networks usually are meant to be used by known parties that know each other and there is a certain degree of trust between nodes of the network. If trust is an issue a public DLT should be used instead.

We have to keep in mind the nature of our system and the trust between nodes. (One can suppose there is a certain degree of trust between banks — since we care about that in this case — and we do not expect banks to be joining in and exiting the network randomly).

Throughout this series we will go deep into how to use the framework and what is actually happening behind the scenes from a user point of view.

Initial Setup

To set up a new Corda project we just need to have IntelliJ installed and have access to the internet. If you have these requirements met, you are more than halfway there already.

We need to download the Corda Kotlin template zip file. Yes, we are using Kotlin because it’s the most amazing language, and since Corda was written in Kotlin, it makes sense to use Kotlin as well.

Since I like to use the terminal to build and run nodes, I just import the project within intelliJ. By doing that you are overriding the default files that come with the project and won’t be able to execute them from inside intelliJ straight away. If you want to do so, you must OPEN the project instead. I will assume you imported the gradle project from now on.

After intelliJ finishes the setup and indexing files we should be able to build the project and generate the default nodes that come with the template and run them on new java virtual machines.

To build the project open the terminal tab within intelliJ (or open a terminal window from the root folder of your project).

execute:

Unix/Mac OS: ./gradlew deployNodes
Windows: gradlew.bat deployNodes

After that we will notice a new build folder generated. If we open that folder, we will find another folder named nodes and that is where our just generated nodes are created and stored and a few scripts to run them called runnodes.

├── build
│ └── nodes
│ ├── Party A
│ ├── Party B
│ ├── Notary
│ ├── runnodes*
│ └── runnodes.bat

To run the generated nodes we can simply execute one of the runnodes script.

execute:

Unix/Mac OS: build/nodes/runnodes
Windows: build\nodes\runnodes.bat

This command launches the nodes generated previously. The nodes are basically java virtual machines (jvm) programs. At the time of this writing there are 3 jvms running, 2 nodes and 1 notary.

great, now to the next article!!!

Master In Software Engineering and Android Engineer at Busuu, with a great passion for technologies, programming and photography.