3.3.1. States and Accounts

To ge<sup>t</sup> started, Ethereum is an *account-based* blockchain, instead of the Unspent Transaction Outputs (UTXO)-based blockchain like Bitcoin network, under which all account states stored locally as a form of state data with the predefined data structure of *Merkle Patricia tree*. As described in [20], Ethereum blocks contain a list of transactions and the Merkle root hash of entire state tree on transactions which are packed in every block. Every

node on the network stores two types of states: the overall blockchain state and the state data containing a list of accounts and their associated states.

There are also two general types of Ethereum accounts: (1) *externally owned accounts (EOAs)* with key pairs generated and assigned for signature-based validations or signing transactions on the network, and (2) *contract accounts*, which essentially act as autonomous agents containing code that only act once they receive a message that has initiated its functionalities to read from and write to internal storage of the deployed smart contracts. The authors of [28,29] also proved that contract accounts can send messages to its counterparts with embedded calls to methods of other deployed smart contracts, which is basically another type of account on Ethereum blockchain.

### 3.3.2. Smart Contracts and Ethereum Virtual Machine

Entities on any consensus mode of Ethereum network are able to write smart contracts with methods to define transaction formats, access permission of the methods, state conversion equations suggested in [30], and literally any self-defined rules applied to method declarations with examples demonstrated in [31].

Entities in the network could first write and deploy a smart contract to the network for its decentralized applications to interact with, via its dedicated node using the blockchain client. The smart contract source code, written in Solidity for instance, is then encoded into *Ethereum bytecode* by the Solidity compiler. The bytecode is added to the data field of a transaction and deployed to the transaction pool of the network queuing to be picked up for further processes. The typical workflow of the smart contract source code is described in Figure 5.

**Figure 5.** The workflow of Ethereum smart contract source.

As detailed in [32], the miners would then pick up the transaction via its node client, pack the validated transaction into a new block, and run the hexadecimal bytecode data of the transaction with its Ethereum Virtual Machine (EVM), which is the execution environment for running transaction code to reach a consensus. The work in [28] details a more complex set of instructions to be compiled in the form of smart contracts, to generate operation codes (e.g., *PUSH1 0* × *60 PUSH1 0* × *40 MSTORE*) and run based on the operation codes each time a specific method in the smart contract related to a specific transaction that is invoked following the rules set within the deployed smart contract. The smart contract could then have state transitioned on each miner's local persistent storage on state data, only if data of the transaction are executed by the EVM successfully. For miner nodes on the network to be able to validate state changes brought by the transaction with the deployed smart contracts, they would be required to run the data, which is the bytecode with operation codes, retrieved from the transaction, on its EVM to check if it is actually

a valid state transition. This would impose a large computational redundancy on the network, but it is necessary in order to reach the decentralized consensus.

There is also an inherent constraint on the number of computational steps a transaction can perform, which is limited with a concept of "*Gas*"—essentially the cost incurred by totaling all the methods of a deployed smart contract executed in a submitted transaction. The cost calculation is based on the gas spending guideline of each functional pattern predefined in [28]. Nodes will need to specify a maximum amount of gas they are willing to pay per transaction, and if not explicitly stated, then the client implementation of the network (e.g., Go-Ethereum, Parity) would determine the amount automatically. The storage shall be as lean as possible as it could cost an absurd amount of resources. There are current technologies which could enable decentralized data storage, such as in [33], and therefore decentralized solutions could be built and not required to stick with central database architecture. Every block, created by miners after the consensus reached among nodes running on the network, has a block gas limit similar to the transaction gas limit. The gas limit is the upper bound on the amount of computation a transaction can perform on its workflow in the network, and that is why people think Ether as the crypto fuels of Ethereum due to a fact that gas cost will be paid in Ether.

### *3.4. Blockchain 1.0 Versus Blockchain 2.0 and Later Versions*

Blockchain implementations have been phased based on their development and use cases described in [34,35], respectively. While Blockchain 1.0, with the representative example of the Bitcoin network [18], focused on the development of cryptocurrencies for peer-to-peer electronic payments, Blockchain 2.0, such as Ethereum explained in [20,28] as well as Hyperledger Fabric discussed in [21], enabled the concept of smart contract. Blockchain 2.0 has a more flexible data structure and functionality enabled by deployed smart contracts. Blockchain 3.0 focuses on developing ÐApps essentially having backend logic patterns running on a decentralized peer-to-peer platform with a dedicated user interface of it. Blockchain 4.0 focuses more on matching blockchain technology and its implementations usable especially to those Industry 4.0 business demands, such as process automation, enterprise resource planning, and integration of different execution systems respectively.

Starting from Blockchain 1.0, the Bitcoin network [18] is indeed the first use case of blockchain technology, aimed at offering a peer-to-peer version of electronic cash. The Proof-of-Work consensus algorithm applied to Bitcoin network, its unique *UTXOs* model, and the potential hash rate-based double-spending in [36], which could still exist in Bitcoin network, are the major characteristics and topics discussed and advanced among Bitcoin or even the entire blockchain development community. Blockchain 2.0 moved on enabling programmable blockchains with Ethereum. A variety of underlying concepts of Ethereum blockchain, such as account-based, smart contracts, gas, and Ethereum Virtual Machine, as well as explaining how Ethereum, is designed and progressed to be different from, and even more capable than, Bitcoin network, are explained in [20,28], respectively, as representative examples.

There are indeed extensive differences in terms of implementation and usage in both phases. Figure 6 demonstrates the most crucial differences in different perspectives, followed by explanations on why modern decentralized solutions would be developed with frameworks and functionalities provided and enabled in Blockchain 2.0.


**Figure 6.** Comparison of Blockchain 1.0 and Blockchain 2.0 (including later versions).


While the open-source Ethereum blockchain has been planning a major *Ethereum 2.0* (Eth2) upgrade to its network to address scalability concerns, there has been an array of blockchain frameworks in Blockchain 2.0. These frameworks are available for developing decentralized solutions based on a concept of enterprise blockchain, such as Hyperledger Fabric depicted in [21] or Tendermint Core developed based on the system approaches covered in [37,38]. Like Ethereum, all of these have been seeking to prove that enhanced security, enhanced degree of decentralization, and enhanced scalability are not at odds.

### *3.5. Related Work of Blockchain Implementations*

With the advancement of blockchain development in recent years, there have been some existing blockchain innovations developed in different domains and in combination with other emerging technologies to decentralize software systems with centralized architecture of different purposes. A blockchain-based digital certificate system and blockchainenabled system for personal data protection were proposed in [39,40], respectively. Furthermore, the works in [41,42] have also given an overview of blockchain-based applications developed in different domains where a variety of examples of blockchain systems and use cases are developed, could be found in healthcare domain, as depicted in [43,44], focused on decentralizing health record managemen<sup>t</sup> and storage.

Blockchain innovations have also been implemented across the supply chain industry, and some are specifically with use cases of decentralizing and improving product traceability and anti-counterfeiting aspects of the supply chain industry. The authors of [45] have proposed a concept of a blockchain system to enhance transparency, traceability, and process integrity of manufacturing supply chains, while an Ethereum-based fully decentralized traceability system for Agri-food supply chain managemen<sup>t</sup> named AgriBlockIoT was developed in [46]. Furthermore, there is a wide range of blockchain innovations applied in supply chain industry, such as the novel blockchain-based product ownership managemen<sup>t</sup> system in [47], a blockchain-based anti-counterfeiting system coupled with chemical signature for additive manufacturing described in [48], and an ontology-driven blockchain design for supply chain provenance in [49], as well as a temperature monitoring and anti-counterfeiting system approach for pharmaceutical supply chains as depicted in [50].

Some implementations are conceptualized and developed based on computationextensive permissionless blockchain networks and consensus algorithms, aiming at full decentralization over scalability and stability of such decentralized systems developed. Instead of developing blockchain implementations based on conceptual design, decentralizing legacy anti-counterfeiting systems with centralized architecture already implemented in the industry, further with blockchain innovations integrated with, would be a more pragmatic way to start with so as to provide timely support to improve the snowballing situation of product counterfeits in supply chain industry.
