2. Background and Related Work
Blockchain represents each transaction in the form of a block, so a blockchain appears as a chain of blocks [
9]. Besides the information about the transaction, the new block holds additional information such as the block number, block time creation, and block hashing. The idea of the blockchain came from connecting the new block with the previous block. The created block uses a hash function to hash the transaction information with the previous block hash [
10]. Therefore, the blockchain appears as a chain of connected blocks. Hence, if any hacker wants to track or sniff the transaction information, they must hack all previous blocks. A blockchain forbids the use of third-party intermediaries [
11]. For instance, banks are not permitted to interfere with money transfers.
Figure 1 shows that the blockchain appears as a chain of connected blocks.
Blockchain has three different versions [
12]. Blockchain Version 1.0 is built to secure cryptocurrency and was released in 2005 by Hall Finley. Blockchain Version 1.0 uses Distributed Ledger Technology (DLT), which makes blockchain protect financial transactions and is carried out with the aid of bitcoin. However, this version lacks restrictions since any user may complete any bitcoin transaction. Blockchain Version 1.0 is utilized in payments and digital currency [
13]. Version 1.0 of blockchain had a flaw in that mining bitcoin was wasteful and was not scalable, which led to the release of the updated version. Therefore, blockchain Version 2.0 was improved to solve the problems of blockchain Version 1.0. This version of the blockchain supports smart contracts and simple cryptocurrencies. Small contracts are hence little computers that reside in chains of blocks. These little computers run free software that automatically checks the earlier established conditions, such as facilitation, verification, or enforcement, and lowers transaction costs. Ethereum has supplanted bitcoin in blockchain Version 2.0 [
14]. As a result, blockchain Version 2.0 processed many transactions quickly on the public network.
Blockchain Version 3.0 is based on features called Decentralized Apps (DApps). A DApp is similar to a regular app in that it may have a frontend written in any language that calls its backend, and that code runs on a decentralized peer-to-peer network in the backend. It uses decentralized communication and storage methods, such as Ethereum Swarm. Numerous decentralized applications exist, including BitMessage, BitTorrent, Tor, and Popcorn [
15]. Nowadays, many blockchain platforms have appeared. Thus many researchers have started to discuss the role of the blockchain and make a comparison between the platforms. For example, Ratta et al. [
16] discussed the role of using blockchain versions of IoT technology to improve healthcare applications. The authors showed that they could use IoT and blockchain in the healthcare system in three key areas: remote patient monitoring, medication traceability, and medical record management. They also mention the difficulties that face IoT and blockchain in healthcare systems.
Macdonald et al. [
17] discussed how the blockchain could use bitcoin. They also compared Ethereum, IBM Open Blockchain, Intel Sawtooth Lake, Blockstream Sidechain Elements, and Eris blockchain platforms based on many factors, such as usability, scalability, security, and feasibility. Their comparison showed that Ethereum is the best-suited one.
Yu et al. [
18] carried out a practical comparison between Ethereum, Hyperledger Fabric, and MultiChain blockchain platforms. Their comparison is limited to the blockchain methods that contain a smart contract system. This comparison showed that the implemented application determines the best platform to use (e.g., maintenance for Ethereum, fine-grained access control for Hyperledger Fabric, and rapid development for MultiChain). The authors also suggested using blockchain technology in the biomedical and healthcare sectors to reduce the probability of data theft.
Chowdhury et al. [
19] presented a comparative analysis of various blockchain platforms. The authors compared 11 blockchain platforms. They used quantitative and qualitative analysis to help developers choose the best blockchain platform. The results of their analysis prove that Hyperledger Burrow lacks comprehensive documentation. As a result, the authors advised against using it. Their results also show that the Fabric platform was robust and that Sawtooth offered the best level of security.
Furthermore, many scientists have developed a blockchain-based security system based on one of the blockchain versions. Rupa et al. [
20] proposed an IoT system that monitors and manages the automated vehicle. They developed a blockchain system to secure and store the data collected from the IoT system. They created a new block to store the data, then used the SHA-1 algorithm to hash the new block and connected it with the previous block.
Bigini et al. [
21] identified the importance of using blockchain in IoT applications. They also provided summaries of studies and reports that aimed to assess the state of the market and pinpoint challenges for adopting a user-centric development strategy. Mohanta et al. [
22] presented a comprehensive analysis of the numerous applications of blockchain technology. Additionally, they discussed the difficulties in implementing blockchain and the related security and privacy concerns. Li et al. [
23] developed a mechanism to securely and effectively transfer prescription histories among various healthcare organizations. In the Decentralized Medication Management System (DMMS), a doctor evaluates the patient and issues a prescription. No one can access the patient’s record without the patient’s private key because the prescription is encrypted with the patient’s public key. In addition to the doctor viewing the patient’s record with the patient’s consent, the patient can view their record. Ktari et al. [
24] offered a platform built on IoT that enables patient health monitoring. They employed blockchain as a safe method to secure patient data. They collected medical data from several intelligent sensors, including blood pressure, SPO2 levels, and EEG signals. These data were collected with a Raspberry PI 4 embedded platform that served as a smart data relay, processed on a backend server, and finally saved in a Blockchain embedded node. The preliminary findings demonstrated the platform’s efficacy as a potential low-cost example of a protected electronic health record (EHR). Ibrar et al. [
25] used blockchain smart contracts to provide a controlled response to the needs of patients, doctors, and healthcare providers. They used blockchain to share health data among blockchain users. The Modified Merkle Tree data structure was also used to hash new blocks. The blockchain serves as a clinical data repository in this system, giving patients easy access to their electronic health records through healthcare providers. A distributed ledger that records all occurrences details is used. Through the use of cryptographic hash algorithms, this system offers great security and integrity. The effectiveness of the suggested approach has been tested through several trials. Khatoon [
26] presents recent studies about blockchain-based healthcare applications and several blockchain-based processes for the healthcare industry to improve data management. Several medical data, including challenging surgical and clinical trial procedures, have been developed and implemented using the Ethereum blockchain platform. A feasibility study was conducted to determine the cost of implementing the smart medical contract system’s workflows for managing healthcare. This paper presents lowering the cost of healthcare services. Because the author uses smart contracts with blockchain, this paper uses blockchain version 2.0. Baiju et al. [
27] used blockchain version 2.0 with the Ethereum blockchain. Truffle served as a building block for the system. Smart contracts managed electronic medical records. These contracts track the transactions and computations that occur inside the system. They modified the smart contracts to make them workable since medical information differs from the resources utilized with blockchains, such as bitcoins and NFTs. They saved the data using the DApp wallet address, and it was required to access them to make changes to the patient’s data. An operational logistic regression model receives the data as input and tunnels it over the API to analyze it to determine the patient’s health state. The model then calculates the results and gives the data to the user. Mehbodniya et al. [
28] developed a security framework based on the blockchain model. The authors used a modified Lamport Merkle digital signature technique to hash a new block. They used a central healthcare controller (CHC) to perform authentication and verification as well as know who created the signature. The signature must be verified using the validation hash of the public key and the create key. Their results showed that their proposed method is more effective, affordable, and quick.
In [
29] we proposed a pervious blockchain and master contract system. In this system, we use blockchain to store the medical data of the patient and master contract to guarantee sending the money to the doctor after they send the treatment. We connect the last block with the new block by hashing the medical data of the new transaction with the last block hash code. We carry this out using the SHA-256 algorithm and use run length code to compress the data. This system takes O(n + d) time complexity to create a new block.
There are some recent studies that built a blockchain system with the aid of a DL learning algorithm. For example, Kumar et al. [
30] developed a security system using blockchain and a DL algorithm. They used an Ethereum blockchain model to store the medical data, Stacked Sparse Variational Autoencoder (SSVA) algorithm to transform the medical data into any form readable by the computer, and the Self-Attention-Based Bidirectional Long Short-term memory (SABBLS) algorithm to detect any attack type. They used IoT-Botnet and TON-IoT datasets to ensure the security of their system. The results show that their method performed better than all previous methods.
All current works contain several flaws. They based their approach on the Ethereum blockchain without any modification to it. As a result, creating blocks requires extra time in their system. Additionally, they developed their security mechanism without requiring authentication of the two parties to the transaction. As a result, hackers could be able to impersonate patients or doctors.
3. Secure Blockchain Model
The proposed method consists of two parts. The first part implements a blockchain that creates a new block by hashing the transaction information and the previous block hash. Our blockchain uses SHA-256 to hash the new block. The second part of the system is to implement a new technique to check the authentication between the two parties.
Figure 2 shows the framework of the proposed method. This figure shows that we used a previously developed IoMT system that we implemented before [
8].
Figure 2 shows that our IoMT system measures vital signs. Then microcontroller sends them to the blockchain. Next, a blockchain starts to create a new block. We connected the new block by using the last block hash. Then the blockchain checks the two parties of the transaction. This check is conducted by asking the patient and physician to send their hash codes. After the blockchain receives the two parties’ hash codes, it compares the two hashes with the hash code that it generates. Then, the physician can access the patient vital signs through the blockchain. When the physician sends the treatment, the blockchain creates a new block of the treatment and has the new block with the last block.
To design our blockchain, we first need to establish what a block is because a blockchain is made up of them. The main piece of information stored in a blockchain is a block. Blocks are stored securely using the blockchain as its primary function. The letters Bl designate a generic block. When there is a transaction between two entities, a block is formed. Block Bl
f may be defined as follows since it has several entries (D) of size M:
where D is the entries inside the block. A link between two blocks is established using a mathematical conundrum known as the proof of work. The header of the second block is where this link will show up. A miner is someone who is looking for evidence of their effort. Let us imagine two blocks, Bprev and Bnew, together with an amount known as bits and denoted by the letter t. A goal number can be generated right away from the value of t, which expresses how difficult the proof of work is. This target is a 64-digit hexadecimal number, where the leftmost digits are largely zeros, such as:
00iqwe1234kjugfwr785621vu4abpot23r40a78sfasdasdcvfreqfghy45621ab40.
We employ the Sha-256 hashing function algorithm on the blockchain. After assuming that we are aware of the hash of the block before it, SHA(
Bli), we will define the hash of a specific block. The formula we use to determine the new block’s hashing is given by:
where
stamp(
t) stands for the present time and
stands for the concatenation operation. Using the aforementioned notations, we may provide block
Bl’s header after the proof of work for blocks (
Bli,
Bl) has been resolved:
where
is the transaction information. We design a new algorithm, Algorithm 1, to describe the role that our blockchain plays.
Table 2 shows the notations that are used in all algorithms in this work.
Algorithm 1 The proposed medical blockchain |
Input: AD(), AD()) Output: Begin sendsofto the usesto computeusingand. creates aby adding, , and. addto the chain and connects it tousing. x = Checkparties(AD(), ad()) If x== true access ofthrough sends treatment to uses to compute using and . creates a by adding , , and . seesthrough End
|
Algorithm 1 presents that our developed IoMT system developed in [
8] measures the patient vital signs and sends them to the blockchain system. Our blockchain system creates a new block by adding vital signs and hashing the code of the new block. The hash code of the new block is calculated using the last block’s hash code and the vital signs of the new block. Finally, the blockchain checks the authentication of the transaction parties. If the two users are authenticated, the physician obtains permission to see the patient’s vital signs and can then send the treatment to the blockchain system.
The blockchain starts to create a new block to store the treatment. Blockchain connects the new block with the last block by hashing the treatment information with the last block hash code. Finally, blockchain gives access to the patient to see treatment.
We use the SHA-256 algorithm to obtain the hashing code of the new block. We also use the hashing code to connect the new block with the last block. Algorithm 2 presents the modified SHA-256 algorithm used in this work, which is needed to convert vital signs and the last block hash into ASCII form. Therefore, we divide the data into blocks. Each block consists of 512 characters. If the last block does not contain 512 characters, then we expand it with 0 characters to make it 512 characters. Therefore, we use the LZ4 algorithm to compress the data.
Algorithm 2 The modified SHA-265 algorithm |
SHA-256( , )
- 1:
input: and - 2:
output: hashing function - 3:
begin - 4:
O=concatenate () - 5:
ascii_data → ASCII(. - 6:
X = size(ascii_data) /512 - 7:
For i = 1 to X - 8:
For j = 1:512 - 9:
If i == 1 - 10:
B[i][j] = ascii_data[j] - 11:
else - 12:
K = j + 512*i; - 13:
B[i][j] = ascii_data[k] - 14:
End - 15:
End - 16:
End - 17:
Ifsize( B[lastrow]) < 512, - 18:
For i = size( B[lastrow]: 512 - 19:
B[ size( B[lastrow]][j] = 0 - 20:
End. - 21:
For i = 0:64 - 22:
H = LZ4(B) - 23:
End - 24:
Return Hashing. - 25:
End
|
Algorithm 2 shows that the new block hash code does not start with a specific number of zeros. This step makes our algorithm perform faster than usual.
The second part of our system is to check the authentication of parties between the patient and the client. Thus, in this paper, we also implemented a party-authentication technique. In this technique, we use our modified SHA-256 hashing function.
We implement this technique in our blockchain system. The blockchain combines the two addresses (patient and doctor) and specific words, for example, the hello word. Then it hashes them using a modified SHA-256 algorithm. The doctor and patient devices also start to combine the address of the patient and doctor’s wallets and add the hello word to them. Next, they hash it using the modified SHA-256 algorithm. After that, they send their hashing code to the blockchain. Then, the blockchain compares the received hash with the hash that it creates. If it is equal, the blockchain trusts the two devices and starts to perform its work. Otherwise, it knows that the device is not authenticated. Algorithm 3 and
Figure 3 show the steps that the blockchain performs to ensure party authentication.
Algorithm 3 Party-authentication algorithm |
Checkparties(AD(), AD()) Input: AD(), AD() Output: True or false Begin combines AD with and stores it in message variable HashM=SHA-256(message, “hello”) combines AD with and stores it in message variable Hashp=SHA-256(message, “hello”) sends Hashp to combines AD with and stores it in message variable HashD= SHA-256(message, “hello”) sends HashD to compares between (HashM and Hashp and (HashM and HashD) End Return false
|
4. Experiments and Result
In the blockchain, each wallet has an address. We suppose that we have three wallets in our blockchain.
Table 3 shows the three wallets that we have in our blockchain.
The IoT system that we developed before collects the vital signs of patient 1 and sends them to the blockchain, which then creates a new block.
Table 4 shows the information that the blockchain stores in the block.
The blockchain uses the previous information and the last block hash code to create a new hash using a modified SHA-256 algorithm.
Table 5 shows the hash code that results from the previous transaction.
Table 5 shows that we do not permit the hash code to start with zeros. Therefore, the system must trust the two parties (patient and doctor). The blockchain uses the party-authentication technique to do this.
Table 6 shows how the blockchain authenticates parties.
Table 6 shows that the blockchain combines the patient’s wallet address with the wallet address of the doctor and adds the hello word to them. Then, the blockchain uses SHA-256 to hash the message that results from the combination. The patient’s and doctor’s devices perform the same previous steps to obtain the hash. Then, they send that hash to the blockchain, which compares it with the calculated hash code. If the two hash codes are not equal, the blockchain stops the operation. Otherwise, the blockchain creates a new contract between patient 1 and doctor 1, and the physician can access the blockchain to see the vital signs of the patient. After the doctor receives the vital signs, they respond with the treatment that the patient must take.
Table 7 shows the treatment that the doctor sends to the patient.
The blockchain creates a new block to store the doctor’s response. The new block will create a hash code for that block by using the doctor’s response and the hashing of the last block.
Table 8 shows the hash code that represents the new block.
Finally, the blockchain permits the patient to see the treatment that the doctor sent to the patient.
Table 9 shows the blockchain blocks after the process is ended.
The robustness of blockchain is measured by four attributes [
31]. The four characteristics of blockchain robustness are the hashing code cannot be reversed, blocks must be linked together, a consensus algorithm exists, and the blockchains are decentralized. We showed that our proposed method used a modified SHA-256 hash function algorithm. This function produces a hash code that cannot be reversed. We also proved that the hash function hashed the transaction information and previous block hash code together, so our blockchain linked the blocks together. The proposed system used an Ethereum blockchain platform that used Proof of Stake as a default consensus algorithm. Finally, the proposed blockchain used a distributed ledger, which means that it is decentralized. Therefore, this proposed blockchain method is more robust. The proposed method used a party-authentication technique that checks the individuals’ identities before they can access the data. We also show that it is very difficult to change any block information. This means that the proposed method is dependable.
We adjusted the hashing function by compressing data with the LZ4 algorithm. As a result, assuming the hashing code does not begin with multiple zeros, the time complexity of our proposed method is O(n), where n is the size of the hash function. The time is decreased by using LZ4 data compression. Because building a smart contract does not require much time, the time complexity for doing so is O(1).
Table 10 presents the comparisons between some related work, blockchain versions, and our proposed method.
Table 10 further demonstrates that the proposed method takes one second to create a new block while all blockchain versions take longer than that. This table also shows that the proposed technique is expandable because a decentralized database is utilized. From
Table 10, it is seen that our proposed system’s time complexity is lower than that of all current approaches. The time complexity of blockchain 3.0 is equal to the time required by our previous proposed method. However, because the proposed technique employs LZ4 to compress data, it requires less time than blockchain 3.0 or our previous method takes. The time required to construct a certain number of blocks using all current techniques and our suggested methodology is depicted in the following figure.
Figure 4 demonstrates how our proposed approach may build several blocks in 1 min. If we want to create 500 transactions, we must be able to build 500 transactions. Building 500 blocks will take 500 s or 8.5 min using our proposed method. Blockchain 1.0 will construct the 500 blocks in 90,000 s, or 25 h. Building the same number of blocks will take 7000 s (2 h) on blockchain 2.0. The 500 blocks on blockchain 3.0 will be constructed in 1000 s or 17 min. Our pervious blockchain system takes 750 s (12.5 min) to build 500 blocks.
Table 10 proves that our proposed approach performs better because it takes slightly longer to generate the block than other methods since it employs the LZ4 algorithm to compress the data.
Figure 4 again demonstrates how quickly any number of blocks may be constructed using our proposed technique.
Table 10 also shows that our system ensures the identification of the patient and the doctor using a party-authentication technique.
Figure 4 and
Figure 5 show the results of new experiments using the same experimental settings to compare these methods with the proposed system.
We also analyze our system and other blockchain versions according to green computing rules.
Figure 5 shows the analysis of our system and related works when there is a need to create 500 blocks. We exclude blockchain 1.0 because it gives the worst results. This result happens because it takes 25 h to create 500 blocks.
Figure 5 shows that we use three metrics to compare the proposed method and blockchain versions: the time to create 500 blocks, carbon footprint, and energy needed. A carbon footprint measures the entire amount of greenhouse gases produced by our daily activities. Energy needed metrics show the electricity needed to create 500 blocks.
Figure 5 shows that our proposed system does not require a large quantity of energy to create 500 blocks. It takes 27.25 WH.
Figure 5 also shows that the carbon footprint needed is 3.03 g Carbon dioxide equivalent (CO2e).
Figure 5 also shows that our previous system performs better than all other blockchain versions. It needs 39.61 WH energy to create 500 blocks. Blockchain 3.0 performs better than blockchain 2.0. It consumes 52.91 WH energy, while blockchain 2.0 consumes 369.77 WH.