I’ve recently spent a lot of time attempting to qualify and quantify to factors that make a blockchain, and more specifically a public permissionless blockchain, an appropriate architecture for a particular use-case.
Recently the loudest use-case being touted as to how public blockchains will revolutionise the world is through securities tokens, or regulated ICOs. Apparently having seen the success of unregulated ICOs (by which I assume people mean the roughly $10 billion raised, according to icodata.io), interests have turned to how to keep from getting fined by the SEC, FCA, AMF, BaFIN, JFSA, etc… Having spent a lot of time listening to, reading about, and being pitched the benefits of distributed ledger technology and cryptocurrencies I think that some of these factors have started to crystallise in my mind. But before setting sail on the USS ICO, it might be worthwhile to take a look at what these things actually cost to run and use.
As a caveat though, given the nascent stake of these technologies and economically incentivised networks I reserve the right to alter my opinion at a future state in time as facts become clearer and data proves or disproves my view (you know, like a reasonable person).
Last year I published a post on classifying DLT and blockchains based on two factors, the degree to which they shared information and the functionality at the ledger level. More than one year on, despite pivots in projects and advancements in the underlying technology, I still believe that this is a helpful framework. At the risk of being accused of unashamed self-promotion, my conclusion from this is what I need to touch-upon in much greater depth:
“So with that I will finish up by saying, like many technologies in the world there are different varieties. Some are more suitable in certain circumstances than others. While some may deviate (greatly) from their ancestors, that does not make them any less useful, though perhaps they may not be useful in solving the problem that the original was designed to solve. I for one wouldn’t spend my time trying to use Hyperledger fabric v1.0 to build a “purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution”. But by the same token, I wouldn’t envisage placing my medical history or deed to my house on Bitcoin’s blockchain either.”
Given this as a jumping off point, it is worth describing a few basic assumptions that I make which have an overarching influence on how I layout my thinking in the rest of this post.
- Distributed Ledgers, Blockchains, and Cryptocurrencies are still experiments;
- Decentralisation is relatively expensive (because it relies on redundancy of data and computing, and also because the latency of sending messages over large networks does not benefit from a phenoma similar to Moore’s Law), and;
- Economics will eventually catch-up with the hype and inflated expectations around these technologies.
It is also helpful to agree on a few definitions (which I cover in more depth in the Taxonomy post), and admittedly are still imperfect.
- Distributed Ledger — A record of ownership, which multiple parties (entities) use through a common peer-to-peer network, and is stored across multiple locations;
- Distributed Ledger Technology (DLT) — The set of protocols that defines the above;
- Blockchains — A subset of Distributed Ledgers in which all parties are privy to all transactions which are confirmed on the ledger, and in which transactions are grouped and stored in blocks that are linked to one another in sequential order,
- Public Blockchains — A blockchain that does not contain formalised requirements which prohibit any potential participant from adding/creating blocks, or accessing the data and peer-to-peer network of its blockchain (i.e. permissionless). Note: A participant must still meet the requirements of the network consensus rules in order to add (mine/mint) a block, which may be practically beyond the capabilities of many potential participants,
- Cryptocurrency — A native unit of account within a public blockchain, which is used to incentivise the running and security of its blockchain, and;
- Tokens — Non native assets or coins held within a public blockchain, which cannot be used to compensate entities who run and secure the blockchain (i.e. ICO tokens).
Now that we’ve glossed over the contentious bits, let me state the two hypotheses that I will explore in this post:
- The cost to maintain and secure a blockchain has a direct, and positive correlation with the ability of a network to secure against real or perceived censorship, and;
- Economically rational uses for public blockchain technology will be confined to instances where the real or perceived threat of censorship by external actors justifies the transactional cost required to maintain and secure a blockchain.
To really boil this down, I want to test whether public blockchains are useful in situations where there is not the risk of a transaction being muted or deleted by a powerful third party (e.g., a government). Said even more simply, are public blockchains useful when you aren’t breaking the law (pertinent to our discussion - the Securities Act of 1933)?
At this point I’ve probably triggered a few readers who vehemently reject such a narrative and cite statistics that show that actual criminal usage involving cryptocurrencies is really rather low, or that state that given the completely transparent nature of a blockchain the traceability of such a transaction makes it a poor choice for crime (Such analysis does, however, miss external issues including tax evasion/money laundering which do not necessarily result in on chain transactions). I’m sure that these people are also switching off, because I don’t “get it”, for those still with me I implore you to keep going.
Now don’t get me wrong, I think that Bitcoin, Ethereum and other cryptocurrencies, more generally, are great. I’m also not pious or naive enough to argue that all laws are just and that breaking the law is never warranted, cryptocurrency usage in Venzuela is often cited as an excellent example where the laws enforced by a totalitarian regime harm the local population and the use of Bitcoin has allowed individuals to trade with neighbouring countries to buy food. For people pointing this out, I emphatically agree, and will attempt to prove or disprove the economic arguments behind this exact point (also a great time to remind people to re-read assumption C about hype which in turn leads to easy money). It is also worth differentiating between using a cryptocurrency through the public blockchain channel (the focus of this post) and using it in an immobilised or semi-immobilised manner (e.g., second layer scaling solutions, custodial exchanges) — which I will look at in a follow-on post (Please don’t comment about Lightning Network/Plasma. I know, I know, but that isn’t covered today).
To attempt to answer my questions, in a somewhat coherent manner, I first attempt to quantify the relationship between the cost of using a public blockchain and its ability to fend off attack.
Before delving into this point however, a bit of background on the question is helpful. The original, and at the time of writing, most well known public blockchain is that used by Bitcoin. The blockchain was originally described, albeit not in name, in the Bitcoin Whitepaper as a timestamp server where “each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.” Batching transactions into blocks, however was not the novelty that Bitcoin brought into existence, the subsequent section in the Whitepaper described a method to introduce a real world costs into changing previous transactions, Satoshi Nakamoto termed this “Proof-of-Work”.
Figure 1: Extract from Bitcoin Whitepaper describing the blockchain and Proof-of-Work mechanism serving Bitcoin. https://bitcoin.org/bitcoin.pdf
By combining the layering of transactions into grouped and timestamped blocks that refer to all previous blocks then requiring the satisfaction of a valid “proof-of-work” a successful miner was rewarded with the ability to:
a) create new native units of account in the system, and
b) receive all transactions fees in the latest block.
Another factor discussed in the Whitepaper was the necessity to account for increased capabilities of miners on aggregate to produce a valid “proof-of-work”, as well as variable interest in doing so. Put very simply, one’s ability to successfully produce a valid “proof-of-work” is a function of one’s relative contribution, in terms of hardware CAPEX and electricity burned (in kWh), amongst a global, similarly incentivised competitors. Read, everyone is constantly trying to outspend everyone else in terms of hardware and electricity to earn cryptocurrency. This introduced three important points which are relevant to the rest of this point:
- native units of account are necessary to ensure that validators are properly incentivised which allows us to have an assumption of “immutability” in such systems,
- “inflation” is an important variable in properly incentivising these systems, and
- The “assumption of immutability” is probabilistic, and is not fixed over time.
Let’s take a quick break here to visit the notion of a DLT or a blockchain without a token. Whilst some disagree with me here, I view these not only as a valid design choice, but very likely a system which is well suited for a variety of uses and environmental challenges. Though many have described these as sharing the property of “immutability” in absolute terms (which as we pointed is not true even for public blockchains with a native unit of account), this should not be considered as a characteristic of DLT or permissioned blockchains, even if in probabilistic terms it may be the case.
Well then, where do these permissioned systems excel? As Richard Gendal Brown and the team working on Corda at R3 point out, many technological issues between businesses are the result of a lack of a shared perception between two or more independent parties. The current (non-DLT) solution to this problem is via reconciliation, or by introducing a third party arbiter. These can add additional costs, and introduce new risks (including the credit risk of the arbiter). Even with the adoption of DLT solutions on this problem, there will still be instances where the traditional way of doing things is the most efficient (note to self, that’s another post that needs writing).
Coming back to hypothesis 1: “the cost to maintain and secure a blockchain has a direct, and positive correlation with the ability of a network to secure against real or perceived censorship”, let’s turn our attention towards the cost of maintaining a blockchain.
As I stated previously there are two principal methods to compensate the maintaining of a public blockchain, inflating the base of native cryptocurrency through a process of seigniorage, and levying transactions fees. In Bitcoin and Ethereum, as well as all other proof-of-work blockchains, both these forms of compensation exist, inflation in the form of block rewards, and transaction fees charged to include a transaction in a block.
Transaction fees are the simpler fee to understand, so let’s look at an example Bob has 50 examplecoin (EXC) wants to send Alice 10 EXC. To ensure that the transaction gets mined into a block, Bob creates a new transaction from his account containing two transactions, the first for 10 EXC paid to Alice’s address, and the second for 39.9999 EXC back to his own account. The remaining .0001 EXC is thus available to the next successful miner who confirms this transaction.
Several minutes after Bob submits the transaction a miner (Carlos) provides a valid proof-of-work to the network which includes Bob’s payment to Alice. Alice now has 10 EXC available to spend, Bob has 39.9999 EXC and Carlos has received a 0.0001 EXC fee. All is good in the world and everyone leaves happy understanding exactly what was charged and to whom.
The second type is slightly more nebulous, going back to our example.
Let’s assume that the 50 EXC that Bob originally held before sending 10 to Alice, and paying 0.0001 to Carlos in fees were the only EXC that existed. Which means before the transaction Bob had 100% of the EXC in existence, and after Bob had 79.9998%, Alice had 20% and Carlos had 0.0002% of all EXC in existence. Now, let’s assume that as a reward for mining a successful block, in addition to all transaction fees for transactions included in that block, Alice, Bob, and Carlos all agree that the miner should be able to create 5 EXC which will become available to that successful miner.
So now in our example when Bob pays Alice 10 EXC, Carlos receives 0.0001 EXC in fees + 5 EXC, meaning that the total number of EXC in existence is now 55 (10% inflation). I acknowledge that this isn’t “inflation” in the macroeconomic sense, but simply an increase in the monetary base, but this is widely understood in the crypto-world (cryptocurrency, not cryptography). This means that Bob now has 72.7271%, Alice has 18.1818% and Carlos has 9.0911% of all EXC in existence. Clearly the introduction of new EXC into the system, not only rebalances the distribution of who owns EXC, but effectively ‘charges’ larger holders (i.e. Bob) proportionally more in doing this. If we assume that the value of all the EXC was $50 before the block was mined (1 EXC = 1 USD), ceteris paribus, after the block was mined 1 EXC = 0.9091. This means that Bob effective fee for the transaction was (1–0.9091)*39.9999 = $3.6364 for the transaction and from Alice (1–0.9091)*10 = $0.9091, for an all in cost of $4.5454 (which is, by no coincidence, the value of Carlos’ holdings). Again, noting here, I am not attempting to say whether this is good or bad, it just “is”.
Moving swiftly along, we can see look at these costs in Bitcoin (BTC) and Ethereum (ETH) on a daily basis broken down into these two categories, first in terms of USD:
Sources: Blockchain.info (Bitcoin, since 2010–11–28); Etherscan.io (Ethereum)
A quick note, while the cost per transaction (CPT) is interesting, it is susceptible to distortion due to the number of transactions processed in aggregate over a given time frame, as well as differences between the functioning of networks (10 minute blocks in BTC, ~15 second blocks in ETH), therefore we will primarily look at transactions on a daily basis.
Notice two things, in general there is a positive correlation between increased Miner Rewards (inflation) and Transaction fees; and though Bitcoin and Ethereum are very different and the scale of costs vary (particularly on transaction fees) the distribution is strikingly similar and likely nonlinear (it curves up).
Now, the more astute readers amongst you will point out that, because these are denoted in “dirty filthy statist dollars” it is quite normal that both rise in unison. While that’s not the point (yet), but don’t worry, I’ve got you bro. If we remove the effect of not only the USD value, but also denote the costs in terms of a percentage of the total monetary base (i.e. 5 EXC over 50 EXC = 10% inflation) we can see a few familiar trends:
Sources: Blockchain.info (Bitcoin, since 2010–11–28); Etherscan.io (Ethereum)
First is that when inflation is high (dots to the right), transaction fees are rarely high (low, left dots on the first graph). The next thing that jumps out is that as the inflation rate decreases towards zero, the aggregate transaction fees are higher more often and are rarely zero. Some have explained the high fees on Bitcoin (BTC) in terms of periods of increased activity, and possibly done with intent, though a very similar trends has occurred in Ethereum (ETH). It is worth noting that ETH shows peak slightly to the right of BTC’s peak (which then dropped back down), this coincided with several particular events in the Ethereum network in late 2017/early 2018, remember CryptoKitties? One large difference between the ETH and BTC distributions is the presence of groupings around certain zones, I’ve highlighted them in the next chart:
Sources: Blockchain.info (Bitcoin, since 2010–11–28)
The above chart, again, shows the distribution of Bitcoin inflation, and transaction fees measured over the number of Bitcoin in existence on that day. The colours on the chart denote the block reward (Miner Reward) in effect on that day. The red dots represent approximately the first four years of Bitcoin’s existence when each block mined allowed the successful miner to create 50 BTC. On 28 November 2012, the number of BTC that each miner was allowed to create upon successful completion of the proof-of-work reduced to 25 BTC, this is represented by all the green dots. The second halving, where the block reward was further reduced to 12.5 BTC, where it currently stands at the time of writing, came into effect in July 2016 and is represented by all the grey dots. As you can see, in addition to a gradual move left with every new block created in the Bitcoin network where the inflation rate is gradually reduced by virtue of each single BTC having less of an impact on the other BTC already mined, there large gaps at each halving. The effect of this halving means that should BTC continue at the rate it is going in approximately the year 2140 there will be no block rewards, and all compensation for mining will come from transaction fees.
Enter Bitcoin Cash (BCH)
Before jumping into the totally, not at all emotive issue of Bitcoin Cash and scaling, it is probably worth reminding readers about the Bitcoin blocksize debate.
In 2014 discussion started about potential limitations to the growth of the number of transactions that could be processed by the Bitcoin network, calls grew louder in 2015 and 2016 about differing approaches, ultimately culminating in two actions taking place in 2017.
The first (chronologically) was a hard fork of the Bitcoin network, which created the network known as Bitcoin Cash (commonly referred to by its primary ticker symbol “BCH”). The second to become live on the Bitcoin (BTC) network was a modification known as Segregated Witness (or “Segwit”).
So why did this happen?
Good question, returning to our time machine, and going way back to the heady early days of Bitcoin: 2010.
The first iterations of the Bitcoin codebase allowed the blocks (those grouped transactions that are processed every 10 minutes or so) to be of unlimited size, in 2010 due to a number of changes to the way that people supported and used Bitcoin it was decided that this presented a risk. The result was limiting the size of the blocks that could be produced by any miner and presented back to all other users, this was set at 1 mb. At first this wasn’t too much of an issue as the number of transactions on Bitcoin was extremely low, then in 2013 with the price surpassing $1,000 the number of transactions handled by the Bitcoin network grew more quickly.
Discussions in 2015 highlighted the concern that at some point in the future the 1 MB limit could present a bottleneck to the transactions confirmed by the network. Sparing you the gory details, two approaches emerged:
1) raise the blocksize from 1 mb, and
2) decrease the size (in bytes) of an average transaction.
While I am not taking a view on which approach is or is not superior in this post (if you’re interested I suggest that you do your own research on these approaches), one of the underlying reasons for supporting either approach appeared to stem from a view on what Bitcoin is best suited to do.
Massively glossing over the detail, those supporting the first approach (raising the blocksize limit) generally view Bitcoin as an everyday payments system, whereas those backing the second approach see Bitcoin more as a store of value (“digital gold” is often cited as an analogy). In 2017 it was clear that discussions had reached an impasse and that concrete action was the only way forward. Having most certainly left out a load of nuance, which is likely to result in me getting hate mail from supporters of either approach (love you XOXOXO), let’s talk about the results. On 1 August 2018, Bitcoin Cash was born, mining block 478,559 which was nearly 2 mb in size. BCH supporters cheered their successful steps forward and BCH gradually gained in hashing power (more miners), and price (in USD).
Coming back to the purpose of this post, there are a few things to remember which have relevance to this post:
a) The ‘fundamentals’ of the money supply in BCH exactly mirror those of BTC (i.e. 12.5 every ~10 minutes currently, 21m BCH in ~2140), and
b) the goal of BCH was to reduce the cost of processing/confirming transactions.
For those still following from before the history lesson we are looking at the cost of running the network, which can be broken down into inflationary cost and transaction fees. With BCH working with the same ‘monetary policy’ as BTC, meaning inflation should be the same (n.b. this was not necessarily the case immediately after the fork due to a mechanism designed to ensure that the BCH network could adjust the difficulty more quickly than was the case before the fork), the transaction fees come into play. BCH quickly demonstrated that the average cost per transaction was lower than a corresponding transaction in BTC as a percentage of the number of their base currency already mined. A reminder again, while this is certainly interesting and merits further study, we are curious about the effects on an aggregate basis on a daily timeframe. If we map the same graph seen earlier comparing BTC and ETH, to now include BCH we see a strikingly familiar distribution pattern but at a lower daily aggregate fee level:
Sources: Blockchain.info (Bitcoin, since 2010–11–28); Blockchair.com (Bitcoin Cash, since 2017–08–01; Etherscan.io (Ethereum)
Also of note is the broader range present in the BCH distribution, which is due to the difficulty mechanism adjustments which resulted in blocks being miner faster or slower until this was upgraded in November 2017.
From all three networks, we see an emerging pattern that suggests that lower levels of inflation in the monetary base tend to correlate with higher levels of fees being required to maintain the network. We can further assert that this relationship may be nonlinear, where periods with lowering inflation experience aggregate transaction fee increases which occur at a rate of change which increases as inflation rates decrease.
Speculating on the reasons behind this could include an uncertainty of transactions fees paid versus certainty of inflation payments for a given amount of input (another post for another day). Logic would dictate that this pattern has an upper bound, in that as inflation rates approach zero, fees cannot consume more than 100% of the transactions moved across a blockchain, which themselves are also unlikely to be more than a few percentage of the total monetary base in any reasonably short time frame (that’s another post).
We should also note, and in particular in the case of BCH, that it could be possible that the aggregate daily levels of transactions fees could match, or even exceed those paid in BTC for a given level of inflation whilst maintaining lower cost per transaction, should the relative volumes of transactions in BCH outperform those of BTC. This in itself is not inconsistent with the aspirations of BCH to be used by a large number of users on a daily basis, which necessitates a higher number of transactions and thus greater velocity of the monetary base.
Right, so let’s say that we wrapped up the argument that tokens are necessary to run these systems and that inflation is part of that cost. Next, and slightly more theoretical is that of “immutability” or so-called censorship resistance. Personally I think the latter is a better descriptor, albeit it still slightly misleading.
So returning to the comment made in the Bitcoin Whitepaper:
“Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.”
We mentioned that in proof-of-work blockchains, there is a global race, measured in “hashes” or the number of attempts to create a valid proof-of-work to present to the network which requires hardware investment and burning electricity. Successful miners are compensated in the native unit of account, hopefully in excess of their investment. In the event that this is the case (i.e. RoI is positive), more miners should join the network thereby reducing the relative weight of existing miners, and existing miners should increase CAPEX and energy expenditure.
This is, of course, a relatively sanitary view of the equation, as not all miners will have equal access to hardware and electricity, and the cost of these may greatly vary. Additional considerations include latency of the network to broadcast a successful proof-of-work to the next successful miners, meaning that even if you had free electricity and hardware, mining from Mars — where it takes light and thus messages ~14 minutes to reach Earth — is very unlikely to be profitable. The average delay during the Mars Curiosity mission was 13:48, and depending on the relative position of Earth and Mars in their orbits this can range from a low of approximately 4 minutes and a high of approximately 24 minutes. If, by the way, you’re questioning a point about the distance between Mars and Earth in a post about cryptocurrencies you’re awesome! Also, a message for Elon Musk fans, don’t, just don’t…
If, on the contrary, miners lose money in securing the network would we expect a reduction in the number of miners and the total hashing power within a network leaving only the miners with access to cheaper inputs or those willing to operate at a loss (i.e. less profit, greater concentration amongst fewer parties).
In the event that there is a viable substitute (e.g., BTC and BCH) miners may move between networks in the event that the mining the other network is profitable rather than quitting the mining business either temporarily or permanently. Aspect inherent in the design of networks that make substitution more difficult (e.g., different hashing algorithms) are less likely to see miners substituting between networks.
These effects are particularly notable in networks where hardware investment has been made into specialised hardware known as Application-Specific Integrated Circuit (ASICs), which are designed to do a specific task but are uneconomical for anything else. The effect is that BTC/BCH mining which relies heavily on ASICs is not easily substitutable into Litecoin or Ethereum which use different algorithms. Ethereum, however, is dependent on more commoditised hardware (GPUs) which can be used amongst a wide variety of cryptocurrencies as well as for non-cryptocurrency uses including PC gaming.
Having looked at some of the reasons why miners may choose to mine, or not mine, let’s quickly discuss what is at stake. To understand this, we first need to understand what a public blockchain does. In an attempt to simply it, let’s say — a public blockchain network orders transactions that adhere to predetermined rules which then become binding amongst all participants in the network, in which the validator of these transactions cannot be known a priori.
The key of course from this is that the validator of a particular block -and as such the transactions in the block- should not be known by anyone (including themselves) until a time in which they are able to enforce it. In the case of proof-of-work systems this requires providing a satisfactory solution to the proof-of-work. Should someone be able to determine who will mine the next valid block then we have a situation where the assumption of an open, censorship resistant system no longer exists, as the anyone with this knowledge can either unanimously make decisions about subsequent transactions (denying participation or rejecting transactions) if they are that validator, or coerce that validator into applying such decisions. Should someone be able to reliably be able to predict the validation and enforce their discretionary actions upon the network over enough time then they may also be able to revert previously accepted transactions.
Bringing this back to observations on actual cryptocurrency systems, we can see the effects of concentration of mining as measured through a Herfindahl Index amongst all identified mining pools in BTC since 2013. Miners marked as ‘unknown’ by blockchair.com have been group as a single entity. Whilst this does not give an accurate reflection of early mining, since late 2012 a majority of successfully mined blocks have been produced by an identified pool.
Source: Blockchair.com, Coindesk
This chart highlights that the amount of control that a small number of actors (miners) has varies over time (increase/decrease of Herfindahl Index), which has a knock-on effect on the probability of the ability for any single mining entity to gain sufficient influence over the BTC network to create an unexpected and enduring impact. It should be noted that control or influence can also take place externally, including through full node (non-mining nodes, c.f. UASF), BIP/EIP committees, and other political entities. These are beyond the scope of this post. It also appears to show that periods in which mining tends to become less concentrated have correlated with a subsequent increase in the price of BTC as measured in USD. If this is in fact the case, it would lend validity to the claim that less control by a small number of actors (or a single actor) has a positive impact in investors’ willingness to pay for a cryptocurrency. This higher Dollar value in turn leads to a higher cost of conducting a transaction, ceteris paribus.
Bringing our two concepts of decentralisation and cost together, we should briefly highlight the assumption that we made early on in this post that decentralisation is expensive. Below we show the Herfindahl Index (over a weekly basis) plotted against the cost of transactions:
Source: Blockchair.com, Blockchain.info
Much like the effect of inflation, we can see that periods of lower concentration of mining have tended to coincide with higher aggregate transaction fees being paid to confirm transactions. Revisiting our comment on the USD cost of a transaction, we should consider that if prices of the cryptocurrency rises, and the cost of transactions rise in terms of the base currency due to the higher USD price of the cryptocurrency the rise in the total cost of conducting transactions could be exacerbated.
Other solutions, which aim to build a decentralised consensus without employing proof-of-work, exist.
The foremost of these solutions is known as proof-of-stake, which seeks to allow coin holders in a network to group transactions in blocks, and use their holdings to back a particular outcome or path should there be a disagreement of which block is the latest valid block from which subsequent blocks should be formed. Supporters of these consensus mechanisms see such solutions as having the potential to remove the necessity of making real world investments (and in particular the consumption of electricity) from the securing of the public blockchain network.
To date several public blockchains utilise this method either as the sole manner in which to maintain consensus (e.g., NXT, QTUM), while others employ a hybrid solution that combines proof-of-stake with proof-of-work (e.g., Peercoin, Decred). Several influential developers in the Ethereum community, including its creator, Vitalik Buterin, have expressed a long time desire to move to a proof-of-stake mechanism, going as far as introducing a “difficulty bomb” inside the rules that govern the system to ensure that action would be taken in the future.
Notably, proof-of-stake coins tend to have very low, or zero inflation rates, when compared with proof-of-work coins. This would suggest, at least implicitly, that transaction fees will need to either be sufficient to guarantee that past blocks are not changed (and perhaps variable in nature), or that such an assumption of censorship resistance will remain merely conceptual. While the promise of creating consensus without the need for the consumption of large quantities of electricity is certainly interesting, a majority of the solutions currently utilising proof-of-stake remain relatively small and, I believe, lack sufficient transaction volumes to effectively evaluate today (so that’s another post). With that said, it is worth leaving the question on the table of what degree of modelling has gone into compensation of stakers/minters during periods of low transaction volumes, as a lack of proper incentivisation to “do the right thing” during these periods could challenge whether enough economically rational individuals would choose such a system to ensure sufficient volumes. While it could be argued that this is also the case for proof-of-work chains, the reliance on external costs (i.e. hardware and electricity) enforce a minimum cost on the system which helps to incentivise miners to remain honest.
Let’s recap where we have come to so far.
We showed that public blockchains compensate validators for their contribution through the use of a native unit of account, and that compensation can come in the form of inflating the monetary base by issuing new units, and through fees levied directly on transactions in the network. We also saw that as the inflation decreases, fees rise to compensate lost inflation revenues at a nonlinear, and increasing rate of change. We also focussed on factors that could affect the censorship resistance of a blockchain and how that assumption can vary over time. We conclude here in stating that decreasing inflation should shift the cost of securing a network to transaction fees, and that improved security of the network further increases the cost of making transactions.
Bottom line, trustworthy blockchains are expensive.
Wait?! I thought blockchains were going to revolutionise the world making everything cheaper because we took out the middleman.
On to hypothesis number 2:
“Economically rational uses for public blockchain technology will be confined to instances where the real or perceived threat of censorship by external actors justifies the transactional cost required to maintain and secure a blockchain.”
Cryptocurrency and public blockchain supporters often ask why someone would both using a permissioned blockchain or DLT when a centralised database will do just fine. Though condescending, the logic shouldn’t be thrown out the window. I would also advocate taking their question and extending it backwards, given that we know that public blockchains cost money (inflation and transaction fees), why would we not just use a database instead?
The short answer here is that in a lot of cases this could work, there is of course a trade-off, chiefly we have to trust someone to be honest and to not turn us off. If the particular application that we are interest in is preserving a fixed number of units for others to trade or “HODL”, the notion of having a single god who can dictate the terms of the the system seems even less appealing.
I don’t care, I want to use a blockchain!
Ok then cowboy, let’s take a look at the price tag. Recall earlier we defined the price of running a public blockchain as the sum of inflation and transaction fees, adding these together is simply the mining revenue of a particular blockchain over a given time frame. If we wanted to calculate how much it would cost to run Bitcoin for a month we can simply add up the amount of new coins issued by the mining process and the transaction fees for all transactions that month, then multiply them by the price in USD. For Bitcoin this looks like the following:
Of course in the early days, when Bitcoin was worth nothing, transacting was effectively free. Money was still spent on mining and running computers, but no one charged anyone to use it because Bitcoin was worth basically nothing, then very little.
As the price grew in Dollar terms the price of running Bitcoin went up, alongside demand for using Bitcoin to send bitcoin. In early 2012, mining revenues on Bitcoin amounted to approximately $750,000 per month, by early 2015 this number had risen to roughly $13 million, and in March of 2018 it was approximately $275 million.
Sounds fantastic, “but how do we translate that back into something that we can compare to databases?” you ask.
To answer that question, let’s recall the basic operations going on inside a public blockchain, like Bitcoin. The first is collecting and validating transactions (computing), the second is saving them (storage) and the third reading from the storage.
For any public blockchain these functions are quite basic and do not require the awesome mining farms being operated to generate the hashes necessary to secure Bitcoin. Staying with Bitcoin, we can do some pretty simple calculations to ascertain how much computing and storing is required to run the actual grunt work (less the mining). If we take a look at the activity inside the Bitcoin blockchain, we can see the number of transactions confirmed and the increase in the size of the blockchain (stored). The chart below shows this on a monthly basis:
We also know that Bitcoin blocks should be produced every 10 minutes on average, which equates to 144 blocks per day, or roughly 4320 each month. In addition we know that the approximate total size of the Bitcoin blockchain was 165 GB in late April 2018.
Now that we know the amount of transactions which need validation, and the number of batch (blocks), a historical size of the blocks confirmed per month, and the total size of the Bitcoin blockchain, we can take a look at what our good friends at Amazon AWS would charge us to do this hard work.
- 5 million transactions per month (~7k per hour), which get confirmed into
- 4,320 batches per month (blocks) stored into the standard storage mechanism
- And we get 100 million queries to our database per month (people checking their balance)
- All the 165 GB of older blocks getting stored into the infrequent access storage
- And another 1 million queries per month to the older transactions
Given that we’re only processing about 7,000 transactions an hour we can probably get away with a medium size t2, but let’s YOLO and get ourselves a large m5 server which can handle gaming applications and enterprise databases.
And because we don’t want the CIA or GCHQ immediately spying on our stuff, let’s set it up in the Paris-based data centre. Much like our beautiful public blockchains, using cloud allows me to give access to everyone to submit transactions and query their balance.
Putting this together, Amazon has given me an estimated monthly bill of $127.16 (after my $0.15 free tier discount of course).
Wait?! Did he say Amazon wants $127.16… and Bitcoin was $275 MILLION?!!!!!! I’m firing the nearest blockchain thought leader!
And if we take a look at Ethereum, we can see that the cost of securing the network has been higher than that of Bitcoin recently, topping $400 million in March 2018.
Of course Ethereum takes blocks more often than Bitcoin (roughly every 15 seconds vs. 10 minutes), equating to approximately 172,800 batches per month. It also allows for smart contracts and handles more transactions, both of which take more relatively more storage space than Bitcoin.
The Ethereum blockchain registered roughly 75 GB in late April 2018 (for a GETH Fast sync, which doesn’t contain all the data but gives a base for comparison), and was growing at roughly 7 GB per month. Ethereum also handled approximately 20 million transactions per month (~28k per hour), which was higher than that of Bitcoin. If we bang that into our AWS calculator (and in the spirit of YOLO, double our processing to an extra-large m5 instance, though in fairness the other one was probably still overkill), we pay a monthly charge of $208.90, after our $0.15 discount of course.
So while I fully acknowledge that the actual parameters of performance needed on AWS may vary, even if we’re off by a factor of 100 (or 10,000), we still have a reasonably large difference between the cost of running AWS and running the same functions through a public blockchain.
We’ve also identified that the reason for that difference in cost is down to the censorship resistance and control of the two options. Amazon could, of course, receive a court order to shut down my illegal databaseCoin which performs between 7 and 28 million transactions per month, or even force me to perform KYC/AML checks on the people using my databaseCoin (blasphemy). Given the dispersion of contributors to both Bitcoin and Ethereum, as well as the relatively low barrier to become a contributor to the mining process (not saying that you’ll be successful) that same court would find it more difficult to change the rules for those networks. Assumes a scenario where large, identifiable mining operations are targeted by external forces which results in a decline in the total amount of hashing in the network and thus difficulty in hashing.
Now, given the *several hundred* million Dollar monthly price tag to move from AWS to Bitcoin or Ethereum, the obvious question is who would do this?
Ah, good question indeed.
If we go back to our hypothesis and assume that people are vaguely rational, the only good reason to pay this premium is to have that sweet, sweet censorship resistance. As we highlighted in the previous paragraph, one good reason would be to prevent a court from shutting us down for running an illegal money transmission service. Another good reason would be if one was concerned about a dictator getting all up in their business and convincing the operator of the centralised service to block transactions which go across borders (e.g., Venzuelan capital controls). Coming around full circle, the USS ICO would have very likely never set sail on a cloud based architecture due to the threat of enforcement by the SEC.
In conclusion, we saw that public blockchains are not cheap to secure and maintain, however the processing of transactions that they do is pretty reasonable — clarifying, this is the equivalent of running all the transactions of the network through a single, full non-mining node and completely doing away with the hashing.
We also discussed why someone would favour a public blockchain over a more centralised architecture. Logic led us to establish that censorship resistance is really the only benefit of moving from the more centralised control offered by cloud providers or permissioned blockchains to the less centralised control offered by public blockchains.
This isn’t to say that anyone using a cryptocurrency is a criminal, they could make good (even if slightly volatile) investments, and solutions layered on top of blockchains which reduce the need to actually pay transactions fees for classes of transactions which are unlikely to be censored or reversed may develop to a point where they are economically viable for a wider range of uses. I want to also finish by recognising that additional developments at the base layer (the public blockchain) may add additional scalability which could allow for more transactions, thus spreading the cost of securing such networks, however I remain doubtful that these will significantly lower (if at all) the cost of maintaining the network as a whole.
Thanks to those who took the time to read and comment. If you have other comments or questions, please do reach out.
Vini, vidi, FUDi.