My Journey with the Corda Blockchain
Recently, I was asked if I could help implement a prototype based on the Corda blockchain technology. The idea was to build a novel type of document management system (DMS) which can be used to securely share legal documents between companies or business units. I had never heard of the Corda platform before and was pretty much sceptical. So I dug into it and tried to understand the key concepts and then started to code. Now I’d like to share some of my insights during this endeavour:
Corda is a distributed ledger technology
In a blockchain such as Bitcoin all ledger entries are public and can thus be verified anytime by anyone with access to the distributed ledger. Cryptographic functions are used so that the ledger cannot be tampered with.
Corda and blockchain are both based on distributed ledger technology (DLT) but there is a subtle difference: in Corda, you can only see those ledger entries in which you are involved on a need-to-know basis as a participant. This increases privacy because even though participants of a blockchain are anonymous it is still possible to derive certain information using big data analysis or machine learning algorithms. Strictly speaking, Corda is not a blockchain even though it has a lot of commonalities.
Corda has smart contracts
Smart contracts in Ethereum consist of state and behaviour. They are therefore similar to objects in object-oriented programming. Contracts in Corda are different, they essentially verify if a transaction is valid and therefore can be commited to the Corda ledger. Corda contracts are stateless verification functions.
Corda is open source and implemented in Kotlin
It struck me: the Corda platform is available at GitHub under the Apache 2 License. The project is under active development and has quite a community. The driving company behind Corda is R3, an international consortium with a lot of top financial institutions backing it. Wat?
Now they chose the Java platform and Kotlin as their main programming language. Gradle is used as the build tool and IntelliJ IDEA as the IDE. Wow, I’ve never seen a project of this size set up like that!
Solutions in Corda are implemented as Corda apps, or CorDapps for short. A lot of sample CorDapps exist as well. They really helped to implement my own CorDapp.
A lot of dev docs exist as well and they have excellent support on Slack.
Corda is not lightweight and needs further optimization
The major downside is that Corda is currently pretty heavyweight. It reminds me somewhat of big legacy Java EE application servers with huge turnaround times.
The intent of the Corda team is a good one: the platform consists of a bunch of complex technology, such as application server features, a messaging engine, a workflow manager and databases that are abstracted away from the developer in order to gain a good developer experience as pointed out in this blog post.
However, there are good abstractions and bad abstractions. I wasn’t happy with the embedded web server. I couldn’t implement my use cases properly and had to replace it with another one which took quite some time. Luckily, there was a sample from one of the R3 devs as well. My choice was Spring Boot as those guys are really doing an excellent job: they got the right abstractions while maintaining a lot of flexibility.
To sum up, I was able to show that the Corda platform can be used to implement the use cases I was asked to prototype. However, the developer experience can be improved which is also pointed out in the ThoughtWorks Tech Radar. I also wonder why they didn’t leverage the Spring platform because Spring is very modular, has the right integration abstractions, and has excellent Kotlin support.
Corda as a platform is promising and it remains to be seen how it will evolve in the future.
