# A Generalized Blockchain-Based Government Data Sharing Protocol

Authors: Zilin Liu; Anjia Yang; Huang Zeng; Changkun Jiang; Li Ma
Journal: Security and Communication Networks
 (2023)

---

## Abstract

In order to catch the express train of the digital age and seize the opportunities brought by the development of blockchain technology, many government departments have begun to build blockchain-based data sharing protocols. Most existing data sharing protocols are built on different blockchains with different specific features. The interaction between them is not trivial, leading to the phenomenon of “data islands.” Therefore, we consider building a data sharing protocol compatible with various blockchains. In this work, we propose a generalized blockchain-based data sharing protocol, which takes fairness, privacy, auditability, and generality into account simultaneously. With adaptor signature and zero-knowledge techniques, the proposed protocol ensures a secure and fair data sharing process and is compatible with various blockchains since it only requires the underlying blockchain to perform signature verification. Finally, we implement our construction on an Ethereum test network and conduct a series of experiments. The results demonstrate the practicality of our construction while remaining good functionalities.


---

## Body

## 1. Introduction

With the advent of digital age, the level of digital development has become one of the important indicators to measure the degree of modernization and comprehensive strength of a country. Under this trend, the construction of digital government is constantly advancing, and government data are also accumulating. In order to improve the efficiency of government departments and deepen the cooperation between departments, these data need to be shared and exchanged between government departments [1, 2]. However, due to the management and division of labor of government departments for a long time, the data of different government departments are often controlled by themselves. These data are widely stored in different units, departments, and network environments. It is difficult for them to be shared between departments, resulting in the phenomenon of “data islands.”At the same time, with properties of decentralization, traceability, and immutability, blockchain technology has been widely explored to promote data trust, sharing, co-governance, and co-maintenance [3–12]. With the help of blockchain technology, the trusted third party in the data sharing protocol is replaced by a public ledger maintained by all users. Any data sharing behavior between users will be recorded in this ledger to facilitate subsequent auditing and tracking.However, most existing blockchain-based data sharing protocols require the underlying blockchains to provide some specific functionality. In particular, some data sharing protocols (e.g., [13, 14]) are built on blockchains, which support hash time-lock contract (HTLC). Some protocols (e.g., [15, 16]) are built relying on unspent transaction output (UTXO) structure-based blockchains. Some protocols (e.g., [4, 11, 17, 18]) are constructed on blockchains which provide smart contract functionality. Some protocols (e.g., [19–21]) are built based on the Internet of things application-based (IOTA-based) blockchain. Some protocols (e.g., [22–24]) are constructed relying on the permissioned blockchain. It is difficult for data to be shared between different blockchains with different features. In order to step over this barrier, Jiang et al. [25] proposed a new blockchain named PolyChain, which provides high modularity, flexibility, scalability, reliability, and security. Then, they create a data sharing protocol based on PolyChain. Nevertheless, their protocol requires a major update to the existing blockchain architecture, which is to migrate the protocol from the original underlying blockchain to PolyChain.With the above consideration, we are motivated to consider whether we can construct a data sharing protocol assuming only the bare minimal ability of the underlying blockchain to verify a signature. It would be compatible with a wide variety of blockchains and does not require updates to the existing underlying architecture of blockchain-based data sharing protocols. In this work, we propose a positive answer to the above consideration. We introduce a new data sharing protocol, which takes fairness, privacy protection, auditability, and generality into account simultaneously. The contributions of our work can be summarized as follows:(i)
We devise a data sharing protocol that is compatible with various existing blockchains. The generalized data sharing protocol is constructed relying on the adaptor signature. It provides fairness, privacy protection, auditability, and generality at the same time. In this protocol, the on-chain operation is only to verify a signature, which is compatible with various non-/Turing-complete blockchains. Furthermore, existing data sharing protocols can be easily converted to generalized protocols with only a software update.(ii)
We implement our construction on an Ethereum test network [26]. We perform a series of experiments to show the effectiveness and efficiency of our construction. The results show that they require at most 35 milliseconds to be computed and a communication overhead of less than 300 bytes in the worst case. Therefore, our construction can be regarded as a promising tool to realize a practical data sharing protocol.The remainder of the paper is organized as follows. We introduce the related work in Section2 and present preliminaries in Section 3. Then we will discuss our system model, threat model and design goal in Section 4. Next, we illustrate our construction in Section 5 and analyze the security of our construction in Section 6. We conduct a series of experiments in Section 7. Finally, we conclude our work in Section 8.


## 2. Related Work

Most existing blockchain-based data sharing protocols constructed rely on some specific functionality of the underlying blockchain. Some data sharing protocols work with blockchains which support hash time-lock contract (HTLC). Mohanty et al. [13] propose SIoVChain, a time-lock contract-based privacy preserving data sharing scheme with incentives for social Internet of vehicles. Zhang et al. [14] develop a homomorphic hashing-based transaction segmentation scheme and propose an efficient IoT data sharing approach relying on it. Some protocols rely on unspent transaction output (UTXO) structure-based blockchains. Wang et al. [15] construct a novel lightweight authentication and a UTXO-based blockchain data trading system to facilitate online data trading. Noh et al. [16] built a blockchain-based user-centric records management system, which is convenient for sharing of medical records among institutions. Some protocols require the underlying blockchain to support smart contracts. Jaiman and Urovi [4] present a blockchain-based data sharing consent model which helps individuals exercise access control over health data. Shrestha et al. [27] introduce a traceable and incentive customer data sharing platform, which allow users sharing their data with business enterprises. Xu et al. [17] propose a blockchain-based secure data sharing platform with fine-grained access control. Naz et al. [11] construct a secure data sharing platform with the help of blockchain technology and an interplanetary file system. Hoang et al. [18] propose a privacy preserving blockchain-based data sharing platform that protects user anonymity and data confidentiality. Singh et al. [28] design a secure cross-domain blockchain-based data sharing protocol for IoT industrial. Theodouli et al. [29] devise a blockchain-based system to facilitate healthcare data sharing. Some protocols are based on the Internet of things application-based (IOTA-based) blockchain. Hassija et al. [19] introduce a blockchain-based framework for lightweight data sharing and energy trading. Gangwani et al. [20] facilitate data sharing among Internet of things devices with the help of IOTA-based blockchain. Abdullah et al. [21] emphasize secure sharing of health data in the digital healthcare system by exploring the potential of a IOTA Tangle [30]. Some protocols are based on the permissioned blockchain. Xia et al. [23] construct a blockchain-based data sharing for electronic medical records by utilizing the permissioned blockchain technology. Wang et al. [22] propose a medical data sharing platform based on permissioned blockchains. Xiao et al. [24] introduce a cross-organizational medical data sharing framework with the help of a permissioned blockchain.Among them, to construct a general data sharing protocol, Jiang et al. [25] propose a new blockchain named PolyChain, which provides high modularity, flexibility, scalability, reliability, and security. Then they construct a data sharing platform based on PolyChain. However, this scheme focuses on constructing a new blockchain and designing a data sharing platform based on it but does not consider devising a data sharing platform, which is compatible for existing blockchains. Such a solution requires developers to make changes to the underlying blockchain architecture of the existing data sharing platforms, which is complicated and cumbersome to operate.


## 3. Preliminaries

In this section, we will cover some notations and preliminaries instructions that will be used when constructing our protocol.


### 3.1. Notations

The security parameter is denoted by1λ for λ∈N. The notation x⟵$S is used to represent that an element x is uniformly sampled from a set X. We denote by y⟵Fx the output of the probabilistic polynomial time (PPT) algorithm F on input x. If the algorithm F is a deterministic polynomial time (DPT) algorithm, the notation is y≔Fx.


### 3.2. Noninteractive Zero-Knowledge

An NP relation is denoted byR and a set of positive instances with related to the relation R is denoted by L (i.e, L=x∃ws.t.Rx,w=1). If R is poly-time decidable and for any PPT adversaries A, the probability of A producing a witness w that satisfies Rx,w=1 is bounded by a negligible function; we name R as a hard relation. A noninteractive zero-knowledge proof scheme NIZK includes two algorithms. PNIZK is the prover algorithm where π⟵PNIZKx,w and VNIZK is the verifier algorithm where 0,1:=VNIZKx,π. We refer readers to [31] for further details.


### 3.3. Adaptor Signature

An adaptor signature is defined relying on a digital signatureΣDS and a hard relation R which includes four algorithms ΣAS=PreSig,PreVf,Adapt,Ext. We can presign some information over a hard relation with σ^⟵PreSigsk,m,Y. The validation of the pre-signature can be verified using PreVfm,Y,σ^. Besides, the pre-signature can be converted to a valid signature with the corresponding witness with σ:=Adaptσ^,y. With the pre-signature/signature pair σ^,σ, we can extract the witness y using y≔Extσ,σ^,Y. A secure adaptor signature provides three properties: pre-signature correctness, pre-signature adaptability, and witness extractability. For more details, we refer readers to [32].


### 3.4. Blockchains

As in [33–35], we model an ideal ledger (blockchain) functionality B as a trusted append-only bulletin board. The ideal functionality FB maintains the list of all transactions of each user and updates when a new transaction is performed. It provides these properties: (a) complete decentralization, namely, the public ledger is maintained decentralized; (b) correctness and traceability, which means that each node is able to trace and verify the correctness of the data; (c) immutability implies that the on-chain transactions are tamper-resistant; and (d) cryptography, namely, the security of the blockchain is guaranteed by the underlying cryptography techniques.


## 3.1. Notations

The security parameter is denoted by1λ for λ∈N. The notation x⟵$S is used to represent that an element x is uniformly sampled from a set X. We denote by y⟵Fx the output of the probabilistic polynomial time (PPT) algorithm F on input x. If the algorithm F is a deterministic polynomial time (DPT) algorithm, the notation is y≔Fx.


## 3.2. Noninteractive Zero-Knowledge

An NP relation is denoted byR and a set of positive instances with related to the relation R is denoted by L (i.e, L=x∃ws.t.Rx,w=1). If R is poly-time decidable and for any PPT adversaries A, the probability of A producing a witness w that satisfies Rx,w=1 is bounded by a negligible function; we name R as a hard relation. A noninteractive zero-knowledge proof scheme NIZK includes two algorithms. PNIZK is the prover algorithm where π⟵PNIZKx,w and VNIZK is the verifier algorithm where 0,1:=VNIZKx,π. We refer readers to [31] for further details.


## 3.3. Adaptor Signature

An adaptor signature is defined relying on a digital signatureΣDS and a hard relation R which includes four algorithms ΣAS=PreSig,PreVf,Adapt,Ext. We can presign some information over a hard relation with σ^⟵PreSigsk,m,Y. The validation of the pre-signature can be verified using PreVfm,Y,σ^. Besides, the pre-signature can be converted to a valid signature with the corresponding witness with σ:=Adaptσ^,y. With the pre-signature/signature pair σ^,σ, we can extract the witness y using y≔Extσ,σ^,Y. A secure adaptor signature provides three properties: pre-signature correctness, pre-signature adaptability, and witness extractability. For more details, we refer readers to [32].


## 3.4. Blockchains

As in [33–35], we model an ideal ledger (blockchain) functionality B as a trusted append-only bulletin board. The ideal functionality FB maintains the list of all transactions of each user and updates when a new transaction is performed. It provides these properties: (a) complete decentralization, namely, the public ledger is maintained decentralized; (b) correctness and traceability, which means that each node is able to trace and verify the correctness of the data; (c) immutability implies that the on-chain transactions are tamper-resistant; and (d) cryptography, namely, the security of the blockchain is guaranteed by the underlying cryptography techniques.


## 4. System Model, Threat Model, and Design Goal

In this section, we will introduce the system model, the threat model, and design goals of our construction.


### 4.1. System Model

As shown in Figure1, there are three roles in our system: the sender, the receiver, and the blockchain.Figure 1
The system model.


#### 4.1.1. Sender

The sender is the person who wishes to transfer his data access right to someone else. He wants to transfer his data access key to the receiver in a secure way and can record the process on the blockchain.


#### 4.1.2. Receiver

The receiver is the person who aims to receive the data access right.


#### 4.1.3. Blockchain

The blockchain acts as an important part in our construction. It is responsible for accepting the transaction submitted by the sender and verifying the signature of the transaction.In our system model, assume that the sender wants to grant her data access key to the receiver. She first generates a transaction, presigns it, and sends it to the receiver. The pre-signature attached to the transaction is similar to a lock. If the sender decides to grant her key, she will sign the transaction and upload it on the blockchain. Once the receiver observes that the transaction has been uploaded on chain, he can combine the previously obtained transaction with the on-chain transaction to extract the secret key and gain the access to the data.


### 4.2. Threat Model

We define the following security assumptions to describe the attacks our construction will be exposed.(i)
No party is trustworthy(ii)
All parties are rational and greedy, they will choose actions that are in their interests at all costs(iii)
The underlying blockchain is secure and cannot be controlled by any malicious partiesBesides, we also present some types of threats that our construction will face.


#### 4.2.1. Breaking Data Confidentiality

Malicious parties who do not participate in the transaction can attempt to obtain the data access right by analyzing the transactions on the blockchain.


#### 4.2.2. Breaking Fairness

A malicious sender can attempt to generate an invalid presignature over their transaction, so as to avoid the receiver obtaining the data access key in the subsequent operation.


### 4.3. Design Goal

Relying on the aforementioned system model and threat model, we define our design goals as follows:(i)
Fairness: neither party to the transaction can disrupt the execution of the construction and damage the fairness of the other party(ii)
Malicious behaviour resistance: our construction has the ability to resist the aforementioned threats


## 4.1. System Model

As shown in Figure1, there are three roles in our system: the sender, the receiver, and the blockchain.Figure 1
The system model.


### 4.1.1. Sender

The sender is the person who wishes to transfer his data access right to someone else. He wants to transfer his data access key to the receiver in a secure way and can record the process on the blockchain.


### 4.1.2. Receiver

The receiver is the person who aims to receive the data access right.


### 4.1.3. Blockchain

The blockchain acts as an important part in our construction. It is responsible for accepting the transaction submitted by the sender and verifying the signature of the transaction.In our system model, assume that the sender wants to grant her data access key to the receiver. She first generates a transaction, presigns it, and sends it to the receiver. The pre-signature attached to the transaction is similar to a lock. If the sender decides to grant her key, she will sign the transaction and upload it on the blockchain. Once the receiver observes that the transaction has been uploaded on chain, he can combine the previously obtained transaction with the on-chain transaction to extract the secret key and gain the access to the data.


## 4.1.1. Sender

The sender is the person who wishes to transfer his data access right to someone else. He wants to transfer his data access key to the receiver in a secure way and can record the process on the blockchain.


## 4.1.2. Receiver

The receiver is the person who aims to receive the data access right.


## 4.1.3. Blockchain

The blockchain acts as an important part in our construction. It is responsible for accepting the transaction submitted by the sender and verifying the signature of the transaction.In our system model, assume that the sender wants to grant her data access key to the receiver. She first generates a transaction, presigns it, and sends it to the receiver. The pre-signature attached to the transaction is similar to a lock. If the sender decides to grant her key, she will sign the transaction and upload it on the blockchain. Once the receiver observes that the transaction has been uploaded on chain, he can combine the previously obtained transaction with the on-chain transaction to extract the secret key and gain the access to the data.


## 4.2. Threat Model

We define the following security assumptions to describe the attacks our construction will be exposed.(i)
No party is trustworthy(ii)
All parties are rational and greedy, they will choose actions that are in their interests at all costs(iii)
The underlying blockchain is secure and cannot be controlled by any malicious partiesBesides, we also present some types of threats that our construction will face.


### 4.2.1. Breaking Data Confidentiality

Malicious parties who do not participate in the transaction can attempt to obtain the data access right by analyzing the transactions on the blockchain.


### 4.2.2. Breaking Fairness

A malicious sender can attempt to generate an invalid presignature over their transaction, so as to avoid the receiver obtaining the data access key in the subsequent operation.


## 4.2.1. Breaking Data Confidentiality

Malicious parties who do not participate in the transaction can attempt to obtain the data access right by analyzing the transactions on the blockchain.


## 4.2.2. Breaking Fairness

A malicious sender can attempt to generate an invalid presignature over their transaction, so as to avoid the receiver obtaining the data access key in the subsequent operation.


## 4.3. Design Goal

Relying on the aforementioned system model and threat model, we define our design goals as follows:(i)
Fairness: neither party to the transaction can disrupt the execution of the construction and damage the fairness of the other party(ii)
Malicious behaviour resistance: our construction has the ability to resist the aforementioned threats


## 5. Our Construction

In this section, we first discuss the design challenges we need to overcome when devising our construction, then we will illustrate the proposed construction in detail. Finally, we will present a concrete instance to show how to instantiate it.


### 5.1. Design Challenges

It is not trivial to put forward a generalized and secure data sharing protocol. Many challenges arise when we are trying to construct such a data sharing protocol.(i)
Generality: With the development of the blockchain technology, many government departments have begun to build blockchain-based applications. In order to facilitate the data sharing between different blockchain-based applications, we are demanded to devise a generalized data sharing protocol. In this work, we utilize the adaptor signature to achieve this property. With this tool, our data sharing protocol only requires the underlying blockchains to provide signature verification and can be applied to various blockchains.(ii)
Auditability: The transfer of the data access rights between different government departments needs to be recorded in a log to facilitate subsequent audits. In this work, we leverage the blockchain technology to record it. The immutability feature of the blockchain technology can help us achieve security monitoring of data access rights and tracking of the transfer process.(iii)
Privacy: Privacy protection [36, 37] is also taken into account when transferring data access rights between different government departments. They do not want others to extract data access keys by analyzing transactions on the blockchain. In this work, our construction only requires signature verification on the blockchain, and no additional operations are required. Therefore, the malicious party cannot obtain more information than the transaction signature, which prevents him from further analysis of the transactions and protects the users’ privacy.


### 5.2. The Generic Construction

Our generic data sharing protocol is denoted byΠ. It can be achieved by leveraging an adaptor signature ΣAS=PreSig,PreVf,Adapt,Ext relying on a digital signature ΣDS=Gen,Sign,Vrfy which is used by the underlying blockchain and a hard relation R. The operations of our protocol can be divided into two aspects: off-chain operations and on-chain operations. The concrete details are depicted in Figure 2. We will discuss each aspect separately at a high level in the following:Figure 2
Algorithms and protocols for the generic construction.


#### 5.2.1. Off-Chain Operations

Assume that government departments want to work together, department employees need to share some data during this period. These data were stored in various departments and can be accessed by those with certain permissions. In order to ensure the security of the data sharing process, the sender of the data hopes that no third party other than the receiver of the data can spy on the data access key through their operations. The sender and the receiver are denoted byU0 and U1, respectively. The sender firstly generates a public/private key pair pk,sk and sets it as a public parameter/trapdoor pair pp,td. This pair is used to blind the information to be transmitted next, preventing others from analyzing the transmitted information to obtain some secrets (e.g., data access keys). Then, U0 generates a puzzle P over the data access key k with the public parameter pp. The corresponding zero-knowledge proof over the puzzle P is attached to prove that the puzzle is solvable. At this moment, he generates a transaction tx which is used to pass the data access key to the receiver and presigns this transaction. Note that the pre-signature σ^ is bound with a puzzle P, which means that the pre-signature can only be turned into a valid signature if the solution of the puzzle P is known. After receiving such a tuple from the sender, the receiver will verify the validation of the proof π and the pre-signature σ^ to ensure that the data access key can be obtained after a validly signed transaction is uploaded on the blockchain.


#### 5.2.2. On-Chain Operations

If the sender decides to grant the data access key to the receiver, he will sign the transactiontx and upload it on the blockchain B with the corresponding valid signature. If the receiver notices that the transaction tx has been uploaded on the blockchain B, he can extract the key k from the pre-signature/signature pair σ^,σ. Therefore, the receiver gains the data access and is able to read the data. The sender and the receiver successfully achieved data sharing between them.


### 5.3. Schnorr-Based Instance

In the following, we introduce a concrete instanceΠSch to show how to instantiate our protocol. The instance is based on a Schnorr-based adaptor signature and includes two aspects: the off-chain operations and the on-chain operations. The details are shown in Figure 3.Figure 3
The Schnorr-based construction.


#### 5.3.1. Off-Chain Operations

We consider a scenario that the senderU0 and the receiver U1 work in different government departments, and the two government departments need to work together, so U0 and U1 want to share data between them. Besides, U0 hopes to transfer a data access key k to U1 without leaking information to the third party. In order to achieve this goal, they first mutually agree on a transaction and a corresponding pre-signature, which is used to secretly transmit the key in the latter. Note, that in this concrete construction, G is an elliptic curve group of prime order q with a generator g. The commitment scheme and the non-interactive zero-knowledge scheme are denoted by com and NIZK, respectively. In the beginning, U0 and U1 are required to generate a shared Schnorr public key pk01Σ. The shared key generation can be achieved by using [34]. Then, U0 generates a puzzle P over the access key k and calculates the corresponding proof π. U1 will verify whether the puzzle P is solvable after the puzzle/proof pair P,π is sent by U0. After that, U0 and U1 jointly process a coin tossing protocol to agree on a randomness R=k+r1+r2. They exchange of gr1 and gr2 with each other to blind the puzzle P. The corresponding proof is attached during the coin tossing process. At this moment, U0 and U1 can mutually calculate an “almost” valid signature σ^:=e,s^ while the valid form is e,s^+k. The pre-signature σ^ is calculated over some messages (e.g., the transaction id) which are jointly agreed before. Notice that U1 is able to verify the validation of such a pre-signature σ^ during the former calculation. At this moment, they complete the off-chain operations together, and U1 is guaranteed to obtain the data access key k if U0 uploads the transaction attached with the valid signature on the blockchain in the latter.


#### 5.3.2. On-Chain Operations

If the sender decides to grant the data access keyk to the receiver, he will convert the “almost” valid signature to a valid signature. Please note that the valid form of the signature is σ:=e,s^+k. Then, U0 uploads the transaction on chain with the corresponding signature σ. After the transaction is recorded on the blockchain B, U1 can achieve the valid signature σ from the on-chain transaction. Therefore, he has the ability to combine the pre-signature σ^ with the valid signature σ to calculate the data access key k. At this moment, the receiver can read the corresponding data with the extracted key. The corresponding data are successfully shared between the sender and the receiver. It is worth mentioning that the process of transferring data access rights will also be recorded on the blockchain, which facilitates subsequent auditing.


## 5.1. Design Challenges

It is not trivial to put forward a generalized and secure data sharing protocol. Many challenges arise when we are trying to construct such a data sharing protocol.(i)
Generality: With the development of the blockchain technology, many government departments have begun to build blockchain-based applications. In order to facilitate the data sharing between different blockchain-based applications, we are demanded to devise a generalized data sharing protocol. In this work, we utilize the adaptor signature to achieve this property. With this tool, our data sharing protocol only requires the underlying blockchains to provide signature verification and can be applied to various blockchains.(ii)
Auditability: The transfer of the data access rights between different government departments needs to be recorded in a log to facilitate subsequent audits. In this work, we leverage the blockchain technology to record it. The immutability feature of the blockchain technology can help us achieve security monitoring of data access rights and tracking of the transfer process.(iii)
Privacy: Privacy protection [36, 37] is also taken into account when transferring data access rights between different government departments. They do not want others to extract data access keys by analyzing transactions on the blockchain. In this work, our construction only requires signature verification on the blockchain, and no additional operations are required. Therefore, the malicious party cannot obtain more information than the transaction signature, which prevents him from further analysis of the transactions and protects the users’ privacy.


## 5.2. The Generic Construction

Our generic data sharing protocol is denoted byΠ. It can be achieved by leveraging an adaptor signature ΣAS=PreSig,PreVf,Adapt,Ext relying on a digital signature ΣDS=Gen,Sign,Vrfy which is used by the underlying blockchain and a hard relation R. The operations of our protocol can be divided into two aspects: off-chain operations and on-chain operations. The concrete details are depicted in Figure 2. We will discuss each aspect separately at a high level in the following:Figure 2
Algorithms and protocols for the generic construction.


### 5.2.1. Off-Chain Operations

Assume that government departments want to work together, department employees need to share some data during this period. These data were stored in various departments and can be accessed by those with certain permissions. In order to ensure the security of the data sharing process, the sender of the data hopes that no third party other than the receiver of the data can spy on the data access key through their operations. The sender and the receiver are denoted byU0 and U1, respectively. The sender firstly generates a public/private key pair pk,sk and sets it as a public parameter/trapdoor pair pp,td. This pair is used to blind the information to be transmitted next, preventing others from analyzing the transmitted information to obtain some secrets (e.g., data access keys). Then, U0 generates a puzzle P over the data access key k with the public parameter pp. The corresponding zero-knowledge proof over the puzzle P is attached to prove that the puzzle is solvable. At this moment, he generates a transaction tx which is used to pass the data access key to the receiver and presigns this transaction. Note that the pre-signature σ^ is bound with a puzzle P, which means that the pre-signature can only be turned into a valid signature if the solution of the puzzle P is known. After receiving such a tuple from the sender, the receiver will verify the validation of the proof π and the pre-signature σ^ to ensure that the data access key can be obtained after a validly signed transaction is uploaded on the blockchain.


### 5.2.2. On-Chain Operations

If the sender decides to grant the data access key to the receiver, he will sign the transactiontx and upload it on the blockchain B with the corresponding valid signature. If the receiver notices that the transaction tx has been uploaded on the blockchain B, he can extract the key k from the pre-signature/signature pair σ^,σ. Therefore, the receiver gains the data access and is able to read the data. The sender and the receiver successfully achieved data sharing between them.


## 5.2.1. Off-Chain Operations

Assume that government departments want to work together, department employees need to share some data during this period. These data were stored in various departments and can be accessed by those with certain permissions. In order to ensure the security of the data sharing process, the sender of the data hopes that no third party other than the receiver of the data can spy on the data access key through their operations. The sender and the receiver are denoted byU0 and U1, respectively. The sender firstly generates a public/private key pair pk,sk and sets it as a public parameter/trapdoor pair pp,td. This pair is used to blind the information to be transmitted next, preventing others from analyzing the transmitted information to obtain some secrets (e.g., data access keys). Then, U0 generates a puzzle P over the data access key k with the public parameter pp. The corresponding zero-knowledge proof over the puzzle P is attached to prove that the puzzle is solvable. At this moment, he generates a transaction tx which is used to pass the data access key to the receiver and presigns this transaction. Note that the pre-signature σ^ is bound with a puzzle P, which means that the pre-signature can only be turned into a valid signature if the solution of the puzzle P is known. After receiving such a tuple from the sender, the receiver will verify the validation of the proof π and the pre-signature σ^ to ensure that the data access key can be obtained after a validly signed transaction is uploaded on the blockchain.


## 5.2.2. On-Chain Operations

If the sender decides to grant the data access key to the receiver, he will sign the transactiontx and upload it on the blockchain B with the corresponding valid signature. If the receiver notices that the transaction tx has been uploaded on the blockchain B, he can extract the key k from the pre-signature/signature pair σ^,σ. Therefore, the receiver gains the data access and is able to read the data. The sender and the receiver successfully achieved data sharing between them.


## 5.3. Schnorr-Based Instance

In the following, we introduce a concrete instanceΠSch to show how to instantiate our protocol. The instance is based on a Schnorr-based adaptor signature and includes two aspects: the off-chain operations and the on-chain operations. The details are shown in Figure 3.Figure 3
The Schnorr-based construction.


### 5.3.1. Off-Chain Operations

We consider a scenario that the senderU0 and the receiver U1 work in different government departments, and the two government departments need to work together, so U0 and U1 want to share data between them. Besides, U0 hopes to transfer a data access key k to U1 without leaking information to the third party. In order to achieve this goal, they first mutually agree on a transaction and a corresponding pre-signature, which is used to secretly transmit the key in the latter. Note, that in this concrete construction, G is an elliptic curve group of prime order q with a generator g. The commitment scheme and the non-interactive zero-knowledge scheme are denoted by com and NIZK, respectively. In the beginning, U0 and U1 are required to generate a shared Schnorr public key pk01Σ. The shared key generation can be achieved by using [34]. Then, U0 generates a puzzle P over the access key k and calculates the corresponding proof π. U1 will verify whether the puzzle P is solvable after the puzzle/proof pair P,π is sent by U0. After that, U0 and U1 jointly process a coin tossing protocol to agree on a randomness R=k+r1+r2. They exchange of gr1 and gr2 with each other to blind the puzzle P. The corresponding proof is attached during the coin tossing process. At this moment, U0 and U1 can mutually calculate an “almost” valid signature σ^:=e,s^ while the valid form is e,s^+k. The pre-signature σ^ is calculated over some messages (e.g., the transaction id) which are jointly agreed before. Notice that U1 is able to verify the validation of such a pre-signature σ^ during the former calculation. At this moment, they complete the off-chain operations together, and U1 is guaranteed to obtain the data access key k if U0 uploads the transaction attached with the valid signature on the blockchain in the latter.


### 5.3.2. On-Chain Operations

If the sender decides to grant the data access keyk to the receiver, he will convert the “almost” valid signature to a valid signature. Please note that the valid form of the signature is σ:=e,s^+k. Then, U0 uploads the transaction on chain with the corresponding signature σ. After the transaction is recorded on the blockchain B, U1 can achieve the valid signature σ from the on-chain transaction. Therefore, he has the ability to combine the pre-signature σ^ with the valid signature σ to calculate the data access key k. At this moment, the receiver can read the corresponding data with the extracted key. The corresponding data are successfully shared between the sender and the receiver. It is worth mentioning that the process of transferring data access rights will also be recorded on the blockchain, which facilitates subsequent auditing.


## 5.3.1. Off-Chain Operations

We consider a scenario that the senderU0 and the receiver U1 work in different government departments, and the two government departments need to work together, so U0 and U1 want to share data between them. Besides, U0 hopes to transfer a data access key k to U1 without leaking information to the third party. In order to achieve this goal, they first mutually agree on a transaction and a corresponding pre-signature, which is used to secretly transmit the key in the latter. Note, that in this concrete construction, G is an elliptic curve group of prime order q with a generator g. The commitment scheme and the non-interactive zero-knowledge scheme are denoted by com and NIZK, respectively. In the beginning, U0 and U1 are required to generate a shared Schnorr public key pk01Σ. The shared key generation can be achieved by using [34]. Then, U0 generates a puzzle P over the access key k and calculates the corresponding proof π. U1 will verify whether the puzzle P is solvable after the puzzle/proof pair P,π is sent by U0. After that, U0 and U1 jointly process a coin tossing protocol to agree on a randomness R=k+r1+r2. They exchange of gr1 and gr2 with each other to blind the puzzle P. The corresponding proof is attached during the coin tossing process. At this moment, U0 and U1 can mutually calculate an “almost” valid signature σ^:=e,s^ while the valid form is e,s^+k. The pre-signature σ^ is calculated over some messages (e.g., the transaction id) which are jointly agreed before. Notice that U1 is able to verify the validation of such a pre-signature σ^ during the former calculation. At this moment, they complete the off-chain operations together, and U1 is guaranteed to obtain the data access key k if U0 uploads the transaction attached with the valid signature on the blockchain in the latter.


## 5.3.2. On-Chain Operations

If the sender decides to grant the data access keyk to the receiver, he will convert the “almost” valid signature to a valid signature. Please note that the valid form of the signature is σ:=e,s^+k. Then, U0 uploads the transaction on chain with the corresponding signature σ. After the transaction is recorded on the blockchain B, U1 can achieve the valid signature σ from the on-chain transaction. Therefore, he has the ability to combine the pre-signature σ^ with the valid signature σ to calculate the data access key k. At this moment, the receiver can read the corresponding data with the extracted key. The corresponding data are successfully shared between the sender and the receiver. It is worth mentioning that the process of transferring data access rights will also be recorded on the blockchain, which facilitates subsequent auditing.


## 6. Security Analysis

We will discuss the security of the proposed construction in this section. The construction relying on adaptor signature and non-interactive zero-knowledge proof defeat against the threats is defined in Section4. The details will be introduced in the following.


### 6.1. Breaking Data Confidentiality

A malicious party may attempt to extract the data access key through observing the transaction on the blockchain. Through analyzing the transactions, he can obtain a valid signature. We denote such a signature asσ. If the malicious party wants to extract the corresponding data access key k of the signature σ, he needs to acquire the corresponding pre-signature σ^. However, the communication between the sender and the receiver in the off-chain operations takes place in a secure communication channel. Therefore, the malicious party cannot capture more information. The only way for him to obtain a pre-signature is to forge one. If he can extract the data access key from the signature and forge the pre-signature pair σ,σ^′, it means that σ^′ is a valid forgery. In other words, the malicious party has the ability to break the unforgeability feature of the adaptor signature. The probability of such an event occurring is bounded by a negligible function, so the threat does not occur.


### 6.2. Breaking Fairness

A malicious sender may attempt to send an invalid pre-signature to the receiver in the off-chain operations, so as to avoid the receiver from obtaining the data access key in the on-chain operations. This threat occurs in the following situation. The malicious sender uploads a transaction with a valid signatureσ′ on the blockchain, while the receiver cannot extract a valid witness from it. If this is the case, it means that we cannot extract a valid witness from the valid pre-signature and signature pair (σ^,σ′). That is to say, the malicious sender is able to against the witness extractability feature of the adaptor signature. The probability of such a situation occurring is bounded by a negligible function. Therefore, the threat cannot happen.


## 6.1. Breaking Data Confidentiality

A malicious party may attempt to extract the data access key through observing the transaction on the blockchain. Through analyzing the transactions, he can obtain a valid signature. We denote such a signature asσ. If the malicious party wants to extract the corresponding data access key k of the signature σ, he needs to acquire the corresponding pre-signature σ^. However, the communication between the sender and the receiver in the off-chain operations takes place in a secure communication channel. Therefore, the malicious party cannot capture more information. The only way for him to obtain a pre-signature is to forge one. If he can extract the data access key from the signature and forge the pre-signature pair σ,σ^′, it means that σ^′ is a valid forgery. In other words, the malicious party has the ability to break the unforgeability feature of the adaptor signature. The probability of such an event occurring is bounded by a negligible function, so the threat does not occur.


## 6.2. Breaking Fairness

A malicious sender may attempt to send an invalid pre-signature to the receiver in the off-chain operations, so as to avoid the receiver from obtaining the data access key in the on-chain operations. This threat occurs in the following situation. The malicious sender uploads a transaction with a valid signatureσ′ on the blockchain, while the receiver cannot extract a valid witness from it. If this is the case, it means that we cannot extract a valid witness from the valid pre-signature and signature pair (σ^,σ′). That is to say, the malicious sender is able to against the witness extractability feature of the adaptor signature. The probability of such a situation occurring is bounded by a negligible function. Therefore, the threat cannot happen.


## 7. Performance Analysis

In order to demonstrate the feasibility and the performance of our construction, we develop a prototypical Python implementation and conduct a series of experiments. We instantiate the Schnorr signature over the elliptic curvesecp256k1 (the one used in Bitcoin), use the libraries math, and random for corresponding calculations. The commitment scheme is modeled as a random oracle [38] with the SHA-256 algorithm.


### 7.1. Testbed

We conduct our experiments on a personal computer with an Intel (R) Core (TM) i7-10875H, 2.30 GHz, and 32 GB RAM. We measure the algorithms in on-chain and off-chain operations but do not consider the key generation algorithm for that this phase does not affect the online performance of our construction. We refer readers to [39] for the details of the key generation algorithm. The details of our evaluation is depicted in Table 1.Table 1
The resources required to execute the algorithms for our construction.
SenderReceiverOff-chainTime (ms)27.6630.78Comm (bytes)27294On-chainTime (ms)7.110.006Comm (bytes)——TotalTime (ms)34.7730.79Comm (bytes)27294Computation cost (gas)457340


### 7.2. Computation Time

We measure the computation time that each user required when performing different algorithms. From Table1, we observe that the computation time required for the off-chain operations accounted for a large portion of the total time. Notice that in this protocol, we grant the data access key on the blockchain. Therefore, the computation time does not vary with the size of the data. The time spent on off-chain operations accounts for the majority of each user’s operational time since the sender and the receiver need to perform verification to prove they behave honestly. In particular, it only takes 0.006 ms for the receiver to obtain his data access key in the on-chain operations.


### 7.3. Communication Overhead

We measure the communication overhead by calculating the information that the sender and the receiver need to exchange during the execution of each phase. The communication overhead is mainly generated in the off-chain operations. The sender need to send 272 bytes of information to the receiver and the receiver responds with 94 bytes information. The communication of the sender is higher than that of the receiver since the senders needs to send some additional proof information. In addition, there is a communication overhead for the receiver because the two parties involved need to perform a coin tossing protocol to jointly generate the relevant transaction information.


### 7.4. Computation Cost

We implement our construction on an Ethereum test network [26] and measure the computation cost through calculating the gas required by the smart contract. We observe that 45734 units of gas is required when the sender conducts his transaction on chain. At the time of writing, we consult the Ethereum gas price website “ETH Gas Station” [40] to know that the average gas price per unit is 14.9 gwei; our construction therefore costs considerably less than 0.0007 Ether.


## 7.1. Testbed

We conduct our experiments on a personal computer with an Intel (R) Core (TM) i7-10875H, 2.30 GHz, and 32 GB RAM. We measure the algorithms in on-chain and off-chain operations but do not consider the key generation algorithm for that this phase does not affect the online performance of our construction. We refer readers to [39] for the details of the key generation algorithm. The details of our evaluation is depicted in Table 1.Table 1
The resources required to execute the algorithms for our construction.
SenderReceiverOff-chainTime (ms)27.6630.78Comm (bytes)27294On-chainTime (ms)7.110.006Comm (bytes)——TotalTime (ms)34.7730.79Comm (bytes)27294Computation cost (gas)457340


## 7.2. Computation Time

We measure the computation time that each user required when performing different algorithms. From Table1, we observe that the computation time required for the off-chain operations accounted for a large portion of the total time. Notice that in this protocol, we grant the data access key on the blockchain. Therefore, the computation time does not vary with the size of the data. The time spent on off-chain operations accounts for the majority of each user’s operational time since the sender and the receiver need to perform verification to prove they behave honestly. In particular, it only takes 0.006 ms for the receiver to obtain his data access key in the on-chain operations.


## 7.3. Communication Overhead

We measure the communication overhead by calculating the information that the sender and the receiver need to exchange during the execution of each phase. The communication overhead is mainly generated in the off-chain operations. The sender need to send 272 bytes of information to the receiver and the receiver responds with 94 bytes information. The communication of the sender is higher than that of the receiver since the senders needs to send some additional proof information. In addition, there is a communication overhead for the receiver because the two parties involved need to perform a coin tossing protocol to jointly generate the relevant transaction information.


## 7.4. Computation Cost

We implement our construction on an Ethereum test network [26] and measure the computation cost through calculating the gas required by the smart contract. We observe that 45734 units of gas is required when the sender conducts his transaction on chain. At the time of writing, we consult the Ethereum gas price website “ETH Gas Station” [40] to know that the average gas price per unit is 14.9 gwei; our construction therefore costs considerably less than 0.0007 Ether.


## 8. Conclusion

In this work, we devise a blockchain-based data sharing protocol, which takes fairness, privacy protection, auditability, and generality into account simultaneously. Besides, we show how to instantiate it by presenting a Schnorr-based instance. Finally, we conduct a series of experiments to illustrate the effectiveness and efficiency of our construction. The results show that our construction is piratical and can be regarded as a promising tool to realize a generalized and secure data sharing platform.



---

*Source: 9998433-2023-02-06.xml*