Dr Gideon Greenspan: Blockchain design is academic work and shouldn't just be decided by banks

Dr Gideon Greenspan, the founder of Coin Sciences and MultiChain, believes the fundamentals of blockchain design constitute "academic work" and is probably not something that should be just decided by banks.

Greenspan told IBTimes: "First of all you have got fundamental architectural questions. There's different ways of doing blockchains at the most fundamental level, kind of how do you express the rules about whether a transaction is valid or not.

"I think that's probably not something that should be just decided by the banks between them, but that's almost like a piece of academic work that needs to be developed."

Greenspan compared this to work that was done decades ago in laying the theoretical foundations for the relational databases that run the world today.

He added: "I wouldn't say that either banks or startups were intrinsically qualified or otherwise to work out these fundamentals.

"Rather, I think this is work that should be done by experienced computer scientists and system architects, wherever they might happen to be.

"The hiring of Richard Gendal Brown by R3 is I think a recognition of this fact, and a very positive step," he said.

The next level in this architectural model concerns the protocol that would be used for the nodes in the network to communicate with each other, which also needs to be standardised.

For instance, MultiChain uses the Bitcoin protocol with some small changes, and also the Ethereum protocol.

The top level is like the application layer: the appropriate logic for financial transactions for example.

Greenspan explained that between Bitcoin logic at one end of a spectrum and Ethereum's general purpose Turing complete computation at the other, is a continuum.

"The architecture defines where in that continuum your blockchain is going to sit and wherever you choose on that continuum, you have to then actually write the logic.

"That's something which is very specific to each application. Specific financial applications such as asset transfers or exchange transactions, or corporate loan syndication - each of these things will require its own logic. That also is something that is going to have to be standardised."

He said that if the communications protocol could be the same for many different applications, that's going to make for a much more efficient kind of system with much more code in common.

Greenspan describes Bitcoin as using a "transaction constraint" model to ensure money isn't created out of thin air. He explained that each bitcoin transaction is a database transaction which deletes a bunch of rows on a database, and then creates a bunch of rows in their place.

One of the important constraints for a bitcoin transaction is to ensure the total amount of bitcoin in the rows created is not more than there was in the rows deleted.

So Bitcoin cannot be created out of thin air, unless it's a coinbase transaction which the miners embed which is where they get their reward.

Another model is the smart contracts or Ethereum model, which could be described as stored procedures in more traditional database terminology.

In this model every operation that modifies a database is performed by a piece of code that was written at the time that database was created, so nobody is able to modify the database directly.

All they can do is send messages or make calls to this piece of code and that code performs the modification. Therefore any rules about what's permitted and not permitted in terms of modifying the database are embedded in that piece of code.

It's another way to enforce restrictions on what can be written to a database, which has also been proven to work.

These two models have strengths and weaknesses - there are things you can do with one, you can't do with the other, noted Greenspan.

"There are models of scalability that work with one and not with the other. So the question we are grappling with right now, as we design our next generation product is: what is the right model for a shared database to get as many of the features that we want without sacrificing performance or scalability?

"To put it in a nutshell, the Ethereum model of smart contracts or stored procedures can do anything and a transaction constraint model cannot.

"On the other hand, the transaction constraint model enables much, much greater concurrency and parallelism than the smart contract model or the stored procedure model.

Referring to the Bitcoin-like, transaction constraint model he said: "Every transaction only modifies locally a very small amount of data and the transaction explicitly contains information on which piece of data it modifies, therefore you can run many, many of these transactions in parallel and can know that they are not going to interfere with each other.

"In a stored procedure model you don't know that. So when you make a call to a stored procedure it can read anything on a database, and it can write anything on a database, so you actually have to do them one at a time, one after the next. So there's pluses and minuses in each."

Indeed, the Ethereum yellow paper mentions at the end there are scalability issues, because there is this notion of having a global database state that is modified by each transaction.

"It's fine for experimentation and it has a great amount of flexibility. But when you start trying to reach the amount of throughput that you have in relational databases today it's probably not going to work."

"Our challenge is to design an enterprise blockchain platform and we have got some specific ideas about how that should look.

"I'm not going to go into too much detail at this point because there is a big scrum on in the world to get there.

"But we have a specific thesis about how that should look from a product perspective."