Addressing Scalability Issues in Blockchain: A Use case from Healthcare

Addressing Scalability Issues in Blockchain: A Use case from Healthcare | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Addressing Scalability Issues in Blockchain: A Use case from Healthcare Lipsa Sadath, Deepti Mehrotra, Anand Kumar This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-1903767/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract The opportunities with blockchain technology has grown immensely especially with its unique features such as immutability, transparency, decentralization etc. It is also important that the basic features such as privacy, security and scalability co-exists. Our novel study proposes a framework named ERSB (Enhanced Reliability of a Scalable Blockchain) implemented with Hyperledger fabric as a solution to address scalability issues. Multiple records are generated and processed during a patient’s hospital visits/stays, laboratory tests and insurance claims. When there are networks of hospitals under one umbrella (a group of hospitals), it is critical to address maintenance of this complex system in context of the afore-mentioned unique features. Our proposed framework uses a hierarchical model at hospital networks, laboratory and insurance company that has multiple levels. Stages are evaluated with nodes added along with smart contracts. Smart contracts are also amended with more changes to observe performance, reliability and latency of the model at the first level of hierarchy. Blockchain BCT Scalability Smart Contract Hyperledger Fabric Hierarchical Model Healthcare Sector Patient Data Privacy Data Security Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 1. Introduction Technology took a real turn with Blockchain as a medium that enabled data transfer between peers or participants as that established transparency without intermediaries in the system [ 1 ], [ 2 ]. This was a strong discovery. When there was a stock exchange collapse, Satoshi Nakamoto first established the concept in 2008 through the Bitcoins [ 3 ] - the first cryptocurrency. With smart contracts [ 4 ] in ethereum [ 5 ] and their popularity, the concept was much used in developing most of the blockchain built systems in other entities. These included finance, healthcare, education, government organizations, supply chain [ 6 ] and now extended to artificial intelligence[ 7 ] etc. The technological breakthrough that had the potential to revolutionize the way society did trade and interacted. It gained reputable label for its ability of allowing mutual untrusted nodes to exchange financial value and engage without the involvement for a trust worthy third party member. Bitcoin was one of the first to successfully implement Blockchain technology and attract the public’s attention. After which, many crypto companies and currencies emerged thereby making Blockchain a highly discussed and popular topic. Blockchain combines technology features like cryptography, P2P networking, distributed system, transparency, access identity permissions, open source, autonomy, and immutability. This makes the technology very secure as the transactions cannot be tweaked or tampered with and all the entities/parties, which make the transactions, are kept anonymous [ 8 ]. Thus, Blockchain offer integrity protected distributed ledgers, provides transparency of the entire process by upholding a set of global states. The participating nodes agree upon the existence, value and histories of all states. Each state contains multiple transactions. Hence, the Blockchain is a way to manage distributed transaction. The concerned entities preserve replicas of the data and jointly agree on a transaction execution order. This high performance blockchain system is a means for completely monitoring a system as if under the surveillance of a legal third party. However, then as more users entered the blockchain systems, there appeared the issue of scalability [ 9 ]. Our study addresses the issue of scalability in blockchain technology with the help of a use case in the healthcare sector. At the time of this experiment, the system is evaluated at level-1. That is joining the basic 3 organizations. To test and understand the scalability issues, we have presently used one channel through the three organizations adding peers through all three. Transactions were increased from 10 to 1000 to know the performance of the system. The paper discusses scalability issues, structure of blockchain, different consensus models, relevance of hyperledger fabric, hierarchical model and the proposed ERSB model. 2. Scalability Issues With more users in the public chains such as Bitcoins and Ethereum, the scalability issues have arisen from sometime [ 10 ] with blockchains. To an extent, this has affected the technology in terms of development that can be implemented in other domains also. Much research has taken place in this area by researchers as well as software development companies. Though many of these solutions act to the needs somewhat, many other important aspects of blockchain systems such as security and decentralization were the biggest challenge to maintain [ 9 ]. Thus as more nodes increases, validating every node and every transaction was an issue due scalability. At the same time, it is important that all transactions validate themselves for the next transactions. This is important for appropriately further validating the entire system. One of the major techniques that could be used was to redesign the blocks or to do a storage optimization. Even as the blockchain challenges exists, the technology still thrives to excel in its implementations. Many frameworks are in discussion on these grounds. Few of them were on-chain and other few off-chain. Especially with smart contracts in picture. 3 Blockchain Structure And Smart Contracts A complete block structure [ 56 ] will have the following data structure that extends from the genesis (first block) to the block “n”. The application can be in any area like cryptocurrency, asset management or any security systems. Figure: [ 1 ] explains this concept. There are blocks created and added to the chain that starts from the genesis block. Every node added runs the chaincode or smart contract to form the block and keep the ledger same for all the peers. Every block will have transaction and hash details including that of the previous block. A legal agreement or contract that is in the form of digital set of codes between two parties during a deal is how a smart contract works in the blockchain environment. This ethereum concept in cryptocurrencies verify the nodes in a decentralized network. Thus, smart contracts initiate a deal as if it is a trusted third party in action [ 4 ], [ 11 ]. The integrity of smart contracts is also a concern during implementation. This is even more essential in a public network where unknown parties get involved in transactions. Mainly because public networks use smart contracts where nodes are unknown to each other. This may not be of large concern in private organizations as the verifications take place at organization level itself and controlled more by a central authority that is the organization itself. When blockchain technologies (BCT) have the cryptographic models to maintain security of the systems, consensus protocols [ 11 ] add complexities to these models for quality and trustworthy BCT transactions. It is important that the nodes separately at their ends run these consensus protocols in order to ensure these nodes reach the required consensus about their previous transactions. This will help new block entries in the correct order needed. The nodes get ready to participate in any transaction with the hashes of the previous blocks. Typically, validation is established to improve the trust among all nodes in the system because all nodes produce identical outputs. This is in accordance with the consensus rules. 4 Consensus Protocols Nevertheless, new challenges and security issues keep on emerging every day due to which the design of a consensus protocol remains a major issue. The consensus of Blockchain is that every entity/node maintains the same distributed ledger. In the blockchain, the entity/party is both the server and the host. It requires exchanging information with other similar entities/parties to arrive at a consensus. It is important that the Consensus Protocol implemented must also be suitable for certain blockchain type that has the framework and purpose for which the blockchain is used [ 9 ],[ 12 ]. Some of the major Consensus Protocols are discussed below: A. Proof of Work (PoW) Bitcoin, the popular Cryptocurrency, uses the Proof of Work consensus. All participants or miners compete to resolve a computational puzzle in order to generate a new block [ 3 ]. Here, on resolving the puzzle, the miner broadcasts the message to other participants for verification and gets a chance to create a new block. This protocol provides security in the form of block mining. But this protocol achieves its consensus by placing blocks in a distributed system even though the notes may show faults such as them being unreliable, unavailable, malicious, and more. The security of these kinds of the network is supported by specialized hardware and electricity, which makes them overpriced and inefficient from a resource and environmental standpoint [ 13 ]. One of the main challenges of this protocol is Selfish mining. It was an attack discovered by Eyal and Sirer [ 14 ]. Selfish mining is when a miner keeps his/her discovered blocks private and continues to mine over them. This attack enables Selfish miners to avail unfair rewards. This scenario destroys the decentralized structure of the system and raises the success rate of various similar attacks. Another kind of attack is Double Spending [ 21 ]. Double Spending is when spending happens again on the same asset that is, an attack mode when a currency is stolen and the attacker transmits a copy of the transaction as though it is original. Earlier, double spending was thought to be difficult and impossible due to the mining power. But, in 2016, a paper published by Sompolinsky and Zohar [ 15 ] exposed that an attacker could easily launch this attack on low mining power with the combination of Selfish Mining. Another kind of attack is Feather Forking [ 16 ],[ 17 ] proposed by Miller. In this attack, the attacker forks the blockchain to render the entire blocks invalid confirming the target. The attacker declares this publicly. The attacker continues the mining until the main chain is “k” blocks forwards. Luckily, the attack is considered unprofitable and the success rate is low with the mining power. Scientists argue that the latency is less when miners follow the consensus and compliant strategies [ 18 – 20 ] and this improves scalability to an extent. B. Proof of Stake (PoS) In Proof of Stake [ 8 ], [ 9 ] a method selecting which node can create, a new block relies on the stake rather than computational power. That is, participants get a chance to vote and elect leaders. These leaders are elected by their investments. Hence the name Proof of Stake. The challenges of verification here still exists because of the computational elimination. Etheruem uses the PoS consensus [ 22 ]. What makes this different from Proof of Work is that the nodes do not need to adjust their nonce many times instead; the nodes can solve this with the amount of stake. This makes proof of stake an energy-saving consensus because it does not use lots of computational power to arrive at a consensus [ 23 ]. For the block to be valid, it needs to have an address and a timestamp. Along with that, the user also needs to provide proof of ownership of the address. Also, due to one block being created per round of Proof of Stake [ 24 ], the generation and transaction speeds of blocks are much quicker than Proof of work. This has led to the recent popularity of this protocol. The security of Proof of Stake relies on many factors. A few of the Proof of Stake protocols are considered secure as long as the messages sent by network reaches their destinations within a certain time limit and handles scalability to extent. C. Delegated Proof of Stake (DPoS) This model has a small group of delegates elected by the stakeholders. These delegates produce and validate the blocks. This algorithm was used for addressing scalability issues in Bitshare and EOS. The model reduce the time taken for the block generation and considered as just 3 secs. This divides the system into 3 parts. The first part is the witnesses that are elected through the voting system and play the main role by generating the blocks. The second is the delegates and the third is the workers. Security concerns arise for the fact that witnesses usually hold the block generation rights for a long period unless for a specific reason. This is considered as a risky situation [ 25 ]. In Delegated Proof of Stake, the node that create the block is also responsible for validating the transactions. In this protocol, a token holder can vote for their preferred block producer and their votes will be prioritized based on their stake. In addition, Token Holders may give their stake to another voter and cast a vote on their behalf in the block producer election [ 26 ]. Once they are elected, they may create blocks after verification of transactions that were created for the last block time in the order in which they were selected. If all blocks in the transactions are verified and signed, they receive rewards. Also, the rewards are shared equally with the users who voted for them. However, the rewards will not be given if they do not do their task in the allowed time. After which if the block is missed, and transactions remain unverified. Users could also vote out any offending party/delegate if they believe that there is malicious intent or activity involved thereby keeping real-time voting secured. Another advantage is its efficiency for Generating Blocks [ 25 ]. The number of blocks created by this protocol increases as time increases. The reason for this is that the time taken to select the node remains unchanged, which is why the protocol’s time increase. This leads to a slight increase in the creation of blocks. Compared to traditional protocols, this one has improved security, efficiency and better decentralization of block generation [ 27 ]. The model was further taken for other improvements using the lattice models as well [ 28 ]. D. Practical Byzantine Fault Tolerance (PBFT) In current blockchains, Bitcoin uses Proof of Work (PoW), Ethereum uses Proof of Stake (PoS), other consensus were also discussed. The PBFT algorithm was created from Byzantine Generals Problem. It remains unharmed by malicious attacks and is implemented in many distributed computing environments. A Byzantine fault occurs when in a distributed system, the nodes fail and the information about the failure is inconsistent and unclear. The community has discussed quite a bit about this problem. It is still unclear as to what vulnerability brings this condition to a system. These discussions have also proposed various architectural solutions [ 29 – 31 ]. A solution to this was with the proposal of PBFT (Practical Byzantine Fault Tolerance) [ 32 ], [ 33 ]. In PBFT, there is a group that requires a leader, who is then elected using an ‘Election Algorithm’. Hence, the other nodes are known as Replicas. If a primary node fails, a new leader maybe selected with the creation of a new group. However, the nodes do not change their state and the requests remain organized. This is what makes this algorithm safe [ 34 ]. The system has a protocol with a 3 phase. The first phase is pre-prepare, the second is prepare and the third is the commit phase. The entire system has one message orderer server that begins the working of the phases on receiving a client request. This primary server broadcasts a message to pre-prepare to all other replica servers. During the prepare phase, if the any server makes a decision to accept the broadcasted pre-prepare message, then the server broadcasts accepted messages to all other replicas again. While “f” is the number of faulty nodes indicator, the server starts the commit phase, when it receives a 2f + 1 messages as feedback. As in the prepare phase, the commit phase also has servers sending broadcast messages to others and wait for 2f + 1 messages as feedback. This is a kind of voting to indicate that majority of the servers and clients agree on the messages sent [ 8 ]. IBM utilized PBFT for developing ‘Hyperledger fabric’ that provides member registration, identity management, auditability and more which helps to achieve high performance in certain environments [ 35 ]. While scalability is limited and needs improvement, PBFT has shown excellent performance with latency and throughput. Due to this protocol’s fault tolerance, many experts add this to their blockchain systems [ 36 ]. PBFT works in a synchronized system and needs many voting rounds, which makes it impractical. PBFT has inspired many BFT protocols with better security and performance. For synchronous networks, PBFT may exploit the timeout algorithm and detect of any issues or anomaly of the primary node [ 37 ]. Though PBFT works without computational tasks, it might cause some communication overhead. The utilization of PBFT in the Hyperledger fabric is an advantage in private organizations in terms of security, latency and throughput where the system is in a controlled permissioned environment. E. Hybrid and Other Consensus When protocols are combined, they form to give some classic models like the hybrid ones. PoW and PBFT were combined and used in Byzcoin [ 38 ]. Scalability was an advantage here when PBFT was able to reduce the cost of the prepare and commit phases by using a protocol called Cosi [ 39 ]. Mainly PoW was seen combined with many other consensus to form hybrid consensus [ 40 ]. Other consensus models that were proposed to improve the scalability was Proof of Authority (PoA) [ 41 ] relies on a very limited number of block validators that undergo rigorous security and identity scrutiny, thereby protecting the security and enhancing scalability. Proof of Participation (PoP) [ 42 ] was built on PoS and PoW combined. Unlike PoW the computational task is simpler and the transactional fee is distributed among participants which encourages them. Proof of Capacity (PoC) depends on miner’s disk space capacity to generate next block and get a reward. This is much similar to PoW but with less complex computational tasks. 5 Types Of Frameworks In Bct There are various blockchain frameworks such as Hyperledger, Openchain, Graphene, Corda, Multichain and various other blockchain frameworks. Since Blockchain technology can be used anywhere, major interest from various organizations has increased and it has caused more and better technology/frameworks. Hence, the technology is used in finance, commerce, healthcare, government, agriculture, and various other fields you can think of. For this to be implemented, organizations are required to choose a certain type of framework to suit their demands [ 44 ]. Openchain is a framework released by Coinprism. A framework that is designed to issue and manage digital assets. This framework is mainly used for finance and banking organizations. It also allows us to manage various kinds of financial transactions. It has enhanced anti-fraud and anti-theft systems, which is optimized and adaptive to different systems or needs. The architecture is mainly based around a client-server framework, which is more reliable than peer-peer framework. It is also a private network, and various users on GitHub actively update it. It is also open source and runs on JavaScript [ 45 ]. Graphene is a framework written in C + + language and it is the most adaptable one. It was created as an exchange medium for various cryptocurrencies, since then it has been used for various other fields. It is the most transparent and reliable framework it can process around 5,000 to 100,000 + transactions per second which is most required by large financial organizations. It has the fastest block creation time as compared to other frameworks. It is an open source, and it is a private/public network [ 46 ]. Corda is a framework written in Kotlin and Java, and it works as a mediator for businesses to cut down on transactional expenses. It has also helped with reducing the cost of record keeping and help business make their transactions mobile. The framework is open source, and it can be used to store and synchronize data between various financial institutes. It helps with keeping an open network to transfer various valuable assets with privacy. Its network is private, and permission based, therefore those with access can view or use the assets on the given server/network [ 47 ]. Multichain is written in C + + language and it can help you create a private block that can be used by your company or by various other companies. It was initially created to beat major problems affected by blockchains in financial areas, it even offers privacy packages and access levels for compartmentalizing data for protect. It even allows user permissions for the organization to set which user has which type of access. Members of the framework can manage the size of the block but can only view the data if they have their own private key. All blockchains created in the framework are regionalized which increase the security level. Multichain is easily configurable and modifiable [ 48 ]. One of the frameworks used by Hyperledger known as Hyperledger Fabric, which was created by various Japanese companies. This is a collaborative project to develop an open-source blockchain framework for enterprise usage. Its goal is develop blockchain technology by developing and implementing a cross-industry method for distributed ledgers that has the potential to revolutionize the way businesses transact globally in an open –standard platform. The system gained more popularity because of the PBFT used in it and ease of implementation and community that supported the framework. Hence, Hyperledger fabric framework is used to implement our use case. 6 Hyperledger Fabric Hyperledger is an integrated blockchain framework that acts as a base for developing various blockchain-based products and applications using components that can be used by private entities. It is open source. It is designed in an environment in which multiple users can work within, which makes it suitable for finance, healthcare, and various domains. The community is quite huge and are its members [ 49 ] are currently funding it. In the year 2016, the Linux Foundation launched the project. The framework was then created to host a mobile-focused framework that is easy to use and execute. Hyperledger Fabric is an open, proven, enterprise-grade, distributed ledger platform. It has advanced privacy controls so only the data you want shared gets shared among the “permissioned” (known) network participants [ 50 ]. Some of the main benefits [ 51 ], features and applications of the framework are discussed below: A. Benefits i. Permissioned Network: Decentralized trust in a network of participants. ii. Confidential Transactions: Only data you want to share will be sharable. iii. Pluggable architecture: It is easily usable regardless of usage size/environment. iv. Ease of use: Custom languages and custom architectures. B. Features and Applications The core purpose of Fabric is Blockchain services; this category includes components such as a consensus manager, distributed ledger, peer-to-peer protocol and ledger storage [ 52 ]. The consensus manager is in charge of providing an interface to the consensus algorithm as well as receiving transactions from other Hyperledger networks and executing them according to the desired consensus algorithm type [ 52 ]. Certain use cases and specific trust models have adapted this for modular consensus protocols. The platform includes a native implementation of Solo, a consensus protocol in which the endorsing nodes execute and validate transactions in accordance with endorsement policies. Nevertheless, it is easy to adapt as other consensus protocols like the PBFT are used to be able to allow several ordering nodes, can be plugged in [ 53 ] [ 54 ]. Smart contracts use distributed ledger to record relevant state information during transactions. These transactions include chaincode. Which executes operations that may result in the global state being updated. The state is saved on a disk by each node. Fabrics block structure includes data like version, timestamps, transaction hash, state hash and prior hash. The other component is the peer-to-peer protocol, built using Google’s googleRPC platform. Protocol buffer defines the message structure in Fabric. The network discovers peers and executes confidential and public transactions using various messages. The final component is the ledger storage; RockDB is used to save state [ 52 ]. Major features are: i. Membership Service: Fabric implements a private permissioned model by utilizing a portable idea of membership coupled with industry standard identity management systems. A membership service provider or the MSP determines a node’s identity in a Fabric network. These nodes may include client nodes those who may propose transactions for or peers who maintain the ledger and its state; or ordering service nodes who determine the order of all transactions [ 53 ][ 54 ]. These features work together to provide fabric users with access control. It integrates public key infrastructure to facilitate authorization and identity management operations. There are three certificate authorities; Certificate Authority is one that will provide a long-term certificate to enrolled participants in order to provide to verify their identity. The transaction certificate authority issues transaction certificates to participants in order for them to send transaction via the network. TLS certificates are issued by a TLS to secure network level communication between fabric nodes. Fabric offers an entirely new blockchain design to accommodate flexibility as well as a revamped approach to dealing with non-determinism resource exhaustion, and performance threats [ 52 ]. ii. Chaincode Services: Fabric implements application logic with smart contracts known as chaincodes [ 53 ]. Chaincodes execute inside a secure container that this service creates. It is comprised up of two parts: a secure container and a secure registry. Deploy Transaction – take the installed chaincode, written in the Go programming language and is ready to use [ 52 ]. iii. Invoke Transaction: Invoke the transactions of a specific chaincode previously installed. Chaincode runs transactions and updates the state, then reports if the transaction was successful or unsuccessful [ 52 ]. iv. Nodes: The fabric has three types of nodes namely the client, peer and ordered. The clients are the application users that initiate a transaction, a peer maintains a transaction by committing them and maintaining the ledger state by also letting other peers know the status, orderer nodes ensure the transaction communication and services by creating the blocks. v. Peers: The peers are owned by organizations. It is a must that organizations own at least one peer. They responsibly notify the clients about the application submission or transaction update. The diagram shown below shows peer communications. The peers can be from different organizations communicating and doing transactions. Each peer can be independently running in their own environment. And can get connected to one or more channels. Thus peers are assigned a specific role in an organization and given blockchain access by a Certificate Authority [ 66 ]. The peer waits for other peers for the ledger approval. This process is the consensus. vi. Consensus: The consensus in a hyperledger fabric has three steps of endorsing, ordering and validating the transaction. These are steps in a transaction flow. First the transaction is run and checked if it’s a correct transaction. Then the ordering takes place. This step does not have any grammar check or semantic check. Finally its validated. 7 Blockchain In Healthcare –use Case Because of data replication, healthcare suffers the largest issues at all times applications due to scalability. This is because patient data are updated all the time based on regular checkups. A patient undergoes many tests from different laboratories or departments in a hospital (Figure: 3) which may include tests like X-Ray, MRI scan or blood tests. These hospitals may belong to a network of hospitals. Data may be replicated in such scenario. Majority of these data is used for Research and Development. The data may also include many patient personal data. In a typical blockchain scenario, the data is encrypted and stored in a data lake. Hence, main challenges areas obviously in the medical field itself [ 55 ]. 8 Hierarchical Model–a Solution To Scalability Scalability enhancement was proposed by Sahoo et.al [ 57 ] in their hierarchical model [Figure: 4] as a solution to scalability. The model uses the lattice property of set of intervals where the access control and details are given at abstract levels instead of all communications within an entire block. This abstract mathematical interpretation [ 58 ] is used in security, programming and databases [ 59 – 61 ]. Access control mechanism is a difficult implementation in organizations with hierarchy. A better and reliable solution is to have smart contracts in the system. Every next hierarchy level has the BCi levels, verifications and validations that is at the private networks of the organizations. Private Blockchains are the highlight in the system at local levels in the organization. Then these are branched out to public blockchains with hierarchies. This is where the level of abstraction is proposed from a lower level. Hierarchical Model using Hyperledger Fabric for ERSB System There are many stakeholders for the data stored in a healthcare sector. This ranges from patients, doctors, hospitals, hospital networks to insurance companies. There can be a network of hospitals that record the patient data that are needed when there is an insurance claim. Whenever there is a reference to the data stored, we assume the patients also have an access and are aware where their data is used unlike the present scenario. This is where the hyperledger fabric and the inbuilt chaincode or smart contract is essential. Our healthcare use case assume that the insurance company access the patient data in an abstraction model and access as in a branch. Hierarchical model in clinical data study has been attempted before [ 62 ]. The model below is the hierarchical representation [Figure: 5]. It represents Insurance company on top in the hierarchy. A group of hospitals that belong to a particular network will report to the hospital network unit. Each hospital can be under the hospital network that are owned by the same group. And then there are multiple departments under each hospital. The enormous amount of patient data is a concern in such scenario. And only those channels that need the data should access them at that time through their peers. 9 Implementation Of Ersb Model The blockchain was implemented using the IBM’s hyperledger fabric model [ 63 ] with the hierarchical model [ 57 ]. The implementation [Figure: 5] shows how the first level of BCT is established between three organizations. That is one single channel that holds the same data that is accessible by all the organizations in the chain. The organizations that are used in the use case are Insurance company that gets all the data from a hospital network, The hospital network that holds data from all the concerned hospitals that come under them, and a set of ‘n’ hospitals that are linked to the same network, For example; a hospital branch that is in Texas (United States of America) and another one in Edinburgh (United Kingdom). A client who may take treatment from both the places should be able to access his data safely and know and discuss his rights with the Insurance company in whichever part of the world he goes. All the ledgers at all the hospitals are expected to update themselves after every transaction. Figure 6 : Implementation of Hyperledger fabric in the ERSB Model The experiment uses Java script on the chaincode [Figure: 6]. The chaincode consists of the following data in the script that the hospitals have and is accessible by the Insurance Company: 1. Transaction ID 2. Patient ID 3. Type of service, for example: consulting a doctor, lab test, medicine purchase etc. 4. Doctor ID 5. Cost of the Service 6. Insurance ID Since the consensus depend on the smart contract, the transaction is validated only when the policy is met according to the rules of the insurance company. These smart contracts are otherwise called the chaincode. The chaincode is deployed in the channel and once the transaction is ordered and validated, organizations are able to access the chaincode. Each peer (p) that is hosted by the hospital, hospital network and the insurance company act as an endorser or committer who commits a transaction and keeps the ledger state updated or the world state database. Before any transaction is committed, the endorsing peer endorses the transaction. Not all peers are endorsers in a transaction but all peers are committers to store the world state database for that particular channel with the updated asset information. The client applications (c) need to access the ledgers and for this, they get always connected to the peers. Only endorsed transactions are committed and stored and are accessible by the clients. Typically, whenever the user makes any transaction, the endorsed transaction is submitted and then committed. The user application also receives a notification about this. Whenever the client or a patient application requires an endorsed transaction to be committed, the ordering service (O) takes this up. That is, the ordering service orders the transaction and groups them as a block, sends them to the peers (hospital, hospital networks and the insurance company). This is important because this determines the order of all the services and the transactions until then. The MSP plays an important role ensuring all the protocols and mechanism for cryptography are maintained in the system. This include rules to check and maintain authenticity and authority of peers in the chain. Either from the fabric or an external Certificate Authority (CA) is used to issue keys and generate the MSPs in each peer (for hospital, networks and the Insurance). The experiment has recorded the time in accessing existing records from 100 to 1000 transactions-between the 3 organizations -Insurance Company, Hospital Network and Hospital1. This experiment currently works under the basic hierarchical model with first level of abstraction in hierarchy tested. This is much similar to the linear model at level1, as they all run through the same channel. The time to fetch the transactions are recorded with 100 transactions and then raised to 1000. The time is recorded with 118 peers or nodes added. The aim of the experiment is to replicate more number of transactions to check the throughput and latency with the same chaincode. Each time a record of complete transaction access is noted along with a search needed for a particular transaction. We assume 5 insurance companies, 100 hospital networks and each hospital to have 10 departments at least. 10 Results And Discussions More transactions are accessible. The experiment is conducted at different network connections. Time is recorded as before adding nodes and after adding nodes. The two operations performed separately are complete transactions accessed and search one particular transaction. Chaincode is found immutable because after every change in the chaincode the network had to be restarted. Transaction fetch and search is seen affected at stage one of implementation with more nodes added to the same channel. TPS might have been affected by the network connection. The user time is how long your program was running on the CPU, and the sys time was how long your program was waiting for the operating system to perform tasks for it. So basic benchmarking can be with user time + sys time. Real can be affected by other running processes and is considered more inconsistent. Hence we have considered user + sys time to check the results. Observation 1 : The test results in figure: 9 shows difference in time is not very evident with our experiment readings before and after adding the nodes. The first experiment is fetching the complete transaction dataset every time with an increment in 100 transaction added at each time. Hence scalability is increased at 100 transactions. Observation 2 : The test results in figure: 10 shows difference in time is not very evident with our experiment readings before adding nodes and after adding the nodes. The second experiment is searching for a particular transaction at a time. 100 transactions were added each time to the dataset. Hence the scalability is increased at 100. Observation 3 : When the first part of the implementation is done, there is some significant delay that is experienced while adding the peers. Once the peers are added then more or less the fetch time is the same. When more transactions are added, the response time with or without peers are the same. Hence there is a steady increase linearly. Observation 4 : The experiment is confirmed with a t-test performed using the time recorded during the entire transaction fetch and individual search operation. In both the above scenario, the Null Hypothesis and Alternate Hypothesis is as follows: Null Hypothesis: There is no significant difference in the means of the sample time between the two methods (Before adding the nodes). Alternate Hypothesis: There is significant difference between the means of sample time between the two methods (After adding the nodes). The Null Hypothesis is accepted in both above experiments in Figure: 9 and Figure: 10 since the nodes addition has not affected the framework. 11 CONCLUSION AND FUTURE WORK The next level of implementation will be as shown below to test the scalability. The models will be compared with same and different chaincodes, with more channels and nodes added. The main feature of a Blockchain system is that it believes entities to behave in an arbitrary manner, also known as Byzantine. Blockchain is more secure than traditional database systems, as it is built to tolerate Byzantine failure [ 64 ][ 65 ]. Blockchain technology introduced in a variety of industries including finance and banking, healthcare, government, security and many more. Every blockchain framework has a distinct goal and use case. When choosing a blockchain framework, there are a number of factors to consider as each framework comes with its own set of features. Ever since the conception of Blockchain implemented by Bitcoin, the world of crypto has not only popularized but also improved in terms of speed, scalability and so on. What we have discussed in this paper is just four of many consensus protocols. We have been able to analyze how they work, what is their fault tolerance etc. We have even been able describe their performance in terms of each of them and have identified the current problem / security issue. However, these all are at the time of writing this paper. New Protocols are introduced, and current Protocols upgrade regularly with better security, scalability, and speed. We hope that you were able to grasp the gist of few of the consensus protocols and their functions. The paper has further discussed different framework in BCT and why hyperledger fabric is a chosen one. The case study focuses on the healthcare sector with hierarchical model and abstract interpretation using smart contracts at each level. At the time of writing this paper, the experiment conducted is until the first abstract level, which creates, connect between hospital network and the insurance company. As we go down the levels in the model, scalability can be dealt by using the data only at the hospital or local level and not replicating all the data at all levels. The experiment holds three organizations in the chain where Hospital1 and Hospital 2 belong to the Hospital network presently. In addition, the network is connected to the Insurance Company. Our future work will be an expansion from here with multiple departments in the hospitals hosting their data where each hospital will maintain their own blockchain in the private mode, which according to the model will be BC1, and the network of hospitals will be BC2. This would further extent to BC3 to the Insurance company. As more channels will be added the hierarchical levels should also increase. This level of abstraction should reduce data duplicity because data should be accessible only where required within those particular channels. References Butijn, B.J., Tamburri, D.A., Heuvel, W.J.V.D.: Blockchains: a Systematic Multivocal Literature Review. (2019). arXiv preprint arXiv:1911.11770. Crosby, M., Pattanayak, P., Verma, S., Kalyanaraman, V.: Blockchain technology: Beyond bitcoin. Appl. Innov. 2 (6–10), 71 (2016) Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system.(2008). (2008) Macrinici, D., Cartofeanu, C., Gao, S.: Smart contract applications within blockchain technology: A systematic mapping study. Telematics Inform. 35 (8), 2337–2354 (2018) Buterin, V.: What is Ethereum?. Ethereum Official webpage. Available: (2016). http://www.ethdocs.org/en/latest/introduction/what-is-ethereum . html [Accessed on 07-06-2020] Chang, S.E., Chen, Y.: When blockchain meets supply chain: A systematic literature review on current development and potential applications. IEEE Access. 8 , 62478–62494 (2020) Salah, K., Rehman, M.H.U., Nizamuddin, N., Al-Fuqaha, A.: Blockchain for AI: Review and open research challenges. IEEE Access. 7 , 10127–10149 (2019) Zhang, S., Lee, J.H.: Analysis of the main consensus protocols of blockchain. ICT express. 6 (2), 93–97 (2020) Zhou, Q., Huang, H., Zheng, Z., Bian, J.: Solutions to scalability of blockchain: A survey. IEEE Access. 8 , 16440–16455 (2020) Wang, H., Zheng, Z., Xie, S., Dai, H.N., Chen, X.: ``Blockchain challenges and opportunities: A survey,'' Int. J. Web Grid Services. 14 (4), 352 (2018) Hanada, Y., Hsiao, L., Levis, P.: November. Smart contracts for machine-to-machine communication: Possibilities and limitations. In 2018 IEEE International Conference on Internet of Things and Intelligence System (IOTAIS) (pp. 130–136). IEEE. (2018) Evermann, J., Kim, H.: Workflow Management on Proof-of-Work Blockchains: Implications and Recommendations. SN Comput. Sci. 2 (1), 1–22 (2021) Zhang, R., Preneel, B.: May. Lay down the common metrics: Evaluating proof-of-work consensus protocols' security. In 2019 IEEE Symposium on Security and Privacy (SP) (pp. 175–192). IEEE. (2019) Heilman, E.: March. One weird trick to stop selfish miners: Fresh bitcoins, a solution for the honest miner. In International Conference on Financial Cryptography and Data Security (pp. 161–162). Springer, Berlin, Heidelberg. (2014) Sapirshtein, A., Sompolinsky, Y., Zohar, A.: February. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security (pp. 515–532). Springer, Berlin, Heidelberg. (2016) Miller, A., Juels, A., Shi, E., Parno, B., Katz, J.: Permacoin: Repurposing Bitcoin Work for Data Preservation. In IEEE Symposium on Security and Privacy, (2014) Miller, A.: Feather-forks: enforcing a blacklist with sub-50% hash power. bitcointalk.org, [Accessed on 03-11-2021] Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A., Felten, E.W.: May. Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In 2015 IEEE symposium on security and privacy (pp. 104–121). IEEE. (2015) Miller, A., LaViola, J.J.: Jr. Anonymous Byzantine Consensus from Moderately-Hard Puzzles. A Model for Bitcoin (2014) Garay, J., Kiayias, A., Leonardos, N.: The Bitcoin Backbone Protocol: Analysis and Applications. Cryptology ePrint Archive, Report 2014/765, (2014) Karame, G.O., Androulaki, E., Capkun, S.: October. Double-spending fast payments in bitcoin. In Proceedings of the 2012 ACM conference on Computer and communications security (pp. 906–917). (2012) Casper-Proof-of-Stake-Compendium, Accessed: Nov 4, 2021. [Online]. Available: https://eth.wiki/en/concepts/casper-proof-of-stake-compendium Vashchuk, O., Shuwar, R.: Pros and cons of consensus algorithm proof of stake. Difference in the network safety in proof of work and proof of stake. Electron. Inform. Technol. 9 (9), 106–112 (2018) Nguyen, C.T., Hoang, D.T., Nguyen, D.N., Niyato, D., Nguyen, H.T., Dutkiewicz, E.: Proof-of-stake consensus mechanisms for future blockchain networks: fundamentals, applications and opportunities. IEEE Access. 7 , 85727–85745 (2019) Yang, F., Zhou, W., Wu, Q., Long, R., Xiong, N.N., Zhou, M.: Delegated proof of stake with downgrade: A secure and efficient blockchain consensus algorithm with downgrade mechanism. IEEE Access. 7 , 118541–118555 (2019) Dantheman:. DPOS Consensus Algorithm-The Missing White Paper. [Online]. Available: (2021). https://steemit.com/DPoS/@dantheman/ DPoS-consensus-algorithm-this-missing-white-paper Kaur, S., Chaturvedi, S., Sharma, A., Kar, J., A Research Survey on Applications of Consensus Protocols in Blockchain. Security and Communication Networks, 2021. (2021) Zhou, T., Li, X., Zhao, H.: DLattice: A permission-less blockchain based on DPoS-BA-DAG consensus for data tokenization. IEEE Access. 7 , 39273–39287 (2019) Driscoll, K., Hall, B., Sivencrona, H., Zumsteg, P., September. Byzantine fault tolerance, from theory to reality. In International Conference on Computer Safety, Reliability, and Security (pp. 235–248). Springer, Berlin, Heidelberg. (2003) Veronese, G.S., Correia, M., Bessani, A.N., Lung, L.C., Verissimo, P.: Efficient byzantine fault-tolerance. IEEE Trans. Comput. 62 (1), 16–30 (2011) Kotla, R., Alvisi, L., Dahlin, M., Clement, A., Wong, E., October. Zyzzyva: speculative byzantine fault tolerance. In Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles (pp. 45–58). (2007) Castro, M., Liskov, B.: Practical Byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst. (TOCS). 20 (4), 398–461 (2002) Canetti, R., Rabin, T., ``Fast asynchronous Byzantine agreement with optimal resilience,'' in Proc. 25th Annu. ACM Symp. Theory Comput.-STOC, pp. 42–51. (1993) Zoican, S., Vochin, M., Zoican, R., Galatchi, D., November. Blockchain and consensus algorithms in Internet of Things. In 2018 International Symposium on Electronics and Telecommunications (ISETC) (pp. 1–4). IEEE. (2018) Vukoli´c, M.. The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication. In Proceedings of the International Workshop on Open Problems in Network Security, Zurich, Switzerland, 29 ; pp. 112–125. (2015) Feng, L., Zhang, H., Chen, Y., Lou, L., Scalable dynamic multi-agent practical byzantine fault-tolerant consensus in permissioned blockchain. Applied Sciences, 8(10), p.1919. (2018) Xiao, Y., Zhang, N., Lou, W., Hou, Y.T.: A survey of distributed consensus protocols for blockchain networks. IEEE Commun. Surv. Tutorials. 22 (2), 1432–1465 (2020) Kogias, E.K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., Ford, B., ``Enhancing bitcoin security and performance with strong consistency via collective signing,'' in Proc. 25th USENIX Security Symp. USENIX Secur., pp. 279–296. (2016) Syta, E., Tamas, I., Visher, D., Wolinsky, D.I., Jovanovic, P., Gasser, L., Gailly, N., Khoffi, I., Ford, B., ``Keeping authorities `honest or bust' with decentralized witness cosigning,'' in Proc. IEEE Symp. Secur. Privacy (SP), May pp. 526–545. (2016) Pass, R., Shi, E., ``Hybrid consensus: Efficient consensus in the permissionless model,'' in Proc. 31st Int. Symp. Distrib. Comput. (DISC), Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, (2017) Chikezie, U., Karacolak, T., Do Prado, J.C., August. Examining the Applicability of Blockchain to the Smart Grid Using Proof-of-Authority Consensus. In 2021 IEEE 9th International Conference on Smart Energy Grid Engineering (SEGE) (pp. 19–25). IEEE. (2021) Nandwani, A., Gupta, M., Thakur, N., ``Proof-of-participation: Implementation of proof-of-stake through proof-of-work,'' in Proc. Int. Conf. Innov. Comput. Commun. New Delhi, India: Springer, pp. 17–24. (2019) Bano, S., Sonnino, A., Al-Bassam, M., Azouvi, S., McCorry, P., Meiklejohn, S., Danezis, G., Consensus in the age of blockchains. (2017). arXiv preprint arXiv:1711.03936. Yuan, Y., Fei-Yue, W.: "Blockchain and cryptocurrencies: Model, techniques, and applications.". IEEE Trans. Syst. Man Cybernetics: Syst. 48 (9), 1421–1428 (2018) Baliga, A.: "The blockchain landscape." Persistent Systems. 3 , 5 (2016) Ozisik, A., Pinar, et al.. "Graphene: efficient interactive set reconciliation applied to blockchain propagation." Proceedings of the ACM Special Interest Group on Data Communication. 303–317. (2019) Benji, M., Sindhu, M.: "A study on the Corda and Ripple blockchain platforms." Advances in Big Data and Cloud Computing, pp. 179–187. Springer, Singapore (2019) [10] Ismailisufi, A., et al.. "A Private Blockchain Implementation Using Multichain Open-Source Platform." 2020 24th International Conference on Information Technology (IT). IEEE, (2020) Thakkar, P., Nathan, S., Viswanathan, B., "Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform," IEEE 26th International Symposium on Modelling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), 2018, pp. 264–276, doi: (2018). 10.1109/MASCOTS.2018.00034 Cachin, C.. "Architecture of the Hyperledger blockchain fabric." Workshop on distributed cryptocurrencies and consensus ledgers. Vol. 310. No. 4. (2016) Baliga, A., et al.. "Performance characterization of Hyperledger fabric." 2018 Crypto Valley conference on blockchain technology (CVCBT). IEEE, (2018) Sajana, P., Sindhu, M., Sethumadhavan, M.: On blockchain applications: hyperledger fabric and ethereum. Int. J. Pure Appl. Math. 118 (18), 2965–2970 (2018) Polge, J., Robert, J., Le Traon, Y.: Permissioned blockchain frameworks in the industry: A comparison. ICT Express (2020) Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., Muralidharan, S., April. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the thirteenth EuroSys conference (pp. 1–15). (2018) Zheng, Z., Xie, S., Dai, H.N., Chen, X., Wang, H.: Blockchain challenges and opportunities: A survey. Int. J. Web Grid Serv. 14 (4), 352–375 (2018) Dinh, T.T.A., Wang, J., Chen, G., Liu, R., Ooi, B.C., Tan, K.L., May. Blockbench: A framework for analyzing private blockchains. In Proceedings of the 2017 ACM International Conference on Management of Data (pp. 1085–1100). (2017) Sahoo, S., Fajge, A.M., Halder, R., Cortesi, A., A Hierarchical and Abstraction-Based Blockchain Model. Applied Sciences, 9(11), p.2343. (2019) Cousot, P.: Abstract interpretation. ACM Comput. Surv. (CSUR). 28 (2), 324–328 (1996) Blanchet, B., March. Security protocol verification: Symbolic and computational models. In International Conference on Principles of Security and Trust (pp. 3–29). Springer, Berlin, Heidelberg. (2012) Jana, A., Halder, R., Kalahasti, A., Ganni, S., Cortesi, A.: Extending Abstract Interpretation to Dependency Analysis of Database Applications. IEEE Transactions on Software Engineering (2018) Halder, R., Cortesi, A., Abstract interpretation Hassani, H., Huang, X., Silva, E., 2018. Big-Crypto: Big data, blockchain and cryptocurrency. Big Data and Cognitive Computing, 2(4), p.34. (2012) Kuo, T.T., Ohno-Machado, L., Modelchain: Decentralized privacy-preserving healthcare predictive modeling framework on private blockchain networks. (2018). arXiv preprint arXiv:1802.01746. Benedict, A. et.al, Course Guide, Blockchain Developer 2019, IBM MEA Skills Academy, Course code SABCD ERC 2.0 Wüst, K., Gervais, A., June. Do you need a blockchain?. In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT) (pp. 45–54). IEEE. (2018) Dinh, T.T.A., Liu, R., Zhang, M., Chen, G., Ooi, B.C., Wang, J.: Untangling blockchain: A data processing view of blockchain systems. IEEE Trans. Knowl. Data Eng. 30 (7), 1366–1385 (2018) Blockchain, Overview, IBM material @IBM Corporation 2018, (2019) Additional Declarations No competing interests reported. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-1903767","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":124722352,"identity":"ff17e385-6132-49cd-8d8b-0528e0f51335","order_by":0,"name":"Lipsa Sadath","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABHElEQVRIiWNgGAWjYBACPiCWYGA4IMfAwNgAEuABCyfg0cIG1pJwwBiopbEBoQWPHpiWxAaYNQyErGHjP/zwxs8fd9L7px1uf8zbdkfG4Hjv4w8Pfxxm4G9vwK5FIs3YsifhWe6M24mNzbxtz3gMzhw3k0hIOMwgceYADi0MZhI8CYdzGyBaDvNIzkhjYwBpYbiB3XVs/Me/Sf5JOJwuD9cy/xnzB5AW+fsPcHg/x0waaEuCAUwLvwQbA9hhBjdweF8ip9haJu2w4UaglplzzgG18KSxSSSkpfMYnsHuMH7+4xtvvrE5LC93O/3Bhzdlh+3Z2I8xf/xhYy0ndxy791EAEw+C3cyDWx0SYPyBYNcRpWMUjIJRMApGBAAAgClj95XdVwUAAAAASUVORK5CYII=","orcid":"","institution":"Amity University","correspondingAuthor":true,"submittingAuthor":false,"prefix":"","firstName":"Lipsa","middleName":"","lastName":"Sadath","suffix":""},{"id":124722353,"identity":"eb073482-1245-4ef2-83c5-c6af2f8c54e0","order_by":1,"name":"Deepti Mehrotra","email":"","orcid":"","institution":"Amity University Uttar Pradesh","correspondingAuthor":false,"submittingAuthor":false,"prefix":"","firstName":"Deepti","middleName":"","lastName":"Mehrotra","suffix":""},{"id":124722354,"identity":"7e1473a1-ddd9-4443-8e9f-16297e14689c","order_by":2,"name":"Anand Kumar","email":"","orcid":"","institution":"Amity University","correspondingAuthor":false,"submittingAuthor":false,"prefix":"","firstName":"Anand","middleName":"","lastName":"Kumar","suffix":""}],"badges":[],"createdAt":"2022-07-28 04:59:10","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-1903767/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-1903767/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":24733105,"identity":"ab0a3746-8dd8-42a6-9239-be8631871054","added_by":"auto","created_at":"2022-08-03 17:00:07","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":33314,"visible":true,"origin":"","legend":"\u003cp\u003e\tBlockchain Data Structure on a fully validating node\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e","description":"","filename":"floatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/c727699705f1862390a21af3.png"},{"id":24733597,"identity":"d881cbe0-2036-4ae9-a339-3143f5d9b54e","added_by":"auto","created_at":"2022-08-03 17:05:07","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":26868,"visible":true,"origin":"","legend":"\u003cp\u003e\tHyperledger Fabric\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e","description":"","filename":"floatimage2.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/6a00d37e664e310121394fb0.png"},{"id":24733114,"identity":"7349b225-c4be-464b-9bd1-14c603de2568","added_by":"auto","created_at":"2022-08-03 17:00:07","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":31524,"visible":true,"origin":"","legend":"\u003cp\u003eRepresentation of Blockchain data in Healthcare Use case\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e","description":"","filename":"floatimage3.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/131f106a526c62967d4de193.png"},{"id":24733107,"identity":"92583d3a-9756-416c-a3fd-9ea26b7d1c1d","added_by":"auto","created_at":"2022-08-03 17:00:07","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":72056,"visible":true,"origin":"","legend":"\u003cp\u003eDiagrammatic Representation of Hierarchical Blockchains\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e","description":"","filename":"floatimage4.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/5d0667cec97c87804320efff.png"},{"id":24733109,"identity":"8c6aa032-4f6f-4a42-b578-74ee46e583e3","added_by":"auto","created_at":"2022-08-03 17:00:07","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":236337,"visible":true,"origin":"","legend":"\u003cp\u003eEnhance Reliability of Scalable Blockchain Solution (ERSB) Model\u003c/p\u003e","description":"","filename":"floatimage5.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/4a1f4ab1df47fa7bd5519be4.png"},{"id":24733108,"identity":"339c21d9-c82e-4a33-be93-9f9385f74c2a","added_by":"auto","created_at":"2022-08-03 17:00:07","extension":"png","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":27683,"visible":true,"origin":"","legend":"\u003cp\u003eImplementation of Hyperledger fabric in the ERSB Model\u003c/p\u003e","description":"","filename":"floatimage6.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/4330db2f3707e30db126c3e3.png"},{"id":24733600,"identity":"c4f8d8c4-06e4-4f34-ac3a-e3b57d80d9c4","added_by":"auto","created_at":"2022-08-03 17:05:07","extension":"png","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":33053,"visible":true,"origin":"","legend":"\u003cp\u003eData on chaincode\u003c/p\u003e","description":"","filename":"floatimage7.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/44912296a0d4cf2201c6da52.png"},{"id":24733601,"identity":"3ae379d4-2969-4eeb-8e1d-240edccb4778","added_by":"auto","created_at":"2022-08-03 17:05:07","extension":"png","order_by":8,"title":"Figure 8","display":"","copyAsset":false,"role":"figure","size":19040,"visible":true,"origin":"","legend":"\u003cp\u003eExample data on chaincode –First level\u0026nbsp;\u003c/p\u003e","description":"","filename":"floatimage8.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/4539cbe5061a0a6d6d32d351.png"},{"id":24733112,"identity":"14568ce8-d8ee-4ba5-bf57-b487078d13f1","added_by":"auto","created_at":"2022-08-03 17:00:07","extension":"png","order_by":9,"title":"Figure 9","display":"","copyAsset":false,"role":"figure","size":203288,"visible":true,"origin":"","legend":"\u003cp\u003eExample data on chaincode –First level installations and time recorded for transactions\u003c/p\u003e","description":"","filename":"floatimage9.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/390cca91160512b390476371.png"},{"id":24734179,"identity":"5a7e0a27-73ed-4463-9293-21a370fe4c87","added_by":"auto","created_at":"2022-08-03 17:10:07","extension":"png","order_by":10,"title":"Figure 10","display":"","copyAsset":false,"role":"figure","size":26958,"visible":true,"origin":"","legend":"\u003cp\u003eSample time recorded to access complete transactions before and adding nodes\u003c/p\u003e","description":"","filename":"floatimage10.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/5e2b52350c6c424ea82e8500.png"},{"id":24733598,"identity":"c53e8672-91f7-4844-a7f1-04e65c6b609e","added_by":"auto","created_at":"2022-08-03 17:05:07","extension":"png","order_by":11,"title":"Figure 11","display":"","copyAsset":false,"role":"figure","size":20865,"visible":true,"origin":"","legend":"\u003cp\u003eResults with Transactions and User Time Recorded for a particular search operation\u003c/p\u003e","description":"","filename":"floatimage11.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/836625c5eb6c6e43ecdbbcd5.png"},{"id":24733602,"identity":"e1ae21e6-6144-4f64-bd33-34fa8cef9177","added_by":"auto","created_at":"2022-08-03 17:05:07","extension":"png","order_by":12,"title":"Figure 12","display":"","copyAsset":false,"role":"figure","size":9213,"visible":true,"origin":"","legend":"\u003cp\u003eExample data on chaincode –More nodes added with hierarchies\u0026nbsp;\u003c/p\u003e","description":"","filename":"floatimage12.png","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/fc8f388ac781d9a482c2df27.png"},{"id":24734181,"identity":"dc9c3df1-a168-429c-89ee-16812a2ccf4b","added_by":"auto","created_at":"2022-08-03 17:10:11","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1450671,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-1903767/v1/4a101476-cda1-4e59-8fe0-3c55acf89da1.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"Addressing Scalability Issues in Blockchain: A Use case from Healthcare","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eTechnology took a real turn with Blockchain as a medium that enabled data transfer between peers or participants as that established transparency without intermediaries in the system [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e], [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e]. This was a strong discovery. When there was a stock exchange collapse, Satoshi Nakamoto first established the concept in 2008 through the Bitcoins [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e] - the first cryptocurrency. With smart contracts [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e] in ethereum [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e] and their popularity, the concept was much used in developing most of the blockchain built systems in other entities. These included finance, healthcare, education, government organizations, supply chain [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e] and now extended to artificial intelligence[\u003cspan citationid=\"CR7\" class=\"CitationRef\"\u003e7\u003c/span\u003e] etc. The technological breakthrough that had the potential to revolutionize the way society did trade and interacted. It gained reputable label for its ability of allowing mutual untrusted nodes to exchange financial value and engage without the involvement for a trust worthy third party member.\u003c/p\u003e \u003cp\u003eBitcoin was one of the first to successfully implement Blockchain technology and attract the public\u0026rsquo;s attention. After which, many crypto companies and currencies emerged thereby making Blockchain a highly discussed and popular topic. Blockchain combines technology features like cryptography, P2P networking, distributed system, transparency, access identity permissions, open source, autonomy, and immutability. This makes the technology very secure as the transactions cannot be tweaked or tampered with and all the entities/parties, which make the transactions, are kept anonymous [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eThus, Blockchain offer integrity protected distributed ledgers, provides transparency of the entire process by upholding a set of global states. The participating nodes agree upon the existence, value and histories of all states. Each state contains multiple transactions. Hence, the Blockchain is a way to manage distributed transaction. The concerned entities preserve replicas of the data and jointly agree on a transaction execution order. This high performance blockchain system is a means for completely monitoring a system as if under the surveillance of a legal third party. However, then as more users entered the blockchain systems, there appeared the issue of scalability [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e]. Our study addresses the issue of scalability in blockchain technology with the help of a use case in the healthcare sector.\u003c/p\u003e \u003cp\u003eAt the time of this experiment, the system is evaluated at level-1. That is joining the basic 3 organizations. To test and understand the scalability issues, we have presently used one channel through the three organizations adding peers through all three. Transactions were increased from 10 to 1000 to know the performance of the system. The paper discusses scalability issues, structure of blockchain, different consensus models, relevance of hyperledger fabric, hierarchical model and the proposed ERSB model.\u003c/p\u003e"},{"header":"2. Scalability Issues","content":"\u003cp\u003eWith more users in the public chains such as Bitcoins and Ethereum, the scalability issues have arisen from sometime [\u003cspan citationid=\"CR10\" class=\"CitationRef\"\u003e10\u003c/span\u003e] with blockchains. To an extent, this has affected the technology in terms of development that can be implemented in other domains also. Much research has taken place in this area by researchers as well as software development companies. Though many of these solutions act to the needs somewhat, many other important aspects of blockchain systems such as security and decentralization were the biggest challenge to maintain [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e]. Thus as more nodes increases, validating every node and every transaction was an issue due scalability. At the same time, it is important that all transactions validate themselves for the next transactions. This is important for appropriately further validating the entire system.\u003c/p\u003e \u003cp\u003eOne of the major techniques that could be used was to redesign the blocks or to do a storage optimization. Even as the blockchain challenges exists, the technology still thrives to excel in its implementations. Many frameworks are in discussion on these grounds. Few of them were on-chain and other few off-chain. Especially with smart contracts in picture.\u003c/p\u003e"},{"header":"3 Blockchain Structure And Smart Contracts","content":"\u003cp\u003eA complete block structure [\u003cspan citationid=\"CR56\" class=\"CitationRef\"\u003e56\u003c/span\u003e] will have the following data structure that extends from the genesis (first block) to the block \u0026ldquo;n\u0026rdquo;. The application can be in any area like cryptocurrency, asset management or any security systems. Figure: [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e] explains this concept. There are blocks created and added to the chain that starts from the genesis block. Every node added runs the chaincode or smart contract to form the block and keep the ledger same for all the peers. Every block will have transaction and hash details including that of the previous block.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eA legal agreement or contract that is in the form of digital set of codes between two parties during a deal is how a smart contract works in the blockchain environment. This ethereum concept in cryptocurrencies verify the nodes in a decentralized network. Thus, smart contracts initiate a deal as if it is a trusted third party in action [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e], [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e]. The integrity of smart contracts is also a concern during implementation. This is even more essential in a public network where unknown parties get involved in transactions. Mainly because public networks use smart contracts where nodes are unknown to each other. This may not be of large concern in private organizations as the verifications take place at organization level itself and controlled more by a central authority that is the organization itself.\u003c/p\u003e \u003cp\u003eWhen blockchain technologies (BCT) have the cryptographic models to maintain security of the systems, consensus protocols [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e] add complexities to these models for quality and trustworthy BCT transactions. It is important that the nodes separately at their ends run these consensus protocols in order to ensure these nodes reach the required consensus about their previous transactions. This will help new block entries in the correct order needed. The nodes get ready to participate in any transaction with the hashes of the previous blocks. Typically, validation is established to improve the trust among all nodes in the system because all nodes produce identical outputs. This is in accordance with the consensus rules.\u003c/p\u003e"},{"header":"4 Consensus Protocols","content":"\u003cp\u003eNevertheless, new challenges and security issues keep on emerging every day due to which the design of a consensus protocol remains a major issue. The consensus of Blockchain is that every entity/node maintains the same distributed ledger. In the blockchain, the entity/party is both the server and the host. It requires exchanging information with other similar entities/parties to arrive at a consensus. It is important that the Consensus Protocol implemented must also be suitable for certain blockchain type that has the framework and purpose for which the blockchain is used [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e],[\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e]. Some of the major Consensus Protocols are discussed below:\u003c/p\u003e \u003cp\u003eA. Proof of Work (PoW)\u003c/p\u003e \u003cp\u003eBitcoin, the popular Cryptocurrency, uses the Proof of Work consensus. All participants or miners compete to resolve a computational puzzle in order to generate a new block [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e]. Here, on resolving the puzzle, the miner broadcasts the message to other participants for verification and gets a chance to create a new block. This protocol provides security in the form of block mining. But this protocol achieves its consensus by placing blocks in a distributed system even though the notes may show faults such as them being unreliable, unavailable, malicious, and more. The security of these kinds of the network is supported by specialized hardware and electricity, which makes them overpriced and inefficient from a resource and environmental standpoint [\u003cspan citationid=\"CR13\" class=\"CitationRef\"\u003e13\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eOne of the main challenges of this protocol is Selfish mining. It was an attack discovered by Eyal and Sirer [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e]. Selfish mining is when a miner keeps his/her discovered blocks private and continues to mine over them. This attack enables Selfish miners to avail unfair rewards. This scenario destroys the decentralized structure of the system and raises the success rate of various similar attacks. Another kind of attack is Double Spending [\u003cspan citationid=\"CR21\" class=\"CitationRef\"\u003e21\u003c/span\u003e]. Double Spending is when spending happens again on the same asset that is, an attack mode when a currency is stolen and the attacker transmits a copy of the transaction as though it is original. Earlier, double spending was thought to be difficult and impossible due to the mining power. But, in 2016, a paper published by Sompolinsky and Zohar [\u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e] exposed that an attacker could easily launch this attack on low mining power with the combination of Selfish Mining.\u003c/p\u003e \u003cp\u003eAnother kind of attack is Feather Forking [\u003cspan citationid=\"CR16\" class=\"CitationRef\"\u003e16\u003c/span\u003e],[\u003cspan citationid=\"CR17\" class=\"CitationRef\"\u003e17\u003c/span\u003e] proposed by Miller. In this attack, the attacker forks the blockchain to render the entire blocks invalid confirming the target. The attacker declares this publicly. The attacker continues the mining until the main chain is \u0026ldquo;k\u0026rdquo; blocks forwards. Luckily, the attack is considered unprofitable and the success rate is low with the mining power. Scientists argue that the latency is less when miners follow the consensus and compliant strategies [\u003cspan additionalcitationids=\"CR19\" citationid=\"CR18\" class=\"CitationRef\"\u003e18\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR20\" class=\"CitationRef\"\u003e20\u003c/span\u003e] and this improves scalability to an extent.\u003c/p\u003e \u003cp\u003eB. Proof of Stake (PoS)\u003c/p\u003e \u003cp\u003eIn Proof of Stake [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e], [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e] a method selecting which node can create, a new block relies on the stake rather than computational power. That is, participants get a chance to vote and elect leaders. These leaders are elected by their investments. Hence the name Proof of Stake. The challenges of verification here still exists because of the computational elimination. Etheruem uses the PoS consensus [\u003cspan citationid=\"CR22\" class=\"CitationRef\"\u003e22\u003c/span\u003e]. What makes this different from Proof of Work is that the nodes do not need to adjust their nonce many times instead; the nodes can solve this with the amount of stake. This makes proof of stake an energy-saving consensus because it does not use lots of computational power to arrive at a consensus [\u003cspan citationid=\"CR23\" class=\"CitationRef\"\u003e23\u003c/span\u003e]. For the block to be valid, it needs to have an address and a timestamp. Along with that, the user also needs to provide proof of ownership of the address.\u003c/p\u003e \u003cp\u003eAlso, due to one block being created per round of Proof of Stake [\u003cspan citationid=\"CR24\" class=\"CitationRef\"\u003e24\u003c/span\u003e], the generation and transaction speeds of blocks are much quicker than Proof of work. This has led to the recent popularity of this protocol. The security of Proof of Stake relies on many factors. A few of the Proof of Stake protocols are considered secure as long as the messages sent by network reaches their destinations within a certain time limit and handles scalability to extent.\u003c/p\u003e \u003cp\u003eC. Delegated Proof of Stake (DPoS)\u003c/p\u003e \u003cp\u003eThis model has a small group of delegates elected by the stakeholders. These delegates produce and validate the blocks. This algorithm was used for addressing scalability issues in Bitshare and EOS. The model reduce the time taken for the block generation and considered as just 3 secs. This divides the system into 3 parts. The first part is the witnesses that are elected through the voting system and play the main role by generating the blocks. The second is the delegates and the third is the workers. Security concerns arise for the fact that witnesses usually hold the block generation rights for a long period unless for a specific reason. This is considered as a risky situation [\u003cspan citationid=\"CR25\" class=\"CitationRef\"\u003e25\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eIn Delegated Proof of Stake, the node that create the block is also responsible for validating the transactions. In this protocol, a token holder can vote for their preferred block producer and their votes will be prioritized based on their stake. In addition, Token Holders may give their stake to another voter and cast a vote on their behalf in the block producer election [\u003cspan citationid=\"CR26\" class=\"CitationRef\"\u003e26\u003c/span\u003e]. Once they are elected, they may create blocks after verification of transactions that were created for the last block time in the order in which they were selected. If all blocks in the transactions are verified and signed, they receive rewards. Also, the rewards are shared equally with the users who voted for them. However, the rewards will not be given if they do not do their task in the allowed time. After which if the block is missed, and transactions remain unverified. Users could also vote out any offending party/delegate if they believe that there is malicious intent or activity involved thereby keeping real-time voting secured. Another advantage is its efficiency for Generating Blocks [\u003cspan citationid=\"CR25\" class=\"CitationRef\"\u003e25\u003c/span\u003e]. The number of blocks created by this protocol increases as time increases. The reason for this is that the time taken to select the node remains unchanged, which is why the protocol\u0026rsquo;s time increase. This leads to a slight increase in the creation of blocks. Compared to traditional protocols, this one has improved security, efficiency and better decentralization of block generation [\u003cspan citationid=\"CR27\" class=\"CitationRef\"\u003e27\u003c/span\u003e]. The model was further taken for other improvements using the lattice models as well [\u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eD. Practical Byzantine Fault Tolerance (PBFT)\u003c/p\u003e \u003cp\u003eIn current blockchains, Bitcoin uses Proof of Work (PoW), Ethereum uses Proof of Stake (PoS), other consensus were also discussed. The PBFT algorithm was created from Byzantine Generals Problem. It remains unharmed by malicious attacks and is implemented in many distributed computing environments.\u003c/p\u003e \u003cp\u003eA Byzantine fault occurs when in a distributed system, the nodes fail and the information about the failure is inconsistent and unclear. The community has discussed quite a bit about this problem. It is still unclear as to what vulnerability brings this condition to a system. These discussions have also proposed various architectural solutions [\u003cspan additionalcitationids=\"CR30\" citationid=\"CR29\" class=\"CitationRef\"\u003e29\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR31\" class=\"CitationRef\"\u003e31\u003c/span\u003e]. A solution to this was with the proposal of PBFT (Practical Byzantine Fault Tolerance) [\u003cspan citationid=\"CR32\" class=\"CitationRef\"\u003e32\u003c/span\u003e], [\u003cspan citationid=\"CR33\" class=\"CitationRef\"\u003e33\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eIn PBFT, there is a group that requires a leader, who is then elected using an \u0026lsquo;Election Algorithm\u0026rsquo;. Hence, the other nodes are known as Replicas. If a primary node fails, a new leader maybe selected with the creation of a new group. However, the nodes do not change their state and the requests remain organized. This is what makes this algorithm safe [\u003cspan citationid=\"CR34\" class=\"CitationRef\"\u003e34\u003c/span\u003e]. The system has a protocol with a 3 phase. The first phase is pre-prepare, the second is prepare and the third is the commit phase. The entire system has one message orderer server that begins the working of the phases on receiving a client request. This primary server broadcasts a message to pre-prepare to all other replica servers. During the prepare phase, if the any server makes a decision to accept the broadcasted pre-prepare message, then the server broadcasts accepted messages to all other replicas again. While \u0026ldquo;f\u0026rdquo; is the number of faulty nodes indicator, the server starts the commit phase, when it receives a 2f\u0026thinsp;+\u0026thinsp;1 messages as feedback. As in the prepare phase, the commit phase also has servers sending broadcast messages to others and wait for 2f\u0026thinsp;+\u0026thinsp;1 messages as feedback. This is a kind of voting to indicate that majority of the servers and clients agree on the messages sent [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eIBM utilized PBFT for developing \u0026lsquo;Hyperledger fabric\u0026rsquo; that provides member registration, identity management, auditability and more which helps to achieve high performance in certain environments [\u003cspan citationid=\"CR35\" class=\"CitationRef\"\u003e35\u003c/span\u003e]. While scalability is limited and needs improvement, PBFT has shown excellent performance with latency and throughput. Due to this protocol\u0026rsquo;s fault tolerance, many experts add this to their blockchain systems [\u003cspan citationid=\"CR36\" class=\"CitationRef\"\u003e36\u003c/span\u003e]. PBFT works in a synchronized system and needs many voting rounds, which makes it impractical. PBFT has inspired many BFT protocols with better security and performance. For synchronous networks, PBFT may exploit the timeout algorithm and detect of any issues or anomaly of the primary node [\u003cspan citationid=\"CR37\" class=\"CitationRef\"\u003e37\u003c/span\u003e]. Though PBFT works without computational tasks, it might cause some communication overhead. The utilization of PBFT in the Hyperledger fabric is an advantage in private organizations in terms of security, latency and throughput where the system is in a controlled permissioned environment.\u003c/p\u003e \u003cp\u003eE. Hybrid and Other Consensus\u003c/p\u003e \u003cp\u003eWhen protocols are combined, they form to give some classic models like the hybrid ones. PoW and PBFT were combined and used in Byzcoin [\u003cspan citationid=\"CR38\" class=\"CitationRef\"\u003e38\u003c/span\u003e]. Scalability was an advantage here when PBFT was able to reduce the cost of the prepare and commit phases by using a protocol called Cosi [\u003cspan citationid=\"CR39\" class=\"CitationRef\"\u003e39\u003c/span\u003e]. Mainly PoW was seen combined with many other consensus to form hybrid consensus [\u003cspan citationid=\"CR40\" class=\"CitationRef\"\u003e40\u003c/span\u003e]. Other consensus models that were proposed to improve the scalability was Proof of Authority (PoA) [\u003cspan citationid=\"CR41\" class=\"CitationRef\"\u003e41\u003c/span\u003e] relies on a very limited number of block validators that undergo rigorous security and identity scrutiny, thereby protecting the security and enhancing scalability. Proof of Participation (PoP) [\u003cspan citationid=\"CR42\" class=\"CitationRef\"\u003e42\u003c/span\u003e] was built on PoS and PoW combined. Unlike PoW the computational task is simpler and the transactional fee is distributed among participants which encourages them. Proof of Capacity (PoC) depends on miner\u0026rsquo;s disk space capacity to generate next block and get a reward. This is much similar to PoW but with less complex computational tasks.\u003c/p\u003e"},{"header":"5 Types Of Frameworks In Bct","content":"\u003cp\u003eThere are various blockchain frameworks such as Hyperledger, Openchain, Graphene, Corda, Multichain and various other blockchain frameworks. Since Blockchain technology can be used anywhere, major interest from various organizations has increased and it has caused more and better technology/frameworks. Hence, the technology is used in finance, commerce, healthcare, government, agriculture, and various other fields you can think of. For this to be implemented, organizations are required to choose a certain type of framework to suit their demands [\u003cspan citationid=\"CR44\" class=\"CitationRef\"\u003e44\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eOpenchain is a framework released by Coinprism. A framework that is designed to issue and manage digital assets. This framework is mainly used for finance and banking organizations. It also allows us to manage various kinds of financial transactions. It has enhanced anti-fraud and anti-theft systems, which is optimized and adaptive to different systems or needs. The architecture is mainly based around a client-server framework, which is more reliable than peer-peer framework. It is also a private network, and various users on GitHub actively update it. It is also open source and runs on JavaScript [\u003cspan citationid=\"CR45\" class=\"CitationRef\"\u003e45\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eGraphene is a framework written in C\u0026thinsp;+\u0026thinsp;+\u0026thinsp;language and it is the most adaptable one. It was created as an exchange medium for various cryptocurrencies, since then it has been used for various other fields. It is the most transparent and reliable framework it can process around 5,000 to 100,000\u0026thinsp;+\u0026thinsp;transactions per second which is most required by large financial organizations. It has the fastest block creation time as compared to other frameworks. It is an open source, and it is a private/public network [\u003cspan citationid=\"CR46\" class=\"CitationRef\"\u003e46\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eCorda is a framework written in Kotlin and Java, and it works as a mediator for businesses to cut down on transactional expenses. It has also helped with reducing the cost of record keeping and help business make their transactions mobile. The framework is open source, and it can be used to store and synchronize data between various financial institutes. It helps with keeping an open network to transfer various valuable assets with privacy. Its network is private, and permission based, therefore those with access can view or use the assets on the given server/network [\u003cspan citationid=\"CR47\" class=\"CitationRef\"\u003e47\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eMultichain is written in C\u0026thinsp;+\u0026thinsp;+\u0026thinsp;language and it can help you create a private block that can be used by your company or by various other companies. It was initially created to beat major problems affected by blockchains in financial areas, it even offers privacy packages and access levels for compartmentalizing data for protect. It even allows user permissions for the organization to set which user has which type of access. Members of the framework can manage the size of the block but can only view the data if they have their own private key. All blockchains created in the framework are regionalized which increase the security level. Multichain is easily configurable and modifiable [\u003cspan citationid=\"CR48\" class=\"CitationRef\"\u003e48\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eOne of the frameworks used by Hyperledger known as Hyperledger Fabric, which was created by various Japanese companies. This is a collaborative project to develop an open-source blockchain framework for enterprise usage. Its goal is develop blockchain technology by developing and implementing a cross-industry method for distributed ledgers that has the potential to revolutionize the way businesses transact globally in an open \u0026ndash;standard platform. The system gained more popularity because of the PBFT used in it and ease of implementation and community that supported the framework. Hence, Hyperledger fabric framework is used to implement our use case.\u003c/p\u003e"},{"header":"6 Hyperledger Fabric","content":"\u003cp\u003eHyperledger is an integrated blockchain framework that acts as a base for developing various blockchain-based products and applications using components that can be used by private entities. It is open source. It is designed in an environment in which multiple users can work within, which makes it suitable for finance, healthcare, and various domains. The community is quite huge and are its members [\u003cspan class=\"CitationRef\"\u003e49\u003c/span\u003e] are currently funding it.\u003c/p\u003e\n\u003cp\u003eIn the year 2016, the Linux Foundation launched the project. The framework was then created to host a mobile-focused framework that is easy to use and execute. Hyperledger Fabric is an open, proven, enterprise-grade, distributed ledger platform. It has advanced privacy controls so only the data you want shared gets shared among the \u0026ldquo;permissioned\u0026rdquo; (known) network participants [\u003cspan class=\"CitationRef\"\u003e50\u003c/span\u003e]. Some of the main benefits [\u003cspan class=\"CitationRef\"\u003e51\u003c/span\u003e], features and applications of the framework are discussed below:\u003c/p\u003e\n\u003cp\u003e\u003cspan\u003e\u003c/span\u003e\u003c/p\u003e\n\u003cp\u003eA. Benefits\u003c/p\u003e\n\u003cp\u003e\u003c/p\u003e\n\u003cp\u003e\u003cspan\u003e\u003c/span\u003e\u003c/p\u003e\n\u003cp\u003ei. Permissioned Network: Decentralized trust in a network of participants.\u003c/p\u003e\u003cspan\u003e\n \u003cp\u003eii. Confidential Transactions: Only data you want to share will be sharable.\u003c/p\u003e\n\u003c/span\u003e\u003cspan\u003e\n \u003cp\u003eiii. Pluggable architecture: It is easily usable regardless of usage size/environment.\u003c/p\u003e\n\u003c/span\u003e\u003cspan\u003e\n \u003cp\u003eiv. Ease of use: Custom languages and custom architectures.\u003c/p\u003e\n\u003c/span\u003e\n\u003cp\u003e\u003c/p\u003e\n\u003cp\u003e\u003cspan\u003e\u003c/span\u003e\u003c/p\u003e\n\u003cp\u003eB. Features and Applications\u003c/p\u003e\n\u003cp\u003e\u003c/p\u003e\n\u003cp\u003eThe core purpose of Fabric is Blockchain services; this category includes components such as a consensus manager, distributed ledger, peer-to-peer protocol and ledger storage [\u003cspan class=\"CitationRef\"\u003e52\u003c/span\u003e]. The consensus manager is in charge of providing an interface to the consensus algorithm as well as receiving transactions from other Hyperledger networks and executing them according to the desired consensus algorithm type [\u003cspan class=\"CitationRef\"\u003e52\u003c/span\u003e]. Certain use cases and specific trust models have adapted this for modular consensus protocols. The platform includes a native implementation of Solo, a consensus protocol in which the endorsing nodes execute and validate transactions in accordance with endorsement policies. Nevertheless, it is easy to adapt as other consensus protocols like the PBFT are used to be able to allow several ordering nodes, can be plugged in [\u003cspan class=\"CitationRef\"\u003e53\u003c/span\u003e] [\u003cspan class=\"CitationRef\"\u003e54\u003c/span\u003e].\u003c/p\u003e\n\u003cp\u003eSmart contracts use distributed ledger to record relevant state information during transactions. These transactions include chaincode. Which executes operations that may result in the global state being updated. The state is saved on a disk by each node. Fabrics block structure includes data like version, timestamps, transaction hash, state hash and prior hash. The other component is the peer-to-peer protocol, built using Google\u0026rsquo;s googleRPC platform. Protocol buffer defines the message structure in Fabric. The network discovers peers and executes confidential and public transactions using various messages. The final component is the ledger storage; RockDB is used to save state [\u003cspan class=\"CitationRef\"\u003e52\u003c/span\u003e]. Major features are:\u003c/p\u003e\n\u003cp\u003ei. Membership Service:\u003c/p\u003e\n\u003cp\u003eFabric implements a private permissioned model by utilizing a portable idea of membership coupled with industry standard identity management systems. A membership service provider or the MSP determines a node\u0026rsquo;s identity in a Fabric network. These nodes may include client nodes those who may propose transactions for or peers who maintain the ledger and its state; or ordering service nodes who determine the order of all transactions [\u003cspan class=\"CitationRef\"\u003e53\u003c/span\u003e][\u003cspan class=\"CitationRef\"\u003e54\u003c/span\u003e]. These features work together to provide fabric users with access control. It integrates public key infrastructure to facilitate authorization and identity management operations.\u003c/p\u003e\n\u003cp\u003eThere are three certificate authorities; Certificate Authority is one that will provide a long-term certificate to enrolled participants in order to provide to verify their identity. The transaction certificate authority issues transaction certificates to participants in order for them to send transaction via the network. TLS certificates are issued by a TLS to secure network level communication between fabric nodes. Fabric offers an entirely new blockchain design to accommodate flexibility as well as a revamped approach to dealing with non-determinism resource exhaustion, and performance threats [\u003cspan class=\"CitationRef\"\u003e52\u003c/span\u003e].\u003c/p\u003e\n\u003cp\u003eii. Chaincode Services:\u003c/p\u003e\n\u003cp\u003eFabric implements application logic with smart contracts known as chaincodes [\u003cspan class=\"CitationRef\"\u003e53\u003c/span\u003e]. Chaincodes execute inside a secure container that this service creates. It is comprised up of two parts: a secure container and a secure registry. Deploy Transaction \u0026ndash; take the installed chaincode, written in the Go programming language and is ready to use [\u003cspan class=\"CitationRef\"\u003e52\u003c/span\u003e].\u003c/p\u003e\n\u003cp\u003eiii. Invoke Transaction:\u003c/p\u003e\n\u003cp\u003eInvoke the transactions of a specific chaincode previously installed. Chaincode runs transactions and updates the state, then reports if the transaction was successful or unsuccessful [\u003cspan class=\"CitationRef\"\u003e52\u003c/span\u003e].\u003c/p\u003e\n\u003cp\u003eiv. Nodes:\u003c/p\u003e\n\u003cp\u003eThe fabric has three types of nodes namely the client, peer and ordered. The clients are the application users that initiate a transaction, a peer maintains a transaction by committing them and maintaining the ledger state by also letting other peers know the status, orderer nodes ensure the transaction communication and services by creating the blocks.\u003c/p\u003e\n\u003cp\u003ev. Peers:\u003c/p\u003e\n\u003cp\u003eThe peers are owned by organizations. It is a must that organizations own at least one peer. They responsibly notify the clients about the application submission or transaction update. The diagram shown below shows peer communications. The peers can be from different organizations communicating and doing transactions. Each peer can be independently running in their own environment. And can get connected to one or more channels. Thus peers are assigned a specific role in an organization and given blockchain access by a Certificate Authority [\u003cspan class=\"CitationRef\"\u003e66\u003c/span\u003e]. The peer waits for other peers for the ledger approval. This process is the consensus.\u003c/p\u003e\n\u003cp\u003evi. Consensus:\u003c/p\u003e\n\u003cp\u003eThe consensus in a hyperledger fabric has three steps of endorsing, ordering and validating the transaction. These are steps in a transaction flow. First the transaction is run and checked if it\u0026rsquo;s a correct transaction. Then the ordering takes place. This step does not have any grammar check or semantic check. Finally its validated.\u003c/p\u003e"},{"header":"7 Blockchain In Healthcare –use Case","content":"\u003cp\u003eBecause of data replication, healthcare suffers the largest issues at all times applications due to scalability. This is because patient data are updated all the time based on regular checkups. A patient undergoes many tests from different laboratories or departments in a hospital (Figure: 3) which may include tests like X-Ray, MRI scan or blood tests. These hospitals may belong to a network of hospitals. Data may be replicated in such scenario. Majority of these data is used for Research and Development. The data may also include many patient personal data. In a typical blockchain scenario, the data is encrypted and stored in a data lake. Hence, main challenges areas obviously in the medical field itself [\u003cspan citationid=\"CR55\" class=\"CitationRef\"\u003e55\u003c/span\u003e].\u003c/p\u003e \u003cp\u003e \u003c/p\u003e"},{"header":"8 Hierarchical Model–a Solution To Scalability","content":"\u003cp\u003eScalability enhancement was proposed by Sahoo et.al [\u003cspan citationid=\"CR57\" class=\"CitationRef\"\u003e57\u003c/span\u003e] in their hierarchical model [Figure: 4] as a solution to scalability. The model uses the lattice property of set of intervals where the access control and details are given at abstract levels instead of all communications within an entire block. This abstract mathematical interpretation [\u003cspan citationid=\"CR58\" class=\"CitationRef\"\u003e58\u003c/span\u003e] is used in security, programming and databases [\u003cspan additionalcitationids=\"CR60\" citationid=\"CR59\" class=\"CitationRef\"\u003e59\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR61\" class=\"CitationRef\"\u003e61\u003c/span\u003e]. Access control mechanism is a difficult implementation in organizations with hierarchy. A better and reliable solution is to have smart contracts in the system.\u003c/p\u003e \u003cp\u003eEvery next hierarchy level has the BCi levels, verifications and validations that is at the private networks of the organizations. Private Blockchains are the highlight in the system at local levels in the organization. Then these are branched out to public blockchains with hierarchies. This is where the level of abstraction is proposed from a lower level.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003e \u003cspan type=\"BoldItalic\" class=\"BoldItalic\" name=\"Emphasis\"\u003eHierarchical Model using Hyperledger Fabric for ERSB System\u003c/span\u003e \u003c/p\u003e \u003cp\u003eThere are many stakeholders for the data stored in a healthcare sector. This ranges from patients, doctors, hospitals, hospital networks to insurance companies. There can be a network of hospitals that record the patient data that are needed when there is an insurance claim. Whenever there is a reference to the data stored, we assume the patients also have an access and are aware where their data is used unlike the present scenario. This is where the hyperledger fabric and the inbuilt chaincode or smart contract is essential. Our healthcare use case assume that the insurance company access the patient data in an abstraction model and access as in a branch. Hierarchical model in clinical data study has been attempted before [\u003cspan citationid=\"CR62\" class=\"CitationRef\"\u003e62\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eThe model below is the hierarchical representation [Figure: 5]. It represents Insurance company on top in the hierarchy. A group of hospitals that belong to a particular network will report to the hospital network unit. Each hospital can be under the hospital network that are owned by the same group. And then there are multiple departments under each hospital. The enormous amount of patient data is a concern in such scenario. And only those channels that need the data should access them at that time through their peers.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e"},{"header":"9 Implementation Of Ersb Model","content":"\u003cp\u003eThe blockchain was implemented using the IBM\u0026rsquo;s hyperledger fabric model [\u003cspan citationid=\"CR63\" class=\"CitationRef\"\u003e63\u003c/span\u003e] with the hierarchical model [\u003cspan citationid=\"CR57\" class=\"CitationRef\"\u003e57\u003c/span\u003e]. The implementation [Figure: 5] shows how the first level of BCT is established between three organizations. That is one single channel that holds the same data that is accessible by all the organizations in the chain. The organizations that are used in the use case are Insurance company that gets all the data from a hospital network, The hospital network that holds data from all the concerned hospitals that come under them, and a set of \u0026lsquo;n\u0026rsquo; hospitals that are linked to the same network, For example; a hospital branch that is in Texas (United States of America) and another one in Edinburgh (United Kingdom). A client who may take treatment from both the places should be able to access his data safely and know and discuss his rights with the Insurance company in whichever part of the world he goes. All the ledgers at all the hospitals are expected to update themselves after every transaction.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eFigure \u003cspan refid=\"Fig6\" class=\"InternalRef\"\u003e6\u003c/span\u003e: Implementation of Hyperledger fabric in the ERSB Model\u003c/p\u003e \u003cp\u003eThe experiment uses Java script on the chaincode [Figure: 6]. The chaincode consists of the following data in the script that the hospitals have and is accessible by the Insurance Company:\u003c/p\u003e \u003cp\u003e \u003col\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003e1. Transaction ID\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003e2. Patient ID\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003e3. Type of service, for example: consulting a doctor, lab test, medicine purchase etc.\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003e4. Doctor ID\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003e5. Cost of the Service\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003e6. Insurance ID\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003c/ol\u003e \u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eSince the consensus depend on the smart contract, the transaction is validated only when the policy is met according to the rules of the insurance company. These smart contracts are otherwise called the chaincode. The chaincode is deployed in the channel and once the transaction is ordered and validated, organizations are able to access the chaincode. Each peer (p) that is hosted by the hospital, hospital network and the insurance company act as an endorser or committer who commits a transaction and keeps the ledger state updated or the world state database. Before any transaction is committed, the endorsing peer endorses the transaction. Not all peers are endorsers in a transaction but all peers are committers to store the world state database for that particular channel with the updated asset information.\u003c/p\u003e \u003cp\u003eThe client applications (c) need to access the ledgers and for this, they get always connected to the peers. Only endorsed transactions are committed and stored and are accessible by the clients. Typically, whenever the user makes any transaction, the endorsed transaction is submitted and then committed. The user application also receives a notification about this.\u003c/p\u003e \u003cp\u003eWhenever the client or a patient application requires an endorsed transaction to be committed, the ordering service (O) takes this up. That is, the ordering service orders the transaction and groups them as a block, sends them to the peers (hospital, hospital networks and the insurance company). This is important because this determines the order of all the services and the transactions until then.\u003c/p\u003e \u003cp\u003eThe MSP plays an important role ensuring all the protocols and mechanism for cryptography are maintained in the system. This include rules to check and maintain authenticity and authority of peers in the chain. Either from the fabric or an external Certificate Authority (CA) is used to issue keys and generate the MSPs in each peer (for hospital, networks and the Insurance).\u003c/p\u003e \u003cp\u003eThe experiment has recorded the time in accessing existing records from 100 to 1000 transactions-between the 3 organizations -Insurance Company, Hospital Network and Hospital1.\u003c/p\u003e \u003cp\u003eThis experiment currently works under the basic hierarchical model with first level of abstraction in hierarchy tested. This is much similar to the linear model at level1, as they all run through the same channel. The time to fetch the transactions are recorded with 100 transactions and then raised to 1000. The time is recorded with 118 peers or nodes added. The aim of the experiment is to replicate more number of transactions to check the throughput and latency with the same chaincode. Each time a record of complete transaction access is noted along with a search needed for a particular transaction. We assume 5 insurance companies, 100 hospital networks and each hospital to have 10 departments at least.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e"},{"header":"10 Results And Discussions","content":"\u003cp\u003eMore transactions are accessible. The experiment is conducted at different network connections. Time is recorded as before adding nodes and after adding nodes. The two operations performed separately are complete transactions accessed and search one particular transaction. Chaincode is found immutable because after every change in the chaincode the network had to be restarted. Transaction fetch and search is seen affected at stage one of implementation with more nodes added to the same channel. TPS might have been affected by the network connection.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe user time is how long your program was running on the CPU, and the sys time was how long your program was waiting for the operating system to perform tasks for it. So basic benchmarking can be with user time\u0026thinsp;+\u0026thinsp;sys time. Real can be affected by other running processes and is considered more inconsistent. Hence we have considered user\u0026thinsp;+\u0026thinsp;sys time to check the results.\u003c/p\u003e \u003cp\u003e \u003cem\u003eObservation 1\u003c/em\u003e:\u003c/p\u003e \u003cp\u003eThe test results in figure: 9 shows difference in time is not very evident with our experiment readings before and after adding the nodes. The first experiment is fetching the complete transaction dataset every time with an increment in 100 transaction added at each time. Hence scalability is increased at 100 transactions.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003e \u003cem\u003eObservation 2\u003c/em\u003e:\u003c/p\u003e \u003cp\u003eThe test results in figure: 10 shows difference in time is not very evident with our experiment readings before adding nodes and after adding the nodes. The second experiment is searching for a particular transaction at a time. 100 transactions were added each time to the dataset. Hence the scalability is increased at 100.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003e \u003cem\u003eObservation 3\u003c/em\u003e:\u003c/p\u003e \u003cp\u003eWhen the first part of the implementation is done, there is some significant delay that is experienced while adding the peers. Once the peers are added then more or less the fetch time is the same. When more transactions are added, the response time with or without peers are the same. Hence there is a steady increase linearly.\u003c/p\u003e \u003cp\u003e \u003cem\u003eObservation 4\u003c/em\u003e:\u003c/p\u003e \u003cp\u003eThe experiment is confirmed with a t-test performed using the time recorded during the entire transaction fetch and individual search operation. In both the above scenario, the Null Hypothesis and Alternate Hypothesis is as follows:\u003c/p\u003e \u003cp\u003eNull Hypothesis: There is no significant difference in the means of the sample time between the two methods (Before adding the nodes).\u003c/p\u003e \u003cp\u003eAlternate Hypothesis: There is significant difference between the means of sample time between the two methods (After adding the nodes).\u003c/p\u003e \u003cp\u003eThe Null Hypothesis is accepted in both above experiments in Figure: 9 and Figure: 10 since the nodes addition has not affected the framework.\u003c/p\u003e "},{"header":"11\tCONCLUSION AND FUTURE WORK","content":" \u003cp\u003eThe next level of implementation will be as shown below to test the scalability. The models will be compared with same and different chaincodes, with more channels and nodes added.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe main feature of a Blockchain system is that it believes entities to behave in an arbitrary manner, also known as Byzantine. Blockchain is more secure than traditional database systems, as it is built to tolerate Byzantine failure [\u003cspan citationid=\"CR64\" class=\"CitationRef\"\u003e64\u003c/span\u003e][\u003cspan citationid=\"CR65\" class=\"CitationRef\"\u003e65\u003c/span\u003e]. Blockchain technology introduced in a variety of industries including finance and banking, healthcare, government, security and many more. Every blockchain framework has a distinct goal and use case. When choosing a blockchain framework, there are a number of factors to consider as each framework comes with its own set of features. Ever since the conception of Blockchain implemented by Bitcoin, the world of crypto has not only popularized but also improved in terms of speed, scalability and so on. What we have discussed in this paper is just four of many consensus protocols. We have been able to analyze how they work, what is their fault tolerance etc. We have even been able describe their performance in terms of each of them and have identified the current problem / security issue. However, these all are at the time of writing this paper. New Protocols are introduced, and current Protocols upgrade regularly with better security, scalability, and speed. We hope that you were able to grasp the gist of few of the consensus protocols and their functions. The paper has further discussed different framework in BCT and why hyperledger fabric is a chosen one.\u003c/p\u003e \u003cp\u003eThe case study focuses on the healthcare sector with hierarchical model and abstract interpretation using smart contracts at each level. At the time of writing this paper, the experiment conducted is until the first abstract level, which creates, connect between hospital network and the insurance company. As we go down the levels in the model, scalability can be dealt by using the data only at the hospital or local level and not replicating all the data at all levels. The experiment holds three organizations in the chain where Hospital1 and Hospital 2 belong to the Hospital network presently. In addition, the network is connected to the Insurance Company.\u003c/p\u003e \u003cp\u003eOur future work will be an expansion from here with multiple departments in the hospitals hosting their data where each hospital will maintain their own blockchain in the private mode, which according to the model will be BC1, and the network of hospitals will be BC2. This would further extent to BC3 to the Insurance company. As more channels will be added the hierarchical levels should also increase. This level of abstraction should reduce data duplicity because data should be accessible only where required within those particular channels.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\u003cli\u003e\u003cspan\u003eButijn, B.J., Tamburri, D.A., Heuvel, W.J.V.D.: Blockchains: a Systematic Multivocal Literature Review. (2019). arXiv preprint arXiv:1911.11770.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCrosby, M., Pattanayak, P., Verma, S., Kalyanaraman, V.: Blockchain technology: Beyond bitcoin. Appl. Innov. \u003cb\u003e2\u003c/b\u003e(6\u0026ndash;10), 71 (2016)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eNakamoto, S.: Bitcoin: A peer-to-peer electronic cash system.(2008). (2008)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMacrinici, D., Cartofeanu, C., Gao, S.: Smart contract applications within blockchain technology: A systematic mapping study. Telematics Inform. \u003cb\u003e35\u003c/b\u003e(8), 2337\u0026ndash;2354 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eButerin, V.: What is Ethereum?. Ethereum Official webpage. Available: (2016). \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttp://www.ethdocs.org/en/latest/introduction/what-is-ethereum\u003c/span\u003e\u003cspan address=\"http://www.ethdocs.org/en/latest/introduction/what-is-ethereum\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e. html [Accessed on 07-06-2020]\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eChang, S.E., Chen, Y.: When blockchain meets supply chain: A systematic literature review on current development and potential applications. IEEE Access. \u003cb\u003e8\u003c/b\u003e, 62478\u0026ndash;62494 (2020)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSalah, K., Rehman, M.H.U., Nizamuddin, N., Al-Fuqaha, A.: Blockchain for AI: Review and open research challenges. IEEE Access. \u003cb\u003e7\u003c/b\u003e, 10127\u0026ndash;10149 (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZhang, S., Lee, J.H.: Analysis of the main consensus protocols of blockchain. ICT express. \u003cb\u003e6\u003c/b\u003e(2), 93\u0026ndash;97 (2020)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZhou, Q., Huang, H., Zheng, Z., Bian, J.: Solutions to scalability of blockchain: A survey. IEEE Access. \u003cb\u003e8\u003c/b\u003e, 16440\u0026ndash;16455 (2020)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eWang, H., Zheng, Z., Xie, S., Dai, H.N., Chen, X.: ``Blockchain challenges and opportunities: A survey,'' Int. J. Web Grid Services. \u003cb\u003e14\u003c/b\u003e(4), 352 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHanada, Y., Hsiao, L., Levis, P.: November. Smart contracts for machine-to-machine communication: Possibilities and limitations. In 2018 IEEE International Conference on Internet of Things and Intelligence System (IOTAIS) (pp.\u0026nbsp;130\u0026ndash;136). IEEE. (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eEvermann, J., Kim, H.: Workflow Management on Proof-of-Work Blockchains: Implications and Recommendations. SN Comput. Sci. \u003cb\u003e2\u003c/b\u003e(1), 1\u0026ndash;22 (2021)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZhang, R., Preneel, B.: May. Lay down the common metrics: Evaluating proof-of-work consensus protocols' security. In 2019 IEEE Symposium on Security and Privacy (SP) (pp.\u0026nbsp;175\u0026ndash;192). IEEE. (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHeilman, E.: March. One weird trick to stop selfish miners: Fresh bitcoins, a solution for the honest miner. In International Conference on Financial Cryptography and Data Security (pp.\u0026nbsp;161\u0026ndash;162). Springer, Berlin, Heidelberg. (2014)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSapirshtein, A., Sompolinsky, Y., Zohar, A.: February. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security (pp.\u0026nbsp;515\u0026ndash;532). Springer, Berlin, Heidelberg. (2016)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMiller, A., Juels, A., Shi, E., Parno, B., Katz, J.: Permacoin: Repurposing Bitcoin Work for Data Preservation. In IEEE Symposium on Security and Privacy, (2014)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMiller, A.: Feather-forks: enforcing a blacklist with sub-50% hash power. bitcointalk.org, [Accessed on 03-11-2021]\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A., Felten, E.W.: May. Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In 2015 IEEE symposium on security and privacy (pp.\u0026nbsp;104\u0026ndash;121). IEEE. (2015)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMiller, A., LaViola, J.J.: Jr. Anonymous Byzantine Consensus from Moderately-Hard Puzzles. A Model for Bitcoin (2014)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eGaray, J., Kiayias, A., Leonardos, N.: The Bitcoin Backbone Protocol: Analysis and Applications. Cryptology ePrint Archive, Report 2014/765, (2014)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKarame, G.O., Androulaki, E., Capkun, S.: October. Double-spending fast payments in bitcoin. In Proceedings of the 2012 ACM conference on Computer and communications security (pp.\u0026nbsp;906\u0026ndash;917). (2012)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCasper-Proof-of-Stake-Compendium, Accessed: Nov 4, 2021. [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://eth.wiki/en/concepts/casper-proof-of-stake-compendium\u003c/span\u003e\u003cspan address=\"https://eth.wiki/en/concepts/casper-proof-of-stake-compendium\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eVashchuk, O., Shuwar, R.: Pros and cons of consensus algorithm proof of stake. Difference in the network safety in proof of work and proof of stake. Electron. Inform. Technol. \u003cb\u003e9\u003c/b\u003e(9), 106\u0026ndash;112 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eNguyen, C.T., Hoang, D.T., Nguyen, D.N., Niyato, D., Nguyen, H.T., Dutkiewicz, E.: Proof-of-stake consensus mechanisms for future blockchain networks: fundamentals, applications and opportunities. IEEE Access. \u003cb\u003e7\u003c/b\u003e, 85727\u0026ndash;85745 (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eYang, F., Zhou, W., Wu, Q., Long, R., Xiong, N.N., Zhou, M.: Delegated proof of stake with downgrade: A secure and efficient blockchain consensus algorithm with downgrade mechanism. IEEE Access. \u003cb\u003e7\u003c/b\u003e, 118541\u0026ndash;118555 (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eDantheman:. DPOS Consensus Algorithm-The Missing White Paper. [Online]. Available: (2021). \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://steemit.com/DPoS/@dantheman/ DPoS-consensus-algorithm-this-missing-white-paper\u003c/span\u003e\u003cspan address=\"https://steemit.com/DPoS/@dantheman/ DPoS-consensus-algorithm-this-missing-white-paper\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKaur, S., Chaturvedi, S., Sharma, A., Kar, J., A Research Survey on Applications of Consensus Protocols in Blockchain. Security and Communication Networks, 2021. (2021)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZhou, T., Li, X., Zhao, H.: DLattice: A permission-less blockchain based on DPoS-BA-DAG consensus for data tokenization. IEEE Access. \u003cb\u003e7\u003c/b\u003e, 39273\u0026ndash;39287 (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eDriscoll, K., Hall, B., Sivencrona, H., Zumsteg, P., September. Byzantine fault tolerance, from theory to reality. In International Conference on Computer Safety, Reliability, and Security (pp.\u0026nbsp;235\u0026ndash;248). Springer, Berlin, Heidelberg. (2003)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eVeronese, G.S., Correia, M., Bessani, A.N., Lung, L.C., Verissimo, P.: Efficient byzantine fault-tolerance. IEEE Trans. Comput. \u003cb\u003e62\u003c/b\u003e(1), 16\u0026ndash;30 (2011)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKotla, R., Alvisi, L., Dahlin, M., Clement, A., Wong, E., October. Zyzzyva: speculative byzantine fault tolerance. In Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles (pp.\u0026nbsp;45\u0026ndash;58). (2007)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCastro, M., Liskov, B.: Practical Byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst. (TOCS). \u003cb\u003e20\u003c/b\u003e(4), 398\u0026ndash;461 (2002)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCanetti, R., Rabin, T., ``Fast asynchronous Byzantine agreement with optimal resilience,'' in Proc. 25th Annu. ACM Symp. Theory Comput.-STOC, pp.\u0026nbsp;42\u0026ndash;51. (1993)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZoican, S., Vochin, M., Zoican, R., Galatchi, D., November. Blockchain and consensus algorithms in Internet of Things. In 2018 International Symposium on Electronics and Telecommunications (ISETC) (pp.\u0026nbsp;1\u0026ndash;4). IEEE. (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eVukoli\u0026acute;c, M.. The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication. In Proceedings of the International Workshop on Open Problems in Network Security, Zurich, Switzerland, 29 ; pp.\u0026nbsp;112\u0026ndash;125. (2015)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eFeng, L., Zhang, H., Chen, Y., Lou, L., Scalable dynamic multi-agent practical byzantine fault-tolerant consensus in permissioned blockchain. Applied Sciences, 8(10), p.1919. (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eXiao, Y., Zhang, N., Lou, W., Hou, Y.T.: A survey of distributed consensus protocols for blockchain networks. IEEE Commun. Surv. Tutorials. \u003cb\u003e22\u003c/b\u003e(2), 1432\u0026ndash;1465 (2020)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKogias, E.K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., Ford, B., ``Enhancing bitcoin security and performance with strong consistency via collective signing,'' in Proc. 25th USENIX Security Symp. USENIX Secur., pp.\u0026nbsp;279\u0026ndash;296. (2016)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSyta, E., Tamas, I., Visher, D., Wolinsky, D.I., Jovanovic, P., Gasser, L., Gailly, N., Khoffi, I., Ford, B., ``Keeping authorities `honest or bust' with decentralized witness cosigning,'' in Proc. IEEE Symp. Secur. Privacy (SP), May pp.\u0026nbsp;526\u0026ndash;545. (2016)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003ePass, R., Shi, E., ``Hybrid consensus: Efficient consensus in the permissionless model,'' in Proc. 31st Int. Symp. Distrib. Comput. (DISC), Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, (2017)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eChikezie, U., Karacolak, T., Do Prado, J.C., August. Examining the Applicability of Blockchain to the Smart Grid Using Proof-of-Authority Consensus. In 2021 IEEE 9th International Conference on Smart Energy Grid Engineering (SEGE) (pp.\u0026nbsp;19\u0026ndash;25). IEEE. (2021)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eNandwani, A., Gupta, M., Thakur, N., ``Proof-of-participation: Implementation of proof-of-stake through proof-of-work,'' in Proc. Int. Conf. Innov. Comput. Commun. New Delhi, India: Springer, pp.\u0026nbsp;17\u0026ndash;24. (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBano, S., Sonnino, A., Al-Bassam, M., Azouvi, S., McCorry, P., Meiklejohn, S., Danezis, G., Consensus in the age of blockchains. (2017). arXiv preprint arXiv:1711.03936.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eYuan, Y., Fei-Yue, W.: \"Blockchain and cryptocurrencies: Model, techniques, and applications.\". IEEE Trans. Syst. Man Cybernetics: Syst. \u003cb\u003e48\u003c/b\u003e(9), 1421\u0026ndash;1428 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBaliga, A.: \"The blockchain landscape.\" Persistent Systems. \u003cb\u003e3\u003c/b\u003e, 5 (2016)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eOzisik, A., Pinar, et al.. \"Graphene: efficient interactive set reconciliation applied to blockchain propagation.\" Proceedings of the ACM Special Interest Group on Data Communication. 303\u0026ndash;317. (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBenji, M., Sindhu, M.: \"A study on the Corda and Ripple blockchain platforms.\" Advances in Big Data and Cloud Computing, pp. 179\u0026ndash;187. Springer, Singapore (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003e[10] Ismailisufi, A., et al.. \"A Private Blockchain Implementation Using Multichain Open-Source Platform.\" 2020 24th International Conference on Information Technology (IT). IEEE, (2020)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eThakkar, P., Nathan, S., Viswanathan, B., \"Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform,\" IEEE 26th International Symposium on Modelling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), 2018, pp.\u0026nbsp;264\u0026ndash;276, doi: (2018). \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1109/MASCOTS.2018.00034\u003c/span\u003e\u003cspan address=\"10.1109/MASCOTS.2018.00034\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCachin, C.. \"Architecture of the Hyperledger blockchain fabric.\" Workshop on distributed cryptocurrencies and consensus ledgers. Vol.\u0026nbsp;310. No. 4. (2016)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBaliga, A., et al.. \"Performance characterization of Hyperledger fabric.\" 2018 Crypto Valley conference on blockchain technology (CVCBT). IEEE, (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSajana, P., Sindhu, M., Sethumadhavan, M.: On blockchain applications: hyperledger fabric and ethereum. Int. J. Pure Appl. Math. \u003cb\u003e118\u003c/b\u003e(18), 2965\u0026ndash;2970 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003ePolge, J., Robert, J., Le Traon, Y.: Permissioned blockchain frameworks in the industry: A comparison. ICT Express (2020)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eAndroulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., Muralidharan, S., April. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the thirteenth EuroSys conference (pp.\u0026nbsp;1\u0026ndash;15). (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZheng, Z., Xie, S., Dai, H.N., Chen, X., Wang, H.: Blockchain challenges and opportunities: A survey. Int. J. Web Grid Serv. \u003cb\u003e14\u003c/b\u003e(4), 352\u0026ndash;375 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eDinh, T.T.A., Wang, J., Chen, G., Liu, R., Ooi, B.C., Tan, K.L., May. Blockbench: A framework for analyzing private blockchains. In Proceedings of the 2017 ACM International Conference on Management of Data (pp.\u0026nbsp;1085\u0026ndash;1100). (2017)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSahoo, S., Fajge, A.M., Halder, R., Cortesi, A., A Hierarchical and Abstraction-Based Blockchain Model. Applied Sciences, 9(11), p.2343. (2019)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCousot, P.: Abstract interpretation. ACM Comput. Surv. (CSUR). \u003cb\u003e28\u003c/b\u003e(2), 324\u0026ndash;328 (1996)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBlanchet, B., March. Security protocol verification: Symbolic and computational models. In International Conference on Principles of Security and Trust (pp.\u0026nbsp;3\u0026ndash;29). Springer, Berlin, Heidelberg. (2012)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eJana, A., Halder, R., Kalahasti, A., Ganni, S., Cortesi, A.: Extending Abstract Interpretation to Dependency Analysis of Database Applications. IEEE Transactions on Software Engineering (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHalder, R., Cortesi, A., Abstract interpretation Hassani, H., Huang, X., Silva, E., 2018. Big-Crypto: Big data, blockchain and cryptocurrency. Big Data and Cognitive Computing, 2(4), p.34. (2012)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKuo, T.T., Ohno-Machado, L., Modelchain: Decentralized privacy-preserving healthcare predictive modeling framework on private blockchain networks. (2018). arXiv preprint arXiv:1802.01746.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBenedict, A. et.al, Course Guide, Blockchain Developer 2019, IBM MEA Skills Academy, Course code SABCD ERC 2.0\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eW\u0026uuml;st, K., Gervais, A., June. Do you need a blockchain?. In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT) (pp.\u0026nbsp;45\u0026ndash;54). IEEE. (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eDinh, T.T.A., Liu, R., Zhang, M., Chen, G., Ooi, B.C., Wang, J.: Untangling blockchain: A data processing view of blockchain systems. IEEE Trans. Knowl. Data Eng. \u003cb\u003e30\u003c/b\u003e(7), 1366\u0026ndash;1385 (2018)\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBlockchain, Overview, IBM material @IBM Corporation 2018, (2019)\u003c/span\u003e\u003c/li\u003e\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":true,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"Blockchain, BCT, Scalability, Smart Contract, Hyperledger Fabric, Hierarchical Model, Healthcare Sector, Patient Data, Privacy, Data Security","lastPublishedDoi":"10.21203/rs.3.rs-1903767/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-1903767/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eThe opportunities with blockchain technology has grown immensely especially with its unique features such as immutability, transparency, decentralization etc. It is also important that the basic features such as privacy, security and scalability co-exists. Our novel study proposes a framework named ERSB (Enhanced Reliability of a Scalable Blockchain) implemented with Hyperledger fabric as a solution to address scalability issues. Multiple records are generated and processed during a patient’s hospital visits/stays, laboratory tests and insurance claims. When there are networks of hospitals under one umbrella (a group of hospitals), it is critical to address maintenance of this complex system in context of the afore-mentioned unique features. Our proposed framework uses a hierarchical model at hospital networks, laboratory and insurance company that has multiple levels.\u0026nbsp;Stages are evaluated with nodes added along with smart contracts. Smart contracts are also amended with more changes to observe performance, reliability and latency of the model at the first level of hierarchy.\u003c/p\u003e","manuscriptTitle":"Addressing Scalability Issues in Blockchain: A Use case from Healthcare","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2022-08-03 17:00:05","doi":"10.21203/rs.3.rs-1903767/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"3786da3c-fa76-4e30-bbe6-09058006c61c","owner":[],"postedDate":"August 3rd, 2022","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[],"tags":[],"updatedAt":"2022-08-03T17:00:07+00:00","versionOfRecord":[],"versionCreatedAt":"2022-08-03 17:00:05","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-1903767","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-1903767","identity":"rs-1903767","version":["v1"]},"buildId":"7rjqhiLT3MXkJMwkYKINL","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}