The short story of building Corda that we shout from the rooftops.
Hey there, if you’re reading this, odds are that you’ve seen one of the many (16!) bootcamps that my team has run over the past month in multiple time zones. Certainly, we’re excited about something; but you’re busy, we all are. So I’m going to SparkNotes the lectures so you don’t need to suffer through my voice for a painstaking 163 minutes; you’re welcome. I’ll include only the most important concepts and code snippets so that you have everything you need.
Our first workshop was entirely around the concept of blockchain in general. What is a blockchain, and how do they work?
This term can be overloaded so it’s important to start with some basic clarity on what a blockchain is supposed to do. Keep in mind that what we’re building is a data store. Think of a spreadsheet that you share with some coworkers on the office computer. There are rows and columns in a sheet that can be edited in any way, and you can hit undo to view the way the sheet used to look.
This has some issues because you can’t see who made edits at what times. The ‘undo’ feature is nice but it doesn’t give you a robust history.
The big difference with blockchain is better history features, the spreadsheet is always accurate and it’s stored on multiple computers. The blocks are the edits, and the chain links all the edits to the sheet from the beginning. These sound nice, but when you start working with it you start to see the value.
Imagine the following; Everyone gets unique keys, and mathematics enables those keys to make edits tied to that person’s identity. Each transaction is applied to the previous version of the sheet so you can see the entire history of every single edit made.
The modular arithmetic is such that and a transaction can’t be faked unless your programmers are bad at math. PSA to use large public exponents! Otherwise, you can get hit with factoring problems!  Fortunately Corda does this for you ?
In other words, Blockchains use cryptography to bring identity and integrity to the spreadsheet.
Now it’s important to remember that in principle, each pair of keys is tied to a particular identity that can be a part of transactions. You’re going to be running a single Corda node for each person on the network.
So if you’re now going to maintain a blockchain in a developer application, that can get pretty painful pretty quickly. Fortunately, you could use the abstractions provided to you by Corda to create programs that manipulate the shared facts on the blockchain between everyone that’s using this shared information; we call these apps CorDapps.
That being said it may not surprise you that our second workshop was on this exact topic.
Basics of these CorDapps Fundamentals.
Remember that in-principle, each person is running their own node that is representing their identity for their transactions on the blockchain, and CorDapps facilitate the exchanges of ownership of whatever you want to track in your shared spreadsheet of who-knows-what.
We generally think about these digital objects as possessing some value and then think about who owns what digital objects, and then change ownership or create new objects. This all sounds harder than it really is.
There are essentially three things to keep in mind for your Cordapps; states, contracts, and flows.
A state is an object; anything that can be represented digitally can be a state. They’re basically java classes that you treat like any other, but they can be used within Corda for a lot of really nice features on top of them.
Contracts represent what you can do with the objects you have. They outline rules for making a transaction legitimate.
– To sell a car you have to have a car.
– You can’t buy a car for a negative amount of money
– In NJ cars have 6 character license plates.
These are examples of contract rules you could write and have enforced whenever a transaction to sell a car takes place.
With this in mind implementing contracts is easy. Here’s a contract verifying the act of issuing a state with (some currency, an issuer, and an owner).
So it makes sense that some of these contract rules are things like:
– “We are issuing currency for the first time”
– “There’s no input to the transaction”
– “The currency must be positive”
Now that we have our objects, and we outline what we can do with them using contracts, we just need a way to actually change the items on the blockchain.
That’s what flows do, you run a flow on a given node, and the flow does the work of implementing your custom logic to actually update the ledger and talk to the other parties involved so that you can make meaningful progress on tracking information between everyone involved.
There’s a lot going on here, and I’d recommend taking a look at our actual Bootcamp cordapp and our second workshop to better understand what this code is really doing. 
Define the objects and what you can do with them, and Corda will do the rest.
Once you’ve done the work to write these CorDapps you really can just get started and spin up the nodes for anyone you want. However, if you’re just trying to build an MVP, multiple nodes might not be the best use of your time and money just yet. Which brings us to our THIRD workshop!
Accounting for everyone is hard
You may have realized by now that every party running their own Corda node can get pretty expensive, and won’t scale nicely with the size of the network. So what can we use to deal with the scaling challenge? The answer is the Corda AccountsSDK.
Nobody likes maintaining 200 machines to represent each of their customers on a shared network, or for all of their internal departments to use a blockchain. Corda now has an AccountsSDK to deal with these problems so you don’t have to.
In the code you actually barely have to do anything to get this to work, you’re only using an identity instead of it being assumed when running the flow from a node.
So just make sure to select your account in the code when running your flows.
If you select the accounts correctly when running your flows you actually won’t need to change anything else when running your flows that we built earlier.
Simply put; You can use Corda accounts to represent multiple parties on a single Corda node which can make life much easier for you.
So if we really can represent whole groups with a small number of Corda nodes, the next thing to think about is to make it easier to represent a wide variety of different use cases so that we can make it easier for you, a CorDapp developer. Furthermore, it should not surprise you that our final workshop was on this exact thing.
“Tokens” on the Blockchain
A token is essentially a digital representation of an asset, that can represent an object that is fungible or nonfungible. This very abstract definition will help get us to something we can use for almost anything.
If you’ve ever done stock trading then you already know what a token is. It’s a digital representation of a liability representing a stock that the brokerage owes to you.
When you’re trading stocks you’re really trading tokens, and when you request it from a brokerage you can (probably) get the actual paper stock certificate as the rightful owner of a share of the company. As you’d expect that would remove the token since you’d have the paper in front of you.
Corda lets you do the same thing by creating fungible tokens for things like currency, and non-fungible tokens like the deed to a house. The power of the Corda TokenSDK comes in because of all the functionality we can handle for you if your object fits the definition of a token.
And generating a token is also quite simple, in the middle of your flows you can just use them directly (you’ll also need to adjust your state object definitions a bit but that’s all)
You’ll start to see the power of this if you look through the Corda TokenSDK documentation on how you can issue, create, modify, and redeem tokens. My colleague Ashutosh has written a great article on this and I recommend checking it out.
Corda Tokens do a lot of the work for you to implement abstractions like currency or abstract obligations to real assets.
Congratulations! We’ve made it to the other side; you now understand the basics of building CorDapps and have our code and workshops to see it done for you.
The use cases for Corda open-source are many. You have the knowledge to build something extraordinary, and we need that now more than ever.
 See this fantastic paper from the University of Michigan “Minding your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” from Henninger et al., find that here: https://factorable.net/weakkeys12.extended.pdf
 You can find the Bootcamp CorDapp here, namely Solutions.md and our second Bootcamp where I actually implement this and run it: https://github.com/corda/bootcamp-cordapp/
– Our Corda Developer Bootcamp: https://www.youtube.com/watch?v=BIhRZJl_NaA&t=1s
– Our Accounts Bootcamp: https://www.youtube.com/watch?v=nn_6SD2Pr5s
– Our TokenSDK workshop: https://www.youtube.com/watch?v=IAViczRAEyU
Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.
— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.
Follow David on Twitter here.