Following up from this past week’s post on whether you can have a blockchain separate from Bitcoin itself, it became pretty clear a small portion are still trumpeting the idea that Bitcoin is blockchain is PoW Hashing + the bitcoin token.
Changing any of the token, the data structure, or the trust model is seen as breaking the rest by this contingent.
In the interests of having a productive framework for how to discuss these issues going forward, we should probably start by finding out exactly what a blockchain is and what exactly we can change before the concept becomes something other than a blockchain.
Is The Blockchain Just Bitcoin?
I started by just searching the phrase “what is a blockchain” on Google.
I suppose it’s case closed then! For anyone new to the concept, they can be assured that blockchain is bitcoin is blockchain.
Just to be sure though, let’s scroll a little further down the page and see if the Bitcoin Wiki has anything to say on the matter.
It turns out they do have a page that does describe the blockchain where they describe the blockchain as follows:
“A block chain is a transaction database shared by all nodes participating in a system based on the Bitcoin protocol.”
It seems they claim as well that a blockchain == Bitcoin. However, there’s a bit of evidence that this exact wording might be a part of the same ongoing debate between whether or not you can consider anything that isn’t Bitcoin to be running on a blockchain.
Digging through the revisions, you can see a user named ‘weex’ changed the wording from the original text below to the revised text above in August 2012.
“A ‘block chain’ is a transaction database shared by all nodes participating in a crypto-currency such as Bitcoin.”
This small (but important) distinction is also shared elsewhere on the wiki.
“Block chains were invented specifically for the Bitcoin project but they can be applied anywhere a distributed consensus needs to be established in the presence of malicious or untrustworthy actors.”
In fact, that same page makes reference to the fact that while it’s possible to build additional functionality on top of the Bitcoin blockchain itself, it’s preferable to build a brand new blockchain that’s built specifically to handle that functionality.
Great. So What is a Blockchain?
I would posit that a blockchain consists of three main, complementary parts:
- A Shared State
- A Set of Rules for Updating State via Blocks
- A Trust Model for Timestamping
I would also argue you can customize each of these aspects to the needs of your specific use case, and we’ve only barely scratched the surface on what this construct can look like.
A Shared State
The very first thing we need to form a blockchain is the state that people can access and that we update through blocks/transactions.
This can be stored in a variety of ways. The Satoshi clients mainly use a TXOut based representation, many newer blockchains are using a balance based system, and for more purpose-specific blockchains you may use something more exotic.
As most blockchains so far have been forms of digital money, the most common representation to store is list of balances of who owns what money in that network. However, we do have some examples, such as Namecoin, of blockchains that store non-monetary information as part of their shared state.
As an example, in the Mental Poker Blockchain that we have built, not only do you hold a monetary balance for a given address, but there’s a method of storing game state for each hand played on the network, and the protocol handles the coordination of players dealing hands to each other and resolving the end of the hand.
A Set of Rules for Updating State via Blocks
Blocks are simply a collection of valid transactions, a pointer to a valid previous block they build upon, and proof of it being a valid block itself.
The rules regarding a transaction being valid or not depend on the exact use case for the blockchain. As most blockchains are mainly used for payments, the address having a sufficient balance (however that’s implemented) to make the payment and pay the fee is generally the model for a valid transaction in these systems. There are more complex transaction types as well in most of these blockchains, but their usage is still fairly niche in comparison.
Using our poker blockchain again as an example, one of our custom transactions is raising in a poker hand. In order for that transaction to be valid, there needs to be an active poker hand being played, it needs to be their turn to act, and they must have sufficient money in the hand to make their raise. If all those conditions are held, that transaction will be accepted as valid, and the state of their game will update as a result.
The block being valid itself is baked into the trust model (assuming it’s building on a previous valid block and all the transactions inside the block are valid), so we’ll discuss that in the next section.
A Trust Model for Timestamping
This aspect is where most of the controversy arises.
As a blockchain is a series of blocks in a specific order, coming to a consensus on both the blocks and the order is necessary for a blockchain to function.
Bitcoin solves this problem using HashCash to determine which history has the most hashing power behind it. The theory behind using this security model is that real-world resources must be expended in order to generate hashes, so as long as >50% of the resources in the network are honest, the chain will progress honestly. The real-world is naturally more complicated, but that’s the general idea behind the security model.
The other major model is a Proof of Stake model, where your influence on the network is determined by your share of the network’s digital resources. Again, the real world is more complicated than that, and there’s lots of debate on exactly how robust you can make a truly decentralized Proof of Stake blockchain.
Using the Proof of Stake model, you can also set up a distributed organization such that different ownership shares represent a controlling share of the blockchain, rather than using the share of value held on that blockchain.
The issue at the crux of most of the controversy is the implication that a trust model is being left out altogether. A smaller (and much more nuanced) portion of the debate revolves around the various tradeoffs the newer Proof of Stake consensus systems make, but the bulk of the discussion is currently devoted to the idea that the concept of a trust model is being thrown out altogether in these more novel constructs.
In fact, most of the more interesting discussions along these lines are much more nuanced than that and explicitly understand the tradeoffs and limitations you have under different constructs.
To simplify things, we can mainly think of consensus algorithms as lying on a 2×2 matrix with Permissionless vs Permissioned systems on one axis and token vs non-token incentives on the other axis:
| Permissionless | Permissioned | |
| Explicit Token | HashCash / Proof of Work | Proof of Stake |
| No Explicit Token | *Magic* | Organization as a Blockchain |
There are lots of valid and interesting discussions surrounding the various tradeoffs you can make in the three realistic quadrants, and we will explore some of those in future posts.
Conclusion
A very valid point in a vacuum (the fact that you need incentives to form a decentralized consensus) is being used to muddy the issue of exactly what a blockchain is and isn’t, what a blockchain can be used for, and what viable trust models exist. This is also in direct contradiction to how the word has been used for years within the community.
This is only anecdotal, but in the almost five years I have been using Bitcoin and following the discussions surrounding Cryptocurrencies, it’s only in the last month that I’ve seen such a hardline dismissal of the possibility of there being viable blockchains that aren’t Bitcoin.
There are an almost unlimited number of use cases that can be put on specialized blockchains, and there are an almost unlimited number of trust models that can be built to secure those systems. It’s up to those who are building those services to choose the relevant trust model for their use case, putting up with the overhead of a completely decentralized and permissionless system when necessary, and allowing for a more appropriate trust model otherwise.
