By Parth Shukla, 180Protocol CTO
As promised during our presentation at CordaCon last week, we want give more detail on our initiatives building on Corda, sharing our experiences with the community. For a refresher, please check out our CordaCon presentation here.
When we set out to develop our own digital assets issuance and administration platform (the IAN) for private fixed income instruments on the eve of 2020, we had little doubt that R3 Corda was the right technology platform. It made a lot of sense: open source core, strong transaction-level privacy, very mature technology stack (Java), strong developer community, excellent documentation, and — last but not least — access to the Corda team itself. We were sharing physical office space with R3 in London as entrepreneurs-in-residence.
Fast forward a month, and we were in the weeds of the day-to-day reality of being a pre-seed fintech startup developing their first product on Corda. As early as during the detailed design and initial prototyping phases we started tripping over things. Strangely enough, the team had hands on experience with Corda in an enterprise setting from previous lives, and none of the issues we stumbled upon were novel. However, aspects of Corda that were perceived as non-issues, or even desirable features, in an enterprise context suddenly started to be problematic.
R3 were very supportive, and our commitment to Corda has not wavered in the slightest. It’s a fantastic product, and our tech team felt privileged to have access. What we saw were not bugs (although we saw one or two), or outright missing critical functionality (no product is ever complete), but incompatible features for fintech Cordapp developers. Corda’s product philosophy wasn’t always suited to the volatile environment of a fintech with its urgency-driven and resource-constrained full-stack technology team.
The IAN, our digital assets issuance and administration platform, is built on Corda, but Corda itself is not the only component of the architecture. A few other moving parts had to be developed including user interface components and middleware that would allow the IAN to be fully integrated into client’s IT systems estates (for example payment gateways). We saw that due to several Corda product design decisions, using Corda as a component of the system exerted disproportionate impact on other components.
Metaphorically, it was as if there was a massive gravitational pull in the middle of the galaxy making all stars, even the heaviest and brightest, spin around and ultimately converge. The challenge we had was to fight Corda’s pull toward taking our overall architecture in a direction we did not want to go.
As of today, the standard way to interact with a Corda node is through Corda RPC – a highly flexible and vastly complicated binary protocol tightly coupled to the implementation of Corda itself. To use Corda RPC one must have Corda client code, which effectively forces use of Java.
This isn’t much of a problem for a corporate user or a consultant. Java people are in ample supply, and the general consensus architecture is to develop a middle-tier component in Java, which speaks to Corda via the RPC on one end, implements all server-side business logic, and then presents a UI to the user. Pretty uncontroversial, and has been done by many organisations many times over, ourselves included.
Except we felt uncomfortable. There are two key reasons:
The SECOND reason was infrastructure. At 180Protocol we are big proponents of Cloud-native architectures. We like to use managed services from Cloud providers. They are cost-effective, but principally they allow us to minimise risk around managing and securing the infrastructure used to run our application components. We wanted to optimise and use a function-as-a-service architecture pattern (also known as serverless) which is supported by all major cloud platforms, and is a very cost-effective way to develop and deploy loosely coupled backend components. Now, it happens that Node.js is a good option for developing functions owing to its fast bootstrap time and low memory footprint. One would have thought that Java is also a valid choice, but in practice many web and middle-tier frameworks like Spring Boot come with a lot of baggage and footprint, making it nearly impossible to develop serverless function-based applications. So, in short, Java did not feel right from this perspective either. Interestingly, this is also an area which did not feel problematic in enterprise context, as entire departments are dedicated to running Java-based application backends, which are taken for granted.
This way we were successfully able to limit the pull of Corda and use a technology stack we were comfortable with. We also thought such approach would be better for a start-up, as it allows more efficient resourcing and makes production of infrastructure more secure and light-weight. Finally, we believe this is not a unique problem for 180Protocol, and that many other development teams using Corda – from start-ups to corporates – face similar challenges.
For more information, please check out our presentation from CordaCon 2020, where we discussed our exciting initiatives building on Corda. Please don’t hesitate to reach out if you wish to follow up via our website www.180protocol.com.