Understanding how blockchain immutability changes over time and visualizing it to stakeholders.
Currently, there exists a debate in cryptocurrency communities over the definition of immutability. One can currently not fully measure aspects of immutability as strong vs. weak immutability, but only whether something is immutable or not. This becomes an issue as blockchains try to upgrade new features that allow for future functionality but are wrestling with how that can follow the tenets of immutability.
The issue we find here is that we often look at immutability in blockchains as a latent variable, just like we do with IQ. The problem with IQ is that it has negative implications on the measurement of human intelligence because it unfairly assumes a singular number to explain something as complex as consciousness and intelligence.
We should then look at immutability of the blockchain as something that is complex to define because of the many properties that are important to different stakeholders. However, we can also provide an estimate based on features of the blockchain where immutability is measurable.
Then, like Nassim Taleb has argued for intelligence being a vector of unknown range, where if we know the limit, we can predict the future, the same can be said about immutability.
However, while IQ has major ramifications as it classifies people unfairly as a statistic, in the case of blockchains, we can borrow from the ideas to create a similar vector to measure immutability subsystems. This won’t provide us with a clear answer but can help us analyze blockchains better and explain the different aspects of immutability to stakeholders.
In order for us to come up with a better measure of quantifying immutability, we need to first figure out an actual measure of what classification we can assign to a subsystem on the question of immutability vs. mutability.
Here’s the Table of Content of this post. The first 9 sections are an introduction to the immutability vector and its features, which we use as a quick way to quantify different chains.
In the section about Finney Ratio and Immutability Map, we propose a way to represent them over time.
In the Szabo Score section, we go over ways to quantify overall immutability based on the map.
We then talk about how it allows us to plot future events. Then we draw our conclusions.
Table of Contents
- Many Subsystems of Blockchain Immutability
- Monetary Policy
- Consensus Mechanism
- Hashing Algorithm
- Chain State
- Reserved State Space
- Transaction History
- Transaction Finality
- Pre-Described Agreements
- Finney Ratio and Immutability Maps
- Szabo Score
- Plotting Future Events
- Looking Ahead
The Many Subsystems of Blockchain Immutability
Unlike decentralization, which we can quantify more in percentages, in immutability, the correct measurement must be binary. In other words, a subsystem can either be mutable or immutable. There are no other ways to look at it that we can use for the time being.
So, we would like to define immutability more as a vector with multiple scalar features in it, each with its own value measuring one subsystem.
To write down each scalar, we propose the following:
Here, the i represents a variable being classified as immutable or mutable, where it refers to a specific subsystem of the blockchain we are aiming to measure.
Various features of the immutability vector can be proposed. We decided to focus on those eight subsystems of immutability.
- Immutability of Monetary Policy
- Immutability of Consensus Mechanism
- Immutability of Hashing Algorithm
- Immutability of Chain State
- Immutability of Reserved State Space
- Immutability of Transaction History
- Immutability of Transaction Finality
- Immutability of Pre-Described Agreements
We will be going over all those eight subsystems, and try to quantify the value of each subsystem in the case of three blockchains: Bitcoin, Ethereum and Ethereum Classic.
We can group them as part of the immutability vector as defined in the following.
It’s important to keep in mind that all those different subsystems that affect a blockchain’s immutability pre-agreements happen on the social layer.
On the social layer, you can propose a hard fork to add a supply cap or remove restrictions and caps. You can implement an irregular state change to return back people’s money or you can add new op-codes.
Let’s now go over the different subsystems before we propose ways to measure immutability and to visualize it.
Immutability of the Monetary Policy is a measure of the change in the Monetary Policy of the blockchain historically.
Examples of monetary policies in blockchains include the 21 million bitcoin supply cap or Ethereum’s infinite supply of Ether.
Here, we will need to look at the moment a monetary policy was first described or mentioned and if changes were made to it after.
For example, a change in the block issuance number from constant supply to a lower number or a supply cap on the total issued currency units constitutes a change in the monetary policy.
Let’s first look at Bitcoin. The question for Bitcoin has always been when was the monetary policy first introduced. From scanning the archive and the original code, we see that the original whitepaper and code published by Satoshi Nakamoto (the pre-release) contains no mention of 21 million supply cap.
It was only in the first-version release in January 2009 that we first see Satoshi discussing the 21 million supply cap and references to it in the code.
The question then becomes, which is the right Bitcoin canon, when it was first published in the white paper with the pre-release code or when it first went online in early January 2009? There’s a good 2 months gap in between where Satoshi and Finney and others worked on the first version release, where the supply cap was introduced.
In this code block, we see the block reward is halved every 4 years, or every 210000 blocks.
In the pre-release version, the code is nowhere to be seen. In the archives here, we can see the text of the original bitcoin announcement about the supply cap.
Total circulation will be 21,000,000 coins. It’ll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.
So, because I’m considering the first time the network went online to be on the first version release based on the references linked, bitcoin’s immutability value for monetary policy is 1.
However, it’s important to note here that Satoshi wasn’t the best programmer and even though he intended there to only be 21 million bitcoins, it actually will continue over 21 million due the way C++ is designed. BIP-42 (although written on April Fool) intends to set the supply cap to strictly 21 million bitcoins in the year 2214, which by then will violate immutability of monetary policy. So although currently, Bitcoin has a monetary policy value of 1, it’ll violate it in the year 2214.
If we look at Ethereum, we can see in the white paper that their monetary policy was an infinite supply with a fixed block reward issuance (5 ETH) for the rest of the chain’s lifecycle.
This is clearly a violation of the immutability of monetary policy. While one can argue that Ethereum doesn’t have a monetary policy due to having an infinite supply, the constant issuance of ETH per block for its infinite supply is still a monetary policy.
Therefore, we assign it a value of 0.
Ethereum Classic follows the same story due to the application of the monetary policy of a supply cap on circulating ETC as can be seen in ECIP-1017.
Because Ethereum Classic continues the original chain from the white paper with a resistance to the DAO fork, a change in its monetary policy by issuing a supply cap is a violation of immutability of the monetary policy.
So, therefore, we also assign ETC a value of 0 in this category.
Consensus deals with the mechanism of decision-making on the blockchain. The most popular type of consensus is Proof-of-Work, which is currently found in Bitcoin, Ethereum and Ethereum Classic.
Immutability of the consensus mechanism is an important measure of understanding whether a blockchain is modifying its mechanism in the future.
For example, if Ethereum moves from Proof-of-Work to Progressive Proof-of-Work or to Proof-of-Stake, it breaks the immutability value for consensus mechanism.
Currently, all three coins (ETC, BTC, and ETH) have always been on Proof-of-Work consensus, so the value for each of them is 1.
Hashing algorithms refer to the tools used to measure consensus mechanism. For example, most Proof-of-Work chains like BTC (Hashcash) and ETH/ETC (Ethash) use hashing algorithms that are based on SHA-256.
If at any time in the future, any of those chains switch the hashing algorithm to be SHA-3 or some other algorithm, then it violates immutability of the hashing algorithm.
This can be an ok thing to do if say SHA-256 is broken in the future and the security of all those chains relies on having a harder to break hashing algorithm. By then, despite breaking immutability in that category by moving to a new hashing algorithm, it actually improves security. It’s a tradeoff.
For now, though, all three chains will receive a value of 1.
The immutability of the state set is the assumption that the state never gets irregularly modified outside of its regular change.
In other words, if we assume the state of the blockchain is S, where S is constantly being updated and modified regularly with each block, any irregular modification of S would denote a value S′ such as S′ is an irregular State set. What we define as irregular state change is anything that affects the transaction history and finality of the ledger in any way.
To date, only one chain has made an irregular state change, resulting in an S′ prime: Ethereum during the DAO Hard Fork.
The irregular state change allowed for a bailout of stolen money from the DAO hacker, which has modified the state to result in S′.
We can specify it using the following rule:
Using this rule, the values for ETC and BTC are 1 while ETH becomes 0.
Reserved State Space
Reserved State Space is a measure of empty addresses that are reserved for future modifications on the blockchain to allow for the addition of new features.
For example, when one adds in Op-Codes for Solidity like
REVERT on Byzantium Hardfork for Ethereum or the upcoming Atlantis one for Ethereum Classic, they’re modifying the reserved state space which was initially empty.
This category is important to note that the modification of empty reserved state space follows it’s intended design and even if there’s been a new addition of op-codes that break immutability here, it’s ok because that’s the whole point of using it.
Currently, Bitcoin has a 0 for no modification of reserved state space because Bitcoin added it’s first new op-code in December 2015 with BIP-65.
Ethereum, having implemented Byzantium and Constantinople hardforks which added several new op-codes, breaks immutability in this category.
Ethereum Classic doesn’t violate immutability in the reserved state space category (yet) but plans on doing so with Atlantis hardfork that’s coming this September.
So while Ethereum Classic is given a score of 1 here, it’ll be 0 in a few months when the hardfork is implemented.
So, here, ETC gets a value of 1 while ETH and BTC get a value of 0.
In measuring the immutability of transaction history, we try to determine whether the history of transactions that have been written to the ledger have been modified later on.
Say, for example, we add Transaction Y to Block B today. Then, a few days later, someone successfully 51% attacks the network and mines the blocks in order to modify Transaction Y on Block B (it’s a very expensive operation to do with the amount of hash rate needed). That would violate Transaction History on the blockchain.
Ethereum’s bailout of the DAO token holders who lost their ETH during the DAO hack isn’t a violation of transaction history on the ledger (even if it’s a bailout) because the original transaction by the DAO hacker to steal the ETH wasn’t modified in the future by the DAO fork. Instead, what the DAO fork introduced was an irregular state change.
Therefore, in this category, historically, neither of the three chains every experienced a violation of transaction history immutability. So, each chain gets a score of 1.
In transaction finality, we look at whether a transaction that enters the blockchain after some confirmations is final.
Since blockchains are probabilistic and the more confirmations a transaction has, the more it is final, the measure becomes one of what constitutes a good amount of confirmations.
If we decide a confirmation of 1 for each chain, we are in trouble because sometimes 51% attacks and blockchain reorgs happen. Reorgs can happen if say there’s a delay in network propagation from miners in China, which means a transaction that is added to a block mined by someone in America might not be final if say a miner in China has mined a longer chain but has a delay in communicating with the rest of the network. By the time they do, their chain becomes the longer chain and the other transactions will have to be re-added to the network.
Therefore, transaction finality on one block confirmation would result in a 0 for all chains and is an unrealistic way of looking at immutability of transaction finality.
It’s important to understand that due to 51% weakness of Proof-of-Work chains, waiting for longer confirmations is the only way to probabilistically reach transaction finality.
In the events of the 51% attack on Ethereum Classic with a double-spend attack on a few shady exchanges, exchanges were waiting for shorter block confirmations than the economic value of bitcoin. No other transaction was lost in the process, but the finality at the moment was threatened on the exchange side.
The solution was longer confirmation times. If we use the Coinbase metric for confirmation times that are fit for each chain, then we see that BTC, ETH, and ETC all have a score of 1.
To further illustrate the point of how longer confirmation times improve transaction finality, observe the early interactions between Satoshi and Hal Finney on this topic here.
“The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.
Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.” — Satoshi Nakamoto
Pre-described Agreements relates to any rules that a user acknowledges before using the blockchain. A violation of pre-described agreements is a change in immutability.
Many examples of pre-described agreements exist, but here, we will use the example of private and public key rules.
The rule of blockchains is that only the owners of the private keys can transact from the address and the account. So, if you don’t own the private key of an account on the blockchain with say 1 million ETH, you can’t move those ETH around.
This is why it’s important that Satoshi’s address on Bitcoin has 1 million BTC that hasn’t been moved. It’s also why Craig Wright can’t prove he’s Satoshi because he doesn’t own the private key for the address that is known to belong to Satoshi.
In the case of the DAO hard fork, a violation of pre-described agreements has taken place with the bailout of stolen funds on a new forked network by Ethereum, which unfortunately makes ETH mutable in this category and is therefore assigned a value of 0.
Ethereum Classic was a rejection of the DAO hard fork and therefore still maintains on the social layer the pre-described agreement, making it still a 1. However, ECIP-1015 which modified the gas costs on Ethereum Classic did violate the Pre-Described agreements on block 2,463,000. Therefore, ETC has a value of 0 in this category.
There has never been historically a bailout in the history of Bitcoin, even during the Mt. Gox Hack, so it retains a value of 1.
The Finney Ratio and Immutability Maps
Now, having done the preliminary analysis on all the features of the immutability vector, we can create a table with the values to get a better picture.
Binary values for each immutability variable gives us an immediate picture of whether or not there’s a mutation in one of the features.
While this chart gives us a quick way to measure blockchain immutability, we can also use time as another variable to consider.
The benefit of using time is that we can actually see how long does each feature of a blockchain stay immutable before there’s a violation in immutability.
We can measure time passing in blockchain via block numbers. We propose the Finney Ratio for measuring time passage in blockchain with mutated features.
Here, the Finney Ratio applies to any of the immutability variables that have a 0 value. So, for all variables in immutability vector I, we replace the 0 with the Finney Ratio.
Basically, we get the ratio of when the mutation occurs (as measured by block number it occurs on) by the latest block value.
I will specify the following Block (latest) that I use in the calculations for each chain:
ETH: Block 7,680,546
ETC: Block 7,958,559
BTC: Block 574,302
Now, let’s observe the features that were violated for ETH and at what block number.
ETH’s violation of Monetary Policy immutability happens around the Byzantium Hard Fork where there was a reduction in reward at block number 4,370,000. It’s also the same block where the new op-codes were added, violating Reserved State Space category of immutability.
So, the Finney Ratio for those two categories is 4.37 / 7.68 = 0.57
If we look at the other violations, both the violation in Pre-Described Agreements and Chain State happen on the DAO Fork at block number 1,920,000. So, the Finney Ratio for those two categories is 1.92 / 7.68 = 0.25
We can group the values for Ethereum in the following table.
Now, let’s plot it. We can use here a radar chart which we can call an Immutability Map to be able to plot the change in immutability for ETH over time.
Here, we see the effects of the DAO in early penalization of Ethereum, with the larger growth in the chain pushing the Chain State and Pre-Described Agreements closer to 0 as time passes on. We also see the effects of Byzantium Hard Fork on the network.
Now, let’s move on to ETC.
In Ethereum Classic, two violations happened, the Monetary Policy breaking in immutability which happens at block 5,000,000 and the Pre-Described Agreement violation back at block 2,463,000 for ECIP 1015.
This will result in a Finney Ratio of 0.63 for Monetary Policy and one of 0.31 for Pre-Described Agreements.
Here’s a table to highlight the values we calculated.
We can plot the Immutability Map for ETC in the following diagram.
What’s interesting here is that the violation in Monetary policy for ETC has a Finney ratio of 0.63, which is close to the Finney ratio of 0.57 for ETH’s violation in monetary policy immutability. The same applies to Pre-Described Agreements, ETC’s 0.31 Finney Ratio is close to ETH’s 0.25 Finney Ratio.
For Bitcoin, the violation of Reserved State Space happens around December 2015 with the implementation of BIP-65 for adding a new op-code.
I have no information about when in December 2015 has it been activated, so what I did was take the minimum and maximum block number for December 2015 and average their values in order to get an approximate block number.
386,270 is Minimum Block number on December 2015
391,150 is Maximum Block number on December 2015
BigQuery Code linked here
Average Block Number for BIP-65 is 388,710. So, the Finney Ratio for Reserved State Space is 0.67.
The following table shows the updated immutability vector values.
We can plot the immutability map of Bitcoin here.
What’s the benefit of having us calculate the Finney ratio for each violation in immutability in the Immutability vector? It helps us understand the timelines of blockchain immutability better when we try to see how long a blockchain’s features preserve immutability through time.
The good thing is that, given a long enough timeline, the Finney Ratio approaches zero. The longer a blockchain preserves immutability in each of its features, the larger the immutability map.
In the case of Bitcoin, it’s gonna still have a great area of immutability until BIP-42 is implemented around the year 2214 whereafter, the violation in Monetary Policy value happens.
Now, what if we want to get a score of the Immutability Vector?
The Szabo Score
In order to quantify the immutability maps we are observing with one number, we propose using what we call a Szabo Score. The Szabo Score is simply the entropy measurement of a blockchain’s immutability.
Why did we decide to use entropy here to measure? In information theory, entropy measures the unpredictability of the state. If a highly probable event happens, it gives us no new information about it since it’s expected to happen. Also, if a lower probable event happens, it gives us a lot of more information of when it occurs. So, in entropy, flipping a dice has a higher value because of the low probability of each dice value than say flipping a coin.
We can rephrase probability in the case of immutability here. Instead of probability, we are looking at the Finney Ratio and trying to measure it. Here, if a Finney Ratio is 1 for each value of the immutability variables, it gives us no new information as it will always be a 1, and thus, fully immutable. The entropy value of a fully immutable vector (all values are 1) is 0.
The interest lies in variables where there is a violation of immutability and pushing the Finney Ratio towards 0 over time. Here, over time, the dropping in “probability” or Finney Ratio for one of the variables does increase the entropy or Szabo Score. It allows us to gauge how a violation in immutability in a blockchain leads to more uncertainty over time.
We can write the Shannon Entropy formula in terms of the Szabo Score as follow:
We are measuring on a base of 10 of the logarithm because we are dealing with decimal and not binary points.
Given the vector values of each chain in the previous tables where the 0s are replaced with their Finney Ratios, we can then calculate the Szabo score of each chain.
Here, we can see that the higher the Szabo Score, the less immutable a blockchain is over time. The more time passes after a blockchain violates one of its immutability variables, the higher the Szabo score climbs, decreasing its immutability. Bitcoin in the Szabo Score table above has the lowest Szabo Score, therefore the highest immutability. Ethereum Classic has a higher immutability than Ethereum due to its lower Szabo Score.
So, a good way to measure the immutability of blockchains is to take the Szabo Score (entropy of the immutability vector with mutable values of 0 replaced by their Finney Ratio) and the minimum Finney Ratio (ratio of the first break in the immutability of a blockchain feature) to be able to understand blockchain immutability and their timelines better.
Plotting Future Events
The other cool thing about using Immutability Maps is that it can allow us to predict how a blockchain’s immutability can change in the future.
For example, in the case of Atlantis Hard Fork happening on Ethereum Classic, we can assume it’ll go as planned on block number 8,750,000 in September 2019. We know that by then, Ethereum Classic will break the immutability category of Reserved State Space.
We can take a look at what happens after that in several months at block number 9,500,000 to get a picture of the immutability map of Ethereum Classic.
Obviously, the caveat here is that Atlantis goes as planned on block number 8,750,000. What we can see is a slow shift in the future away from Reserved State Space slowly towards 0. Same happens with Monetary Policy and Pre-Described Agreements, they’re pushed slowly over time to 0.
What’s also useful is that we can visualize future events like if say SHA-256 gets broken and all blockchains hardfork to SHA-3, violating their Hashing Algorithm immutability but maintaining security. Even Ethereum moving to Proof-of-Stake can be plotted using the immutability map.
What’s currently interesting about all three chains is that they all share an immutability value of 1 for Transaction Finality, Transaction History, Hashing Algorithm and Consensus Mechanism.
There exists an ECIP for Hashing Algorithm change to SHA-3 for Ethereum Classic. Ethereum is planning to move to Proof-of-Stake. The timelines of when future changes happen have an effect on the blockchain’s immutability map and score.
In the case of post-Atlantis hard fork for Ethereum Classic, we get a new Szabo Score of 0.3307 at block 9,500,000.
That’s an increase from the current ETC Szabo Score of 0.2837, indicating the chain is becoming less immutable with time passing and violating new subsystems of immutability. However, it’s a slower increase in the score over time.
One of the most important things we want to do with Finney Ratio, Szabo Score and Immutability Maps is to help stakeholders visualize immutability in blockchains and how it gets affected over time.
Being able to do this in a coherent manner that helps people understand the implications of blockchain immutability allows us to decide what aspects of immutability are important to a community’s values.
For example, a break in SHA-256 and an upgrade to SHA-3 violates the Hashing Algorithm category of immutability but improves security.
Moving from Proof-of-Work to Proof-of-Stake violates Consensus Mechanism of immutability but improves scalability in the long term.
Adding new op-codes violates Reserved State Space but extends blockchain functionality over the long run.
The whole point is to understand that immutability is about tradeoffs, and each blockchain community would then need to decide which tradeoffs are worth pursuing.
If you have any comments or feedback or concerns, don’t hesitate to reach out on Twitter or comment here! If you are looking for the Github repository used for this article, link is here.
Thank you to Anthony Lusardi, Wei Tang and Donald McIntyre for your feedback on immutability that helped with this article.