Blockchain in the real economy - use case analysis framework

Note: this article is an abridged version  from the corresponding part of the "Blockchain for Cities research"

Blockchain technologies could be applied to all different sectors of the real economy. There are two ways we can analyze a blockchain use case, vertically where we dive into each component of the individual use case, or horizontally, where we compare them across the sectors. This article takes the verticle approach to look at the components of individual use cases; we introduce the horizontal perspective in another article Blockchain for the real economy - Use Case classification methods.

To analyze the common components of any blockchain use case regardless of its application domain, we define an analysis framework as illustrated in Figure 1.

At the top of the framework are what we call writers and readers. They are the parties interacting with the blockchain to conduct transactions. In the center of the framework are the assets, which are the subjects handled by the blockchain transactions. Depending on the use cases, three key properties about these transactions have to be considered: transparency, privacy, and anonymity.

There are three important pillars at the bottom part of the framework describing the underlying blockchain platform: distributed consensus mechanism for the ledger database, smart contracts for business logic, and crypto tokens that belong to the blockchain infrastructure and/or applications.

In terms of the relationship among these components, the writers and readers on top are external to the blockchain and the bottom pillars are internal to the blockchain platform. The assets in the center are the linkage between these two groups. The transparency, privacy, and anonymity requirements of the transactions come from the external use case properties but are fulfilled by the internal blockchain platform. Let us examine the different components.  

ASSETS

A key feature of blockchain applications is maintaining a distributed database that keeps a tamper-resistant transaction record for the associated assets.

Type of assets

On-chain vs. off-chain assets: all blockchain for the real economy use cases inherently involve assets of the real world that are not available on the blockchain. We call these off-chain assets as opposed to on-chain ones that reside directly on the blockchain. Many of the pure cryptocurrency blockchain applications in the finance domain, for example, might only need to deal with on-chain assets.

Digital vs. non-digital assets: assets can be digital or non-digital. Blockchain is a digital platform so on-chain assets are also digital. Off-chain assets may or may not be digital. We consider digital assets to include both assets that are digital by origins such as software code, digital media, and those that could have a native digital representation, e.g., an electronic version of a document. Non-digital off-chain assets may be physical (tangible) or intangible, both need to be digitalized before they can be handled on-chain. This digitalization process is an important part of the blockchain use case implementation.

Digitalization of non-digital assets

Many physical assets have some kind of unique digital identifier that can distinguish them from one another. These identifiers can naturally be their digital representations on the blockchain. Examples include the Electronic Product Code (EPC) of goods, Vehicle Identification Number (VIN) of cars, and Radio Frequency Identification (RFID) tag of cargos. Usually, digital representation of the assets also includes additional attributes depending on the use case, such as the ownership of products, the mileage number of vehicles, the location and temperature conditions of the goods in transportation. Some other physical assets such as natural resources are not easily distinguishable. They can be digitalized using the values of their attributes. For example, water meter reading along with the meter owner's identity can be used as a digital representation of individual water consumption.

Intangible assets can also be digitalized through ownership and values of other attributes. Electricity is an important non-digital intangible asset in the energy sector. Similar to water, it can be represented by the meter owner's identity and digital readings from the meter device.

Bringing digital assets on-chain

Once off-chain assets become digital, they still need to be brought on-chain so that the blockchain can process them. This process could be done through human or machine-based operators. However, an additional step might be needed. Blockchains are known to be notoriously unsuitable for storing large files directly. This is because the mechanism that ensures the blockchain’s immutable and tamper-resistance properties necessitates a lot of expensive cryptographic computations for on-chain transactions. A larger transaction size will make the process even more expensive and results in a very slow network. Therefore, typically only small-sized digital assets are recorded directly on the blockchain. For the majority of the digital assets that require larger space, e.g., those include large documents, images, or videos, the best practice is to store a small digital signature of the original asset on the blockchain and store the original asset off-chain. The signature on the blockchain can be used to verify the original asset when necessary. The decision of whether to store the asset on-chain in full or in digest format is dependent on many practical factors such as what kind of blockchain platform is used and what performance result is needed.

Writers

The writers in the framework refer to parties (humans or machines) who can submit changes to the blockchain database. It is important not to confuse them with the so-called blockchain miners. Miners validate the transactions, reach consensus and commit the transaction records onto the blockchain. They are internal entities of the blockchain network. The writers here are external actors to the blockchain. They initiate transactions that could update the blockchain database, but it is up to the blockchain’s internal mechanisms to accept those updates.

Public, private, and asymmetric writing permissions

Permission to write is an important factor that differentiates the use cases. A use case could allow either public writing (anybody can write) or private writing (only an authorized group of participants can write).

Public writing is common for use cases targeting the general public. In the economic sector, a peer-to-peer market for goods or services is an example that is suitable for public writing.

In many other cases, writing needs to be restricted for an authorized group of participants, either individuals or institutions. In an electronic voting case, for example, writers can be limited to citizens of the specific region for which the voting is conducted.

In addition to private versus public writing, writers may have different levels of writing privileges. In a product ownership registration and tracking system, only the original manufacturers should be allowed to register the new product they produce. The rest of the public could have the right to update the ownership attribute on the record of that product. These roles are not exchangeable and therefore the system involves asymmetric writing privileges.

Readers

The readers in the framework are the parties (humans or machines) who can view transaction records on the blockchain database. Similar to the writing case, the reading of records on the blockchain could also be public or private. Many public-facing use cases such as government policy sharing and public research data sharing adopt the public reading model. Other blockchain use cases enforce private reading where only authorized parties can read. For example, patients' medical records may be accessed only by authorized personnel.

Transparency, privacy, and anonymity of records

Transparency of transaction records is a key value proposition of blockchain. However, most of the use cases that involve off-chain assets often require privacy and anonymity for those transaction records as well.

For the identities of the transaction parties, since blockchain mechanisms typically represent a participant by a cryptographically generated address that consists of a long string of digits and characters unrelated to the real identity, it already provides a level of pseudo-anonymity protection. The real identity and the addresses are in general not linkable unless special traffic forensics techniques are employed. If the contents of the transactions need to be protected from public viewing, they can be explicitly encrypted as well.  

Dedicated privacy-preserving transaction mechanisms such as zero-knowledge proof can also be used to protect the transactions. These mechanisms allow a ‘‘prover’’ to prove that he has knowledge of a secret statement to a ‘‘verifier’’, without revealing the secret itself. When used in blockchain, it ensures that during the interaction, the computer verifying the transaction learns nothing about the transaction other than its validity. Therefore, the identity and content of the transaction can be hidden from the network.

Certain blockchain architectures, such as the permissioned blockchain we will introduce below, are able to restrict who can join the network and their levels of participation. That provides another way of protection for privacy and anonymity in those blockchain networks.

Underlying blockchain technologies

The bottom part of the framework in Figure 1 is the blockchain infrastructure, highlighted by three key components: distributed consensus, smart contract, and crypto token systems.

As we mentioned in our Introduction to Blockchain, the first blockchain Bitcoin is designed for the payment use case with very limited programming capabilities. In comparison, Ethereum is the first and by far the dominant blockchain with full smart contract support, suitable for all types of use cases. Therefore it is a preferred choice for many people looking to apply blockchain in more complicated financial and beyond financial use cases.

However,  many alternative blockchains have also been developed in recent years which optimize for specific types of applications.

Permissionless vs. permissioned blockchain

One important blockchain worth mentioning is HyperLedger Fabric developed by IBM. It is also a blockchain platform that fully supports smart contracts, but it represents a different blockchain architecture. In the Bitcoin and Ethereum blockchain model, anyone can join and participate in their peer-to-peer network. So they are known as permissionless blockchains. This is similar to the Internet model, where any computer can connect and become part of it. HyperLedger Fabric, on the contrary, belongs to the permissioned blockchain category. These blockchains still maintain a distributed ledger, but it also contains a logically centralized identity management system that controls who can access the network. This hybrid model has been popular especially for applications used by industrial consortiums or enterprises.

Distributed Consensus Mechanisms

In the blockchain network, transaction records are enclosed in a structured called block and then committed to a distributed ledger. The distributed consensus mechanism is the critical process to determine which block can be accepted to the ledger. This is akin to agreeing on distributed power allocation because the computer (also called a node) authoring the accepted block is able to change the state of the database shared by every other node.

Proof-of-Work distributed consensus

The Bitcoin blockchain employs a proof-of-work distributed consensus mechanism. In this system, nodes in the network compete for the opportunity to author the next block by calculating a cryptographically sophisticated puzzle. The calculation costs intensive processing power. If a node solves the puzzle and wins the slot, he can propose a block to be included in the distributed ledger. However, to prevent the block proposer from including fraudulent transactions in that block, there is a follow-up implicit consensus process. Basically, other nodes in the network will verify the transactions in the proposed block before deciding on whether to accept that block or not. The verification is possible because of the transaction transparency nature of the blockchain. If the node finds any anomaly in the proposed block, it can reject the block and keep the prior state of the blockchain intact. Otherwise, if everything goes well, the node confirms the new block and accepts the updated blockchain state. The likelihood of a block being rejected diminishes exponentially with the number of acceptance confirmations it receives from different nodes. After a certain number (e.g., six in the case of Bitcoin) of confirmations, the block is considered permanently committed to the blockchain ledger.

Proof-of-Stake distributed consensus

There has been heavy criticism over the proof-of-work mechanism, most significantly because it consumes a lot of energy to perform the intensive computations involved. Currently, Ethereum also uses proof-of-work. But it is in the process of switching to an alternative mechanism called proof-of-stake that eliminates the expensive computational cost. In a proof-of-stake Ethererum network, the nodes compete for the block authoring opportunity by locking the blockchain's native token Ether as a stake. The higher the value of Ethers the node stakes, the more likely the node wins the block authoring slot. However, if the slot winner behaves maliciously by introducing false transactions, the other verification nodes will detect it and the misbehaving node's staked Ether will be slashed as punishment.  

Byzantine fault tolerance distributed consensus

In permissionless blockchains like Bitcoin and Ethereum, consensus mechanisms are competitive in nature. That is because the nodes in those blockchains do not trust each other, and having them put up some stakes (e.g., computing power in proof-of-work, direct economic value in proof-of-stake) to participate in the consensus outcome protects the security of the network.

In a permissioned blockchain like Hyperledger Fabric, the nodes who are authorized to create new blocks are known. This opens up the possibility for a different type of distributed consensus protocol, most notably the Byzantine fault tolerance mechanism. In a typical practical Byzantine fault tolerance environment, nodes are divided into clients and validators. The clients send their transactions to a primary validator, which in turn broadcast the information to other validators. Those validators process the transaction and send a response back to the original client. The client collects at least one-third of the same results from all the validators to confirm the transaction. The Byzantine fault tolerance mechanism has the capability to function successfully in the presence of a certain number of malicious or faulty nodes. It can also achieve much higher performance on transactions per second, specifically, in the order of tens of thousands of transactions compared to roughly single-digit transactions per second for the original Bitcoin blockchain.

Smart contracts

Smart contracts implement the blockchain use case business logic using computer code. The original Bitcoin blockchain was not designed for smart contracts but is still capable of limited scripting functions. Newer blockchains such as Ethereum and Hyperledger Fabric provide full-fledged smart contract programming capability for different kinds of use cases. In our Introduction to the blockchain, we talked about the basics of smart contracts. We also discussed how to categorize blockchain use cases based on the business model that its smart contract realizes.

Crypto token model

In permissionless blockchains, the crypto token model creates an important incentive to align the economic interest of trustless participants in a decentralized environment. Token holders on the blockchain naturally have a vested stake in the success of the specific crypto token and its underlying blockchain infrastructure that supports it.

In contrast, permissioned blockchains have centralized control on participation. They generally do not need the type of crypto tokens serving as incentives to sustain the blockchain infrastructure. However,  crypto tokens could still be helpful at the application level depending on the use cases.

Utility tokens vs. security tokens

Different ways of using crypto tokens come with different token economic models. The two common models are utility and security. Utility tokens mainly provide utility values. For instance, the Ether token is used to pay transaction fees on the Ethereum network. Security tokens offer an important incentive mechanism to the holder. These tokens could entitle their holders to voting rights that decide the future of the blockchain development, or profits sharing with the platform, e.g., from transaction fees. Sometimes the line is not clear between a utility token and a security token. For example, Ether is a utility token to pay transaction fees. But when Ethreume migrates to a proof-of-stake distributed consensus model, holders can stake their Ether and earn rewards, making it like a security. The Howey test is considered an official guide on this topic.

Infrastructure vs. application level tokens

Another way of looking at crypto tokens is to see at which layer they function. We can group crypto tokens into infrastructure-level tokens and application-level tokens. Infrastructure level tokens are directly issued for the underlying blockchain. Ether is the infrastructure token for the Ethereum network and is used for Ethereum blockchain transaction fees.

Crypto tokens can also be created on the Ethereum network by various applications, and these are called application level tokens. With smart contracts opening up a wide spectrum of blockchain applications, these crypto tokens can now represent any tradable asset. These assets can be fungible or non-fungible. Fungible means something that can be replaced by other identical things. For example, a common dollar bill is fungible because we can exchange it with another dollar bill with the same value. Non-fungible things are unique. An original masterpiece painting is non-fungible because it has a dramatically different value from a copy of it. The use of crypto tokens makes implementing many business logic much easier and facilitates programmable asset exchange on the blockchain. For that reason, blockchains such as Ethereum provide standard mechanisms for application token issuance, distribution, and exchange, including for both fungible and non-fungible assets.

Conclusions

In this article, we introduce a component-based common framework for analyzing and comparing blockchain use cases in any application domain. At the center of this framework is the assets that the use case is handling. The writers and readers are the respective entities who conduct transactions on the assets. The records of the transactions need to satisfy the transparency, privacy, and anonymity requirements of the use case. We also highlighted three pillars in the underlying blockchain infrastructure. Smart contracts include computer code that implements the business logic of the use case. Distributed consensus is the key mechanism to maintain the shared ledger in the blockchain system. Crypto token models play important roles in many use cases as part of the utility supporting the blockchain infrastructure, as an incentive to align interests of various stakeholders, and as a way to bring numerous fungible and non-fungible real-world assets to the blockchain space. Finally, security should be an implicit requirement of all the components and the whole system, even though it is not explicitly shown in the framework.

Note: this article is part of my Introduction to Blockchain, Crypto, Metaverse and Web3: Beyond the Hype. You may find the rest of the articles in the series here.