MIStore: a Blockchain-Based Medical Insurance Storage System

Currently, blockchain technology, which is decentralized and may provide tamper-resistance to recorded data, is experiencing exponential growth in industry and research. In this paper, we propose the MIStore, a blockchain-based medical insurance storage system. Due to blockchain’s the property of tamper-resistance, MIStore may provide a high-credibility to users. In a basic instance of the system, there are a hospital, patient, insurance company and n servers. Specifically, the hospital performs a (t, n)-threshold MIStore protocol among the n servers. For the protocol, any node of the blockchain may join the protocol to be a server if the node and the hospital wish. Patient’s spending data is stored by the hospital in the blockchain and is protected by the n servers. Any t servers may help the insurance company to obtain a sum of a part of the patient’s spending data, which servers can perform homomorphic computations on. However, the n servers cannot learn anything from the patient’s spending data, which recorded in the blockchain, forever as long as more than n − t servers are honest. Besides, because most of verifications are performed by record-nodes and all related data is stored at the blockchain, thus the insurance company, servers and the hospital only need small memory and CPU. Finally, we deploy the MIStore on the Ethererum blockchain and give the corresponding performance evaluation.


Introduction
Bitcoin, proposed in 2009 by Satoshi Nakamoto [1], is the first decentralized cryptocurrency which maintains a public transaction ledger, called blockchain, in a distributed manner without the central authority. The core technological innovation of Bitcoin is Nakamoto consensus which provides a high-probability guarantee that an adversary cannot alter a transaction once this transaction is sufficiently deep in the blockchain, assuming honest nodes control the majority of computational resources in the system. The Nakamoto blockchain works in a permissionless model, where any node can freely join and leave the protocol, and there is no a-priori knowledge of the set of consensus nodes. This  Alternative cryptocurrencies called altercoins (e.g., Litecoin [2], Ripple [3] and Ethereum [4]) have achieved enormous success. Several consensuses to manage blockchain-based ledgers have been proposed: proof-of-work [5], proof-ofstake [6,7], proof-of-space [8], proof-of-activity [9], proofof-human-work [10], practical Byzatine fault-tolerance [11], or some combinations [12][13][14]. Especially, most existing cryptocurrencies, including Bitcoin, adopt proof-of-work.
Blockchain is a tamper-resistant timestamp ledger of blocks that is utilized to share and store data in a distributed manner. The stored data may be payment records (e.g., Bitcoin, Litecoin), contract (e.g., Ethererum) or personal data. Currently, blockchain has attracted enormous attention from academics and practitioners (e.g., computer science, finance and law) due to its signal properties containing distributed structre, security, privacy and immutability [17]. In blockchain, users can generate a arbitrary number of public keys that effectively prevents them from being tracked, and this ensure users' privacy. Recently, blockchain has been widely utilized in non-monetary applications including but not limited to: securing robotic swarms [19] and verifying proof of location [20]. Moreover, blockchain can use cryptography technologies [31][32][33] to improve it security, privacy and functionality.
Recently, blockchain-based medical system is a hot topic. Yue et al. [18] proposed a APP of sharing healthcare data, where patients control, send and own their data easily. Moreover, Qi et al. [30] proposed the MeDShare, a system that can address the problem of medical data sharing among medical big data servers in a trust-less environment. Besides, Ekblaw et al. [29] presented the MedRec, decentralized record management system to resolve electronic health records by using blockchain. In the researches, they did not provide the function of homomorphic computing for data recorded at the blockchain, and they just utilized the blockchain as a storage tool. Therefore, in the systems, a node cannot help others to process encrypted data.
In an ideal and basic medical insurance business, there are a hospital, a patient and an insurance company. The insurance company can to know a sum of the patient's specified spending records, however the company cannot learn the details of the spending records. Furthermore, servers can help the insurance company to process a patient's spending records without learning anything about the spending records. Otherwise, it will result in a risk of information leakage. Moreover, once the insurance company attempt to know the patient's sum of spending records, the insurance company can get his desired result without any help of hospital and patient. Finally, the most important point is that all data must be verifiable and tamper-resistant. Otherwise, the system could not be credible.
To address the problems, in the present paper, we propose the MIStore, a blockchain-based medical insurance storage system. Features of MIStore can be summarized as follows: • Decentralization. There is no the third party authorities to provide any authentication. Moreover, any node may become some hospital's server if the node and the hospital wish. Besides, data is stored at the blockchain, rather than cloud servers. • Secure data storage. On the one hand, every transaction's publicly verifiable data must be verified by all record-nodes before the transaction is included in the blockchain. On the other hand, we suggest that MIStore adopts the Practical Byzantine Fault-tolerance (PBFT) to be the consensus scheme of the blockchain, and all related data is stored at the blockchain. Due to PBFT's property of tamper-resistance, data, which has been included by record-nodes in the blockchain, cannot be modified or deleted by anyone. Due to the above two points, it provides high credibility to all users. Therefore, once a transaction has been included in the blockchain, all its publicly verifiable data is credible. • Threshold. For instance, a hospital performs a (t, n)threshold MIStore protocol among a patient, an insurance company and n servers. Firstly, the hospital store confidential data in the blockchain. Secondly, the servers cannot learn anything from the data if more than n − t servers are honest. • Efficient verification. Key data is recorded in the transaction's payload, and most of key data is publicly verifiable. Therefore, record-nodes can help other nodes to verify payloads' data before the transactions are recorded in the blockchain. Consequently, once a transaction has been recorded in the blockchain, the transaction's publicly verifiable data is credible. After that, the transaction's receiver needs not to perform the verifications performed by record-nodes. Moreover, the receiver just needs to perform very little verification that can be performed only by him. In this way, it significantly reduces users' verifying computations, and receivers just perform some simple and few computations, rather than complex and massive computations. • Efficient homomorphic computation. According to insurance company's query, servers can perform homomorphic multiplications and additions on their shares, and then generate responses. Moreover, the homomorphic computations calculated by servers are efficient additions and multiplications of finite field.
Organization In "Background", background is introduced. In "System setting and model", we show the system setting and model. In "An overview of MIStore", an overview of MIStore is given. We introduce construction of the MIStore system in "MIStore". In "Performance evaluation", a performance evaluation is given. Finally, a short conclusion is given in "Conclusion".

Background
Bitcoin [1] is a decentralized payment scheme in which every participant maintains its own local copy of the whole transaction history, "chain" of "blocks" called blockchain. Blockchain is maintained by anonymous record-nodes, called miners, via executing a consensus scheme that extends the blockchain. The record-nodes are connected by a reliable peer-to-peer network. Bitcoin consistency relies on the idea of computational puzzles-a.k.a. moderately proof-of-work put forth by Dwork and Naor [16]. In Bitcoin, payers broadcast transactions and miners collect transactions into their local blocks. A block contains two parts: block-body and block-header. Specifically, the block-body contains the transactions. The block-header contains the hash value of previous block, the current Unix time, target value, a nonce and a merkle root of transactions. In Bitcoin consensus, a block to be valid if the cryptographic hash of its header must be smaller than a target value. Moreover, if some miner finds a solution of the cryptographic puzzle, then he immediately broadcasted his block including the solution to others. After that, upon verifying the block, others will receive and add this block as a new one in its local blockchain and then continue the mining process on its updated blockchain. The creator of the block is rewarded with bitcoins (coins in Bitcoin system) via the coinbase transaction which is the first transaction in the block-body. Consequently, bitcoins are created and distributed among miners. Moreover, this creator is also rewarded by transactions fees for all transactions included in the block. Besides, Bitcoin assumes that a majority of computational power is controlled by honest players. Smart contract is proposed by Ethereum [15] that is similar as Bitcoin. Smart contracts represent the implementation of a contractual agreement, whose legal provisions have been formalized into source code. Contracting parties can structure their relationships efficiently, in a self-executing method and without the ambiguity of words. Reliance on source code enables willing parties to simulate the agreement's performance before execution and model contractual performance. Moreover, smart contracts introduce new relationships that are both automatically enforced and defined by code, but that are not linked to any underlying contractual rights or obligations. In the present paper, before hospital and servers work, they should mortgage coins in smart contracts, respectively. Besides, if someone does not work honestly, then anyone can input the corresponding evidences to obtain a part of the "wrongdoer"'s guarantee deposit.
In the paper, the security of Shamir's (t, n)-secret sharing (SSS) [21] is the security base of our system. We extend SSS to obtain a threshold secure multi-parties computing protocol that will be described in the Appendix. Besides, we use elliptic curve [22,23] point multiplication to generate commitments of core data. Then we utilize bilinear map (pairing computations) [25] to verify the correctness of the committed core data.
Figures presented in the paper are created by using Visio.

Blockchain network and cryptographic keys
MIStore is comprised of record-nodes and light-nodes. Specifically, all record-nodes are connected by a reliable peer-to-peer network, and each light-node connects with a certain number of record-nodes. Record-nodes are responsible to maintain the blockchain via Practical Byzantine Fault-tolerance (PBFT) consensus and store the entire blockchain list. Specifically, time is divided in to epoches. In an epoch, record-nodes collect and verify transactions sent to the blockchain network, and they record valid transactions in their local blocks. By performing PBFT, some record-node's block become the valid block of the epoch. After that, all record-nodes join in the next epoch to build the next block. While, light-nodes do not store the entire blockchain, and they store all block-headers. Moreover, in the system, there is no trusted public key infrastructure. It means that any node can generate a arbitrary number of key-pairs by itself. In a blockchain system, all users communicate with each other via transactions of blockchain, and they only trust messages presented at blockchain. Additionally, each record-node can poll a random oracle [24] as a random bit source. Besides, by mortgaging a certain amount of coins with an address, a light-node can become a hospital or insurance company with the address.
A node is honest if it follows all protocol instructions and is perfectly capable of sending and receiving information. Furthermore, a node is malicious if it can deviate arbitrarily from protocol instructions. Finally, in a blockchain system, all users communicate with each other via transactions of blockchain, and they only trust messages presented at blockchain.

Assumptions
According to Practical Byzantine Fault-tolerance [11] consensus scheme, we assume that 2 The basic instance In the paper, we mainly introduce the basic instance that contains a patient, a hospital and insurance company. For the patient, a more complex instance can be combined by the basic instance. Moreover, we assume that medical payments recorded in the blockchain belong to the range of the corresponding medical insurance.

An overview of MIStore
In this paper, we propose a blockchain-based medical insurance storage system, called MIStore. The system may help an insurance company to obtain the sum of patient's medical medical spending records. Moreover, the medical spending data recorded at the blockchain are always confidential to servers as long as a certain number of servers are honest. In this system, there are four parties that are patients, hospitals, servers and insurance companies. All related data is recorded at the blockchain. Due to the property of tamper-resistance of blockchain, all users may trust data recorded at the blockchain.
To introduce MIStore's working process, we take the basic instance as a example, which contains a hospital H , a patient P , an insurance company I and n servers Sr 1 , Sr 2 , · · · Sr n . Specifically, H performs a (t, n)threshold MIStore protocol among the n servers by sending an initialize-transaction to the blockchain network. After that, H may send P 's confidential medical spending data to the blockchain network by sending record-transactions. At some later time, if I wants to know the sum of some P 's spending records, then I may send a query-transaction to the blockchain network. After that, active servers will generate and send responses to the blockchain network by sending respond-transactions. Finally, if I collects at least t correct responses, then he can recover the real result. However, it must be pointed that anyone (including I ) cannot learn anything about the correct result with less than t responses. The protocol is secure as long as more than n−t servers are honest. An overview of MIStore is shown in Fig. 1.
In the MIStore, most data is verifiable. For instance, anyone can verify the validation of the initialize-transaction sent by the hospital, a server may verify the correctness of his core share sent by the hospital, an insurance company can verify whether responses are correctly computed by corresponding servers, and a patient can verify whether his spending data is correctly processed by the corresponding hospital. Moreover, because MIStore is decentralized, so there is no centralized node to punish the "bumblers". To punish the bumblers' mistake, we adopt the smart contract. Specifically, before hospitals and servers perform a MIStore protocol, they should a certain amount of mortgage coins in smart contracts, respectively. If someone of them publishes some invalid data in the blockchain, then anyone can input the evidences in the corresponding smart contract to obtain a part of the bumbler's guarantee deposit.

MIStore
In this section, we introduce how MIStore works. We will describe transaction and block used in the system at first.

Transaction and block
In MIServer, a transaction contains two parts that are transaction header and payload. Transaction header and payload are shown in Table 1.
Moreover, the payload might contain secret or public data that may be used in verifications or computations. In the system, according to payload, transactions can be divided into four types. They are initialize-transaction, recordtransaction, query-transaction and respond-transaction, and they can be described by T initialize , T record , T query and T respond as follows: In MIStore, time is also divided into epoches. In each epoch, record-nodes will generate a block belong to the epoch via selected consensus scheme, and a block can be described as follow (Table 2):

Transaction Header Payload
Besides, record-nodes are responsible to verify all publicly verifiable data of transactions before the transactions are included in the blockchain. If any publicly verifiable data is invalid, then honest record-nodes will reject corresponding transactions. The transaction then will not be included in the blockchain. Moreover, due to adopting the Practical Byzantine Fault-tolerance consensus scheme, if a transaction has presented at the blockchain, then all nodes Futhermore, in the MIStore system, record-nodes may perform two kinds of verifications on transactions. The first one is the basic verification, which should be performed on all transactions. They are: -The transaction's inputs have not been used previously.
-The transaction's signature is valid.
-The sum of input coins is equal to the sum of output coins.
The second one is the payload verification, which can be performed on initialize-transactions and respondtransactions. It means that, in the payloads of initializetransaction and respond-transaction, there is publicly verifiable data that may be verified by record-nodes. If a transaction has presented at the blockchain, then it means that most of record-nodes have accepted the transaction's publicly verifiable data. Therefore, the transaction's receiver can consider that the transaction's publicly verifiable data is credible. Thus the receiver just needs to perform some other verifications that can be performed only by him. In this way, the most of verification computations are performed by record-nodes and it helps to decreases servers' and insurance company's verification computations significantly. Figure 2 describes verifications of initialize-transaction, record-transaction, query-transaction and respond-transaction.

Construction of MIStore
To clearly introduce the MIStore system, in this subsection, we describe the basic instance that contains a hospital, a patient, an insurance company and n servers. Specifically, Sr 1 , Sr 2 , · · · , Sr n denote n servers' IDs, ID H is the hospital's ID, ID P is the patient's ID and ID I describes the insurance company's ID. Essentially, more complex instance can be constructed with the basic instance. The symbols used in the paper are shown in Table 3. At first, the hospital and n servers should have published smart contracts to mortgage a certain amount of guarantee coins at the blockchain, respectively. If someone publishes some incorrect data that is verifiable, then the discoverer can send the corresponding evidences to the bumbler's smart contract to prove that the bumbler sent an incorrect data. Then, the discoverer can automatically obtain a amount of reward from the bumbler's smart contract.
After mortgaging guarantee coins, the MIStore system can be performed as follows: • Step 1: Initialization. Hospital randomly samples two polynomials F 1 (x) and F 2 (x) of degree t − 1 over F p as the following polynomials: The i-th plaintext message protected by n servers {CF i,1 , CF i,2 , Ch i } The i-th server's core-share

Resp i
The i-th server's respnse where s core,1 , s core,2 , a 1 , · · · , a t−1 , After that, hospital randomly samples as follow: Then hospital generates a verification key VK as follow: VK = {g, g a t−1 , · · · , g a 1 , g s core,1 , g d t−1 , · · · , g d 1 , g s core,2 , where g is a base point of 256-bit Barreto-Naehrig curve (BN-curve) [25]. For i from 1 to n, hospital does as follows: and After that, the hospital sends the T initialize to blockchain network. • Step 2: Record-nodes verify T initialize . Honest recordnodes will verify all new initialize-transactions before appending them at the blockchain. For instance, when an honest record-node receives the T initialize , he will verify its verification key (V K) at first, and then verify other data with the V K. If T initialize passes the verifications, then the record-node accepts the T initialize and writes it in his local block, otherwise, he will reject the T initialize . The verifications are described as follows: -First, verify the verification key V K. The record-node verifies whether polynomials and l(x), committed in verification key, are well-formed. Specifically, the record-node does as follows: Randomly sample a number x 0 ∈ F p . Compute then the record-node accepts that f 1 (x), f 2 (x), h(x) and l(x) satisfy relationships and forms mentioned at Step 1. Otherwise he rejects the T initialize and stops his verifications.
-Second, verify commitments CM CF i,1 , CM CF i,2 , CM Ch i , i from 1 to n. Specifically, the record-node computes as follows: then the record-node accepts that CM CF i,1 , CM CF i,2 and CM Ch i are correctly computed by the hospital, otherwise he rejects the T initialize and stop his verifications.
If any data cannot pass corresponding verification, then the record-node rejects the T initialize .
Remark 1 Because the record-node randomly samples the number x 0 , so the Eq. 1 is enough to prove the validation of the verification key.
• Step 3: Servers verify core-shares. i from 1 to n, when the Server i sees the T initialize at the blockchain, the server may perform the following computations: -Decrypt C CF i,1 , C CF i,2 and C Ch i . Then he obtains CF i,1 , CF i,2 and Ch i . -If then the server accepts that the T initialize is valid, otherwise he can send his evidences ID T initialize , CF i and Ch i to the hospital's smart contract. After that, the server can obtain a amount of reward.
• Step 4: Record. After seeing the T initialize at the blockchain, the hospital may generate recordtransactions. Moreover, let da 1 , da 2 , · · · , da m denote the patient's spending records. The each spending record has a unique invoice number, ID i invoice . However, they belong to the same initialize-transaction T initialize . Without loss of generality, we assume that the hospital generates two record-transactions (T 1 and T 2 ), and the patient's spending records are da 1 , da 2 , da 3 , da 4 . Then, i from 1 to 4, hospital randomly divides da i into da i = dd i,1 dd i,2 . Then, the hospital computes Then, it generates transactions T 1 , T 2 as follows: After that, the hospital sends T 1 , T 2 to blockchain network. • Step 4.5: Patient verifies spending records. The patient knows the true spending records da 1 , da 2 , da 3 , da 4 . After seeing the transactions T 1 and T 2 at the blockchain, he can verify the correctness of his spending data of T 1 and T 2 . Specifically, he verify whether the following equations are correct, i from 1 to 4.
e(g da i , g) = e(g s core,1 g s i,1 , g s core,2 g s i,2 ) If the above equation holds for each i from 1 to 4, then the patient considers that his spending data is correctly processed by the hospital. Otherwise, he will consider that the hospital is dishonest and send the evidences to the hospital's smart contract to get a certain number of reward. • Step 5: Query. When the insurance company wants to get a sum of spending records related to the initializetransaction T initialize , he may send a query-transaction T query containing ID T initialize to the blockchain network. The T query is described as follows: query Transaction Header

Payload ID
When the query-transaction is appended at the blockchain, it means that insurance company wants to know the sum of all spending records of the patient corresponding to ID T initialize until now.

Remark 2
After the T query is correctly responded by at least t servers, when the patient performs new payments with the hospital, the hospital should generates another new initialize-transaction, including a new verification key, for the patient.
• Step 6: Respond. After the T query has presented at blockchain. If a server wishes to respond the query, then he will generate a response according to the T query . After that, the server will secretly send his response to the insurance company via a respond-transaction T respond . If insurance company collets at least t responses correctly computed by corresponding servers, then insurance company can recover the correct sum of spending records related to the ID initialize . To introduce the process, without loss of generality, we assume that the t servers are Server 1 , Server 2 , · · · , Server t and they wish to respond the T query . According to T query , the servers can obtain s 1,1 , s 1,2 , s 2,1 , s 2,2 , s 3,1 , s 3,2 , s 4,1 , s 4,2 which are recorded in T 1 and T 2 . First, i from 1 to t, the Server i computes as follows: Then Server i encrypts Resp i into with insurance company's public key pk I . Then Server i computes a commitment of Resp i as follow: After that, Server i generates a respond-transaction T i respond , containing ID T initialize , CM Resp i and C Resp i . The T respond can be described as follow:

Transaction Header
Payload ID
• Step 8: Recover. Because the T 1 respond , T 2 respond , · · · , T t respond present at the blockchain, it means that the transactions pass all previous all verifications. Therefore, the insurance company just needs to perform the final verification that can by performed only by him. That is, i from 1 to t, the insurance company decrypts C Resp i and then obtain Resp i . If then insurance company accepts that the Resp i is correctly computed by Server i . Otherwise he rejects the response and can send his evidences ID T respond and Resp i to the Server i 's smart contract, and then insurance company can obtain a amount of reward. If all the t responses pass the verifications, then the insurance company uses lagrange interpolation to reconstruct a polynomial as follow: Finally, the insurance company calculatesF (0) that is the desired result.

Performance evaluation
In this section, we evaluate a performance of the MIStore system. The performance evaluation can be broken into three parts. The first part studies the processing time of cryptographic and mathematic computations in this system. The time of processing transactions is researched in the second part. The last part further demonstrates the processing time of blocks when different transactions are sent to the blockchain network. The section starts with the prototype system setting.

Prototype system setting
MIStore's efficiency mainly depends on the blockchain platform and performance of cryptographic schemes. For instance, in the paper, we use the Ethererum blockchain as the blockchain platform. Specifically, Ethereum's block can contains transactions of at most 62,360 bytes, its average block interval is about 15 s and its transaction's payload contains at most 1014-byte data, so the MIStore's efficiency is significantly limited by the Ethererum blockchain. Therefore, if we use some other more suitable blockchain, then we might get a better throughput. Besides, we use our BN-curve code to perform the pairing and point multiplication. Therefore, time cost of pairing and point multiplication may be longer than the previous optimal works. For instance, in Pinocchio [34], due to their excellent code, a pairing computation just takes 0.9 ms, while ours takes about 84.651 ms. Therefore, if we use their computer platform and code, maybe the performance of the prototype system could be improved. We implement a prototype system that is a (2,3)threshold MIStore protocol among three servers. Specifically, it contains a hospital, a patient, an insurance company and three servers. We use laptops and virtual machines to perform the prototype system. Our laptop's configuration is described as follows: the Intel i5-5300 CPU with 2.30GHz, 4GB memory, Windows 10 OS. In the local area network, we deploy a local blockchain via go-ethereum that is a Go implementation of the Ethereum protocol (https://github. com/ethereum/go-ethereum). In the blockchain network, we deploy four record-nodes (miners), and we use transaction simulator (https://github.com/ethereum/go-ethereum) to simulate the hospital, servers and insurance company to generate and send transactions. Moreover, we record MIStore system's data in the transaction's payload. In the Ethereum blockchain, a transaction's payload can record data of at most 1014 bytes.
Additionally, Ethererum has a embedded signature scheme that is the ECDSA with the secp256k1 elliptic curve [26]. For convenience, we use the scheme to sign messages. Besides, to encrypt key data recorded in the payloads of initialize-transaction and respond-transaction, we use the encryption scheme ECIES with the elliptic curve secp256k1 to encrypt the key data via receiver's public key. It results in that each encrypted message has a length of 96 bytes. Moreover, the encrypted data can be decrypted only by the corresponding receivers since only he has the corresponding private key.
Furthermore, for committing data and verifying committed data, we utilize 256-bit Barreto-Naehrig curve (BNcurve) [25] to commit the data via the base point multiplication. For instance, let G be the base point of the BN-curve. Then, the secret s can be committed by sG. Therefore, a commitment has a length of 64 bytes since any point of the BN-curve has two coordinates and each of the coordinates is of 32 bytes. Moreover, we use the bilinear map e (pairing computation) constructed by the BN-curve to verify the correctness of the commitments. Specifically, e(g a , g b ) = e(g ab , g). For instance, if we want to verify ab = c and we do not want to reveal a, b and c, then we may use the following equation to verify ab = c. e(g a , g b ) = e(g c , g).

Processing time of cryptographic schemes
Generally, the time cost of performing cryptographic schemes will have a certain degree of influence on the time of processing transactions, and then it may influence the efficiency of the system. Therefore, in the sub-section, we discuss the processing time cost of cryptographic and mathematic components.
For each of encryption, decryption, point multiplication, point addition, signing, verifying signatures, pairing, field addition and field multiplication, we perform 1000 experiments to obtain their average time cost. Their average time cost is shown in Table 4.

Generating transactions
In MIStore system, different transactions may have different payloads. For instance, an initialize-transaction includes a verification key, 9 commitments, 3 servers' IDs and 9 encrypted messages, while a respond-transaction only contains a initialize-transaction's ID, an encrypted response and a commitment about the response. Moreover, the sizes of payloads of initialize-transaction, query-transaction and respond-transaction are fixed, while the size of payload of record-transaction is variable. Therefore, different transactions may have different generation time. In the sub-section, we study generation time of transactions in the implementation. We discuss the initialize-transaction at first. In our prototype system, according to "Construction of MIStore", a T initialize 's payload includes a verification key, three servers' IDs, 9 encrypted messages and 9 commitments. Moreover, according to "Prototype system setting", the data recorded in the T initialize 's payload is of 1504 bytes. However, the payload of a transaction, in the Ethererum blockchain, can include at most 1014 bytes. In other words, one transaction cannot contain 1504 bytes. Therefore, in the prototype system, we divide the T initialize into T 1 initialize , T 2 initialize and T 3 initialize in order to record all its data. Specifically, the both transactions can be described as follows: Indeed, record-transactions may have payloads with variable sizes. Moreover, a basic message recorded in a record-transaction's payload is a array of {ID initialize , ID invoice , s k,1 , s k,2 } which is of 128 bytes. Due to that the a payload can include at most 1014 bytes, a recordtransaction's payload can contain at most 7 × 128 = 896 bytes. For convenience, in the prototype system, we only generate record-transactions with the largest payload. Specifically, we only generate two kinds of recordtransactions which are described as follows: A query-transaction, whose payload just includes a initialize-transaction's ID, can be shown as follows: query Transaction Header

Payload ID
A respond-transaction's payload contains the corresponding initialize-transaction's ID, an encrypted response and a commitment of the response. Specifically, Server i 's respond-transaction can be described as follow:

Transaction Header
Payload ID

Resp Resp
In the prototype system, sizes of transactions' payloads are shown in Table 5. For each of T 1 initialize , T 2 initialize , T 3 initialize , T record , T query and T respond , we generate 1000 transactions in order to obtain their average generating time cost. Then their average time cost are shown in Table 6.

Verifying transactions
In the system, before a transaction is appended at the blockchain, most record-nodes must verify the transaction. Specifically, record-nodes verify all publicly verifiable data of the transaction. Moreover, if a transaction has appeared at the blockchain, then it means that it has been accepted by most record-nodes. Therefore, the transaction's publicly verifiable data is credible. Consequently, others (e.g., hospital, patient, insurance company and servers ) do not have to verify the transaction's publicly verifiable data. In this way, it significantly reduces verifying computations of users. In the sub-section, we study transactions' verification time cost. All publicly verifiable data of transactions are summarized as follows: -All transactions' signatures are publicly verifiable data that can be verified by record-nodes. Therefore, if a transaction has appeared at the blockchain, then the transaction's signature is credible, and others need not to verify the signature. -Except signatures, the payloads of initialize-transaction and respond-transaction have public verifiable data that can be verified by record-nodes. Specifically, they are the initialize-transaction's verification key, commitments of core-shares and commitments of responses. Consequently, if an initialize-transaction (or a querytransaction) has appeared at the blockchain, then its publicly verifiable data is credible. Therefore, the transaction's receiver need not to verify the public verifiable data.
In this way, the transaction's receiver just needs to verify some key data that can be verified by only him. For each of T 1 initialize , T 2 initialize , T 3 initialize , T record , T query and T respond , we verify 1000 transactions, and then obtain their average verifying time cost. Then their average verifying time cost are shown in Table 6. Specifically, in Table 6, S is a signing computation, V denotes a signature verification, P M describes a point multiplication on the ECC, P A is a point addition on the ECC, Pairing means a pairing computation, E is a encryption, D denotes a decryption, F M describes a field multiplication and FA is a field addition. For instance, "2PM+3PA+1V+6Pairing" denotes that the corresponding computations contain 2 point multiplications, 3 point additions, 1 signature verification and 6 pairing computations.
It must be pointed that if the system does not use blockchain to record transactions and does not use recordnodes to help users to verify publicly verifiable data, then transaction receivers should perform more verifying computations than the blockchain-based system. Specifically, if that happens and we also use the above transactions and cryptographic schemes, then this will result in: -Because all transactions are stored by some centralized nodes, so storages might be modified or deleted by the centralized nodes. -All related users must independently verify all public verifiable data including the verification key and commitments. -Servers and insurance company might be heavier than the blockchain-based system. Therefore, some computations and operations cannot be processed efficiently, even cannot be performed.
For instance, we assume that a non-blockchain-based MIStore (pure system) is performed. If an insurance company receives a respond-transaction, then it must verify all verifiable data, otherwise it will not trust the transaction. Specifically, he will costs about 528.297 ms to verify it. However, if the system is based on a blockchain network, that is the key point of the paper, then the insurance company just needs to cost 33.936 ms to verify some key  Comparisons between the pure system and the blockchainbased system are shown in Table 7. According to the Table 7, if the system is not based on the blockchain, then the insurance company and servers all need a certain amount of verifying computations. However, if the system is based on the blockchain, then most computations can be done by record-nodes, then the insurance company and servers just need to perform very few verifying computations.

Blockchain performance evaluation
We run our MIStore on the Ethereum blockchain. After generating a certain number of blocks, the block interval tends to be stable. That is, generating 1000 blocks takes about 4.3 h. In other words, generating a block takes about 15.2 s on average. Furthermore, in the Ethereum blockchain, a block can record transactions of at most 62,360 bytes, a transaction with an empty payload is of 308 bytes and a transaction's payload can record data of at most 1014 bytes. Therefore, a transaction's size should be from 308 bytes to 308 + 1014 = 1322 bytes. According to Table 5 and above contents, in our implementation, any transaction's size can be calculated. Transactions' sizes are shown in Table 8. A block can record transactions of at most 62360 bytes. Therefore, if a block only record identical transactions, then the number of recorded transactions has a limit.  In our experiments, because different transactions have different significance, so the more significant transaction should be processed earlier. In the Ethererum blockchain, record-nodes (miners) earlier process a transaction with more transaction fee. Therefore, we set different transactions with different transaction fees. When transactions are pending in a record-node's transaction pool, transactions with more fees will be recorded earlier. In the MIStore system, the initialize-transaction is the base of later transactions. Therefore, it should has the first priority. For quickly responding insurance company's query, we set that querytransaction has the second priority and respond-transaction has the third priority. Finally, record-transaction has the lowest priority. In this way, the system's responding rate will be obviously increased. In our experiments, their transaction fees are shown in Table 9.
In our experiments, after an initialize-transaction has appeared at the blockchain, the hospital continually send record-transactions to the blockchain network. The recordtransactions are same as mentioned at "Construction of MIStore". The data of record-transactions' payloads is called as "spending-data". Every block can contain at most 51 record-transactions with the most arrays of spending data. Then, a block can store spending-data of at most 45696 bytes. Because the blockchain generates a block per about 15 s on average, so the system can record spending-data of at most 3046.4 bytes per second on average. At some later time, the insurance company sends a query-transaction to the blockchain network. Consequently, in the next block, the insurance company can get 3 response-transactions. The respond-transactions are recorded by record-nodes earlier than record-transactions since it has larger transaction fee. Finally, the insurance company can recover his desired data. The whole process only takes about 24 s. MIStore's efficiency mainly depends on the blockchain platform. For instance, in the paper, we use the Ethererum blockchain as the platform. Specifically, Ethereum's block can contains transactions of at most 62,360 bytes, its average block interval is about 15 s and its transaction's payload contains at most 1014-byte data, so the MIStore's efficiency is significantly limited by the blockchain platform. Therefore, if we use some other more suitable blockchain platform, then it might get a better throughput.

Conclusion
In this paper, we propose a blockchain-based threshold medical insurance storage system, called MIStore. Because of combining with blockchain, the system obtains some special advantages, e.g., decentralization, tamper-resistance and record-nodes help users to verify publicly verifiable data. Firstly, the blockchain's property of tamper-resistance gives users high-credibility. Moreover, due to the decentralization, users can communicate with each other without the third-parties. Secondly, the system supports the property of threshold. That is, patient's data is confidentially controlled by servers specified by the hospital, and the stored data is always confidential for the servers as long as a certain number of the servers are honest. Furthermore, according to the insurance company's query, the specified servers can perform homomorphic computations on the data and then get responses. If the insurance company can collect a threshold number of correct responses, then he can recover the correct patient's spending data. Thirdly, all important data is verifiable. In particular, most of data is publicly verifiable. Therefore, record-nodes of blockchain can help users to perform the public verifications. Consequently, this significantly reduces users computations. Finally, a performance evaluation about the system is given.
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http:// creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
Appendix: (t, n)-threshold verifiable homomorphic confidential storage scheme (t, n)-threshold verifiable homomorphic confidential storage scheme (TVHCSS) contains three parties (a distributor, n servers and a querier). Specifically, in TVHCSS, the distributor's messages are protected and controlled by the n servers, and in each server's hands, messages are ciphertext. When a querier sends a query to the n servers, if at least t servers return correct answers to the querier, then the querier can obtain what he wants. While if less than t servers return answers to the querier, then the querier cannot obtain anything.

A.1 Construction of TVHCSS
Symbols, used in the scheme, are summarized at Table 10.
g is a generator of a cyclic group G.
e is a bilinear map, e: G × G → G. For instance, e(g a , g b ) = e(g, g) ab . -D is the distributor's ID.
-Q describes the querier's ID.
-{pk i , sk i } denotes the i-th server's key pair, for i from 1 to n. -{pk Q , sk Q } is Q's key pair. The i-th plaintext message protected by n servers The i-th server's answer-share -d 1 , d 2 , · · · , d m describe the plaintext messages that will be protected by n servers in ciphertext. -Sahre asr i is the i-the server's answer.
The TVHCSS can be described as follows: • Initialize. Let F p be a finite field with character p. D randomly samples a polynomial F (x) of degree t − 1 over F p as the following polynomial.
After that, D randomly samples l(x) of degree t − 1 from F p [x] as follow: l(x) = c t−1 x t−1 + c t−2 x t−2 + · · · + c 1 x. Let D samples a generator g that can generate a cyclic group G. Then D publishes a verification key V K as follow: V K = {g, g a t−1 , · · · , g a 1 , g s core , g b 2t−2 , g b 2t−3 , · · · , g b 1 , g c t−1 , g c t−2 , · · · , g c 1 } • Verify committed polynomials. Anyone can verify whether polynomials f (x), h(x), l(x), committed in verification key, are well-formed and sound. Specifically, he can do as follows: -Randomly sample t different numbers x 0 , x 1 , · · · , x t−1 ∈ F p . -j from 0 to t − 1, compute g f j = (g a t−1 ) x t−1 j (g a t−2 ) x t−2 j · · · (g a 1 ) x j = g a t−1 x t−1 +···+b 1 x j g l j = (g c t−1 ) x t−1 j (g c t−2 ) x t−2 j · · · (g c 1 ) x j = g c t−1 x t−1 j +c t−2 x t−2 j +···+c 1 x j -If e(g f j , g f j ) = e(g h j g l j , g), for all j from 0 to t − 1, then the verifier accepts that the polynomials, committed by verification key, are well-formed and sound. Otherwise, he rejects and return to step Inilialize. D encrypts {F i , h i } with Sr i 's public key as C i = Enc pk i (CF i , Ch i ). D sends C i to Sr i , respectively. For C i , only Sr i can decrypt it since only S i has the corresponding secret key. After obtaining F i and h i , Sr i can verify the soundness of {F i , h i } with verification key {g, g a t−1 , · · · , g a 1 , g s core , g b 2t−2 , g b 2t−3 , · · · , g b 1 , g c t−1 , g c t−2 , · · · , g c 1 }.
Specifically, he computes F * i = (g a t−1 ) Sr t−1 i · · · (g a 1 ) Sr i (g s core ) If F * i = g F i and h * i = g h i , then Sr i accepts F i and h i , otherwise he rejects.
• Publish. D computes s i = d i − s core for 1 ≤ i ≤ m. Then D publishes s 1 , s 2 , · · · , s m that can be seen by anyone including the servers. However, only the servers can use s 1 , s 2 , · · · , s m to generate answer shares that can be used by the querier to recover the corresponding needed result. • Query. The Querier Q sends servers a query that he wants to know a data that can be described as the following equation: where 1 ≤ i 1 , i 2 , · · · , i k 1 +k 2 ≤ m. • Answer. If the i-th server Sr i wishes to answer Q, then he will generate a Share i by calculating with s 1 , s 2 , · · · , s m , F i and h i as follows: Share i = (F i + s i 1 )(F i + s i 2 ) + · · · + (F i + s i k 1 −1 )(F i + s i k 1 ) + (F i + s i k 1 +1 ) + · · · + (F i + s i k 1 +k 2 ) − k 2 h i After that, Sr i encrypts Share i as C share i = Enc pk Q (Share i ) with Q's public key. Then, Sr i sends C share i to Q. • Recover. If Q collects at least t correct and different shares, he can recover the data as described in Eq. 2. Without loss of generality, we assume the t shares come from Sr 1 , Sr 2 , · · · , Sr t . First, Q should verify the validations of Share 1 , Share 2 and Share t . Specifically, i from 1 to t, Q computes g F i = (g a t−1 ) Sr t−1 i · · · (g a 1 ) Sr i (g a 0 ) = g a t−1 Sr t−1 i +···+a 1 Sr i +score After that, with s i 1 , s i 2 , · · · , s i m and bilinear map e, Q further computes E 1 i = e(g F i g s i 1 , g F i g s i 2 )e(g F i g s i 3 , g F i g s i 4 ) · · · e(g F i g s i k 1 −1 , g F i g s i k 1 ) then Q considers that Share i is correctly computed by Sr i . If all Share 1 , Share 2 and Share t are correctly computed by senders, then Q can recover the data with Share 1 , Share 2 and Share t . Specifically, Q can reconstruct a polynomial of degree t − 1 by Lagrange interpolating as follow: Share i t j =1,j =i Sr j − x Sr j − Sr i Finally, F (0) equals to data.