A Cynic’s Approach to Distributed Ledger Technology – Part I

By Mikael Fevang.

The proliferation of cryptoassets (and blockchain technology in particular) over the last couple of years has become difficult to ignore. Tales of effortless wealth and promises of a paradigmatic transformation of finance have been plastered across the media and served as the topic of many dinner discussions. However, we seem to be past the peak of both public and media interest. Perhaps this coincides with the steady decline of crypto markets, or perhaps it is caused by crypto’s failure to deliver on its promises. Ten years have passed since the inception of the sphere’s hegemon – Bitcoin – and we have yet to feel the technology’s practical impact beyond the creation of effortless wealth and bottomless debt.

Some enthusiasts claim that the current market downturn is comparable to the burst of the dot-com bubble at the turn of the millennium. The dot-com bubble was caused by the market valuations of communication technologies far outpacing their fundamental value. However, contrary to other historical speculative bubbles, these technologies later matured and became the fundamental building block of today’s information society. This belief-by-analogy – that cryptoassets are merely immature and ahead of their time – feeds into the continued reluctance to sell off under-performing cryptoassets. To never sell assets – to “hodl” – has become the community’s unquestionable mantra.

There are, however, several fundamental issues with this belief in a rebound similar to what happened to the dot-com technologies.

Before we delve into what these issues are, I will give a quick and simplified recap of what distributed ledger technology (DLT) is. “Normal” centralised ledgers are used for a lot of different purposes, but for the sake of simplicity I will focus on how they are used for processing electronic payments (e.g., bank transfers, credit cards etc.). These ledgers track credit, debit, and the resulting balances between the transacting parties and are held exclusively by payment processors (e.g. banks). However, due to the risk of abuse, only the bank itself can edit the ledgers. You merely request a change every time you use your credit card – a request that the bank can accept or deny. For the vast majority of times such requests are made, they are accepted. However, when they are denied, the transaction cannot happen over the proposed channel. Commonly, requests are denied because of insufficient balance, but they can also be denied if the bank suspects foul play (e.g., fraud, money laundering, etc.) or, in controversial cases, when the bank does not like how you spend your money. This puts the ledger operator in a position of authority where they are able to (in theory) pick and choose which transactions they deem allowable. This implicates that in making any electronic transaction, one must rely on hidden middle parties to ratify the transaction and update the balances diligently and honestly. Trust therefore becomes the name of the game as one must trust the ledger operator to update it properly and not abuse their position of authority. Furthermore, the currencies used on these ledgers (called fiat) are subject to the indirect control of two other parties – states and central banks.

This all sets the stage for DLT and its sub-specimen blockchain, which, at least in its public form, seeks to rid value transactions of the necessity for centralised middle parties and meddling from the government. It seeks to do so by allowing anyone to hold a copy of the complete historical ledger, making transactions permanent and irremovable, and (in theory) allow anyone to make edits to the ledger. As such, the network is not fully owned by any single party. But how, you might ask, can abuse be prevented? What prevents a dishonest user from editing a fake transaction onto the ledger? This is where DLT gets very technical, so only a very simplified account of how it works on a public blockchain will be provided.

As with centralised ledgers, transactions on distributed ledgers need verification as well.

However, the verification is not done by a single centralised party. Instead, it is conducted through a consensus among several other parties (known as “nodes”) that decide whether to verify the transaction. Say that a proposed transaction is broadcast by a user onto the network. The transaction is picked up by these nodes, which propagate the transaction in a gossip-like manner and allow other nodes to inspect if for formal validity. Several parameters are considered at this stage, such as the veracity of the cryptographic public key signature of the transferor, the sufficiency of the balance to support the transaction, and that the transaction does not directly conflict with other transactions. Failing any of these, the transaction is discarded. But if the transaction is deemed formally valid by a node, it is added to the node’s list of valid, yet unconfirmed transactions.

At a given time interval, a node on the network is given the right to issue a “block” – which is its collection of valid transactions linked to the previous verified block. However, there is no authority deciding which node gets the right to do so. The right to issue a block is granted to the node first able to solve a cryptographic puzzle so difficult it borders to guesswork. In addition to the right to issue a block, the node is also rewarded with coins or tokens. Note, however, that the puzzle becomes easier to solve the more computational power the node possesses. An incentive to amass computational power thus emerges. This is called a “proof of work” protocol and is considered a good safety mechanism disincentivising the creation of fake blocks simply because of the investment needed to beat other benevolent nodes. Those that compete for solving the puzzle and being allowed to issue the next block are the so-called “miners”.

Additionally to the above, just like the transactions, the block is then spread like gossip among the nodes which compare the block to their own list of valid and unconfirmed transactions. If found to be similar, the node accepts the block as the next in the blockchain. When a majority of nodes have done the same, the transactions in the block are confirmed and effectuated, and the process starts anew with the next block.

However, do not be fooled and think this is a fool-proof system. There is nothing that prevents an entity from getting control over a majority of the nodes on a network and instruct them to verify a rogue block with invalid transactions – which is known as a “sybil attack”. This has happened to both Bitcoin and Ethereum in the past. This and more will be explored in Part II.

[Part two can be found here.]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s