Accounts library in Corda

Part 1: A Quick Guide

Every new year comes with new possibilities and lots of presents. Why should blockchain developers be left out?

At least that’s what the Corda developers thought when they released Corda version 4.3 this close to the New Year 2020.

The Corda community has been endowed with documentation updates, remarkable new features and the blazing concept of Accounts, all achieved through 550 commits in over 4 months and 400 fixes.

Being a developer, the concept of Accounts swept me off my feet. In a way, this is the Corda developer team saying there is a new sheriff in town baby and not just for the FinTechs but for numerous use cases beyond financial applications.

But what are Accounts and why are they such big news?

In the end, it all comes down to cost, no matter how optimized the code is the cost per Corda node is too high and therefore every organisation can not afford to or rather would not choose to spend that much.

Accounts to the rescue.

As stated by R3, The accounts library allows a Corda node operator to split the vault into multiple “logical” sub-vaults.

To understand this let’s take the example of a company with 20 employees.

All the employees need a separate computer with a very high configuration that would cost a lot. But what if I tell you there is a way you can do mind-boggling cost-cutting.

What if, you buy only one optimum system and all the 20 employees can work on it simultaneously, without affecting its performance to an extent. Imagine separate interfaces for each employee through which they operate on that one system.

You don’t have to imagine anymore cause that’s what accounts facilitate us to do. We can register several users on a single node to carry out transactions, asset management and whatever we need to by creating a sub vault in the node’s vault which will belong to a specific user based on a UUID given to each account owner which also can be used to track back to the main node and its private key.

Obviously, everything comes with a cost which in this case is privacy between the parties involved as Accounts on the same node have access to each other’s data. Don’t worry, there is a way around this too.

On a GitHub issue discussion between me and Mr Roger Willis, member office of CTO, R3’s Corda, he stated that

Sadly, there’s no isolation at the node level but you can add application-level controls to provide authorisation on a per-account basis. This functionality would be baked into your CorDapp and the RPC client associated with it.

So, Accounts are important, they reduce cost, they remove operational complexity etc etc, but how to implement them in your existing Cordapp is the question now.

Let’s dive into the practical section

For your existing CorDapp you need to make the following changes:

1. Include the following imports in the buildscript part of the main build.gradle of your CorDapp

corda_release_version = ‘4.3’

accounts_release_version = ‘1.0-RC04’

accounts_release_group = ‘com.r3.corda.lib.accounts’

confidential_id_release_group = “com.r3.corda.lib.ci”

confidential_id_release_version = “1.0-RC03”

These are the versions and variables you need to define. Please note that Accounts work from Corda version 4.3.

2. Now we need to add the repositories

maven { url ‘http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev’ }

maven { url ‘http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib’ }

Note: Don’t forget to add the maven repositories in “allprojects” code too. There is a repository block in your “buildscript” as well as the “allprojects” block so add the repositories in both of them or it won’t work.

3. There is a build.gradle file in each module and they all need a slight change

• For contract build.gradle add:

cordaCompile”$accounts_release_group:accounts-contracts:$accounts_release_version”

• For workflow build.gradle add:

cordaCompile “$confidential_id_release_group:ci workflows:$confidential_id_release_version”

cordaCompile “$accounts_release_group:accounts-workflows:$accounts_release_version”

• If you want to use the deployNodes task of the templates or any custom task, you need to add the following in your dependencies

cordapp “$confidential_id_release_group:ci-workflows:$confidential_id_release_version”

cordapp “$accounts_release_group:accounts-contracts:$accounts_release_version”

cordapp “$accounts_release_group:accounts-workflows:$accounts_release_version”

And these in your task:

nodeDefaults {

projectCordapp { deploy = false }

cordapp(“$confidential_id_release_group:ci-workflows:$confidential_id_release_version”)

cordapp(“$accounts_release_group:accounts-contracts:$accounts_release_version”)

cordapp(“$accounts_release_group:accounts-workflows:$accounts_release_version”)

}

Note: These should be “Added” so don’t remove the existing code snippets.

This should get you started.

Now you can create flows and states which use anonymous party instead of party, call predefined subflows to create UUIDs for accounts and much more.

Alternatively, if you are just starting out the development you can use the token- account SDK provided here. It has tokens and accounts both dependencies already included.

For keen developers who want to understand Accounts even more and create APIs, I suggest you visit the following link where you can find a sample project containing all the necessary flows for your understanding.

https://github.com/corda/accounts-demo-supplychain

Stay tuned for more insights into Accounts and other fascinating libraries that we at Webmob have been constantly exploring. Part 2 of this series will contain the details of how to build a simple API to create accounts on a particular node in the Corda Community edition. Don’t forget to clap. See you next week.

---

Accounts library in Corda was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.