Security and Communication Networks

Security and Communication Networks / 2021 / Article
Special Issue

Blockchain Technologies for Decentralization and Forensics of Outsourcing Services

View this Special Issue

Research Article | Open Access

Volume 2021 |Article ID 3680359 | https://doi.org/10.1155/2021/3680359

Huiying Hou, Shidi Hao, Jiaming Yuan, Shengmin Xu, Yunlei Zhao, "Fine-Grained and Controllably Redactable Blockchain with Harmful Data Forced Removal", Security and Communication Networks, vol. 2021, Article ID 3680359, 20 pages, 2021. https://doi.org/10.1155/2021/3680359

Fine-Grained and Controllably Redactable Blockchain with Harmful Data Forced Removal

Academic Editor: Yinghui Zhang
Received13 Apr 2021
Revised26 Apr 2021
Accepted11 May 2021
Published29 May 2021

Abstract

Notoriously, immutability is one of the most striking properties of blockchains. As the data contained in blockchains may be compelled to redact for personal and legal reasons, immutability needs to be skillfully broken. In most existing redactable blockchains, fine-grained redaction and effective deletion of harmful data are mutually exclusive. To close the gap, we propose a fine-grained and controllably redactable blockchain with harmful data forced removal. In the scheme, the originator of the transaction has fine-grained control over who can perform the redaction and which portions of the transaction can be redacted. The redaction transaction is performed after collecting enough votes from miners. All users can provide the index of the block containing the harmful data to receive rewards, which are borne by the malicious user who initially posted the data. Miners can forcibly remove the harmful data based on the index. The malicious user will be blacklisted if the reward is not paid within a period of time, and any transaction about such user will not be performed later. In addition, the scheme supports the redaction of additional data and unexpended transaction output (UTXO) simultaneously. We demonstrate that the scheme is secure and feasible via formal security analysis and proof-of-concept implementation.

1. Introduction

The first application of blockchains is Bitcoin [1, 2], which has revolutionized the financial industry. Ever since, hundreds of such cryptocurrencies rise which do not rely on a central trusted authority. The applications of blockchains go far beyond their use in cryptocurrencies [36]. Recently, blockchains have entered numerous domains of applications, such as supply chains, digital twins, insurance, healthcare, or energy. In brief, a blockchain is a decentralized, distributed, potentially public, and immutable log of objects.

Blockchains can be of different types. They can be public as Bitcoin or Ethereum, where the consensus protocol is executed between many pseudonymous participants. Here, the blockchain can be read and written by everyone. Such public blockchains can also be viewed as permissionless because everyone can join the system, participate in the consensus protocol, and establish smart contracts. Blockchains, however, can also be private (also called enterprise or permissioned blockchains) such as Hyperledger, Ethereum Enterprise, Ripple, or Quorum. Here, all the participants and their (digital) identities are known to one or more trusted organizations. Actors have write and read permissions. Such private blockchains can thus be viewed as permissioned because they restrict the actors who can contribute to the consensus on the system state to validate the block transactions. Once an object (such as a block or a transaction) is included in the blockchain (be it private or public), it is persisted and cannot be altered ever again. While immutability is a crucial property of the blockchain, it is often desirable to allow breaking the immutability for personal and legal reasons.

The debate about the immutability of the blockchain becomes more acute due to the adoption of the General Data Protection Regulation (GDPR) by the European Union (EU). Several provisions of the GDPR are essentially incompatible with the immutable blockchains. In particular, the GDPR imposes that the data have the right to be forgotten, while blockchains such as Bitcoin and Ethereum do not allow to remove any data [7]. In addition, by using the immutability of a blockchain, malicious users can broadcast illegal or harmful data, such as (child) pornography and violence information around the world by spending a small fee. The data will be permanently stored and cannot be modified after they are stable on the chain. It is an enormous challenge for law enforcement agencies such as Interpol [8, 9]. One idea is to “filter” all incoming data to check for malicious content before inserting the data into the chain. However, the recent work of Matzutt et al. [10] showed that the above idea is not feasible. Hence, how to skillfully break the immutability of blockchains is an important and urgent problem to be solved.

To solve the above problem, Ateniese et al. [11] first introduced the concept of redactable blockchain and proposed an elegant solution based on chameleon hash functions [12]. The solution addresses the redaction problem of blockchains at the block level, which is coarse grained.

The redactable blockchain should meet the following two properties: (1) the originator of a transaction can specify a fine-grained access control policy about who can modify the transaction and which portions of the transaction can be redacted; (2) the harmful information contained in the previous block can be removed. Unfortunately, there is no redactable blockchain that meets both requirements.

In this paper, we explored how to effectively realize the fine-grained redactable blockchain. Our thought for realizing fine-grained redaction and effective deletion of harmful data simultaneously is shown in Figure 1. In order to support fine-grained access control, a promising way is to adopt the policy-based chameleon hash function (PCH) [13], which allows the originator of a transaction to specify a fine-grained access control policy about who can modify the transaction. However, it may incur the following issue by adopting the PCH. The malicious originator of the transaction may design an access policy that only allows him/her to modify the transaction to store undeletable harmful information in a blockchain. This does not satisfy the second property. To solve the above problem, we try to combine the technology proposed in [14]. The technology allows all users to create removal transactions by spending some transaction fees. Miners then vote on the transaction, and the harmful information is removed if enough votes are collected within a period of time. Obviously, this does not motivate users to actively remove harmful information from the chain because the user is not only rewarded for doing so but also needs to spend transaction fees. In order to motivate users, in this paper, the users create removal transactions without spending transaction fees. If the transaction passes the verification, the originator will obtain the reward paid by the malicious user who posted the harmful information. In addition, this technique only supports the deletion of additional information in the block and needs to store some “old state,” that is, the hash value of the original transaction.

In practice, the redactable blockchains should meet the following three properties: (1) the originator of a transaction can specify a fine-grained access control policy about who can modify the transaction and which portions of the transaction can be redacted; (2) the harmful information contained in the previous block can be removed; (3) the data type that can be redacted is various. In order to support the redaction of various data types, we adopt the idea of the scheme in [15]. In this paper, the blockchain protocol not only supports removing additional information of the block but also redacting UTXO in the transaction. In order to reduce the storage space, we try to adopt a policy-based sanitizable signature [16]. However, in this way, the number of blocks of the signed data cannot be changed, and the set of inadmissible blocks needs to be stored. To solve this problem, we propose an improved policy-based sanitizable signature which allows that the number of blocks of the message can be changed.

1.1. Contributions

In this paper, we first explore how to effectively realize the fine-grained redaction of blockchains while removing the harmful data. We then propose a fine-grained and controllably redactable blockchain protocol with harmful data forced removal. In a nutshell, the contribution of this paper can be summarized as follows:(i)We propose a fine-grained and controllably redactable blockchain protocol with harmful data forced removal. Our scheme not only supports the usual redaction of transactions but also the forced removal of harmful information in the blockchain. The originator of the transaction can specify a fine-grained access control structure about who can redact the transaction and which portions of the transaction can be redacted. Authorized users may spend transaction fees to initiate a redaction transaction to redact the above transaction. Any user can initiate a transaction that contains the index of the block included harmful information without spending transaction fees. If the block does contain the harmful information, the miner who creates the new block can forcibly delete the harmful information. Thus, the harmful data can be removed; even the malicious users specify an access control that only they can modify the data. The user who provided the index of the block can receive the reward which is borne by the malicious user who initially posted the data. The malicious user will be blacklisted if the rewards are not paid within a period of time, and any transaction about the user will not be performed later. Furthermore, the scheme supports not only the redaction of additional data but also UTXO, i.e., unspent transaction outputs.(ii)We present an improved policy-based sanitizable signature scheme, which is based on the scheme in [16]. In our scheme, the number of blocks of the signed data can be changed, and the set of inadmissible blocks does not need to be stored. Users who satisfy the access control policy can modify the portions of the signed data that are allowed to be modified. The authorized users can generate the valid signatures for the modified data without interacting with the original signer. The data owner does not need to collect the identities of the candidate authorized users in advance as the proxy signature schemes would require.(iii)We demonstrate that the proposed scheme is secure and feasible via formal security analysis and proof-of-concept implementation. Specifically, we implement a full-fledged blockchain system, which achieves all the basic functionalities of Ethereum Enterprise. Separately, the blockchain system, including a subset of Ethereum Enterprise’s script language, allows the authorized user to redact the transaction and the miner to delete the harmful data. We evaluate the performance of the blockchain system for chain validation in different scenarios. The results show that the redactable blockchain protocol produces only an insignificant (no more than 3.8%) overhead compared to the immutable blockchain.

1.2. Related Work

The concept of sanitizable signature was introduced by Ateniese et al. [17]. A sanitizable signature scheme allows a sanitizer to update the signed data without interacting with the original signer. In order to ensure the security of the scheme, two necessary security requirements are defined in their scheme: (1) unforgeability, that is, only authorized sanitizers can generate the new valid signatures for the updated data; (2) transparency, that is, the updated data and their signatures are indistinguishable from the original information and corresponding signatures. Unfortunately, they did not give a complete definition of the sanitizable signature nor did they provide the formal security analysis. Brzuska et al. [18, 19] provided the formal definition of sanitizable signatures and gave the formalized definition of the basic security requirements. They introduced five formal security requirements, unforgeability, immutability, privacy, transparency, and accountability, and analyzed the relationships between these security requirements. Canard et al. [20] proposed a generic construction of the trapdoor sanitizable signature. In this scheme, the sanitizer can generate the valid signature for the updated data after receiving the trapdoor key from the original signer. Using an accountable chameleon hash, Lai et al. [21] proposed an accountable trapdoor sanitizable signature. However, neither of the above two schemes gives the concrete construction of the sanitizable signature. After that, many concrete sanitizable signature schemes were proposed [2224]. All of the above sanitizable schemes are not suitable for blockchain rewriting since none of the aforementioned schemes support fine-grained control over candidate sanitizers.

Attribute-based encryption schemes can provide fine-grained access control [2527]. In order to provide fine-grained access control, some attribute-based sanitizable signature schemes are proposed [16, 2830]. The scheme in [28] did not give the specific construct of the attribute-based sanitizable signature. The scheme in [29] did not support the expressive access structure. The scheme in [30] only provided an all-or-nothing solution for data modification. The number of blocks of the signed data cannot be changed, and the set of inadmissible blocks needs to be stored in [16]. In a real environment of blockchain rewriting, the number of blocks of the transaction may be changed, and the set of inadmissible blocks does not need to be contained in its signature. Therefore, in this paper, we improve the policy-based sanitizable signature scheme [16] and propose an improved policy-based sanitizable signature. In this paper, the number of blocks of the signed data can be changed, and the set of inadmissible blocks does not need to be stored. Furthermore, we present a fine-grained and controllably redactable blockchain protocol with harmful data forced removal based on the improved policy-based sanitizable signature scheme.

1.3. Organization

The rest of this paper is organized as follows. In Section 2, we briefly review the preliminaries required in this paper. The system model and design goals are given in Section 3. In Section 4, we introduce the proposed improved policy-based sanitizable signature scheme. We describe the proposed blockchain protocol in Section 5. In Section 6, we introduce the security analysis of the proposed protocol. We evaluate the performance of the proposed protocol in Section 7. Finally, we come to the conclusion in Section 8.

2. Preliminaries

2.1. Notions

We list the notations used in our scheme in Table 1.


NotationMeaning

A monotone collection
The attributes’ universe
A public key encryption scheme
The security parameter
The public parameters of
The public and private key of
The message
The ciphertext
A digital signature scheme
The public parameters of
The signer’s public and private key in
The signature in
A NP-language
A noninteractive proof system for
A common reference string
The statement
The corresponding witness
The proof
The public parameters of PCH
The master key pair of PCH
The set of attributes
The user’s secret key in PCH
The hash value
The randomness
The modified message
The new randomness
The public parameters of P3S
The master key pair of P3S
The signer’s key pair in P3S
The sanitizer’s key pair in P3S
The description of modification

2.2. Access Structure

A collection is an access structure on , where denotes attributes’ universe. If a set is contained in , it is the authorized set. Otherwise, it is an unauthorized set. A collection is monotone if for and .

2.3. Public Key Encryption

A public key encryption scheme consists of the following five algorithms:(i): this algorithm takes the security parameter as the input and outputs the public parameters .(ii): this algorithm takes the public parameters as the input and outputs the public and private key .(iii): this algorithm takes the public key and the message as the input and outputs a ciphertext .(iv): this algorithm takes the private key and the ciphertext as the input and outputs the message .(v): this algorithm takes the public and private key as the input and outputs 1 if belongs to . Otherwise, it outputs 0.

The detailed definition of correctness and security of the public key encryption (PKE) is given in [16]. In this paper, we require correctness and IND-CCA2 security for PKE.

Definition 1. ( IND-CCA2 security). A public encryption scheme is IND-CCA2 secure [16] if for any probabilistic polynomial-time (PPT) adversary , there exists a negligible function such thatThe corresponding experiment is depicted in Figure 2.

2.4. Digital Signature

A digital signature scheme consists of the following four algorithms:(i): this algorithm takes the security parameter as the input and outputs the public parameters .(ii): this algorithm takes the public parameters as the input and outputs signer’s public and private key .(iii): this algorithm takes the private key and the message as the input and outputs the signature .(iv): this algorithm takes the public key , the message , and the signature as the input and outputs 1 if is valid. Otherwise, it outputs 0.

The formal security definition of the digital signature is given in [16]. In this paper, we require correctness and existential unforgeability (eUNF-CMA) for the digital signature.

Definition 2. ( unforgeability). A digital signature scheme is unforgeable [16] if for any PPT adversary , there exists a negligible function such thatThe corresponding experiment is depicted in Figure 3.

2.5. Noninteractive Zero-Knowledge Proof (NIZK)

Let , where is a NP-language with associated witness relation . A noninteractive proof system for the language consists of the following three algorithms:(i): this algorithm takes the security parameter as the input and outputs the common reference string (CRS) .(ii): this algorithm takes CRS , the statement , and the corresponding witness as the input and outputs the proof .(iii): this algorithm takes CRS , the statement , and the proof as the input and outputs 1 if is valid. Otherwise, it outputs 0.

The security of the noninteractive zero-knowledge proof (NIZK) is given in [16]. In this paper, we require completeness for NIZK. In addition to completeness, we require two standard security notions for zero-knowledge proofs of knowledge: zero knowledge and simulation-sound extractability. We define them analogous to the definitions given in [16]. Informally speaking, zero knowledge says that the receiver of the proof does not learn anything except the validity of the statement.

Definition 3. (completeness). A noninteractive proof system is called complete if for all , , , such that , , it holds that .

2.6. Policy-Based Chameleon Hashes

A policy-based chameleon hash (PCH) allows the user, who owns attributes’ set that satisfied the access structure, to compute a hash collision [13]. Specifically, a PCH contains the following six PPT algorithms:(i): this is the public parameters’ generation algorithm. It takes the security parameter as the input and outputs the public parameters .(ii): this is the master key generation algorithm. It takes the public parameter as the input and outputs the master key pair .(iii): this is the user’s secret key generation algorithm. It takes the master secret key and the set of attributes as the input and outputs the user’s secret key .(iv): this is the hash algorithm. It takes the master public key , the access structure , and the message as the input and outputs the hash value and the randomness .(v): this is the verification algorithm. It takes the master public key , the message , the hash value , and the randomness as the input and outputs a bit if and are valid. Otherwise, .(vi): this is the adaption algorithm. It takes the public key , the user’s secret key , the message , the modified message , the hash value , and some randomness as the input and outputs a new randomness .

The detailed definition of correctness and security of the policy-based chameleon hash is given in [13].

2.7. Policy-Based Sanitizable Signature

A policy-based sanitizable signature (P3S) allows the user, who owns attributes’ set that satisfied the access structure, to modify the data and generate the valid signatures for the modified data [16]. Specifically, a P3S contains the following ten PPT algorithms:(i): this is the public parameters’ generation algorithm. It takes the security parameter as the input and outputs the public parameters .(ii): this is the master key generation algorithm. It takes the public parameters as the input and outputs the master key pair .(iii): this is the signer’s key pair generation algorithm. It takes the public parameters as the input and outputs the signer’s key pair .(iv): this is the sanitizer’s key pair generation algorithm. It takes the public parameters as the input and outputs the sanitizer’s key pair .(v): this is the signing algorithm. It takes the public parameters , the signer’s secret key , the message , the description of admission , and the access structure as the input and outputs a signature .(vi): this is the secret sanitizing key generation algorithm. It takes the master secret key , the sanitizer’s public key , and the set of attributes as the input and outputs the secret sanitizing key for the sanitizer.(vii): this is the verification algorithm. It takes the master public key , the signer’s public key , the signature , and the corresponding message as the input and outputs a bit if the signature is valid. Otherwise, .(viii): this is the new signature generation algorithm. It takes the master public key , the signer’s public key , the sanitizer’s secret key , the secret sanitizing key , the signature , the corresponding message , and the description of modification as the input and outputs the new signature for the modified message .(ix): this is the proof generation algorithm. It takes the master public key , the signer’s secret key , the signature , and the corresponding message as the input and outputs the proof .(x): this is the proof verification algorithm. It takes the public parameter , the master public key , the signer’s public key , the signature , the corresponding message , and the proof as the input and outputs a bit if the proof is valid. Otherwise, .

The detailed definition of correctness and security of the policy-based sanitizable signature is given in [16].

2.8. Blockchain Protocol

Let denote an immutable blockchain protocol such as Ethereum Enterprise. The nodes in the blockchain protocol obtain their local chain based on a common genesis block. The nodes in the blockchain protocol collect transactions in the whole blockchain ecosystem and then package these transactions into a new block. The chain becomes longer as nodes agree on a new block. Nodes can access the blockchain protocol through the following interfaces.(i): returns the chain if it is the longer and the valid chain in the blockchain ecosystem. Otherwise, it returns .(ii): takes the chain as the input and outputs 1 iff the chain is valid according to the public set of rules.(iii): takes the block as the input and outputs 1 iff the block is valid according to the public set of rules.(iv): takes the transaction as the input and broadcasts it to all nodes in the blockchain ecosystem.

3. Problem Formulation

3.1. System Model

As shown in Figure 4, the system model of the proposed redactable blockchain protocol consists of four entities: the trusted authority (TA), the miners, the users, and the authorized users. Note that the model in this paper is similar to the model in [13]. It is more applicable to permissioned blockchains, such as Hyperledger, Ethereum Enterprise, Ripple, and Quorum.(i)Trusted authority (TA): trusted authority (TA) is fully honest and responsible for generating the signing private key for users who posted the redactable transaction, issuing the attributes and attributes’ key for authorized users, and sending keys to miners.(ii)Miners: miners are fully honest and have powerful computing resources. They are responsible for packaging transactions in the network to generate the new block and removing harmful information from the previous blocks.(iii)Users: users may be malicious. They can post the usual transaction or the transaction containing the index of the block which includes harmful information to the network. Users get fine-grained control over which users can redact their usual transaction and which portions of the transaction can be redacted. The malicious users may specify an access structure that only allows themselves and their conspirators to redact the transaction.(iv)Authorized users: the authorized users are semihonest in the sense that they can modify the portions of the transaction that are allowed to be modified and generate the new valid signatures for the updated data that are indistinguishable from the signatures that the originator generated for the original transaction.

3.2. Design Goals

In order to realize a “healthy” blockchain protocol, the proposed fine-grained and controllably redactable blockchain with harmful data forced removal should satisfy the following properties:(i)Controlled redaction: only authorized users can redact the portions of the transaction that are allowed to be redacted.(ii)Accountability: the authorized user who redacts the transaction can be tracked.(iii)Correctness: correctness ensures that the redacted blockchain is “healthy.” Specifically, a “healthy” blockchain should meet the following characteristics:(a)Chain growth: let and denote two chains possessed by two honest users at rounds and , respectively. Then, , where is the speed coefficient and .(b)Chain quality: generally speaking, the chain quality says that the ratio of adversarial blocks in any segment of a chain held by an honest party is no more than a fraction , where is the fraction of resources controlled by the adversary.(c)Editable common prefix: the usual common prefix says that if and are two chains possessed by two honest users at rounds and , for , is a prefix of . It can be formally denoted as , where is the chain obtained by removing the last blocks from , is the common prefix parameter. Note that the proposed editable blockchain inherently does not satisfy the common prefix. Suppose the voting phase for the redaction transaction is still on at round . At round , the voting phase is complete, and replaces , i.e., the redacted block replaces . In , the -th block is instead of as in . Thus, is not the common prefix of and . We extend this definition. The chains and satisfy one of the following:(1)(2)  The voting phase is complete, and replaces if ,

3.3. Threat Model

Definition 4. (controlled redaction). Controlled redaction ensures that only authorized users can redact the portions of the transaction that are allowed to be redacted. In order to formally describe the controlled redaction, we introduce a game between the challenger and the adversary . Here, we consider two adversaries. One of the adversaries is the adversary , who does not possess the attributes’ set which satisfies the access control policy. Another is the adversary , who tries to redact the inadmissible portions of the transaction. In order to show how and attack the redactable blockchain protocol, we introduce the game between the challenger and adversaries and , respectively.
Firstly, we describe the game between the challenger and the adversary . Trusted authority (group manager) is viewed as a challenger , and the unauthorized user is viewed as an adversary . This game includes the following phases:(i)Setup phase: the challenger runs the and algorithm to generate the public parameters and the master private/public key pair . Then, holds the master private key locally. Finally, sends the master public key and the public parameters to the adversary .(ii)Query phase:(a) queries: the adversary queries sanitizer’s private/public key pair for the public parameters . runs algorithm and returns the private/public key pair to .(b)Sign queries: the adversary queries the signature for the master public key , the signature for the transaction m, the set of admissible blocks , and the access structure . runs to generate the signing key and then runs Sign algorithm to produce the signature . Finally, returns the signature to .(c) queries: the adversary queries the sanitizer’s attribute key for , , and the attributes’ set such that . runs algorithm and returns the sanitizer’s attribute key to .(d) queries: the adversary queries the verification result for , , , and . runs algorithm and returns the result to .(e) queries: the adversary queries the sanitizable signature for , , , , , , and . runs algorithm and returns the new signature to .(f) queries: the adversary queries for , , , and . runs algorithm and returns to .(g) queries: the adversary queries the judge result for , , , and . runs algorithm and returns the result to .(iii)Challenge phase: the adversary adaptively chooses the authorized user’s attributes’ set . Then, runs algorithm to generate the challenged signature for the challenged transaction . Finally, the adversary sends to .(iv)Verify phase: the adversary performs polynomial queries as in the query phase. Consider the adversary has made queries, and let denote the set of information obtained through these queries. runs algorithm and outputs a bit . If , checks whether there exists an such that . If there is such an i, the challenger outputs . Otherwise, outputs .We say that the adversary wins if . In the above game, we want to show that the adversary , who does not possess the attributes’ set such that , should not generate the new valid witness for the transaction. The adversary’s goal is to correctly generate the valid signature for the transaction . We set the advantage of a polynomial-time adversary in this game to be . We say the proposed scheme satisfies the unforgeability of the signature if for any polynomial-time adversary , for sufficiently large n, where poly stands for a polynomial function.
Then, we describe the game between the challenger and the adversary . Trusted authority (group manager) is viewed as a challenger , and the authorized user is viewed as an adversary . This game includes the following phases:(i)Setup phase: the challenger runs the and algorithm to generate the public parameters and the master private/public key pair . Then, holds the master private key locally. Finally, sends the master public key and the public parameters to the adversary .(ii)Query phase:(a) queries: the adversary queries sanitizer’s private/public key pair for the public parameters . runs algorithm and returns the private/public key pair to .(b)Sign queries: the adversary queries the signature for the master public key , the signature for the message m, the set of admissible blocks , and the access structure . runs to generate the signing key and then runs Sign algorithm to produce the signature . Finally, returns the signature to .(c) queries: the adversary queries the sanitizer’s attribute key for , , and the attributes’ set such that . runs algorithm and returns the sanitizer’s attribute key to .(d) queries: the adversary queries the verification result for , , , and . runs algorithm and returns the result to .(e) queries: the adversary queries the sanitizable signature for , , , , , , and . runs algorithm and returns the new signature to .(f) queries: the adversary queries for , , , and . runs algorithm and returns to .(g) queries: the adversary queries the judge result for , , , and . runs algorithm and returns the result to .(iii)Challenge phase: the adversary adaptively chooses the authorized user’s attributes’ set . Then, runs algorithm to generate the challenged signature for the challenged message which does not contain all inadmissible blocks. Finally, the adversary sends to .(iv)Verify phase: the adversary performs polynomial queries as in the query phase. Consider the adversary has made queries, and let denote the set of information obtained through these queries. runs algorithm and outputs a bit . If , checks whether there exists an which does not contain all inadmissible blocks. If there is such an i, the challenger outputs . Otherwise, outputs .We say that the adversary wins if . In the above game, we want to show that the adversary , who redacts the inadmissible blocks, should not generate the new valid signature. The adversary’s goal is to correctly generate the valid signature for the message . We set the advantage of a polynomial-time adversary in this game to be . We say the proposed scheme satisfies controlled redaction if for any polynomial-time adversary , for sufficiently large n, where poly stands for a polynomial function.

Definition 5. (accountability). We say that the proposed fine-grained and controllably redactable blockchain with harmful data forced removal satisfies accountability if TA can extract signer’s identity from any valid transaction’s signature with nonnegligible probability.

4. The Improved Policy-Based Sanitizable Signature

4.1. Algorithm Definition

Let denote a policy-based chameleon hash, label a simulation-sound extractable noninteractive zero-knowledge proof (NIZK) system, be a one-way function, denote an IND-CCA2-secure public key encryption scheme, and be an eUNF-CMA-secure signature scheme. Specifically, the improved policy-based sanitizable signature is described as follows:(i): it takes a security parameter as the input and outputs , where , , , , is a one-way function, and is a cryptographic hash function.(ii): it takes as the input and outputs , where and .(iii): it takes as the input and outputs , where , , , and .(iv): it takes as the input and outputs , where and .(v): it takes , , the message , the set of admissible blocks , and the access structure as the input and outputs if . Otherwise, it outputs , where , , , and . Note that .(vi): it takes , , and the attributes’ set as the input and outputs the sanitizing key , where and .(vii): it takes , , , and as the input and outputs 1 if and are valid, , and can be computed from the message . Otherwise, it outputs .(viii): it takes , , , , , , and as the input. If or is not valid, it outputs . Otherwise, the sanitizer computes , , and . Note that . Then, the sanitizer sets . If is not valid, this algorithm outputs . Otherwise, it outputs .(ix): it takes , , , and as the input and outputs , where , , and .(x): it takes , , , , , and as the input. If and are valid, it outputs 1. Otherwise, it outputs 0.

The improved policy-based sanitizable signature replaces the inadmissible block set in [16] with to allow that the number of blocks of the message can be changed, and the set of inadmissible blocks does not need to be stored. Here, denotes the set of blocks that are not allowed to be modified. The security definition and analysis are given in Appendixes A and B, respectively.

5. The Proposed Protocol

5.1. An Overview

The workflow of the proposed blockchain protocol can be described as follows. Firstly, users can generate a local chain based on the common genesis block and initialize the redaction transaction list , the removal transaction list , the penalty payment transaction list , and the blacklist to be empty. After that, users run to obtain the longest chain in the blockchain network. When the user wants to redact the previous transaction, he/she first broadcasts a redaction transaction by spending some transaction fees. The transaction will be added to the list if it is valid. The miners vote on the transaction. The transaction can be executed if enough votes are collected within a period of time as shown in Figure 5. When a user finds harmful information contained in a block, he/she creates a removal transaction containing the index of the block without spending transaction fees. Miners create new blocks that contain at least one transaction in and one in if they are not empty. The miner removes the harmful information from the block according to the provided index. Meanwhile, the miner generates a penalty payment transaction added to as shown in Figure 6. The transaction will be removed from list after the penalty is paid by the malicious user. If the malicious user fails to pay the penalty within a period of time, he/she will be added to the blacklist . After that, all transactions relating to the malicious user will never be performed.

5.2. Description of the Proposed Protocol

The proposed blockchain protocol runs in a sequence of rounds and consists of the following six algorithms (Figures 710):(i)Initialization: get the local chain , where denotes a common genesis block. Set round , and initialize empty lists , , , and .(ii)Chain update: at the beginning of each round , users run to get the longest chain in the blockchain network.(iii)Propose a redaction: the user proposes a redaction of the transaction by spending some transaction fees.(a)Firstly, the user creates a redaction transaction using the new transaction as shown in Figure 7. In this process, the improved policy sanitizable signature is used to generate the witness for the transaction. We can see from Figure 7 that the hash values for and are the same. Therefore, the hash value of this block will not be changed after redacting the transaction.(b)Then, he/she runs to broadcast the redacted transaction to the blockchain network.(c)Finally, miners add the transaction to the list if the data are UTXO. Otherwise, the transaction is discarded.(iv)Propose a removal of harmful information when the user finds that the transaction , contained in the block with the index , has the harmful information.(a)Firstly, as shown in Figure 8, the user creates a removal transaction , which does not cost transaction fee and contains the block’s index and the transaction .(b)Then, he/she broadcasts the transaction .(c)The transaction will be added to the list if the block does contain the harmful information. Meanwhile, the penalty payment transaction will be created and added to the list . As shown in Figure 9, the transaction contains the amount of the penalty and the address of the malicious user who posts the harmful information. The transaction will be removed from the list after the malicious user pays the penalty.(v)Redacting the chain:(a)For the candidate transaction in the list , the miner substitutes it with the new transaction if the voting process on it has been completed and enough votes have been collected within a period of time t. The transaction is discarded if the votes within a period of time t. If the voting on is still in progress, nothing will be done. Here, denotes the threshold of votes and can be specified by consensus among all users in the blockchain network.(b)For the candidate transaction in the list , the miner removes the harmful information from which is contained in the block with the index .(c)For the candidate transaction in the list , the miner first verifies whether the malicious user pays the penalty within a period of time . If the malicious user pays the penalty, the transaction is removed from . If the malicious user does not pay the penalty within a specified period of time, the user is added to the blacklist , and the transaction is removed from the list .(vi)Creating a new block: the miner collects all transactions from the network for the round and builds a new block which meets the following conditions:(a)It contains at least one transaction in and one in if they are not empty.(b)It contains a vote on the candidate transaction in the list if the voting on is still in process and the miner is willing to endorse.(c)All transactions contained in it comply with the usual transaction rules in the Ethereum Enterprise blockchain, and the validation process is shown in Figure 10.

Finally, if all blocks contained in the local chain satisfy and , the miner extends the local chain and broadcasts the extended chain to the blockchain network.

6. Security Analysis

In this section, we analyze the security of the fine-grained and controllably redactable blockchain protocol with harmful data forced removal in terms of correctness, controlled redaction, and accountability.

Theorem 1. (correctness). The correctness of a blockchain consists of the following three aspects:(1)Chain growth: if the based immutable blockchain protocol satisfies chain growth, the extended editable blockchain protocol also satisfies chain growth.(2)Chain quality: if the based immutable blockchain protocol satisfies chain quality, the extended editable blockchain protocol also satisfies chain growth for any . Here, denotes the ratio of blocks containing the votes of the redacted transaction within a period of time.(3)Common prefix: if the based immutable blockchain protocol satisfies the common prefix, the extended editable blockchain protocol also satisfies the common prefix.

Proof. (1)Chain growth: we note that the redaction in cannot reduce the length of the chain by removing a block from the chain. Thus, the redact operations have no effect on the length of the chain. In conclusion, satisfies chain growth if satisfies chain growth.(2)Chain quality: suppose the adversary posts a malicious redaction transaction for the previous transaction . mines at most ratio of blocks in the voting phase because the adversary only has computational power. Thus, cannot be performed due to . In conclusion, only the honest redaction transaction can be performed and added to the chain.(3)Common prefix: if the chain is not redacted, runs as the immutable blockchain . Thus, satisfies the common prefix. If the chain is redacted and the redacted block replaces in , the voting phase for the block is completed, and enough votes are received. In conclusion, the extended editable blockchain protocol also satisfies the common prefix.

Theorem 2. (controlled redaction). In the proposed scheme, for each PPT adversary , it is computationally infeasible to generate a valid signature for the redacted transaction.

Proof. To prove this theorem, we consider two types of adversaries. One of the adversaries is the adversary who does not possess the attributes’ set which satisfies the access control policy. Another is the adversary , who tries to redact the inadmissible portions of the transaction. In order to show how and attack the redactable blockchain protocol, we introduce the two games between the challenger and adversaries and , respectively. Firstly, we define a game between the challenger and the adversary .
Game 1: in Game 1, both the challenger and the adversary perform as defined in the security definition.(i)Setup phase: the adversary does as in the “Threat Model.”(ii)Query phase: the adversary does as in the “Threat Model.”(iii)Challenge phase: the adversary adaptively chooses the authorized user’s attributes’ set . Then, runs algorithm to generate the challenged signature for the challenged transaction . Finally, the adversary sends to .(iv)Verify phase: the adversary performs polynomial queries as in the query phase. Consider the adversary has made queries, and let denote the set of information obtained through these queries. runs algorithm and outputs a bit . If , checks whether there exists an such that . If there is such an i, the challenger outputs . Otherwise, outputs .Suppose , that is, the adversary wins, we can say that the adversary breaks the security of the policy-based sanitizable signature because the adversary’s goal is to correctly generate the valid signature for the transaction . According to the security of the policy-based sanitizable signature (unforgeability), the probability of each adversary, who does not possess the attributes’ set such that , is negligible.
Then, we define a game between the challenger and the adversary .
Game 2: in Game 2, both the challenger and the adversary perform as defined in the security definition.(i)Setup phase: the adversary does as in the “Threat Model.”(ii)Query phase: the adversary does as the adversary in the query phase.(iii)Challenge phase: the adversary adaptively chooses the authorized user’s attributes’ set (). Then, runs algorithm to generate the challenged signature for the challenged message which does not contain all inadmissible blocks. Finally, the adversary sends to .(iv)Verify phase: the adversary performs polynomial queries as in the query phase. Consider the adversary has made queries, and let denote the set of information obtained through these queries. runs algorithm and outputs a bit . If , checks whether there exists an which does not contain all inadmissible blocks. If there is such an i, the challenger outputs . Otherwise, outputs .Suppose , that is, the adversary wins, we can say that the adversary breaks the security of the policy-based sanitizable signature because the adversary’s goal is to correctly generate the valid signature for the transaction . According to the security of the policy-based sanitizable signature (immutability), the probability of each adversary, who redacts the inadmissible blocks, is negligible.
In conclusion, the proposed blockchain protocol achieves controlled redaction. In other words, only authorized users can redact the admissible portions of the transaction .

Theorem 3. (accountability). In the proposed blockchain protocol, trusted authority (group manager) can extract the identity of the originator of the transaction or the authorized user from any valid witness with nonnegligible probability.

Proof. We prove accountability by a sequence of games.(i)Game 0: as Game 0 in [16].(ii)Game 1: as Game 0, but we replace with the one generated by , i.e., the simulator takes the security parameter as the input and then outputs . Finally, the challenger keeps the trapdoor and starts simulating all proofs.(iii)Assume towards contradiction that the adversary behaves differently. We can then build an adversary which breaks the zero-knowledge property of the underlying proof system. The reduction works as follows. Our adversary receives from its own challenger and embeds it into and generates all other values honestly. All proofs are then generated using the oracle provided and embedded honestly. Then, whatever outputs is also output by . is negligible, where denotes the advantage of the adversary in Game X. Note that this also means that all proofs are now simulated, even though they still prove valid statements.(iv)Game 2: as Game 1, but we replace with the one generated by , i.e., the simulator takes the security parameter as the input and then outputs . Finally, the challenger keeps the trapdoors and . Let be the event that can distinguish this replacement with nonnegligible probability. Moreover, note that, by definition, is exactly distributed as in the prior hop.(v)As we only keep one additional value, i.e., , this is only an internal change. is negligible.(vi)Game 3: as Game 2, but we abort if the adversary outputs valid for which we cannot (as the holder of ) calculate which makes output 0. Let this event be .If occurs, we have a bogus proof contained in as it proves a false statement. Thus, proceeds as in the prior game (doing everything honestly, but using simulated proofs and simulated ) and can simply return the statement claimed to be proven by and itself. is negligible.In conclusion, the proposed blockchain protocol achieves accountability.

7. Performance

In this section, we first give functionality comparison among our redactable blockchain protocol and several related redactable blockchain protocols [11, 1315]. Then, we analyze the computational burden of our redactable blockchain protocol through several experiments.

7.1. Functionality Comparison

We give functionality comparison among our scheme and the related schemes [11, 1315]. As shown in Table 2, our scheme is the only one that satisfies all of the following properties: fine-grained access control, controllable edit, accountability, and supporting the redaction of both additional information and UTXO. The schemes in [11, 14] cannot support fine-grained access control. The scheme in [13] cannot effectively support harmful data deletion. All of these related redactable blockchain protocols cannot support controllable edit, accountability, and the editing of both additional information and UTXO.


ProtocolsFine-grained access controlControllable editHarmful data deletionAccountabilityData type

[11]Additional information
[13]Additional information
[14]