We use cookies to provide the best site experience
Okay

Wildlife diversity of blockchain

Economist, scientific Director of the graduate FINTECH, Director of research Thalamus Lab, Ranepa
Chapter 5. Genealogy of blockchain
Alexander Didenko
In the previous longreads, we put together a "periodic system" of basic elements of cryptoeconomic systems. Now let's look at what kind of variety we come by combining these elements.
Paolo Tasca and Claudio J. Tessone in A Taxonomy of Blockchain Technologies: Principles of Identification and Classification indicate the following aspects for classifying blockchains:
1
Native Currency / Tokenization
Cryptoeconomic systems do have some kind of digital asset which supports basic activities in the platform or community. There are three important issues here: how platform native asset is designed; is there an option for tokenization; and how assets are supplied to the system. The authors propose three possible options for Native asset:
1) none, as in private blockchains, like Hyperledger or Corda realizations, which do not incentivize internally particular behaviors of nodes;
2) own cryptocurrency, like Bitcoin or Litecoin;
3) convertible multiple assets, or own cryptocurrency + native possibility to exchange external cryptocurrencies. In addition to native cryptocurrency, a platform might have an option for users to issue their assets or tokens.

Again, tokenization could be native to the system, like in Ethereum; available through external applications, as colored coins in Bitcoin; or it could be forbidden completely, as in most private blockchains.
Finally, there are three approaches to supplying the system with currency/tokens:
1) limited, algorithm-based emission, which is choice №1 among most cryptocurrencies;
2) unlimited, algorithm-based emission, adopted by few cryptocurrencies;
3) pre-mined, when supply is fixed from the beginning
2
Extensibility
The possibility of integration of cryptoeconomic systems with others depends upon the interaction of interoperability, intraoperability, governance and script language features. Interoperability and intraoperability cover issues, connected with automated information exchange between external non-blockchain entities and other blockchains, respectively. Governance rules determine how the system evolves and adapts to external changes, and how the community is participating in a strategic decision about it. It is an internal "political system" of blockchains
3
Security and privacy
How data is encrypted — does it use SHA, ZK-SNARKS, or other cryptoprimitives? How anonymity of users is maintained within the system — is it native feature, or it requires external add-ons?
4
Codebase
These are important issues for developers, deciding to join the system: what coding language is used for the system, how is it licensed, what is software architecture of the system?
5
Identity management
Who can access sensitive data? What are the roles of participants, what levels of authority are attached to them? How is the set of rules enforced?
6
Charging and rewarding system
Running blockchain systems means incurring costs, which are carried out by participants of the system. As the authors put it, "different kinds of cost models are applied according to:
1) the architectural configuration design;
2) the governance system;
3) the data structure and the computation required on-chain"
7
Consensus
The authors distinguish consensus in a broad and narrow sense. We have discussed consensus extensively in one of the previous longreads; technically speaking, in a broad sense consensus algorithm is communication protocol — or a set of rules — that ensures the immutability of records in an untrusted and asynchronous environment, or, as authors put it, "set of rules and mechanics that allows to maintain and update the ledger and to guarantee the trustworthiness of the records in it".

This aspect is further decomposed on Consensus Network Topology, Consensus Immutability and Failure Tolerance, Gossiping, and Consensus Agreement. The topology could be, basically, decentralized, centralized or distributed. In some cases, complex hierarchies are built: for example, in blockchains where we have different roles for different nodes (approving, minting coins, transacting, etc.)

Consensus Immutability and Failure Tolerance describe various types of errors and attacks that could arise in the system and proofs of the system to all these adversities. Gossiping describes how nodes, connected under certain topology, exchange information (for example, information about new blocks, added to blockchain).

Consensus Agreement is consensus in a narrow sense: a set of instructions, that should be run on every node, to ensure properties, guaranteed by consensus in a broad sense
8
Transaction capabilities
This part describes everything connected to transactions: Data Structure in the Blockheader, Transaction Model, Server Storage, Block Storage, and Limits to Scalability. Data Structure describes functions of the data stored in the block header, which determines "capabilities of the system to store transaction information".

There are two possible options for Transaction Model, known so far: traditional ledger, and UTXO, which we have discussed in the first module. Server Storage describes whether blockchain permits for "thin clients" (i.e. nodes that are transactions-only), or every node in the system must participate in processing transactions as well as transacting itself. Block Storage describes what is stored in blockchains: transactions-only, or transactions and balance data
We have already talked about consensus (long read "Consensus algorithms"). But we have not discussed governance which is a very important issue.
Governance
Governance is an extremely important issue in blockchains. Here you may read basic-level information on this topic. Also, there is an interesting discussion in the Basic Block podcast about governance in decentralized projects (rus).
Blockchain platform business models
Rückeshäuser (2017) developed the classification of the DLT platforms' business models. According to her, there are four aspects by which business models of DLT platforms differ from each other: Core Value Proposition, Market Segment, Value Network Positioning, and Revenue Stream. Value, which DLT platform may provide to its customers, might be in Infrastructure Provision, in Platform-Based Development, in Application-Based Integration, in Service/Application Provision, or in Supporting/Supplementary Services.
Further, it could be provided before, during or after the transaction. Market segments include Software Developers, Big Businesses, Small and Medium-sized Businesses, Private and Business End Consumers, Governments. Finally, revenues could be collected through a transaction-based or revenue-sharing scheme, in the form of licensing and consulting fees, and from subscriptions.

Blockchains-enhancers

Force move games
Also, read about force-move games here and here.
Plasma and state channels
Ambitious public blockchains, such as Bitcoin and Ethereum, have increased requirements for scalability. To compete with global quasi-centralized systems like Visa and SWIFT in terms of transaction speed and safety, they need to find solutions to greatly increase itsbandwidth.
Ambitious public blockchains, such as Bitcoin and Ethereum, have increased requirements for scalability. To compete with global quasi-centralized systems like Visa and SWIFT in terms of transaction speed and safety, they need to find solutions to greatly increase itsbandwidth.
Lightning
Just as Plasma is Layer 2 solution for Ethereum, Lightning is a Layer 2 solution for Bitcoin. It is a protocol designed especially for small-scale transactions. Just as micropayments systems of the end of the 20th-the beginning of the 21st century, it sacrifices some safety to achieve a substantial increase in the speed of transactions.
Sharding
Sharding is a concept long known in computer science. Initially it was a way of partitioning large database into smaller ones to gain efficiency and speed. Nowadays, there are proposals to use it in blockchains — see for example, how sharding is planned to be in TON, a blockchain for Telegram ecosystem. More in-depth information concerning sharding in blockchains as a whole could be found here and here.
Cosmos, Polkadot, and Internet of blockchains
As Polkadot wiki puts, it "Polkadot and Cosmos are both protocols that provide an interface for different state machines to communicate with each other. Both protocols are predicated on the thesis that the future will have multiple blockchains that need to interoperate with each other rather than individual blockchains existing in isolation." These are systems, designed to provide interoperability between blockchains. There is a vision, that one day all blockchains may be connected with each other through such services, just like usual Internet, which we use now.
ZK-rollups
Basically, ZK-rollups are Plasma competitors, based on zero-knowledge proofs. There is an awesome podcast from the Basic Block about it (in Russian). You can also read about it here and here, and watch conference talks on youtube — for example, here and here.
Made on
Tilda