Category: Research

PhD research

2014-current: PhD student (part-time) at the Radboud university

Promotor: Bart Jacobs

Supervisor: Erik Poll

Papers

Articles

Students co-supervised (needs to be updated)

Teaching

<lectures provided>

Journals

<reviewed papers>

An extended version of our drivers paper has been accepted at Concurrency and Computation: Practice and Experience, Wiley, 2020.

In this extended version we evaluate three more use cases. These analysis suggests that, similar to our previous paper, blockchain may not be the best technological choice. As such, choosing blockchain as a technology in these use cases seems like an irrational choice.

Our drivers may explain the rationality behind this seemingly irrational choice.

In a recent study that I did on blockchain use cases, I found that most use cases focus on addressing a particular use case problem with blockchain. However, what consistently was lacking was a discussion of potential threats that are introduced when applying blockchain. From an empirical perspective, I also find that in practice blockchain advocates tend to focus on addressing the use case problem with blockchain, and the threats of blockchain are usually not mentioned.

Personally, I’m a huge fan of blockchain and distributed ledger technology. However, I believe these technologies should be applied where necessary; these technologies should not be applied where possible. Applying these technologies where it could be applied may introduce unnecessary threats.

Although several good surveys exist on the security and privacy threats of blockchain, see for example the work by Li et al. and Conti et al. , there is no survey of organizational risks.

In this white paper we survey potential organizational threats for use cases that adopt blockchain. We grouped the 22 threats in two categories, 1. Threats caused by human behavior, and 2. Threats caused by blockchain. Our survey complements the existing work on security and privacy threats of blockchain. These surveys can be used for the identification of blockchain risks in use case that (plan to) adopt blockchain.

Any feedback is again welcome either through Linkedin or email.

I’m happy because a third paper has been accepted for my PhD. A fourth is under review and two more are currently being written.

The accepted paper (my own version can be found here which is an improved version of this paper) is on Assessing Interoperability Solutions for Distributed Ledgers and will be published in Elsevier’s Journal Pervasive and Mobile Computing.

Background

Although distributed ledgers gradually become and accepted technology, there currently are some challenges that need to be solved. As nearly all current ledgers are siloed, one of those challenges is interoperability between ledgers. Interoperability, from a broad perspective, allows two different, separate ledgers to work with each other.

The need for interoperability is shown by the many initiatives that aim to achieve interoperability between distributed ledgers. Indeed, several solutions have been proposed and an initial classification of these solutions was proposed by Vitalik Buterin here.

The problem

However, it is not always clear which properties these solutions have, nor which particular issues exist in such solutions. This makes it hard to decide which solution to choose. Even more, some consequences of interoperability may be an argument for not interoperating with other ledgers.

Our work

In this (extended) paper we assess interoperability solutions for distributed ledgers. We propose 12 key properties with which we can distinguish between interoperability solutions in three ways.

First, we can distinguish between three kinds of interoperability solutions, being notary schemes, relay schemes, and hash-locking schemes. Second, these properties allow us to distinguish between subcategories of these kinds of solutions. And third, we can distinguish between generic and specific issues of these kinds of solutions.

Furthermore, by using these properties, we describe and analyze five real world solutions, being Polkadot, Cosmos, BTCRelay, Dogethereum and hashlocking schemes in general.

We discuss in detail the zone-spend attack. This attacks considers two interoperating ledgers, and under the assumption that one ledger uses a probabilistic consensus algorithm, we conclude that there exist a risk of creating an immutable, invalid state between the two ledgers, even if one of the ledgers uses a deterministic consensus algorithm. Note that no interoperability solution can mitigate this risk.

Finally we evaluate these 5 solutions and discuss several interoperability issues. We conclude that although the three kinds of solutions offer different functionalities, there exists an overlap of issues between these kinds of solutions. This is useful for deciding which interoperability solution to choose, and becoming aware of the current issues that come with each solution.

Our paper can be found here and feedback is, of course, welcome.

Blockchain may not always be the best suitable technology for a particular problem. However, we observe that blockchain is applied in many initiatives where alternative technologies fit better. Here, adoption of blockchain appears to be an irrational choice.

If blockchain is indeed not the best technical fit in these initiatives, then what drives blockchain adoption?

In August 2018, I presented our work at the Sixth Workshop on Large Scale Distributed Virtual Environments (LSDVE 2018). We propose both technical as well as non-technical blockchain adoption drivers. In particular, these non-technical driver may explain the rationality behind the seemingly irrational choices.

Our paper can be found here: drivers-blockchain-adoption v1.0

Here’s proof of me presenting our work (and hopefully entertaining the crowd with shadow puppets):

Credits: Oliver Stengele

For the full story on the decision scheme below, see my LinkedIn page

Our paper (my personal copy): blockchain alternative