An introduction to the blockchain ecosystem and its taxonomy
The term blockchain doesn’t refer to a single entity, but to an umbrella of heterogeneous technologies that share some core characteristics.
In fact, blockchains are themselves a subclass of the larger distributed system category defined as distributed ledger technology.
The bare-bones anatomy of a blockchain is, essentially, a data structure known as linked list, but with few crucial tweaks that ensure immutability and decentralization.
A linked list is a linear collection of elements where each element points to the next. The linkage between its elements is achieved through a data type named pointer, which is a reference to the memory location of an object.
What is a blockchain?
A blockchain is a backward linked list whose elements can be viewed as blocks. Each one of its blocks references to its previous block through a hash pointer up to the genesis block, which is the first block in the collection of elements that constitutes the blockchain.
A hash is the output of a cryptographic hash function, which is a function that takes inputs of any size and returns a fixed-length output. Such a function has three pivotal properties: it is deterministic — the same input will always produce the same output-, it’s pre-image resistant — the returned output doesn’t reveal any information about the input- and, lastly, it’s collision-resistant — two different inputs are extremely unlikely to return the same output-.
An understanding of these cryptographic properties is not just a marginal technicality, but it’s of essence to have a solid grasp of how the ingenious blockchain design has the potential to revolutionize entire industries across the financial landscape in a world that is becoming more data-driven by the day.
It’s the concoction between the structure of a linked list and cryptography that conjures up one of blockchain’s fundamental properties: immutability.
Since each block’s hash is computed from its own data and each block’s data contains a hash of the data of the previous block, if a malicious actor were to try to alter the data contained in one of the blocks this would alter the entire chain of hashes. One of the hash function’s properties makes it so that even the smallest change in the function’s input will deterministically return a completely different output. In our example, the attacker, after altering the data inside of the target block and its current block hash, would have to subsequently re-calculate the hashes of all the successive elements from the target block onward. Since the process of generating a valid hash that meets the specific blockchain protocol’s criteria is highly computationally-expensive, recreating a consistent chain of blocks is prohibitive for even the most crafty attackers. The criteria that define the difficulty of computing a block hash strictly depend on the specific consensus protocol of a blockchain implementation and can vary quite widely: public blockchains, which are open networks of anonymous or pseudonymous actors, have more computationally-demanding criteria which, paired with economic incentives, make them designed to enforce immutability even against the most well-funded threat models. On the other hand, private and consortium blockchains, which are comprised of restricted networks with identifiable users, have less challenging block generation criteria, since they’re required to face a less menacing spectrum of threat models.
Despite their implementations’ differences, all blockchains are in essence the same data structure: a timestamped peer-to-peer cryptographic fingerprints-based backward linked list which is a ledger of records. Unlike traditional linked lists, where it’s possible to delete elements, a blockchain is an append-only data structure which makes it both tamper-proof and immutable.
Blockchains and distributed ledgers
The technical underpinnings of the data structure at the core of the blockchain are also what defines it as a very specific type of distributed ledger. Distributed ledgers share the same core characteristics as blockchain’s — immutability, censorship-resistance, full auditability and decentralized storage- but can differ significantly in their data structure implementations. Other data structures that are used to model implementations of different types of distributed ledgers include trees and graphs.
Public, consortium and private blockchains: degrees of decentralization
Within the blockchain ecosystem, one of the main benchmarks to distinguish between different types of blockchains and lay down a taxonomy is its degree of decentralization.
Their implementations can be subdivided in public and private and each one of these compartmentalizations can be either permissionless or permissioned. This allows to build architectures whose level of decentralization is not binary, but lies on a spectrum between distributed and fully decentralized.
The public and private notions refer to the openness of the network, while the concepts of permissionless and permissioned refer to the level of user-privilege. The modular mixture of these features, specifically public on the network-side and permissioned from a user-privilege perspective, defines the category of consortium blockchains.
Public blockchains
In public blockchains, which are mostly known for the cryptocurrency market, anyone can join, read the network and perform transactions. We’ve previously mentioned the hash function-based block generation process: such a process is commonly known as consensus protocol. Permissionless blockchains allow anyone who meet the criteria defined in the consensus protocol to join the pool of validators, which is the set of users who append new blocks of data to the blockchain and update its global state. Public permissionless blockchains are the most decentralized implementation and, as such and also due to their mostly anonymous nature, are exposed to the largest attack surface. In order to be resilient against it, their consensus protocol is paired with a sybil-prevention mechanism through a set of economic incentives to promote honest behaviour — the sybil attack is a malicious way of overtaking distributed networks by forging a large number of fake identities.
Consortium blockchains
This overhead in the consensus protocol makes public permissionless systems quite slow since it decreases its transaction throughput, which is the rate with which new blocks are appended to the chain. More generally, there’s a trade-off between decentralization and scalability.
However, not all public blockchains are permissionless: some of them only allow a pre-selected pool of participants to either partially or entirely control the consensus process. This increases the scalability of the blockchain framework at the expense of the decentralization of its network. These systems are defined as permissioned, and public permissioned blockchains are also called consortium blockchains.
Private blockchains
On the other end of the decentralization spectrum, we now have private blockchains. These too can be either permissionless or permissioned, albeit the latter is more common. Their networks cannot be joined without permission and, depending on the implementation, their state cannot be read by non-participants. Their architecture is more modular and designed with a more granular permission system than public blockchains. Also, at the expense of decentralization, they achieve greater scalability and privacy. All these features make it so that they’re more customizable to enterprise-specific requirements and regulatory frameworks.
In fact, as mentioned in our previous article, this approach has turned out so far to be the favorite for public institutions and corporations. In general, closed reputation systems where the identities of the participants are known necessitate a less strict incentive structure than anonymous networks. Nevertheless they still require cryptographic auditability of their data and check and balances among their competing parties, which is where private blockchains come into play.
Blockchains as decentralized computers: turing-completeness
The second distinctive feature to categorize blockchains is turing-completeness. As we will see, turing-completeness is also a fundamental property of the programming language that they support to develop applications on top of them.
If, on the one hand, a blockchain can be regarded as a tamper-proof record-keeping technology, on the other hand it’s also a world computer whose computations are run by many nodes across the globe. These computations are performed in a decentralized fashion through the scripting language supported by the specific blockchain implementation. Turing-completeness is, in a way, a measure of the computational capabilities and expressiveness of that given language. An expressive programming language is able to represent through its syntax constructs a wide compass of ideas and concepts. When a language is turing-complete, it supports iterative constructs — such as for loops- that further broaden the range of computations it can represent.
Turing-complete blockchains enable the development of smart contracts — programs that run on a distributed ledger- that are expressive enough to replicate complex financial functions, allowing the creation of a whole new economic ecosystem on top of them.
Here at BrikkApp we’re working both on a web-based online property investment aggregator to bolster the transparency of the real estate market and empower investors to make more informed decisions, and on a planned blockchain integration to tokenise real estate property investments.
In the next article we will delve more into public and private blockchains with a comparison between ethereum and the hyperledger project. Follow our medium account to keep up to date with the next publications!
