A Taxonomy for Characterizing Blockchain Systems

Since its inception more than a decade ago, blockchain technology has been quickly adopted by a large number of sectors, including finance, healthcare, energy supply, and logistics, due to its numerous benefits, such as decentralization, persistency, anonymity and auditability. However, blockchain applications are intrinsically complex, as they are heterogeneous in nature and require cooperation and interoperation with non-blockchain systems. The complexity of the blockchain systems is further exacerbated by the lack of a clear understanding of their composition. This paper aims to bridge this knowledge gap by proposing a taxonomy for characterizing blockchain systems. The proposed taxonomy classifies a blockchain system into a hierarchy of components: At the top level, the system is organized into an external subsystem, an internal subsystem and an execution environment subsystem. These subsystems are then decomposed into eight fundamental components: Platform, Network, Distributed Ledger, Smart Contract, Consensus Protocol, Digital Wallet, Token, and Node. Each component is further divided into different aspects and each aspect is characterized by various features. This taxonomy thus provides a comprehensive understanding of the composition of a blockchain system, which can better inform software developers in their design and implementation of blockchain systems. The paper presents and illustrates the proposed taxonomy through some application scenarios and a case study.


I. INTRODUCTION
Blockchain technology is a decentralized transaction and data management technology capable of providing security, anonymity, and data integrity without any third-party organization in the control of the transactions [1].Originally developed for Bitcoin cryptocurrency, blockchain technology has now been applied to a wide variety of applications in diverse domains [2], [3], such as education [4], [5], healthcare services [6], smart cities [7], energy supply [8], agriculture and food [9], supply chain management [10], and Internet of Things (IoT) [11].The great potential of blockchain technology lies in its key characteristics of decentralization, The associate editor coordinating the review of this manuscript and approving it for publication was Aasia Khanum .persistency, anonymity, and auditability [12], which make it possible for transactions to be carried out securely without the involvement of a third party.Such a decentralized environment ensures independent control of transactions and data, providing security, anonymity, and data integrity.
However, despite its great potential, developing blockchain applications faces many technical difficulties, as such applications are highly complex and heterogeneous, involving cooperation and interoperation between non-blockchain and blockchain systems.These difficulties are further exacerbated by the lack of a detailed understanding of the composition of blockchain systems.This knowledge gap is considered to be the main obstacle in the design and implementation of highly interoperable blockchain systems [13], [14].With the increased importance of blockchain technology, there is an urgent need for a common terminology to describe the detailed components of blockchain systems.
Although a large number of blockchain taxonomies have been proposed in the literature [13], [15], [16], [17], [18], [19], [20], [21], [22], [23], a comprehensive classification of blockchain systems is still missing.This paper aims to bridge this knowledge gap by proposing a taxonomy for characterizing blockchain systems.The proposed taxonomy classifies a blockchain system into a hierarchy of components: At the top level, the system is organized into an external subsystem, an internal subsystem and an execution environment subsystem.These subsystems are then decomposed into eight fundamental components: Platform, Network, Distributed Ledger, Smart Contract, Consensus Protocol, Digital Wallet, Token, and Node.Each component is further divided into different aspects and each aspect is characterized by different features.The aspects and features are identified inductively and deductively [24].This taxonomy thus provides an elaborate and comprehensive understanding of the composition of a blockchain system, which can be used to inform software developers in their design and implementation of blockchain systems.
The remainder of this paper is organized as follows: Section II provides a brief overview of the blockchain technology and its fundamental characteristics, while Section III reviews related work on blockchain taxonomies.Section IV presents our taxonomy.Section V illustrates the proposed taxonomy through some application scenarios and a case study.Section VI discusses the results and observations through a comparative analysis of the proposed taxonomy and the reviewed literature.Finally, Section VII concludes the paper and suggests future research.

II. OVERVIEW OF BLOCKCHAIN TECHNOLOGY
Since its inception in 2008, blockchain technology has gone through five generations of transformations [25], [26], known as Blockchain 1.0, Blockchain 2.0, etc., as depicted in Figure 1.In 2008, the first generation of blockchain technology was developed to support the transfer of Bitcoin. 1lockchain technology was used to create an immutable, distributed ledger -a record-keeping system -to store data and perform transactions with minimal trust requirements.Business logic is used to exchange cryptocurrencies.In 2013, smart contracts and blockchain were combined in a proposal by Ethereum2 to allow for more complex financial transactions than simple payments and transfers.Such transactions include loans, mortgages, bonds, and stock.Blockchain 2.0 was for money transfer and was based only on cryptocurrencies.In 2015, it became possible to store and exchange physical world assets on blockchains via tokenization, which marked the evolution of Blockchain 3.0; IOTA3 is one such example [27].In 2018, consensus protocols in blockchain systems were empowered by artificial intelligence in Seele 4 as Blockchain 4.0.In 2019, Blockchain 5.0 emerged via Relictum Pro. 5 It restructured blockchains by offering N-dimensional smart contracts.It has expanded blockchain possibilities to enable the formalization of any activity in human life.
According to the literature [28], [29], [30], [31], [32], [33], blockchain technology has these four fundamental characteristics: 1) A Distributed Transactional Platform Supported by a Peer-to-Peer Network.Due to the limited trust and transparency in traditional business models, intermediaries and third parties are required.This requirement makes these models process heavy.Blockchain offers the ability to trust peer-to-peer exchange and automated execution of business contracts.This eliminates the third party and ensures the integrity of processes and data with security and cryptography.The elimination of intermediaries drives a new ecosystem of players and fosters the creation of new profit pools, microeconomies, competitors, consumers, and distributed ecosystems [30].In general, transactions on blockchains can be in the form of transfers, broadcasts, or contract calls.Transfer transactions can be one-or two-way transactions.A one-way transfer is when one participant moves value to another participant with no need to receive value in return, such as ownership transfer and right transfer.A two-way transfer is an exchange between two or more participants, such as cryptocurrency, data, and digital asset exchange.A broadcast is when one participant updates the ledger with value not intended for the participant, such as contract creation transactions.In contract call transactions, an implemented function within a smart contract is invoked by another contract.2) Computational Capability through Smart Contracts.
Blockchain technology offers computational capabilities via smart contracts.A smart contract is a program that defines a set of functions to express highly complex transaction logic [34].These functions enable various blockchain applications in various domains.The capability of a smart contract depends on its operating platform, including its programming language and execution machine.Although smart contracts are assumed to be deterministic by nature, the availability of the required information upon executing a smart contract can affect its determinism [35].When a smart contract requires information from the external world of blockchains, it becomes nondeterministic.Blockchain technology serves two purposes when multiple organizations are involved.First, the correctness of the flow controls and workflow structure is guaranteed as being a repository for business process descriptions.Second, it guarantees the validity of operations as the generated process executions are encoded into smart contracts.
Once transactions are confirmed, data are permanently stored in the ledger, tamper-proof and immutable.Cryptographic mechanisms in blockchains ensure data integrity.Transparency is achieved through public access to the stored data.In addition to these nonfunctional properties, the two significant functionalities of blockchain systems are data storage and computational infrastructure.In addition, blockchain systems can offer data and computation communication, coordination, and facilitation mechanisms as software connectors [28], [29], [36].Given these characteristics, we can claim that blockchain technology has been architected to be secure by design.Its in-built security is derived from the assumption that the peers involved in a transaction are trustless.It was structured from the beginning to safeguard these transactions.In terms of design, blockchain technology includes cryptography and distributed consensus as preventive mechanisms to reduce the risks of cyberattacks.Cybersecurity is necessary to safeguard transactions from external threats.4) Complementary Technology through Interoperability.
Blockchain technology is a sophisticated complement to current technologies rather than replacing them.
Although systems built on top of blockchains can operate alone, there is a need to communicate with other centralized or distributed systems in real business.To a large extent, a blockchain system needs to be interoperable with other blockchain or nonblockchain systems.However, the closed execution environment of a blockchain system does not allow smart contracts to interact directly with external servers or states.Thus, unique approaches to blockchain interoperability have been developed [39].They are oracles [28], [36], hash locking [40], [41], [42], notary [41], [42], relays [41], [42], and application programming interface (API) gateways [43], [44].Blockchain interoperability approaches can be classified into three categories.The first is non-blockchain to blockchain, where data are passed from traditional systems to blockchain systems.The second is a blockchain-tocompatible blockchain, where cross-chain data transfer is enabled between compatible blockchains.The last category is blockchain-to-non-compatible blockchain, where cross-chain data transfer is enabled between non-compatible blockchains.
• Peer-to-Peer Network: A computer network formed by two or more interconnected computer systems (nodes).The systems on the network are equal (thus called peers) and can share resources without requiring a central server.
• Distributed Ledger: A shared, decentralized database system in the blockchain network that provides a transparent, immutable, and cryptographically verifiable transaction record.The ledger has built-in mechanisms that prevent unauthorized transaction entries and enforce consistency in the shared view of the recorded transactions.Unlike traditional distributed databases, distributed ledgers do not have central data storage or special administrative functionality.
• Consensus Protocol: A set of rules based on which users of a blockchain application can reach an agreement or consensus.
• Smart Contract: A computer program that can automatically execute transaction agreements between multiple participants.
• Token: A digital asset that represents cryptocurrency or a real-world object.
• Digital Wallet: A program that stores and manages digital keys and digital assets for blockchain users.
• Node: A computer system on the blockchain network.
Nodes are used to store the aforementioned distributed ledgers, consensus protocols, smart contracts, tokens, and digital wallets.

III. RELATED WORK
Numerous studies have attempted to classify the characteristics of the blockchain technology.The utility of this taxonomy was demonstrated through an illustrative scenario using six crypto assets.Schulze et al. [17] proposed a taxonomy of blockchain platforms.The taxonomy consists of 10 dimensions and 26 characteristics organized in a morphological box.The dimensions are orientation, system architecture, ownership, interaction, governance, access, transaction validation, consensus difficulty, codebase, and reference type.The utility of the taxonomy was illustrated using a single blockchain platform.
In the context of distributed trust and reputation management systems (DTRMS), blockchain technology has been addressed by Bellini et al. [18].The authors aimed to provide a guide for adapting blockchain technology in DTRMS.For this purpose, they developed two taxonomies: the first one is for blockchain technology, and the other one is for DTRMS.Then, a formal concept analysis was applied to the proposed taxonomies to identify the most stable and recurrent features between both taxonomies.The study identified nine dimensions and 24 characteristics organized in a tree structure.The dimensions are openness, access management, business logic, data, ledger distribution, fee, tokenization, consensus protocols, and type.The utility of the taxonomy was not demonstrated.
Another contribution to crypto-assets was due to Arslanian and Fischer [22], who addressed the lack of a universally accepted classification system for such assets and proposed a simplified crypto-asset taxonomy.Their taxonomy consisted of two nested dimensions and five characteristics, which were organized into a hierarchy.The taxonomy was not evaluated.
The study by Tasca and Tessone [13] contributed to the standardization of the classification of blockchain technology.It provided a hierarchical classification of blockchain characteristics.This study aimed to understand the architectural configurations of the technology.Blockchain systems were decomposed into functional and logical components.However, the taxonomy-building approach and the classification basis were not described.Their proposed taxonomy consists of eight dimensions: consensus, transaction capabilities, native currency/tokenization extensibility, security and privacy, codebase, identity management, and charging and rewarding system.The taxonomy consisted of 37 nested dimensions and 72 characteristics.However, the utility of the taxonomy was not demonstrated.
The work by Wieninger, Schuh and Fischer [15] provided different variations in blockchain systems beyond the popular classification of public, private, and hybrid systems.It enabled the differentiation of blockchain types by systematically classifying the fundamental characteristics of the technology in a morphological box.The proposed taxonomy consisted of 11 dimensions: authorization to view transactions, right of proposal, validation of transactions, awareness of identities, type of token, incentive for validation, location of the asset, possibility of change, source code, consensus mechanism, and Turing-complete.In total, the taxonomy consisted of 11 dimensions and 27 characteristics.The utility of the taxonomy was illustrated using a single blockchain platform.
With the goal of investigating blockchain characteristics similar to ours, Sarkintudu et al. [19] developed a taxonomy of financial blockchain platforms.That taxonomy aimed to address the complexity of blockchain implementation to enable access to its full potential.The taxonomy was structured as a table with five columns (dimensions): Operation mode, visibility, task, design architecture, and consensus mechanism.In total, the taxonomy consists of five dimensions and 15 characteristics.The utility of the taxonomy was demonstrated using 24 blockchain platforms.
An earlier taxonomy that addressed the characteristics and classifications of tokens was proposed by Oliveira et al. [23].The proposed taxonomy was organized into four dimensions: purpose, governance, functional, and technical.In total, the taxonomy consisted of 17 nested dimensions and 40 characteristics.This taxonomy was evaluated through a case study.
The study by Tönnissen and Teuteberg [20] focused on smart contracts as the fundamental blockchain components.The study aimed to systematically classify terminology related to smart contracts in order to facilitate the investigation of current use cases and future challenges of smart contracts.The taxonomy consisted of nine dimensions and 24 characteristics which were organized into a table.The dimensions were subject matter, function of contracts, time horizon, ability to renegotiate terms, involvement of consumers, existence of mutual trust, sub-categories of contracts, trigger, and cost of altering.This taxonomy was evaluated by interviewing experts.
One of the earliest works on blockchain classification was by Xu et al. [16].It aimed to address architectural considerations about blockchain and blockchain-based systems.The proposed taxonomy captured major blockchain architectural characteristics.The taxonomy grouped these characteristics into four main dimensions: decentralization, blockchain configuration, storage and computation, and other architectural designs and deployment.Within each dimension, a classification system was structured as a table.A total of 30 nested dimensions and 42 characteristics were identified.Although blockchain examples were used to illustrate the taxonomy, no evaluation was carried out.
Table 1 summarizes the above reviewed taxonomies based on the eight fundamental architectural components described early.As can be seen, none of these taxonomies has considered all these components.Our taxonomy aims to provide a comprehensive blockchain taxonomy based on these eight components.

IV. THE PROPOSED TAXONOMY
An overview of the proposed taxonomy is given in Subsection A. Subsections B to D present a thorough analysis of the blockchain components and their characteristics.

A. OVERVIEW
The proposed taxonomy classifies a blockchain system into five levels, as shown in Figure 2, comprising the systemlevel, the subsystem-level, the component-level, the aspectlevel, and finally, the feature-level.At the system-level, a blockchain system is decomposed into three subsystems, made up of an Execution Environment, an Internal and an External subsystem.At the subsystem-level, a subsystem is divided into a set of architectural components, based on the eight fundamental components of blockchain systems introduced in Section II.At the component-level, a component is divided into a set of aspects (or sub-components).At the aspect-level, each aspect is instantiated by a specific feature (or characteristic), selecting from a set of alternative features.Some features may be further divided into sub-features.The top three levels of our taxonomy are shown in Figure 3.
In what follows, we describe our taxonomy for each subsystem and the relationships (Compositional or Alternative) between its various constituents.

B. EXECUTION ENVIRONMENT SUBSYSTEM
The Execution Environment subsystem consists of a Network, one or more Distributed Ledgers, and a Platform.Each of these components is decomposed into several aspects and each aspect is composed of one or more features.The classification of this subsystem is depicted in Figure 4 and described as follows.

1) NETWORK
A blockchain system is based on a peer-to-peer (P2P) computer network.This network is characterized by six main aspects: Openness, Chain Structure, Access Control, Membership Entity, Member Registration, and Member Identity.Each of these aspects is characterized by a set of features.For example, the Openness aspect of the network is characterized by the features of Public, Private and Federated.Based on these features, a blockchain network can be either public, private or federated.Public networks are open-access and, typically, all the participating nodes can read from and write to their respective ledgers.Private networks are restricted and owned by an organization, where the permission to read and write is maintained within the organization's members.Federated networks are private networks shared by multiple organizations.
The Chain Structure aspect of the network is characterized by Single Chain and Multi Chain.Based on these features, a blockchain can be composed of a single chain or multiple chains.The remaining three aspects, Membership Entity, Member Registration, and Member Identify, are used to describe different characteristics of the participants of the blockchain applications, such as if a participant is a single organization or joint multiple organizations; if the identity of the participants is known to the network or not, as Figure 5 shows.

2) DISTRIBUTED LEDGER
Distributed ledgers are key to the blockchain technology.They record all the transactions committed by the participants of a blockchain network [28], [29].The ledger component is characterized by four aspects: Ledger Architecture, Data Structure, Transaction Model, and Access Control.There are three types of ledger architecture [47]: Single-Ledger Based, Multi-Ledger Based, and Interoperability Based.These three architecture types are briefly described here: The Single-Ledger Based architecture was introduced as a public permissionless solution to serve different application industries, such as supply chains and transportation.Two modifications were made to this public architecture to enable private and hybrid settings.First, a handshaking mechanism and a certificate authority are added to the architecture to solve the issue of openness in public settings.Thus, the architecture can fit into private settings.Second, a constellation component was introduced into the public architecture to make it applicable to hybrid settings [47].
The Multi-Ledger Based architecture is explicitly introduced for private and federated networks to allow confidential transactions within a consortium or single organization.This architecture involves more encryption and decryption operations than hybrid networks with single-ledgerbased architectures.The Interoperability Based architecture has been introduced as a solution to the issue of interoperability between incompatible single-ledger-based blockchains.It can also be adapted for multi-ledger-based blockchains [47].
The data structure of a ledger can be classified as Chain-Based or Directed Acyclic Graph (DAG)-Based [28], [38], [48], [49].Under the Chain-Based structure, a ledger is structured as a list of blocks.DAG-Based structure links data in a directed acyclic graph in a tree instead of a list.
The Transaction Model aspect has three features: Transaction-Based, Account-Based, and Token-Based.Under the stateless Transaction-Based model, tokens are stored in a list of unspent transaction outputs (UTXO).Existing UTXOs are used as inputs for new transactions, which subsequently produce new outputs in their place.Under the stateful Account-Based model, tokens are stored as a balance within an account controlled by a private key or a smart contract.under the stateful Token-Based model, each token has independent data space to store the complete history of the token's ownership.

3) PLATFORM
The blockchain platform provides an operational context and an execution environment of blockchain systems [50].The platform component contains nine aspects, as Figure 4 shows.The Architectural Design aspect of the platform can be divided into three features: Monolithic, Polymorphic, and Modular.A monolithic platform offers services as a bundle with no distinctive architectural separation.A polymorphic platform provides a clear separation of different functions of the platform.A modular platform offers a mean of customization.
The Supported Solutions aspect characterizes if a blockchain platform is Permissioned or Permissionless.
The Energy Consumption aspect has two features: Power Intensive and Energy Saving.The Incentive Mechanism aspect has two sub-aspects: Fee and Reward.The Fee aspect has two sub-aspects: Eligibility and Calculation.The Eligibility characterizes if transaction fees on a blockchain platform are Mandatory, Optional, or Zero.The Calculation determines if a fee is calculated Per Byte, Per Operation, or None.The Reward aspect has four features: Block Reward, Participation Reward, Archiving Reward, and Not Applicable.
If the platform supports the execution of smart contracts, it has specifications for the programming language and execution machines.The Smart Contract Support aspect contains four sub-aspects: Execution Machine, Programmability, Programming Languages, and Turing Completeness.The Execution Machine aspect has four features: Native, Virtual Machine, Container, and Not Supported.The Programmability aspect has three features: Built-in, Programmable, and None.The Programming Languages aspect has three features: Single Language, Multiple Languages, and None.The Turing Completeness aspect has two features: Turing Complete and Turing Incomplete.
The Asset Support aspect has two compositional features: Native Token and Custom Token.The Permission Support aspect characterizes different levels of permissions that are supported by a blockchain platform, if any.This aspect has four features: Network-level, Smart Contract-Level, Ledgerlevel, and None.
The Technical Support aspect consists of three sub-aspects: Deployment, License, and Governance.The Deployment aspect characterizes if a blockchain platform is deployed On Premise or Blockchain-as-a-Service.The License aspect characterizes if a blockchain platform is Open Source or Closed Source.The Governance aspect characterizes if a blockchain platform is supported by a Community, an Alliance, or a Foundation.
The Business Support aspect consists of two sub-aspects: Purpose and Industry.The Purpose aspect has two features: General Purpose and Specific Purpose.The Industry aspect has two features: Cross-Industry and Industry-Specific.

C. INTERNAL SUBSYSTEM
The Internal Subsystem is characterized by three main components: Consensus Protocol, Smart Contract and Token, as Figure 5 shows.These components and their classifications are described as follows.The Finality aspect refers to the property in which a valid block cannot be pruned once it is appended to the blockchain.It has two features: Probabilistic and Absolute.Under this aspect, a consensus protocol can be characterized as Probabilistic or Absolute.Typically, the consensus finality is absolute in voting-based protocols, whereas it is probabilistic in computation-based protocols.The finality of the factor-and combination-based protocols is determined based on their implementation.
The Network Access Control aspect has two features: Permissioned and Permissionless.Different consensus mechanisms are applied in public and private network settings [51], [52].Under this aspect, a compatible blockchain network can be characterized as a permissioned or permissionless.
The Trusted Hardware Utilization aspect indicates whether a specialized hardware is required for implementing the consensus mechanism, such as Intel SGX or ARM TrustZone.It has two features: Required and Not required.

2) SMART CONTRACT
A smart contract source code is deployed on the blockchain by passing its code as transaction data, and the code then becomes immutable.Each contract is represented in the blockchain using a unique address.This address is used to invoke functions inside the contract.These functions can examine conditions, express logic, create new contracts, or terminate their containing contract [28], [38].A smart contract source code consists of functions and events.When a smart contract is terminated, the contract remains on the blockchain, although the contract no longer responds to transactions.This is evident because of the immutability of the blockchain, where the smart contract code is its data.This immutability of a smart contract gives it the characteristic of being a firmware program.For a smart contract to be updated, its current version must be terminated, and then a new version must be deployed on the blockchain.
It is worth mentioning that smart contracts should not be miscategorized as legal contracts.On one hand, a legal contract exists as an agreement between two or more parties.On the other hand, a computer program is a collection of functions and procedures within a source code executed by a computer machine.However, smart contracts are programs that can conditionally transfer digital assets between parties predictably and transparently, which may provide evidence of the ability of smart contracts to facilitate the execution of a legal contract [28].
This component is characterized by five aspects: Hosting Network, Type, Interaction, Events, and License.It is a programming language-agnostic classification that aims to describe concrete smart contract instances.The smart contract execution environment is discussed earlier in this paper as part of the blockchain platform.This taxonomy focuses on classifying concrete instances of smart contracts that deliver business logic to the blockchain systems.The Hosting Network aspect characterizes if a smart contract is deployed on a Mainnet or Testnet.The Type aspect characterize the business logic implemented in the smart contract.Under this aspect, a smart contract can be characterized as Legal, Application, Token, Organization, or Thing contract.Smart Legal contracts encode legally enforceable agreement terms among multiple parties as smart contracts on the blockchain [53].Application contracts express the possible business logic and functions of DApps.Organization contracts refer to decentralized autonomous organizations (DAO).They are complex smart contracts that encode an organization's management and operational rules to allow autonomous operation without the need for a central authority [54].Thing contracts are smart contracts used to register and manage IoT devices [55], [56].
The Interaction aspect has two features: Machine-to-Machine and Human-to-Machine.In the former, smart contracts are invoked and executed by node devices with no human interactions, such as contracting devices in the IoT.In the latter, the invocation of a smart contract involves human interaction, such as in the application and smart legal contracts.These interactions can be recorded in terms of the events.
The Event aspect indicates if there are any events defined by the programmer in the smart contract.It has two features: Defined and Not defined.The License aspect characterizes if a smart contract is open-or closed-source.

3) TOKEN
Blockchain systems offer the distinctive ability to record the existence and transfer of digital assets [28].These assets are known as tokens and can represent real-world objects [38].Numerous taxonomies of digital assets have been proposed in the literature as well as in the industry, such as those by the International Token Standardization Association 6 and Enterprise Ethereum Alliance. 7In addition, a token design decision tree has been proposed to aid the design process of digital tokens when developing blockchain applications [23].This component is characterized by 13 aspects: Layer, Purpose, Standard, Fungibility, Underlying, Underlying Asset Ownership, Transferability, Expiry, Flow, Offerings, Supply, and Issuance.
The Layer aspect considers the technical foundation of the token.It has two features: Native and Secondary.Native tokens are platform-specific tokens that are implemented as a core component of the platform, mostly as a cryptocurrency, The second-layer tokens support the application functions and are called application tokens.Application tokens can be created if the platform supports programmable smart contracts.In some cases, these tokens are implemented on side-chains rather than on the main chain.Hence, they are called side-chain tokens.An application token or a sidechain token; is a secondary token implemented on top of the blockchain main layer.
The Purpose aspect has three features: Utility, Stability, and Security.The Standard aspect considers if the token is implemented according to a token standard [57], such as Ethereum Request for Comments 20 (ERC20) 8 and Simple Asset Standard [58].This aspect has two features: Standardized and No Standard.The Fungibility aspect characterizes a token as Fungible or Non-fungible.
The Underlying aspect characterizes the assets represented by a token, if any.It has three features: No Underlying, A Cryptographic Asset, and Non-Cryptographic Asset.In addition, because tokens can represent real-world assets, the ownership of the underlying assets should be considered.The Underlying Asset Ownership aspect refers to the divisibility of the assets represented by the token.For example, multiple people can own a piece of art.Whole ownership means that an asset is owned by one party.By contrast, fractional ownership means that the asset is logically divided into pieces, and a different party owns each piece.Tokens in the blockchain represent this ownership.This aspect has three features: Whole, Fractional, and Not Applicable.
The Transferability, Expiry, and Flow aspects consider the circulation of a token.The Transferability aspect has two features: Transferrable and Non-transferrable.The Transferrable feature has two sub-features: Absolute and Constrained.The Expiry aspect characterizes the lifetime of the token.Under this aspect, a token is characterized as Expirable or Non-Expirable.The Flow aspect has two features: Linear and Circular.
The Offerings, Supply, and Issuance aspects consider economical foundation of a token.For example, some tokens are issued in a limited or unlimited manner, some are issued when a condition is met, such as mining, whereas others are issued all at once in advance [57], [59], [60], [61].The Offering aspect has four alternative features: Initial Coin-Or Token-Offering (ICO/ITO), Initial Exchange Offering (IEO), Security Token Offering (STO), and Revenue Models.The Supply aspect has two alternative features: Limited and Unlimited.The Issuance aspect has two alternative features: Once and Conditional.

D. EXTERNAL SUBSYSTEM
The External Subsystem is characterized by two main components: Node and Digital Wallet, as Figure 6 shows.These components and their classifications are described as follows.

1) NODE
Nodes are the fundamental elements and communication devices in blockchain networks.They retain ledgers, host smart contracts, execute transactions, and generate blocks.
Ideally, a single-blockchain network can have multiple node types.However, logically, a single full node can operate the network.Nodes and clients are closely related.A node is a hardware device (e.g., computer system) in the network whereas a client provides the interface for the node.For example, Raspberry Pi4 is a node hardware where Geth Ethereum client software can be installed.
This component is characterized by 10 aspects: Category, Role, Operation, Ledger Copy, Ledger Synchronization, Hardware Requirements, Chain Support, Deployment, Access Centralization, and Geolocation.
The Category aspect has four features: Full, Light, Pruned, and Service.The Full nodes are responsible for supporting consensus and verifying transactions or mining, as they store a full copy of the blockchain.The Light nodes rely on full nodes to acquire the required information when communicating with the blockchain.The Pruned nodes store a full copy of a subset of transactions according to a predefined limit and store transaction headers for old transactions.Finally, the Service nodes coordinate the workflow between the network's nodes and do not update the ledger.
The Role aspect has four features: Archive, Block Validation, Data Verification, and Utility.Archive nodes are full nodes that store a complete historical copy of the ledger.Validator nodes are full nodes responsible for consensus and block generation, such as miner and notary nodes.The data verification nodes are light nodes that do not validate blocks.Thus, they need only transaction headers to verify transactions as in simple-payment-verification clients, or possibly no data are synchronized as in minimal verification clients such as incubed (IN3) clients.Finally, service nodes provide utility to the network in aspects other than ledger-oriented operations.For example, proxy nodes in the Klaytn network coordinate the transmission of information between other nodes in the Klaytn network.
The Operation aspect characterizes the operations performed by a node.It has two features: Ledger-Oriented and Network-Oriented.The full, pruned, and light nodes perform ledger-oriented operations that uses and update ledger data.
The Ledger Copy aspect has four features: Full, Partial, Headers only, and None.In contrast to full and pruned nodes, light nodes do not store a copy of blockchains; thus, they cannot validate the blocks.However, they can broadcast transactions and query the blockchain [45], [62].Although archive and validator nodes store a full copy of the ledger, the data stored in archive nodes include intermediate states to build the history of the blockchain.
Nodes may need to maintain a copy of their ledger according to their role.Thus, they need to be synchronized in different ways [63], [64], [65].Regardless of the approach adopted, data to be synchronized and synchronization starting point are fundamental aspects from a classification perspective.The Ledger Synchronization aspect has three sub-aspects: Requisite, Data, and Starting Point of synchronization.The Requisite aspect has two features: Required and Not Required.The Data aspect has four aspects: Block Header, Block Data, Intermediate States, and None.The Starting Point aspect has three features: Genesis, Checkpoint, and None.
Nodes can be any electronic device with sufficient power and technical requirements to perform a job on the network.The Hardware Utilization aspect characterizes the machine used for a node.Under this aspect, a node is characterized as Servers, Computers, Mobile Devices, or IoT Devices.The Chain Support aspect consider the number of networks a node can operate.This aspect has two alternative features: Single Chain and Multiple Chains.
Nodes and clients can be deployed locally on a user's qualified machine, remotely on the cloud in a kind of centralization as the cloud provider controls it, or on a decentralized preconfigured node.Multiple nodes of a single network can be in different geographical locations.The Deployment aspect has two features: On Premise and Node-as-a-Service.The Access Centralization aspect has two features: Centralized 3 rd Party and Decentralized.The Geolocation aspect has seven features: Asia, Africa, North America, South America, Antarctica, Europe, and Australia.

2) DIGITAL WALLET
A digital wallet is used to manage digital assets in blockchains.This component is characterized by 10 aspects: Tangibility, Type, Recovery Mechanism, Custody, Internet Connection, Signing, Supported Tokens, In-Wallet Exchange, Deployment, and Integration Capability.The Tangibility and Type aspects describe the nature of a digital wallet.The Tangibility aspect has two features: Tangible and Intangible.The Type aspect has eight features: Hardware, Paper, Smart Contract, Web, Mobile, Desktop, Browserbased, and Interface.The Browser-based feature has two sub-features: Built-in and Extension.Tangible digital wallets include hardware and paper wallets.The hardware wallets are devices used to store public and private keys in an air gapped environment.A paper wallet is simply a piece of paper with encrypted digital keys printed on it.Intangible wallets are software programs.Smart contract wallets use smart contracts to store assets, adding a unique capability for security and recovery [66].
A user's private key is the only way to manage their digital assets.If lost, it cannot be recovered unless the anticipated wallet has a mechanism for key recovery.The Recovery Mechanism aspect has five features: Passphrase, Guardian, Seed Phrase, Password-Derived Keys, and None.
The Custody aspect has two features: Custodial and Non-Custodial.Custodial wallets are centralized key stores in which users' private and public keys are stored on a server.Users must provide valid passwords to access their wallets and retrieve their keys to manage their own digital assets.In contrast, non-custodial wallets do not save users' data remotely.Instead, public and private keys are stored in a usermanaged storage.
The Internet Connection aspect has two features: Hot and Cold.Whenever a wallet requires an Internet connection to be accessed, it is a hot wallet.This is in contrast with cold wallets, which are air gapped.For example, hardware and paper wallets are cold wallets, whereas software wallets are hot ones.However, there are situations in which software wallets support cold storage when used in an air-gapped environment.
The Signing, Supported Tokens, and In-Wallet Exchange aspects consider the transaction management.Although typical blockchain transactions require only one signature, there are situations in which multiple signatures are required for a single transaction.Hence, a multi-signature (or multi-sig) wallet is required.The Signing aspect has two features: Single-Signature and Multi-Signature.
A digital wallet can support one or more types of digital assets.The Supported Tokens aspect has two features: Cryptocurrency, which is further categorized as Single Cryptocurrency and Multi Cryptocurrency, and Crypto Assets, i.e., non-cryptocurrency tokens.In addition, some wallets are capable of token exchange.The In-Wallet Exchange aspect has two features: Supported and Not Supported.
The Deployment aspect considers where a wallet is deployed.Under this aspect, a digital wallet is characterized as In-App or Stand-alone.Stand-alone wallets are further categorized as Local or Remote.Digital wallets can be integrated with other wallets.The Integration Capability aspect has two features: Integrable and Non-Integrable.The Integrable feature characterizes if the integrated wallet is a Hardware Wallet or Software Wallet.

V. DEMONSTRATING THE PROPOSED TAXONOMY
In this section, we demonstrate our taxonomy by using it to characterize real-world blockchain systems.Based on the design science methodology [67], in the following subsections, we first characterize individual software components in different blockchain systems; we then provide a case study for characterizing a specific blockchain system.

A. CHARACTERIZING INDIVIDUAL BLOCKCHAIN COMPONENTS USING THE PROPOSED TAXONOMY
In this subsection, the proposed taxonomy is used to classify different software components in 80 different blockchain application systems and components we found from the Internet.They are listed in Table 2.

1) CHARATERIZING EXECUTION ENVIRONMENT COMPONENTS a: NETWORK
From the list of blockchain systems presented in Table 2, we identified 10 state-of-the-art blockchain networks for characterization.The results of the characterization using our taxonomy are presented in Table 3. Table 3 shows that, in terms of the Openness, out of the 10 networks, five are public networks (Bitcoin, Etherum, Ardor Parent Chain, Ardor Child Chain, and Klaytn Service Chain), two are purely federated (Corda and Hyperledger Iroha), one is private only (Ardor Private Child Chain), and two allow for both private and federated implementations (Hyperledger Fabric and Klaytn Service Chain).With respect to the Chain Structure, three out of the five (3/5) public networks and one out of the four (1/4) federated networks are single chains, whereas the other six networks are multi-chained.For the Membership Entity, five networks are open for individuals, three are for single organizations, and four are for multiple organizations.Finally, for the Access Control, Member Registration, and Member Identity, we can see an equal distribution of the features for each network.For example, for the Access Control aspect of the network, five networks require permission whereas another five do not.

b: DISTRIBUTED LEDGER
From the list of blockchain systems presented in Table 2, we identified 10 state-of-the-art blockchain distributed ledgers for characterization.The results of the characterization using our taxonomy are presented in Table 4.For conciseness, the analysis of this table is omitted, but a similar analysis as for Table 3 applies.

c: PLATFORM
From the list of blockchain systems presented in Table 2, we identified 10 state-of-the-art blockchain platforms for characterization.The results of the characterization using our taxonomy are presented in Table 5.In Table 5, for the Architectural Design aspect, four platforms are Monolithic, four are Polymorphic, and two are Modular.For example, Hyperledger Sawtooth is a Modular Platform for enterprise solutions.
For the Supported Solution, six support the implementation of Permissioned applications, three support Permissionless applications, and one supports both.Furthermore, of the seven platforms supporting permissioned solutions, one supports permissions on all the three permission levels, one platform supports only network-level permissions, and five platforms support network and ledger permissions.
In term of Energy Use, eight platforms are based on Power Saving, whereas only two are Power Intensive.For the Incentive Mechanism, six platforms calculate transaction fees per operation, where the fees are mandatory in five other platforms.Whereas the Reward mechanism is not applicable to five platforms, block rewards are applicable to four other platforms, participation rewards are applicable to two platforms, and archiving rewards are applicable to only one platform.
For the Smart Contract Support, seven platforms support programable smart contracts, of which five execute such contracts in virtual machines, whereas two execute them in containers.For the Asset Support, two platforms support only native tokens, five platforms support only custom tokens, and three platforms support both native and custom tokens.For the Business Support, all the 10 platforms are cross-industry, including seven general-purpose and three purpose-specific platforms.
Finally, for the Technical Support, nine platforms are open-source and to be deployed on premises, whereas seven of them are governed by a community of developers, one is governed by an alliance, and one is governed by a foundation.IBM Blockchain is the only closed-source platform.

2) CHARATERIZING INTERNAL COMPONENTS a: CONSENSUS PROTOCOL
From the list presented in Table 2, we identified 11 state-ofthe-art consensus protocols for characterization.The results of the characterization using our taxonomy are presented in Table 6.Of these protocols, two are computation-based with probabilistic finality for permissionless networks, one is combination-based with probabilistic finality for permissionless networks, four are voting-based with absolute finality for permissioned networks, and four are factor-based, including one with absolute finality for both permissioned and permissionless networks, and three with probabilistic finality, where two of them are for permissionless networks and one is for both permissioned and permissionless networks.Only one protocol requires the utilization of trusted hardware.
b: SMART CONTRACT Table 7 presents the characterization of 11 smart contracts listed in Table 2. Of the 11 smart contracts given in Table 7, six are application contracts deployed on a Mainnet for Human-to-Machine interactions, four are token contracts for Human-to-Machine interactions including three are deployed on a Mainnet and one is deployed on a Testnet, and one is a thing contract deployed on a Testnet for Machine-to-Machine interactions.All the 11 smart contracts are open source and include user-defined events.

c: TOKEN
We randomly selected 11 tokens from the systems listed in Table 2.The characterization of these tokens is presented in Table 8.Some of these tokens are briefly introduced here: Ether (ETH) is the cryptocurrency of Ethereum.CryptoKitties CK is the application token of CryptoKitties DApp.STEEM, Steem Power SP, and Steem Dollar tokens are fundamental asset classes of the Steem blockchain.DTC is the application token of Dtube DApp, a Steem-based application for video sharing.AFIT is the application token of ActiFit, a Steem-based mobile DApp for promoting healthy habits.Geon coin GC and Geon token GT are application tokens of Geon, an augmented reality application provides locationbased incentives by rewarding its users for physical presence and other real-world location activities.SPiCE is a security token provided by SPICE VC, a venture capital firm that uses the blockchain technology to solve the liquidity problem.
IMMO is the application token of Blockimmo, a decentralized marketplace for tokenized property in Switzerland.
Of these 11 tokens, five are Native Tokens, of which three are for utility, one for stability, and one for security.The remaining six tokens are Secondary, including four for utility, one for stability, and one for security.Of the 11 tokens, eight are Standardized Fungible Tokens, two are Non-Standardized, and one is a Standardized Non-Fungible token.Six tokens are not the representations of an underlying asset, whereas two represent wholly ownable cryptographic assets, two represent wholly ownable noncryptographic assets, and one represents fractionally ownable non-cryptographic assets.In terms of the Expiry aspect, nine tokens are non-expirable where eight are transferable in a circular flow and one is constrainedly transferable in circular flow.Two of the 11 tokens are expirable and transferable in circular flow absolutely for one and constrainedly for the other.
For the four tokens offered via ICO\ITO, one token has a limited supply issued all at once, and three tokens have an unlimited supply issued conditionally.All three tokens offered via a revenue model are issued conditionally, where two tokens have limited supply and one token has an unlimited supply.The two tokens offered via STO have a limited supply, where one is issued conditionally, and the other is issued all at once.The last two tokens are offered via IEO and issued conditionally with a limited supply for one token and an unlimited supply for the other token.

3) CHARATERIZING EXTERNAL COMPONENTS a: NODE
A blockchain network usually contains multiple nodes.Based on the client environment, each node may have different characteristics.Thus, nodes as individual components are TABLE 6. Characterizing 11 consensus protocols in real-world systems using the proposed taxonomy.
typically classified by their owners, as the owners have the of the client environment.In this paper, we characterize the network nodes through the Publicly Accessible Environment Sensor Use Case from IN3 Network. 9This use case describes the use of different nodes and clients in IoT applications in the city of Stuttgart.The characterization of the primary nodes in the use case is given in Table 9.
Of the four nodes, one performs ledger-oriented operations, two perform network-oriented operations, and one performs both operations.For the chain support, one node supports a single chain which is a light node, and three nodes support multiple chains including two service nodes and one full node.Of the four nodes, two are servers, one is a computer, and the other is an IoT device.One node requires synchronization of the block data from the genesis block to participate in block validation.Another node requires synchronization of block headers from a checkpoint to participate in data verification.The remaining two nodes do not require ledger data.On premises and node-as-a-service deployments are in an equal measure.The access to all the four nodes is decentralized.
b: DIGITAL WALLET An example of applying the digital wallet features to a set of state-of-the-art digital wallets is presented in Table 10.Of the 13 wallets, two are tangible hardware and 11 are intangible.Of the 11 intangible wallets, three are mobile app wallets, two are web app wallets, two are smart contract 9 https://in3.readthedocs.io/en/develop/intro.html wallets, and one wallet for each other types.For the recovery mechanism, the seed phrase has a significant number of eight wallets, three wallets have no recovery mechanism, and the other mechanisms have equal measures of one wallet each.Most of the wallets are non-custodial, totaling 12 out of the 13 wallets.Out of 13, seven wallets support both multi-currency and crypto-assets, five wallets support only cryptocurrencies including one wallet supports only a single cryptocurrency, and one wallet supports only crypto-assets.Only one of the 13 wallets supports multiple signatures.The in-wallet is supported by seven wallets of the 13. the wallet deployment, eight support local deployment, two wallets support remote deployment, and two wallets support both deployments.For the integration capability, six out of the 13 wallets are non-integrable, six are integrable with other software wallets, and five wallets are integrable with other hardware wallets.

B. CASE STUDY: CHARACTERIZING AN ENTIRE SYSTEM USING THE PROPOSED TAXONOMY
In this case study, we use our taxonomy to characterize the CryptoKitties application system, 10 a blockchain based computer game for breed-able virtual cats known as Cryp-toKitties (CK) tokens.The game was developed to support blockchain technology education through gamification, as its key mechanism is tied to crypto-assets and smart contracts.CryptoKitties is a featured decentralized gaming application and has been used in several studies [48], [77], [78].Here  we characterize CryptoKitties in terms of its fundamental components, aspects and features.

2) INTERNAL COMPONENTS
The application's internal components consist of PoW as consensus protocol (see Table 6); five smart contracts: Kitty Core, Siring Clock Auction, Sale Clock Auction, Gene Science, and Offer: (see Table 7); and two tokens: ETH and CK (see Table 8).

3) EXTERNAL COMPONENTS
The application has no built-in wallet.Therefore, players must use a stand-alone wallet that supports cryptocurrencies and crypto-assets to use the DApp (see Table 9).Players do not need full nodes However, if a player wants to participate in block validations and, hence, in the overall security of the chain, there is a need to deploy an Ethereum node.The CryptoKitties frontend is a web-based client-server application.It uses relational databases to replicate on-chain data related to the events emitted by the smart contracts.Players must purchase ETH to start buying, selling, and breeding kitties.It requires users to create accounts for the first time.They can then log in using their digital wallets.
CK is non-fungible and represents unique virtual kitties with different visual appearances at varying levels of rarity.These kitties can be sold, bought, gifted, and never die.
Ethereum requires fees to be paid in ETH per transaction on its network.Thus, players must pay fees to place a bid or cancel an offer.This has implications for the game logic of CryptoKitties.On the one hand, an innovative auction mechanism is designed to minimize on-chain transactions and achieve a better user experience.It is a descending clock auction where sellers pay gas fees to initiate an auction, and buyers pay gas fees, in addition to the offer value, only when they complete a purchase of a CK.
However, CryptoKitties requires players to pay additional fees to cover the cost of transactions performed for them as part of the game logic.For example, a birthing fee is required each time the players breed their own kitties.The fee is paid by the player, collected by CryptoKitties smart contracts, and paid to the network miners when a new CK is generated and written to the blockchain.Because the application is based on a distributed ledger with a single-ledger-based architecture, there is a potential for an increasing number of game transactions to crowd out and be delayed by other businesses that use Ethereum.
When CryptoKitties was first released in 2017, the Gene Science contract was a closed-source, whereas the other four contracts were open-source.In 2019, the Gene Science contract was open sourced.The game logic is split between the application backend and frontend.Complicated game functions that require periodically calling of the smart contracts, such as generating new CK tokens (i.e., kitty birth), are handled by the blockchain, whereas other simpler functions, such as rendering images of kitties according to their identified genetic makeup in the smart contract, are handled by the frontend.The frontend handles mapping from CK genotypes (i.e., token Ids) stored on the blockchain to phenotypes stored in the relational database.data are sent from the frontend to Ethereum via the Web3 API, whereas on-chain and off-chain data are retrieved via a RESTful interface.To this end, and at a high-level of abstraction, we can conclude that the architecture of CryptoKitties consists of an onchain backend, an off-chain backend, and a frontend.Linking the CryptoKitties backend to its frontend components offers several insights, as discussed in Section VI.

VI. DISCUSSION
Although we have demonstrated the applicability of the proposed taxonomy through diverse examples found in realworld systems, the taxonomy has not been validated by blockchain systems developers.While validating the taxonomy will be our ongoing research, this section discusses our general observations obtained from using the taxonomy to characterize the blockchain systems and offers our suggestions for some key decisions for the design of blockchain systems.

A. OBSERVATIONS
Blockchain platforms are largely general-purpose, opensource platforms and are governed by communities of developers.In agreement with [79], incentive mechanisms should consider rewarding full nodes, such as archival nodes, despite being miners.In addition, full nodes that solve computational problems and do not win block rewards consume sufficient storage and power with no reward.Blockchain systems are not fully decentralized.Although their execution environment is intended to be decentralized, there are other components that affect the decentralization of the final application, such as custody of the digital wallet and centralized frontends.
Moreover, three expertise areas are essential for developing blockchain applications.The first area of expertise is smart contract development, which focuses on the programming and testing of smart contracts.This area requires a new thinking vector that differs from conventional software development [80], [81].More importantly, smart contracts are deployed as transactions in the blockchain.Thus, deployed smart contracts are immutable, irreversible, and non-modifiable.It is crucial to test smart contracts, ideally on test networks, before actual production of blockchain systems.The second area of expertise is infrastructure setting.This area focuses on configuring and establishing a blockchain system execution environment.It involves working with blockchain platforms and making decisions concerning architectural design such as scalability and data privacy [82], [83].The last area of expertise is front-end development.This area generally focuses on conventional software development, including the UI and user experience design.It also focuses on establishing communication services to the application's backend.

B. DESIGN DECISIONS
From a software developer's perspective, there are some design decisions that should be considered when developing blockchain application systems: 1) At least three licenses should be considered for a single blockchain application.The first is the license of the blockchain platform, the second is the license of smart contracts, and the last is the of the frontend application.2) For a single blockchain application, four deployments should be considered.The first is the deployment of the blockchain platform whether on a local node or as a service; the second is the deployment of the smart contracts, whether on a production or test network and whether on a single chain or multiple chains; the third is the deployment of the frontend application whether local on users' devices or remote on web servers; and the last is the deployment of the digital wallet whether embedded within the DApp, local on users' devices, or remote on web servers.3) For a single blockchain application, there are at least four access-control levels.In addition to the network, ledger, and smart contracts permissions, the frontend can be open access or restricted, for example, to a specific geolocation.4) Membership supported by the backend network is different from the membership supported by the frontend application.For example, a DApp may constrain the members' registration to a certain group of people although the underlying blockchain network is open and its membership is not controlled.

VII. CONCLUSION
In this paper we have made three major contributions to the research and development of blockchain systems: First, we propose a novel taxonomy for blockchain systems.The taxonomy is comprehensive, characterizing a blockchain system using 3 subsystems, 8 fundamental components, 83 aspects, and 198 features.Such a detailed characterization can better inform software developers in their design and implementation of blockchain systems.Based on our literature review, we believe this is the first comprehensive taxonomy for blockchain systems.
Second, we show that the taxonomy is flexible and adaptable to the characterization of individual software components from a wide range of real-world blockchain systems.Using this taxonomy, we can gain a systematic understanding of a blockchain system or their components.
Finally, we offer our observations and insights to blockchain systems developers.We intend to provide this taxonomy as a service, making it accessible by the blockchain researchers and practitioners, so that it can be validated and used in practice.This may also open up collaboration opportunities to extend and standardize the taxonomy.Based on this taxonomy, our future work will research and develop reference software architectures for blockchain systems.

FIGURE 3 .
FIGURE 3. The high-level view of the proposed taxonomy.

FIGURE 4 .
FIGURE 4. Classification of blockchain systems based on their execution environment subsystem components.
1) CONSENSUS PROTOCOLThis component is described by four aspects: Consensus Mechanism, Finality, Network Access Control, and Trusted Hardware Utilization.The Consensus Mechanism implements the contractual agreement between the network members.This aspect has several features: Computation-Based relying on a node's computation power, Factor-Based relying on a factor to prioritize nodes for mining and validation, Voting-Based relying on the number of votes cast by peer nodes in the network, or Combination-Based built on different mechanisms, such as a combination of Factor-Based and Voting-Based.

FIGURE 5 .
FIGURE 5. Classification of blockchain systems based on their internal subsystem components.

FIGURE 6 .
FIGURE 6. Classification of blockchain systems based on their external subsystem components.

TABLE 1 .
A comparison of existing taxonomies based on the eight fundamental components (Y=Yes, N=No).

TABLE 2 .
Blockchain systems and components in the evaluation sample (Y=Yes, N=No).

TABLE 3 .
Characterizing 10 real-world blockchain networks using the proposed taxonomy.

TABLE 4 .
Characterizing 10 real-world distributed ledgers using the proposed taxonomy.

TABLE 5 .
Characterizing 10 real-world blockchain platforms using the proposed taxonomy.

TABLE 7 .
Characterizing 11smart contracts in real-world systems using the proposed taxonomy.

TABLE 8 .
Characterizing 11 tokens using the proposed taxonomy.

TABLE 9 .
Characterizing the network nodes found the publicly accessible environment sensor use case using the proposed taxonomy.

TABLE 10 .
Characterizing 13 digital wallets using the proposed taxonomy.