Comparing Distributed Ledgers by Game of Thrones use case — final comparison
By: Paul Plessing
Tags: Tech, Distributed Ledgers, Blockchain, Comparison, Review

Yes we did it!

We reviewed 8 distributed ledger technologies (DLT’s), and implemented with each DLT a game of thrones use case.

Initial idea

The idea was to find out how easy it is to get a simple use case up and running on various DLT’s. We wanted to implement the same use case in every DLT. Something a little bit more complex than just a simple ‘Hello World!’, so we have to tweak sample code according to our requirements. The requirements are based on game of thrones, because it should be possible to create alliances, like the alliance ‘Khaleesi’ or ‘Cercei’, and to create and add families (‘Stark’, ‘Lannister’) to the alliances. Hence, every alliance can have multiple families, and those families can be transferred between alliances in the case that they change sides. That way we had to understand the basic concepts of how to build applications on the particular DLT.

About the comparison criterias

As most of the reviewed technologies are rather young, there isn’t a whole

lot of knowledge about them to find on the internet. What was key to an easy and straight forward implementation, was the documentation and tutorials for the inspected DLT. However, often the documentation wasn’t complete or something didn’t work on our computers as described in the provided resources. In that case, we were very thankful for the chats of the DLT’s. We were positively surprised that every DLT had a company driven chat on telegram, discord, gitter or something similar where our questions were answered directly from people responsible for the projects.

Furthermore, no matter how good a documentation or a chat-answer is, the ease of the setup was directly tied to the DLT itself. In the case of simple API-calls, the implementation was much easier than compared to having to set up a node or to learn a new DLT-specific language.

In the following, we compared and ranked our inspected DLT’s by 5 metrics:

Novelty of the concept

Complexity of its theory

Complexity of the setup

Quality of the documentation

Responsiveness in chats

We also indicated whether the technology is a private (only permissioned users can join) or public (everyone can join) network, and whether there’s the possibility of storing sensible data without disclosing it to the public or encrypting it.

Please note that we have a strong blockchain background, and already worked with DLT’s like Ethereum. Therefore, big blockchain’s like Bitcoin and Ethereum are state-of-the-art DLT’s for us. When we talk about novelty of a concept, we indicate how advanced the technology behind a given DLT is compared to Ethereum.

We don’t intend to say that Proof-of-Work (PoW) or Proof-of-Stake (PoS) blockchain is not a novel technology, of course it is. But in our comparison we put Ethereum and similar DLT’s at the low end of our novelty ranking.

The same goes for how complex the theory is. It means how hard it was to wrap our head around the concept. Similar to the novelty factor, we already knew about PoW and PoS blockchains, therefore ranking these theories as not very complex.

‘Complexity of setup’ marks how difficult we found it to implement our use case. Did we have a clear path to stroll over, or did we have to use our machete to cut through a jungle? Ethereum was hard to rank, because we already had knowledge about it.

The documentation and official tutorial quality manifests itself in the amount of resources that were provided to the developers, as well as how easy it was to get their sample code up and running. In rare cases that there were also external unofficial tutorials about the DLT, we said it also belongs to the documentation. Of course, Ethereum is by far the most documented DLT, without even counting in the countless tutorials and stackexchange threads.

As already mentioned, we were very pleased about the chats provided by the companies of the DLT’s. We asked questions in chats of every DLT except Ethereum, because for Ethereum there was already enough material to find on the net. All our questions were answered or acknowledged within a day, for some complicated theoretical answers we had to wait 2 days at maximum. The differences in our ranking stems from the speed of answers, and how useful they were to our stated problem. 0bsNetwork for example answered within a minute (!) with a solution to our issue, while Dragonchain also answered shortly, unfortunately their answers regarding the setup didn’t help us (but answers about theory were profound).

Chats of the DLT’s (the chats that we used, some DLT’s have several)

At this point again special thanks to:

@Spl3n in the ICON chat

@bierlingm and @pauldaoust in the Holochain chat

@ttmc in the BigchainDB chat

@Craig Drabik, @Supremax67 and @Tim McHale in the Hashgraph chat

@JeffreyDutch and @j0j0r0 in the Dragonchain chat

@skVie and @JustJamesDev in the 0bsNetwork chat

Comparison table

Finally, we come to the actual comparison table!

Because it’s hard to measure things like complexity of a setup, we decided to rank the DLT’s by the Fibonacci numbers 1, 2, 3, 5, 8, 13, 21, 34, 55, and 89.

The use of Fibonacci numbers in Scrum to estimate tasks seemed perfectly adaptle for this comparison. That way, it’s easier to differentiate between DLT’s, because it’s easier to decide whether it’s an 8 or a 13 in a specific metric, instead of deciding between a 8 and 9. So the DLT that has the lowest score in a metric always starts with 1, and DLT’s with increasingly higher score are ranked with higher Fibonacci numbers.

The increase of a metric also means that this specific DLT has more of this metric, e.g. a high rank in ‘complexity of setup’ indicates that the setup needed to use this DLT is very complex (bad), while a high rank in ‘quality of documentation’ shows that there’s a good documentation (good).

Please note, if there is a question mark as a rank, it means that we couldn’t evaluate this metric with that DLT because there was no chat we used or we couldn’t get our use case to work.

Lastly, the metric ‘type’ indicates whether a network of the DLT can be joined publicly by anyone, or if it’s private i.e. the network operator decides which identities can join. This concerns users as well as miners, and any additional roles in specific DLT’s. ‘Hybrid’ means that the DLT consists of parts that are public and parts that are private. ‘Both’ indicates that there is a version for both a private as well as a public network.

Here it is, all distributed ledger technologies compared to each other: