R3's Mike Hearn: Don't toss out existing enterprise software because of blockchain 'fashion'

Perhaps the strongest message from R3's lead designer Mike Hearn, during a talk about Corda, was that financial institutions do not need to toss out their infrastructure because distributed ledgers have come along.

Hearn said integration is an important topic which is ignored by most other platforms and this derives from an unfortunate tendency, a kind of Silicon Valley mentality. Typically developers that are doing blockchain startups will say they find enterprise software disgusting; enterprise stuff is for big and slow companies, they say. They are cool and hip and are not going to use it.

"Technology is a very fashion-driven place unfortunately," said Hearn, a former senior software engineer at Google and Bitcoin Core developer. "And yet there's a ton of really great infrastructure and software out there in the financial industry and enterprise world, which is insanely powerful and it makes no sense - no sense at all - to abandon it for reasons of fashion. But we see it happen over and over again."

Corda has been built with Java developers at banks, insurance companies and other financial institutions in mind. This is so they can reuse their knowledge, and also they can reuse their code, said Hearn.

"For example we did a prototype using an ISDA standard initial margin model, and there is a Java specification; specified by regulators and so on. And it can just be dropped right in to the smart contract and in to the flows," he said.

The viewable ledger subset can be relational and then queried with SQL and regular database technologies, "you can join it with your private datasets and import it into Excel and do all the other things that businesses do every day - the technology choices other platforms have made preclude all that, for no good reason to be honest.

"So Corda is designed to re-use what's good in the existing infrastructure - and there is a lot that's good. DLT does not mean everything should be thrown out. Corda integrates with what's there and this is one of the reasons that, despite being a small team setting out at the start of 2016, we have been able to catch up because we've leveraged what's out there."

Corda is inspired by Bitcoin but it is not a fork of Bitcoin or Ethereum; it was designed from ground up with industry requirements in mind. "It has not just tweaked one of these platforms, and it is certainly not a way of selling legacy platforms, like mainframes," said Hearn. "There are people out there who say, you can buy our blockchain and we will run it on a mainframe for you, which is about the least blockchain thing I can possibly think of."

From working with developers in the lab, Hearn says he often encounters systems that encrypt stuff, put it into the blockchain and broadcast it to everyone. "So you are sending people encrypted data they are not intended to be able to read ever. It doesn't make any sense. Why would you send people data they can't read or do anything with?

"Or they are putting hashes of things held elsewhere on the ledger, and again, they would never get the data that is actually backing the hash - so why do people do this? Well, because these platforms give you one hammer, which is to put stuff in the blockchain and therefore everything gets dumped on this global ledger, even if it makes no sense. That is bad design."

The Corda team studied use cases in finance and found these involved extremely complex flow charts, and that there are maybe only one or two points where you change the global ledger; everything else is a complex set of negotiations leading up to it.

In other words, the vast majority of finance involves massive state machines moving through these flow charts. "These are just horrible for programmers to implement," said Hearn. "And the payment - that's the simple thing; that is one sub-component of a real application."

A good example of this is interest rate swaps, which have this whole lifecycle of their own: a flow chart that goes right down to the level of individual code operation and becomes enormous, he said. Sending money is just one part of it.

Hearn said doing state machine management rapidly becomes a big part of the complexity of writing the software around DLT. "It's not exciting or particularly sexy and a lot of people don't talk about it as a result, and a lot of startups don't focus on it because none of them know - but we do. The act of changing the ledger surrounded by workflows is very hard to program."

Within this context, the type of things developers need to think about include: "Sending messages, which need to be authenticated so they can't be forged. These need to be encrypted and this can slow things down, so you need to buffer them up; maybe after a while the buffer doesn't fit in memory so you have to put it on to disk; you need to work with slow humans who may or may not be around, and there maybe a team of them - you need to reach the right place; you need to scale and need to have testing for all of this, for every single transition; and all that before we got to check-pointing."

Corda automates a lot of that work, using a thing called a flow framework. A flow is defined as conversation between small sets of parties, which can have some useful applications, such sharing documents, perhaps some shared deal that parties both have an interest in and both need to sign to change the state of the ledger. "So these conversations get people to sign everything. If you study the Corda protocol, it's flows within flows within flows."

The structure of the Corda transaction is similar to that of a Bitcoin transaction. "This may be surprising because a lot of the enterprise ledgers that are out there - Fabric and Quorum and so on - they are all based on Ethereum. That was deliberate; not just because I happened to work on Bitcoin. It was a deliberate design decision to do that.

"So the state of the ledger is defined as a chain of transactions, but they are all consistent. If you could persuade every party in the network to give you everything they have in their database, all of their transactions, you would end up with a ledger that was totally consistent. There wouldn't be any overlaps or complex or things like that."

The Corda design eschews global broadcast to the network. Financial institutions work in terms of legal verified identities. They want to know where the data is going and they want to have these complex conversations between peers on the network. In fact it is a huge global ledger most of which cannot be seen. This design has pros and cons, said Hearn.

"In terms of cons, if you are pricing your payments and you need to verify, you need to audit the history of that payment, I may need to send you lot of data suddenly so you can check the history of the asset. So you get spiky traffic transfers, but financial institutions have good internet connections so that's okay - we are not designing for mobile phones."

He said the ledger has small entries called states, and smart contracts control the evolution of these states, stressing the original Nakomoto conception of a smart contract: a thumbs up or down to check the validity of a transaction.

If there is no global broadcast and no blocks, then how do you resolve double spends? Corda uses a so-called notary (no legal invocation), which is an abstraction of BFT consensus algorithms. "A notary is intended to be a kind of alliance of members on a network. It's a collection of peers on the network that work together to create a service that detects double spends.

"Corda is unique in that you can have more than one notary in the network at once. That means that as new techniques are developed you can introduce new notaries into the system providing new algorithms or new coalitions of parties.

"Then you can actually move stuff past the ledger from being controlled by one notary to another over time. This lets you explore different trade-offs and it makes the whole thing pluggable."

Hearn concluded with a bunch of other useful features, such as attaching files to transactions; PDFs and legal documents for example. He said one company R3 spoke with wants to attach trader surveillance compressed audio recordings deals to the transaction, which is then signed over and becomes a part of the ledger.

"There's also a library of flows to automate common business tasks and eventually documentation because people tell us they like this; we are fanatical about documentation.

"I mention some of this basic stuff because platforms like Ethereum invent their own programming languages and their own IDs and basically toss out 20 years of making great developer tools and reset it all from scratch.

"The tools we've got are fine, and they are open source. I don't know why you would do that."