How Cornell Researchers Are Quietly Reinventing Private Blockchains

Researchers might seem like an unlikely group to probe the private blockchain sphere, where the major players are a mix of banks and tech behemoths. But at least a few Cornell University researchers from the Institute for CryptoCurrencies & Contracts have turned some of their attention toward permissioned implementations in an effort to improve them.

Rather than an open system like bitcoin that anyone can join, private blockchains rely on a set number of known participants to verify transactions and bundle them into so-called 'blocks'.

Current implementations, though, leave something to be desired, the researchers argue.

Simplicity is an important, if dull sounding, piece that Cornell University principal research scientist Robbert van Renesse stressed many private blockchain implementations are missing.

He told CoinDesk:

"Being able to scrutinize technology is the cornerstone of scientific discovery, I think. That peers can understand what’s going on is important. It doesn’t have to be everybody, but if it’s just a handful of people there might be some reason for concern."

That may well be the case for current private blockchain implementations, according to Renesse, as the distributed algorithms that private blockchains rely on are rather complex.

At least, that's the claim.

Scrutable blockchains

Private blockchains generally depend on technologies that predate bitcoin, such as practical byzantine fault tolerance (PBFT), to come to agreement about the history of transactions. There are many different ways for private blockchains to reach agreement and, if research from Cornell is of any indication, certain ways of doing so have been under-explored.

Renesse argued that the Linux Foundation-backed Hyperledger's flagship implementation, Fabric, one of the best-known permissioned blockchain protocols, is an example of one that's too complex.

"The code for the protocol consists of tens of thousands of lines of code. Analysis of the correctness properties is 40 or 60 pages," Renesse said.

The result? Only a few people understand how it works.

Renesse has been researching so-called Byzantine Fault Tolerance (BFT) for decades. Although it sounds befuddling to those not immersed in the science, nodes in a network are notoriously bad at working together. They're clumsy; some fail, while others stop spontaneously.

Put simply, there are a range of problems, and the study of BFT, in particular, deals with some of the more irregular ones.

Now, Renesse is building on a protocol, Bosco, that he developed in 2008.

Originally, he said, he didn't think of it as anything more than a "toy protocol", but, now that private blockchains are gaining ground – and the entire field of distributed systems is taking off as a result – Renesse is researching how it could be used in a permissioned setting.

"I had a look at Bosco and asked, 'How impractical is this exactly?'," he said.

In contrast to something like Fabric, he argued, the algorithm is much simpler – it takes two pages to outline its security guarantees and it can be implemented in 1,000 lines of code.

"This is a protocol that I can explain to high schoolers," he said. "I'm pretty confident that after staring at it for a few days they can understand it inside and out."

Seeking simplicity

IC3 co-director Elaine Shi is working on a similar project.

"I’m a big believer in simplicity," she said, making the same point as Renesse, unprompted and during a separate conversation. She's working on another project, dubbed 'Sleepy', which, like other permissioned implementations, ditches bitcoin's proof-of-work system, which is used to establish the validity of transaction blocks.

It is "extremely simple," she said, adding that it has "strong robustness properties," meaning that the nodes don't fail so easily. Further, it doesn't require global coordination, where every node needs to agree on an action.

"For a consortium, you want to use something that is more manageable," she said, pointing out that other private blockchains, such as Chain Core, don't have this property.

It's a process that they're rolling out step by step. Shi mentioned that she and PhD student Phil Daian have been working with Parity, an ethereum client written in Rust. Parity can support a variety of modes of consensus (including their own private protocol as proof of authority (PoA)). So, the Cornell team is testing how Sleepy works in this setting.

Shi used PoA as a guinea pig for comparisons to Sleepy, arguing that Sleepy has better security guarantees, which were spelled out in a white paper released last fall.

"Proof of authority doesn’t make sense when there’s something clearly better," she said.

Step by step

However, where might these tools might be rolled out? It's a question that's been long asked of enterprise blockchains in general.

For Sleepy, Shi and the Cornell team are starting with collaboration with Parity, but the aim is to eventually incorporate it into other frameworks as well.

Renesse's implementation might not be far enough along for that yet.

"I implemented [Bosco] on a plane ride from Beijing to Newark," he said, adding that the next step is to do a more "proper" evaluation.

There could be a couple drawbacks to the system, however.

Bosco perhaps could run into more node crashes, where nodes stop responding to requests and fail to participate. PBFT guarantees data consistency as long as less than one third of nodes are faulty, while Bosco has a lower threshold of one fifth of the nodes.

Renesse cited another problem that affects all private blockchain systems: that a "malicious bank" could bring the entire system to a halt by flooding it with spam.

He doesn't consider this a potentially major a problem, though, because participants can simply agree to throw out the bad actor. Despite the drawbacks, Renesse thinks Bosco could give banks and institutions another option.

He concluded:

"Banks are most likely to run a protocol and accept the occasional mistake or occasional disgruntled employee that tries to do something bad."

Tech workers image via Shutterstock