{'fraction_non_alphanumeric': 0.01967896672712172, 'fraction_numerical': 0.010271708730952421, 'mean_word_length': 4.894494954540913, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
SimBlock Simulator Enhancement with Difficulty Level Algorithm Based on Proof-of-Work Consensus for Lightweight Blockchain

Proof-of-Work (PoW) was the first blockchain consensus protocol discovered, followed by Proof-of-Stake and others. The disadvantage of the PoW is that it requires high energy consumption compared to other consensus protocols. Based on this weakness, some researchers proposed a lightweight blockchain technology, a modified blockchain that has a simplified algorithm but does not reduce the security factor. This lightweight blockchain is suitable for applications requiring data reliability but with limited computing resources, such as Internet of Things devices. This paper discussed and modified the SimBlock simulator as one of the existing blockchain simulators. It has a visualization tool to look further into the propagation transition of the block. Unfortunately, the existing PoW consensus on the SimBlock simulator is unable to pinpoint the actual hash computation method. Therefore, the hashing process in the SimBlock simulator was modified by including the difficulty level for finding the hash target. The purpose of including the difficulty level was to determine how long it takes to create a block. By knowing the time needed, a recommendation could be obtained for the most suitable difficulty level for a lightweight blockchain and its implementation with IoT devices. There are two options of approaches to the difficulty level referred to in this paper; finding the number of zeros that appear sequentially and are in front of a hash value (leading zero) and finding the number of zeros that appear arbitrarily (count zero). For example, the first difficulty level on a leading-zero quest has the same meaning as searching for a leading zero, the second level of difficulty is the search for the two leading zeros, etc. The block generation time on a blockchain network using the PoW consensus highly depends on the difficulty level. Block generation time and resource utility have been analyzed and compared with other blockchain simulators and existing networks, such as Ethereum and Bitcoin. The modified SimBlock simulator was tested in this experiment using 100–600 nodes, with the expected result of creating 100–1000 blocks. Based on the experiments, creating a block using leading zeros as the hash target for the first to fourth difficulty levels took less than 1 s, whereas when using count zeros (zero-count) as the target hash, it took less than 1 s for the first to fifteenth difficulty levels. Using leading zeros took approximately 237.4 s at difficulty level 7, while count-zero took approximately 633.8 s at difficulty level 19. The experiment was not continued at the next difficulty level because it required a longer compilation time. With the modifications made, the creation of a block on a blockchain network using the PoW consensus can be clearly seen. The difficulty level added to the simulator can also provide information for determining the difficulty level to be implemented on the lightweight blockchain.


Introduction
Blockchain technology is one of the most innovative developments and discoveries that ensures data integrity in a distributed network. It is also called an immutable ledger and holds important information, such as records and ledger entries. Blockchain technology

•
We enhanced the SimBlock simulator by modifying several functions and procedures in the block mining process using difficulty levels based on the PoW consensus. The difficulty level discussed in this paper is finding zeros that appear sequentially at the beginning (leading zero) or randomly (count zero) in a hash value. For example, the first difficulty level means finding a leading zero or an arbitrary number, the second difficulty level is finding two consecutive zeros in front of or in any position, and so on. These difficulty levels are used as a mathematical problem that miners must solve as proof of the PoW consensus. The block generation time on a blockchain network using the PoW consensus is highly dependent on the level of difficulty, so the duration needed to generate a block is significantly different depending on the difficulty level. The experimental results revealed the time needed to create a block based on a certain level of difficulty. These results were then analyzed to determine which level of difficulty is the most suitable for lightweight blockchain implementations.

•
We modified the SimBlock simulator to discover the extent to which this simulator can give us recommendations on the mining process using the PoW consensus, which requires a leading-zero or count-zero search as the target hash. Therefore, in the future, we can propose new mining methods, a new hash target search, or a new consensus algorithm that is most suitable for implementing blockchain technology using IoT devices, considering the computational limitations of these devices.
The remainder of this paper is organized into several sections. Section 2 contains literature reviews of blockchain technology, lightweight blockchain, Proof-of-Work consensus, and the SimBlock simulator. In Section 3, the proposed system model is presented. The experimental setup of this research is discussed in Section 4, and the experiment results are discussed in Section 5. Finally, we provide our conclusion in Section 6.

Blockchain Technology
Blockchain technology is a process of documenting transactions on a new distributed ledger using peer-to-peer electronic transactions proposed by Satoshi Nakamoto and an immutable ledger to store the data. The stored data in a blockchain might be Bitcoin for payment history [1,15], a contract [16,17], or personal data [18].
Transactions that occur within the blockchain network are decentralized, and there is no interference from the authorities. All connected networks can see transactions that happen; therefore, the transactions are transparent [19].
All nodes in the blockchain network propagate and verify every user transaction that occurs and is successfully created in a block (generated by the node miners) through an agreed consensus mechanism [20,21]. Each node that is connected to a blockchain network records the transactions that occur within a block and between blocks connected through a mechanism of mathematical problems that are difficult to solve in a short time. The process of solving these mathematical problems is called the mining process. Nodes that carry out the mining process are called miners. A miner is a node, but not all nodes in the blockchain network are miners. Miners that can complete the mining process have the right to add a block to a blockchain network. After all the nodes verify it, the miner obtains a reward. After the block is verified and connected, the block is distributed to all the blockchain network nodes [22]. Figure 1 illustrates the standard blockchain structure, which comprises several blocks. Each block contains a header and a body. The headers in this structure commonly contain the hash values of the previous block, time-stamp, version, nonce, and Merkle root. Merkle root is the hash of all hashes of all transactions that are a part of blocks in the blockchain network. All transactions that are processed into the Merkle root are illustrated with the symbols TRX1, TRX2, TRX3, and TRX4 shown in Figure 1. These transactions originate from the blockchain user node that performs the financial transaction. For example, "Alice sends $10 to John" is TRX1, "John sends $5 to Richard" is TRX2, and so on. A Merkle tree is a structure used to efficiently verify data integrity. All transactions stored in a block are hashed to be combined with the hash value of other transactions. This hash concatenation process is repeated until there are no more hash values to be combined. The last hash is stored as a Merkle root value. The body part of the blockchain structure contains transaction data stored in the blockchain. The implementation of blockchain technology that implements the PoW consensus has limitations. High-performance computing to process complex and extensive calculations and energy-wasteful factors is an obstacle. A race condition between nodes to pursue the desired target hash requires each node to have high-performance computing to be the first to find the target hash. This leads to wasted energy on nodes that lose out. Some researchers have proposed an alternative known as lightweight blockchain due to these constraints.

Lightweight Blockchain
Lightweight blockchain is currently emerging as an alternative that answers the weaknesses of blockchain technology, especially when using the PoW consensus. A lightweight blockchain is a customized blockchain with a simplified algorithm that still does not reduce the security factor when implemented [23,24]. A lightweight blockchain is suitable for applications requiring data reliability with only limited computing resources, such as IoT devices.
Previous researchers have carried out several studies on lightweight blockchains, mostly related to the technology implemented by IoT devices. Usually, the use of a lightweight blockchain is proposed due to the high-speed data transfer feature and requirement of good data security; therefore, it is challenging to change the data.
Cho et al. [25] proposed two significant points that must be fulfilled in applying blockchain technology, especially when using IoT devices. The first point is about security. Blockchain technology is currently very secure with its cryptographic techniques. However, the use of the PoW consensus in manufacturing a blockchain requires enormous computing resources, so we need a lightweight blockchain that prioritizes data security and reliability. The second point is about the quality of being lightweight. IoT devices have limitations in data storage and computing. Due to these limitations, the implementation of a blockchain on IoT devices must be able to overcome these limitations.
Dittmann et al. [26] mentioned that using a blockchain with a security feature on IoT devices could cause overload. The third-party proxy architecture was proposed to reduce the overload. Conceptually, all transactions made are sent to a proxy server so that they do not burden the IoT devices used.
Tuli et al. [24] proposed a lightweight blockchain framework that can facilitate endto-end integrated relationships using cloud services from the IoT edge. One of the advantages of using this framework is the multi-platform facilities that provide convenience in software development.
Security is a very challenging issue in implementing IoT applications. Therefore, Bilami et al. [27] proposed a lightweight design based on a private blockchain to secure The implementation of blockchain technology that implements the PoW consensus has limitations. High-performance computing to process complex and extensive calculations and energy-wasteful factors is an obstacle. A race condition between nodes to pursue the desired target hash requires each node to have high-performance computing to be the first to find the target hash. This leads to wasted energy on nodes that lose out. Some researchers have proposed an alternative known as lightweight blockchain due to these constraints.

Lightweight Blockchain
Lightweight blockchain is currently emerging as an alternative that answers the weaknesses of blockchain technology, especially when using the PoW consensus. A lightweight blockchain is a customized blockchain with a simplified algorithm that still does not reduce the security factor when implemented [23,24]. A lightweight blockchain is suitable for applications requiring data reliability with only limited computing resources, such as IoT devices.
Previous researchers have carried out several studies on lightweight blockchains, mostly related to the technology implemented by IoT devices. Usually, the use of a lightweight blockchain is proposed due to the high-speed data transfer feature and requirement of good data security; therefore, it is challenging to change the data.
Cho et al. [25] proposed two significant points that must be fulfilled in applying blockchain technology, especially when using IoT devices. The first point is about security. Blockchain technology is currently very secure with its cryptographic techniques. However, the use of the PoW consensus in manufacturing a blockchain requires enormous computing resources, so we need a lightweight blockchain that prioritizes data security and reliability. The second point is about the quality of being lightweight. IoT devices have limitations in data storage and computing. Due to these limitations, the implementation of a blockchain on IoT devices must be able to overcome these limitations.
Dittmann et al. [26] mentioned that using a blockchain with a security feature on IoT devices could cause overload. The third-party proxy architecture was proposed to reduce the overload. Conceptually, all transactions made are sent to a proxy server so that they do not burden the IoT devices used.
Tuli et al. [24] proposed a lightweight blockchain framework that can facilitate end-toend integrated relationships using cloud services from the IoT edge. One of the advantages of using this framework is the multi-platform facilities that provide convenience in software development.
Security is a very challenging issue in implementing IoT applications. Therefore, Bilami et al. [27] proposed a lightweight design based on a private blockchain to secure wireless communication at the device domain level. Once each node is registered for communication, it is suggested for mutual security authentication between the end device and base stations.
In this paper, the term lightweight blockchain focuses on implementing the search for the target hash value by using difficulty levels in creating a block. Modifying the SimBlock simulator by adding a difficulty levels function that applies the PoW consensus is expected to provide accurate information about the determination of the difficulty levels that are suitable for implementing IoT devices. IoT devices are known to have limited computing capacity. With a blockchain, the hashing process carried out using IoT devices has a low hash rate. For example, the Raspberry Pi 4 Model B+ generates around 90-110 hashes per second, while using a computer or laptop with an Intel i7 processor can produce around 1000-1500 hashes per second.

Proof-of-Work Consensus
The execution of consensus algorithms in blockchains and lightweight blockchains is indispensable and becomes a requirement that must be fulfilled before implementation because a consensus algorithm is a mechanism used by all nodes to agree on the addition of new data to the blockchain network. Proof-of-Work (PoW) is the first blockchain consensus set of rules. A blockchain uses a consensus algorithm to reach a mutual agreement about the state of the ledger distributed in its network. In this way, a blockchain builds trust between nodes that do not know each other in a distributed computing environment. The consensus algorithm ensures that each new block added to the blockchain is the only data approved by all the nodes in the blockchain network.
Blockchains typically use one of the following consensus algorithms: PoW [12], Proofof-Stake (PoS), Proof-of-Authority (PoA), or other consensus algorithms [28,29]. The Sim-Block simulator discussed in this paper only supports the blockchain simulation process using PoW and PoA consensus approaches. The adjustment made to the simulator only focused on the additional difficulty level function using the PoW consensus approach. The PoW consensus is when all the nodes in the blockchain network race to solve a riddle and create new blocks with their computation power with hash-based result values to find the nonce value [28]. Figure 2 displays the miner puzzle-solving algorithm in the PoW consensus. to Anna" or even from the sentence "John sends $10 to Anne". Table 1 explains the differences in the results of the hashing process using the SHA-256 cryptographic algorithm based on the similarity of the input. This algorithm efficiently verifies the data, file, and message integrity during the transaction, data identification, and even password verification [31].  An example of this mechanism can be described as follows given data transaction, the dTx, and a target value. Concatenate the transaction using a random number of a nonce. The hash process ceases if the hash target is less or equal to the defined target. If there is no match, the nonce is randomized again, and the concatenation of the transaction with a new random nonce starts again [32,33]. For example, hashProcess(dTx||Nonce) is  The results of this merger are continued in the next step by using a specific hashing method, which in this case is SHA-256. The block creation process is successful if the hash value obtained has a predetermined difficulty level. Suppose the hash value does not have a specified difficulty level. In that case, the nonce value is changed to a random value and then concatenated with the data transaction and the previous hash value to repeat the process. The higher the difficulty level used, the lower the possibility of finding a hash value that has the same number of leading zeros or count zeros as the difficulty level value. This causes a lot of looping to find the hash that matches the target.
The PoW system is used to implement distributed ledger transactions on a peer-to-peer basis. This system scans the transaction value using hash methods such as SHA-1 and SHA-2 to find the hash bits. This hashing function converts/maps data of arbitrary length into fixed-length data. The output of the cryptographic hash function has a specific fixed size. The output length is dependent on the cryptographic hash method used. To ensure data security, the greater the level of the computational complexity of the cryptographic hash function, the more complex the possibility of brute-force attacks. Bitcoin uses SHA-256 [30], which outputs 256 bits or a 64-character hash. Due to its fixed-size output, infinite sets of input values can yield the same hash value for a given hash function. However, producing the same hash value from two or three similar data inputs is impossible. The two or three data inputs certainly have different meanings. For example, the sentence "John sends $10 to Anna" has a different hash value from the sentence "John sends $100 to Anna" or even from the sentence "John sends $10 to Anne". Table 1 explains the differences in the results of the hashing process using the SHA-256 cryptographic algorithm based on the similarity of the input. This algorithm efficiently verifies the data, file, and message integrity during the transaction, data identification, and even password verification [31]. Table 1. Sample of the similarity message produce the different hash output when using SHA-256.

Original Message Hashing Result Using SHA-256
John sends $10 to Anna a2916ed42f2e4bc17801ceb0114f2020012c86972858188a0d1cebf6906cd762

Similar Message Hashing result using SHA-256
John sends $100 to Anna da8d307bd1453807d8f2a649cb42d49d9366a2017bbc8870bca41928675bed83 John sends $10 to Anne 529c15e8afd20b9039058ed0e80fe0a15b5a108d9417dc278860271427f09f33 An example of this mechanism can be described as follows given data transaction, the dTx, and a target value. Concatenate the transaction using a random number of a nonce. The hash process ceases if the hash target is less or equal to the defined target. If there is no match, the nonce is randomized again, and the concatenation of the transaction with a new random nonce starts again [32,33]. For example, hashProcess(dTx||Nonce) is a hypothetical hash function; the outputs are listed in Figure 3.
to Anna" or even from the sentence "John sends $10 to Anne". Table 1 explains the differences in the results of the hashing process using the SHA-256 cryptographic algorithm based on the similarity of the input. This algorithm efficiently verifies the data, file, and message integrity during the transaction, data identification, and even password verification [31].  An example of this mechanism can be described as follows given data transaction, the dTx, and a target value. Concatenate the transaction using a random number of a nonce. The hash process ceases if the hash target is less or equal to the defined target. If there is no match, the nonce is randomized again, and the concatenation of the transaction with a new random nonce starts again [32,33]. For example, hashProcess(dTx||Nonce) is a hypothetical hash function; the outputs are listed in Figure 3. The final hash value of this block is recorded as the hash value of the previous/parent block on the next block creation. When the next block is successfully created, these two blocks are called to have a link/chain between them because they have the same hash The final hash value of this block is recorded as the hash value of the previous/parent block on the next block creation. When the next block is successfully created, these two blocks are called to have a link/chain between them because they have the same hash value. If there is a change in the contents of the block by an unauthorized person that causes the hash value to change, then the existing link/chain is broken because of the difference in the hash value. Therefore, if anyone wants to change the contents of a block, then they have to change all the remaining connected blocks. This takes a lot of effort.
A PoW consensus mechanism can maintain a decentralized ledger of transactions. The PoW causes the nodes involved in the mining process to compete to create blocks.
However, in the process, not all miner nodes reach it, and only one node can win the race in finding the hash target; therefore, it wastes energy, capital, and time for the losing mining nodes [34].
A simulator is needed to show the process that occurs during the creation of a block and the next block and how the hash value of a block is an essential key for making the next block. The blockchain simulator can provide information about all the activities that occur when building a blockchain network.

SimBlock Simulator
The SimBlock simulator is one of the open-source simulators developed by the Tokyo Institute of Technology. This simulator can create a node, generate the block, transmit the block to another node as an event, and be suitable for blockchain network research [13]. The SimBlock simulator also has a visualization tool. The data presented in the JSON file make it easy for users to see the information about creating, transitioning, and propagating blocks to the entire blockchain network. This simulator demonstrates to users how creating a block in a blockchain network uses the PoW or PoA consensus.
The SimBlock simulator is available for operating systems such as Windows, macOS, Ubuntu Linux, or any Unix platform that supports Java with minimum JDK version 1.8.0 and Cradle version 5.1.1. As an event-driven simulator, each node in SimBlock behaves according to the block generation and the exchange messages with other nodes, as shown in Figure 4.
value. If there is a change in the contents of the block by an unauthorized person that causes the hash value to change, then the existing link/chain is broken because of the difference in the hash value. Therefore, if anyone wants to change the contents of a block, then they have to change all the remaining connected blocks. This takes a lot of effort.
A PoW consensus mechanism can maintain a decentralized ledger of transactions. The PoW causes the nodes involved in the mining process to compete to create blocks. However, in the process, not all miner nodes reach it, and only one node can win the race in finding the hash target; therefore, it wastes energy, capital, and time for the losing mining nodes [34].
A simulator is needed to show the process that occurs during the creation of a block and the next block and how the hash value of a block is an essential key for making the next block. The blockchain simulator can provide information about all the activities that occur when building a blockchain network.

SimBlock Simulator
The SimBlock simulator is one of the open-source simulators developed by the Tokyo Institute of Technology. This simulator can create a node, generate the block, transmit the block to another node as an event, and be suitable for blockchain network research [13]. The SimBlock simulator also has a visualization tool. The data presented in the JSON file make it easy for users to see the information about creating, transitioning, and propagating blocks to the entire blockchain network. This simulator demonstrates to users how creating a block in a blockchain network uses the PoW or PoA consensus.
The SimBlock simulator is available for operating systems such as Windows, macOS, Ubuntu Linux, or any Unix platform that supports Java with minimum JDK version 1.8.0 and Cradle version 5.1.1. As an event-driven simulator, each node in SimBlock behaves according to the block generation and the exchange messages with other nodes, as shown in Figure 4. After the block is generated in the first node, an inventory message or INV message is forwarded to the second node or other nodes. The INV message contains all the block inventories, and the receiver responds with the GETDATA message to the sender. Once the sender receives the GETDATA message, the first node sends the requested block transaction to the second node [35]. However, if the second node or other node receives an INV message containing inventory transactions and existing blocks, the node ignores the INV message.
The determination of block creation time in simulation is based on the success of block generation. The mining process that requires massive calculation power is not used in this simulator. However, an assumed number of mining processes per minute is used After the block is generated in the first node, an inventory message or INV message is forwarded to the second node or other nodes. The INV message contains all the block inventories, and the receiver responds with the GETDATA message to the sender. Once the sender receives the GETDATA message, the first node sends the requested block transaction to the second node [35]. However, if the second node or other node receives an INV message containing inventory transactions and existing blocks, the node ignores the INV message.
The determination of block creation time in simulation is based on the success of block generation. The mining process that requires massive calculation power is not used in this simulator. However, an assumed number of mining processes per minute is used in the process of simulation. The number of nodes created can be determined as a representation of the blockchain model. Table 2 presents the parameter used in the SimBlock simulator. The SimBlock simulator shows the propagation transition of the block on a blockchain network. It calculates the arrival time by measuring the propagation delay between the nodes and bandwidth. The message size and bandwidth between the regions are calculated to determine the transmission time.
The design system flow in the SimBlock simulator and the additional modification process of PoW methods with the level of difficulty can be seen in Figure 5. The SimBlock simulator system flow in Figure 5 shows that to create a block using the SimBlock simulator, the user must first determine the parameter values to be used, as shown in Table 2. The RE-GION_LIST parameter value is used to determine the number of locations for the node to be connected. The NUM_OF_NODES parameter value determines the number of nodes connected to the blockchain network. The ENDBLOCKHEIGHT parameter value determines the number of blocks created during the simulation. The mining process is carried out by entering a value in the AVG_MINING_POWER parameter and STDEV_MINING_POWER parameter. The PoW consensus cannot be seen in this case because it has the same block generation time. Therefore, it is proposed to add a mining process using difficulty level as a mathematical problem whilst creating a block so that the SimBlock simulator can display more appropriate information when generating blocks on the blockchain.
In Figure 5, the design system flow in the SimBlock simulator starts with generating the number of regions previously defined by the user. Then, the process is continued by determining the nodes in each region and creating links between created nodes. The process starts by creating and distributing the block to all the existing nodes and calculating the propagation time needed. The block-creating process continues until the ENDBLOCK-HEIGHT parameter value is reached, and the simulation ceases. The SimBlock simulation output results can be accessed in the JSON file. This file can be accessed in the output folder.
In Figure 5, the modified SimBlock simulator focuses on the block creation process using the difficulty level that applies the PoW consensus. The working principle of the PoW is to prove that to solve certain mathematical problems, several experiments are performed. When the attempt cannot solve the problem, a random nonce value is set, and the answer is recalculated. The process of randomly assigning a nonce score continues until it solves the specified mathematical problem. Here, the mathematical problem is based on the level of difficulty. Block generation in the modified SimBlock simulator starts by reading the difficulty parameter value specified by the user and assigning a nonce value at random, then combining all the existing information and performing the hashing process using SHA-256. If the hash value matches the predetermined target hash value (according to the level of difficulty), then the block creation process is declared successful, and the block distribution process throughout the network is carried out. Otherwise, the nonce variable is assigned a random value again, and the hashing process is repeated again until the hash target value is achieved. In Figure 5, the design system flow in the SimBlock simulator starts with generating the number of regions previously defined by the user. Then, the process is continued by determining the nodes in each region and creating links between created nodes. The process starts by creating and distributing the block to all the existing nodes and calculating the propagation time needed. The block-creating process continues until the ENDBLOCK-HEIGHT parameter value is reached, and the simulation ceases. The SimBlock simulation output results can be accessed in the JSON file. This file can be accessed in the output folder.
In Figure 5, the modified SimBlock simulator focuses on the block creation process using the difficulty level that applies the PoW consensus. The working principle of the PoW is to prove that to solve certain mathematical problems, several experiments are performed. When the attempt cannot solve the problem, a random nonce value is set, and the answer is recalculated. The process of randomly assigning a nonce score continues until it solves the specified mathematical problem. Here, the mathematical problem is based on the level of difficulty. Block generation in the modified SimBlock simulator starts by reading the difficulty parameter value specified by the user and assigning a nonce value at

Proposed Design
The SimBlock simulator enhancement was conducted by entering some of the coding programs and required services to support these codes. Using the built-in MessageDigest feature of the Java programming language, which has a hashing function using SHA-256, we aimed to facilitate future upgrades. Changes to the existing class structure were also made by adding nonce, hash_Data, and prev_Hash fields. A nonce value is used to store a unique number that is used as a key while combining all information to reach the hash value. This nonce is randomly generated until the hash target is achieved. hash_Data is used to store the hash value of the block, and prev_Hash is used to store the hash value of the previous block.
A detailed description of the mining puzzle-solving algorithm is provided in Figure 2, described as follows. Algorithm 1 demonstrates the function of generating the block, either a genesis block or another block/next block. The creation of genesis blocks in the function in Algorithm 1 is only performed once in this application. When the first block is generated, a null or zero is determined for the parent field and prev_Hash field. The hash_Data field is loaded with the value of the hash called from the HashProcess() function. The block creation process is carried out by carrying out the mining process by determining the level of difficulty. Algorithm 2 demonstrates the HashProcess() function using hash function SHA-256. The hashing process in Algorithm 2 uses SHA-256 provided by the Java package by concatenating field id, prev_Hash, and nonce. In the future, users can easily change the hashing method, such as MDA5, SHA-256, or others. Algorithm 3 shows the mining process using difficulty that is already declared. public void Mining(int Difficulty) 2.
end-while; 7. end-Mining; The mining process in Algorithm 3 requires difficulty parameters to determine the difficulty level in the mining process. This difficulty value is compared to the number of consecutive zeros that are present or the number of zeros that appears in the hash value obtained from the hashing process. Suppose the number of leading zeros or count zeros that exist has not met the specified difficulty value. In that case, the hashing process is carried out again by changing or providing a random value instead of the nonce field. Henceforth, the hashing process uses SHA-256. The following Algorithm 4 shows the process for calculating the number of leading zeros on a string. Algorithm 4 is used to find and calculate the number of zeros that appear randomly or sequentially from a hash value. The number of zeros that appear sequentially or randomly depending on the specified level of difficulty. The program returns the number of zeros found sequentially or arbitrarily and returns a zero value if it finds an empty hash value.

Experimental Setup
The experimental evaluation setup was completed using these specifications: sixcore processor Intel Core i7-8750H 2.2 GHz; DDR4 memory with 32 GB capacity; primary graphics card GeForce Nvidia series RTX-2070 (GDDR6-8 GB RAM) and secondary graphics card Intel HD 630; and 1 TB Solid State Drive (SSD) as a storage device. The virtual machine from Oracle VM VirtualBox was used for the development system and installed Linux operating system Ubuntu 18.04.4 LTS. Gradle and Java JDK must be installed first before extracting the SimBlock simulator.
After all the SimBlock simulator requirement processes are successfully installed, the existing programs can be changed in the Java installation folder. Determination of parameter settings, as contained in Table 2, can be made in the Settings installation folder. After compiling the application is successful, the output of the SimBlock simulator is stored in the Output installation folder as TEXT files and JSON files.
To conduct comparative experiments under different workloads, we set the same configuration parameters on both simulators and added the PoW method with some difficulty levels to the modified SimBlock simulator. The configuration parameter test for both SimBlock simulators (the original and the modified) is shown in Table 3.
The time need to execute, memory consumption, and CPU resources needed when compiling the simulator based on the configuration settings in Table 3 were observed and compared to determine the performance of both simulators. The experiment was carried out ten times on each configuration mentioned in Table 3 to obtain a good comparison result, and then we calculated the average value. For example, an experiment with 100 nodes with a target of producing 100 blocks, 300 blocks, and 600 blocks was executed 10 times each. The process was similar for experiments with the number of nodes being 300, 600, and 1000.

Result and Discussion
The experiment with the addition of the difficulty level using the PoW consensus on the modified SimBlock was compared with the original SimBlock simulator so that the following data were obtained.

Mining Process Result
On a blockchain network, the mining process is when the miner nodes race to each other to complete a hash target based on a certain level of difficulty in creating a block. The original SimBlock simulator mining process is determined based on the user default value in the AVG_MINING_POWER parameter. With the SimBlock simulator application results modified with the PoW process using the difficulty level factor, the higher the value of the specified difficulty level, the longer the needed mining process. The comparison of the mining process from both simulators (the original SimBlock and the modified SimBlock) can be seen in Figure 6.  In Figure 6, the average value of the mining process was calculated from the number of hashing processes carried out to find a target hash value that is determined based on the difficulty level of all blocks and compared with the time required to create all blocks. The number of hashing processes was obtained from the sum of the nonce values in each block. The higher the difficulty level specified as the target hash, the greater the nonce value obtained.
In Figure 6, the difficulty level experiment only includes the search for up to the fifth difficulty level. It is because at the time of the experiment, the compilation process in the search for the sixth difficulty level took a long time; therefore, the experiment was ceased because it was considered a long enough time that was not workable for a simulator.

Simulator Compilation Time
Before running the SimBlock simulator, the number of nodes and number of blocks specified in Table 3 must be inserted first in the parameter setting. Changes in the number of nodes and the number of blocks require the simulator to be re-compiled. The required compilation time of the original SimBlock simulator with predetermined parameters in Table 3 can be seen in Figure 7. In Figure 6, the average value of the mining process was calculated from the number of hashing processes carried out to find a target hash value that is determined based on the difficulty level of all blocks and compared with the time required to create all blocks. The number of hashing processes was obtained from the sum of the nonce values in each block. The higher the difficulty level specified as the target hash, the greater the nonce value obtained.
In Figure 6, the difficulty level experiment only includes the search for up to the fifth difficulty level. It is because at the time of the experiment, the compilation process in the search for the sixth difficulty level took a long time; therefore, the experiment was ceased because it was considered a long enough time that was not workable for a simulator.

Simulator Compilation Time
Before running the SimBlock simulator, the number of nodes and number of blocks specified in Table 3 must be inserted first in the parameter setting. Changes in the number of nodes and the number of blocks require the simulator to be re-compiled. The required compilation time of the original SimBlock simulator with predetermined parameters in Table 3 can be seen in Figure 7.

Simulator Compilation Time
Before running the SimBlock simulator, the number of nodes and number of blocks specified in Table 3 must be inserted first in the parameter setting. Changes in the number of nodes and the number of blocks require the simulator to be re-compiled. The required compilation time of the original SimBlock simulator with predetermined parameters in Table 3 can be seen in Figure 7. In Figure 7, the number of nodes and the number of blocks generated significantly affect the compile time required by the simulator. Based on the experimental results shown in Figure 6, the modified SimBlock test to find the target hash was only carried out up to the fourth difficulty level because of the long program compilation time that was not workable for simulator applications. The required compilation time of the modified SimBlock simulator using the parameters specified in Table 3 can be seen in Figure 8. In Figure 7, the number of nodes and the number of blocks generated significantly affect the compile time required by the simulator. Based on the experimental results shown in Figure 6, the modified SimBlock test to find the target hash was only carried out up to the fourth difficulty level because of the long program compilation time that was not workable for simulator applications. The required compilation time of the modified SimBlock simulator using the parameters specified in Table 3 can be seen in Figure 8. In Figure 8, the time required to compile the simulator program using 100, 300, 600, and 1000 nodes to create 100, 300, and 600 blocks on the first and second difficulty levels was short, and there was no significant difference. On the third difficulty level, it can be seen that the average time required to compile the simulator was twice that of the second difficulty level. On the fourth difficulty level, the time required increased by more than twice that for the third one.
The experimental results described above were obtained with a leading-zero approach. Experiments with five, six, or more difficulty levels took a long time to compile due to the computational limitations of existing equipment; therefore, the experiment was ceased.
The next experiment was to use a count-zero approach, which was predicted to be more suitable for implementation on IoT devices that are used to mine a block on a blockchain network. Figure 9 shows the time needed to find the hash target using the countzero approach. In Figure 8, the time required to compile the simulator program using 100, 300, 600, and 1000 nodes to create 100, 300, and 600 blocks on the first and second difficulty levels was short, and there was no significant difference. On the third difficulty level, it can be seen that the average time required to compile the simulator was twice that of the second difficulty level. On the fourth difficulty level, the time required increased by more than twice that for the third one.
The experimental results described above were obtained with a leading-zero approach. Experiments with five, six, or more difficulty levels took a long time to compile due to the computational limitations of existing equipment; therefore, the experiment was ceased.
The next experiment was to use a count-zero approach, which was predicted to be more suitable for implementation on IoT devices that are used to mine a block on a blockchain network. Figure 9 shows the time needed to find the hash target using the count-zero approach.
seen that the average time required to compile the simulator was twice that of the second difficulty level. On the fourth difficulty level, the time required increased by more than twice that for the third one.
The experimental results described above were obtained with a leading-zero approach. Experiments with five, six, or more difficulty levels took a long time to compile due to the computational limitations of existing equipment; therefore, the experiment was ceased.
The next experiment was to use a count-zero approach, which was predicted to be more suitable for implementation on IoT devices that are used to mine a block on a blockchain network. Figure 9 shows the time needed to find the hash target using the countzero approach.  Figure 9 shows the results of tests of the hash target search using the count-zero approach on ten different transactions. Each transaction was tested using from the first to twentieth difficulty levels. The count-zero approach is for finding several zeros that appear arbitrarily in a hash value. Figure 9a-c shows that creating a block in a blockchain network with a count-zero approach took an average of less than 1 s, and at the 20th difficulty level in Figure 9f, it took an average of 640 s. For the 21st difficulty level, the experiment was not continued due to the same reason as the hash target search using the leading-zero approach, namely the time it takes for the program to compile. Table 4 shows the sample transaction of hash target search using a count-zero approach, along with various difficulty levels, nonce that is matched and concatenated with the existing transaction message to produce the hash value, and the hash value itself that comprises a minimum of several zeros that appear and match with the difficulty level.

Difficulty
Level Nonce Value Sample Message "John Sends $10 to Anne" Hash Value  Figure 9 shows the results of tests of the hash target search using the count-zero approach on ten different transactions. Each transaction was tested using from the first to twentieth difficulty levels. The count-zero approach is for finding several zeros that appear arbitrarily in a hash value. Figure 9a-c shows that creating a block in a blockchain network with a count-zero approach took an average of less than 1 s, and at the 20th difficulty level in Figure 9f, it took an average of 640 s. For the 21st difficulty level, the experiment was not continued due to the same reason as the hash target search using the leading-zero approach, namely the time it takes for the program to compile. Table 4 shows the sample transaction of hash target search using a count-zero approach, along with various difficulty levels, nonce that is matched and concatenated with the existing transaction message to produce the hash value, and the hash value itself that comprises a minimum of several zeros that appear and match with the difficulty level. A comparison of the percentage of CPU usage required to run the SimBlock with and without improvement of the PoW method with difficulty level is shown in Figure 10. In Figure 10, the percentage of CPU usage on the original SimBlock was high, almost consuming 80% of CPU resources. Meanwhile, in the modified SimBlock, the CPU usage decreased. The more nodes involved and the more blocks created, the more CPU usage dropped below 50%. From Figure 10, the results show that the modified SimBlock proved the efficiency of CPU usage below 50%.

Memory Consumption
A comparison of memory consumption usage that is needed to compile the SimBlock with and without improvement of the PoW method using difficulty level is shown in Figure 11. In Figure 10, the percentage of CPU usage on the original SimBlock was high, almost consuming 80% of CPU resources. Meanwhile, in the modified SimBlock, the CPU usage decreased. The more nodes involved and the more blocks created, the more CPU usage dropped below 50%. From Figure 10, the results show that the modified SimBlock proved the efficiency of CPU usage below 50%.

Memory Consumption
A comparison of memory consumption usage that is needed to compile the SimBlock with and without improvement of the PoW method using difficulty level is shown in Figure 11. dropped below 50%. From Figure 10, the results show that the modified SimBlock proved the efficiency of CPU usage below 50%.

Memory Consumption
A comparison of memory consumption usage that is needed to compile the SimBlock with and without improvement of the PoW method using difficulty level is shown in Nodes. Figure 11 shows that the memory consumption rate on the original SimBlock was always below the modified SimBlock in every configuration test conducted. Based on the observations made in each experiment, the high memory consumption rate was because of the use of the difficulty level as the determination of the target hash value. The higher the specified difficulty level, the more iterations occur to find the specified target hash. In several experiments that were conducted on the first, second, and third difficulty levels, the memory consumption rate was lower than original SimBlock. Meanwhile, in the experiment of the fourth difficulty level, the memory consumption rate was higher than the original SimBlock.

Discussion
Based on the experiments conducted, the addition of a mining process using difficulty level as a hash target in the SimBlock simulator was successfully implemented. The purpose of adding a mining process to the SimBlock simulator using difficulty level as the hash target was to determine how long it takes to create a block on the blockchain network for each difficulty level.
The SimBlock simulator is executed by re-compiling or re-running the program based on the specific parameter settings. The number of nodes involved and the number of blocks to be created are parameters that must be set before the simulator is re-compiled. In the modified SimBlock simulator, a difficulty level parameter was added. The value of this difficulty level parameter affects the number of zeros that appear randomly or sequentially that is to be achieved as a target hash. Figure 6 reveals the increase in the average time required for the mining process because of the use of difficulty levels. This increment was due to more attempts to obtain the desired target hash. The higher the difficulty value, the lower the chance of successfully obtaining the target hash because more or consecutive zeros must appear. The experiment was conducted by testing all difficulty levels as the desired target hash. It started with re-compiling based on the parameters determined with the first difficulty level and then recording the time required when compiling. The same steps were repeated with the second, third, fourth, and fifth difficulty levels. However, when experimenting with the fifth difficulty, re-compiling the modified SimBlock simulator took an extended time, reaching over 5 min. Therefore, the modified SimBlock simulator experiment was only  Figure 11 shows that the memory consumption rate on the original SimBlock was always below the modified SimBlock in every configuration test conducted. Based on the observations made in each experiment, the high memory consumption rate was because of the use of the difficulty level as the determination of the target hash value. The higher the specified difficulty level, the more iterations occur to find the specified target hash. In several experiments that were conducted on the first, second, and third difficulty levels, the memory consumption rate was lower than original SimBlock. Meanwhile, in the experiment of the fourth difficulty level, the memory consumption rate was higher than the original SimBlock.

Discussion
Based on the experiments conducted, the addition of a mining process using difficulty level as a hash target in the SimBlock simulator was successfully implemented. The purpose of adding a mining process to the SimBlock simulator using difficulty level as the hash target was to determine how long it takes to create a block on the blockchain network for each difficulty level.
The SimBlock simulator is executed by re-compiling or re-running the program based on the specific parameter settings. The number of nodes involved and the number of blocks to be created are parameters that must be set before the simulator is re-compiled. In the modified SimBlock simulator, a difficulty level parameter was added. The value of this difficulty level parameter affects the number of zeros that appear randomly or sequentially that is to be achieved as a target hash. Figure 6 reveals the increase in the average time required for the mining process because of the use of difficulty levels. This increment was due to more attempts to obtain the desired target hash. The higher the difficulty value, the lower the chance of successfully obtaining the target hash because more or consecutive zeros must appear. The experiment was conducted by testing all difficulty levels as the desired target hash. It started with re-compiling based on the parameters determined with the first difficulty level and then recording the time required when compiling. The same steps were repeated with the second, third, fourth, and fifth difficulty levels. However, when experimenting with the fifth difficulty, re-compiling the modified SimBlock simulator took an extended time, reaching over 5 min. Therefore, the modified SimBlock simulator experiment was only carried out up to the fourth difficulty level. We did not to continue the experiment using the fifth or higher difficulty level because the computational process was high and took a long time. Therefore, the implementation of a simulator was considered not feasible because it took too long of a wait to obtain results. However, if the hardware used has high computing power, it is possible that an experiment using the fifth or higher level of difficulty level can be conducted. We considered that this experiment discovered the most suitable difficulty level for use on a lightweight blockchain. The experiment with a higher difficulty level was not carried out. Figure 7 shows the time required when re-compiling the original SimBlock simulator program using the parameter settings specified in Table 3. Meanwhile, Figure 8 shows the time required for re-compiling or re-running the modified SimBlock simulator program using the parameter settings specified in Table 3 combined with the first difficulty level up to the fourth difficulty level. The time required to re-compile the original SimBlock program using predetermined setting parameters was shorter than for the modified SimBlock program. The simulator ran faster because in the original program SimBlock, there is no process of searching for a hash target to create a block when re-compiling the program. A comparison of the average level of CPU usage in the SimBlock simulator application, both the original and the modified, shown in Figure 10, showed a significant difference. The original SimBlock exhibited higher CPU usage compared to the modified SimBlock. Even in a configuration using 1000 nodes to produce 100, 300, and 600 blocks, the CPU usage was twice as high compared to the modified SimBlock. The average CPU usage level was lower than the original SimBlock simulator application, and we expect that the use of difficulty levels in this simulator is suitable for lightweight blockchain implementations. In Figure 11, the level of memory consumption on the original SimBlock was less than that of the modified SimBlock. However, for the configurations of 600 and 1000 nodes to produce 100, 300, and 600 blocks, memory consumption requirements increased with increasing nodes. We can conclude that using more nodes in the original SimBlock simulator requires more memory. In contrast to the modified SimBlock, the memory requirements decreased.
Overall, a temporary conclusion was obtained from the experimental results that the SimBlock simulator with the addition of difficulty level as implementation of the PoW consensus shows an increase in memory consumption and CPU usage. The block generation time required by using a low level of difficulty is also considered suitable to be implemented in the IoT technology [36].

Conclusions and Future Work
In summary, the proposed modified SimBlock simulator using difficulty level to implement the PoW consensus in finding a hash target was completely developed. Visualization of the mining process of a block in the blockchain network can be seen in the output of the modified SimBlock simulator application. The output file of this simulator uses a JSON file. The data presented in the JSON file make it easier for everyone to see information about creating, transitioning, and deploying blocks throughout the blockchain network. The relationship between the genesis block and the next block in the simulation can also be seen in the block structure, where each block has a hash value that is the same as the previous hash value in the next block structure. The prev_Hash field in the genesis block has no hashed value because it is the earliest parent block or the first block in the blockchain network. In comparison, the block that is the prev_Hash field containing the hash value is the block that is linked to the previous block (the parent block). The output file also shows the nonce value of a block, indicating the unique value that was successfully obtained to generate the target hash. The hash value of a block appears to have consecutive zeros in front, showing the difficulty level used in creating this block. Based on the evidence from the output generated by the modified SimBlock simulator, we can conclude that the PoW consensus in this experiment could run well and provide more detailed information.
The CPU usage when compiling or re-running the modified SimBlock was noticeably lighter than the original SimBlock. Memory usage in the original SimBlock increased because of the number of nodes used. Meanwhile, in the modified SimBlock, the trend of memory usage also appeared to be increasing but was still lower than in the original SimBlock simulator.
The lightweight blockchain approach using the PoW consensus with a low level of difficulty from this study looks suitable to secure data originating from IoT devices. The application of the PoW consensus when using a low level of difficulty can be used because in making a block, it does not take a long time in the mining process to find the desired target hash. Even with a low level of difficulty, the data generated on the blockchain network remain secure and immutable.
Although the modified SimBlock simulator demonstrates the mining process that occurs when generating a block with leading-zero and count-zero search approaches as the hash target, the SimBlock or the modified one can still be improved in a larger scope, especially for simulating the mining process using the IoT device approach. Here are some aspects that can still be improved in the future.
Consensus selection: If the PoW consensus is still applied to this simulator, then the count-zero algorithm as a target hash value search is considered the most suitable for blockchain-based IoT devices. However, it is possible to use another consensus, such as PoA. When PoA consensus is chosen, the IoT devices that have authorization are the devices that may carry out the mining process. The IoT devices that have authorization are determined by the mechanism of the system itself.
Grouping or clustering devices as a miner: The mining process carried out by an IoT device that has limited computing processes is carried out by sharing computing power (in groups or clustering) from several existing IoT devices. Therefore, to create a block, the target hash search process can be made in groups and not by competing.