Nail the New Year with Blockchain
Try the simple building blocks for truly decentralized apps.
Welcome to the new year! If you’re looking for some inspiration to build on an open-source blockchain, then you’ve come to the right place.
Our goal in building a distributed application can be broken down into three mini-goals:
- Represent abstract entities.
- Represent abstract operations on those entities.
- Trigger those operations and reach consensus among the parties involved.
We call this collection of features a CorDapp, and you can implement them in Java or Kotlin. (To be clear, however, you could use any JVM language.)
So let’s imagine an intuitive use case for our CorDapp: Cars!
Imagine in our simple example that a unique party manufactures cars. After being created, those cars are then distributed to dealerships that sell them to specific persons and corporations. We can perform specific operations on cars, we can manufacture them, and we can sell them, and we can change information about them like license plate number and mileage.
The ideal scenario is where all of these parties use Corda so that the entire history and ownership of that car can be tracked.
To model our car sales, we’ll create three separate abstractions in our programs:
For clarity, I’ll use Java for this tutorial, but the kotlin classes are very similar.
With each of these objects, you have the tools to model the manufacturing of a car, ensuring that the vehicle is valid, and perform a valid issuance of a newly manufactured car according to a set of contract rules — all with the added power of an immutable ledger underpinning it.
Let’s do a short walkthrough of the critical sections of code. If these make sense, then you’ll already understand everything you need.
States are objects, just like you’d model in any other programming language. You can model our car state in a pretty intuitive way.
So our car has a license plate, a VIN number, and other basic properties.
Then is has a bank that owns the car, the dealer holding it, and the manufacturer. We also include some details about the parties to the transaction
If this makes sense then you’re ready to create the operations that can be performed on our car! That’s where contracts come in.
Contracts are our tool to represent the abstract operations that we can perform on these objects.
With your contract, you can create rules to deal with whatever checks you need to ensure your ledger updates are valid. Here’s an example of how simple those checks could be. Thinking back to the car example, this is where we might check things like the license plate and the VIN number to make sure that everything checks out. (You could even use a Corda oracle for this too but that’s another conversation).
For example, if this is a new car, the mileage should probably be low. If you’re buying the car from someone else you don’t necessarily need the mileage to be low so you might check that in a sale differently than you would in the issuance of a newly manufactured car from the factory.
Now that this is in place, both parties can verify the validity of the entire transaction with contract rules. Here, our rules are intuitive enough, an issue command has to correspond to a new car state, and the license plate has to have seven digits.
Assuming these rules are satisfied, the transaction is permitted to complete and it is successful.
The last piece of the puzzle here is flows. Remember that flows are simply tools to trigger transactions between parties on the network. So, we could have a flow that issues our new car and a flow that enables us to share it with another party.
A good example flow is one in which you issue, manufacture your car, and introduce the asset to the blockchain.
In the flow below a car is created and given to a holding dealer. That is why it’s specified here as an output state.
Here our car flow does what we’d expect it to, we give Corda the details of the car and the Corda node representing the manufacturer does the work of creating the car and collecting all the signatures of the other parties that have to be aware of the car’s existence. (You can also extend this example to include regulators like the SEC or observers like NHTSA).
If this flow example code made sense to you then congratulations! You essentially understand Corda and shouldn’t have much trouble getting through our tutorial to build out your own blockchain use cases.
Now as with all things in computing, there’s more detail to understand than just this. There’s a couple of tools here that you’ll need to do some more digging into such as responder flows, the subflows I used for signatures, and the transaction builder, but most use-cases can actually get by with just these building blocks.
Now you’re off to the races ~
I’m sure this isn’t the first blog post you’ve read that helps bring you some inspiration about what you can build with blockchain. I don’t need to convince you of the merits of using open source to create great things.
If you think this tutorial was intuitive and want to build something yourself, I’d encourage you to look at our Corda tutorials and try building something for yourself!
If you have ideas about what you want to build, maybe this is your year. All I ask is if you have some inspiration to tell us about it! You can find us on our slack or tell us about your project at [email protected]. I certainly look forward to seeing it.
Want to learn more about building awesome blockchain applications on Corda? Be sure to visit https://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.