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 [3–6]. 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 [22–24]. 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 [25–27]. In order to provide fine-grained access control, some attribute-based sanitizable signature schemes are proposed [16, 28–30]. 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.
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.
(a)
(b)
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 7–10):(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, 13–15]. 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, 13–15]. 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.
7.2. Proof-of-Concept Implementation
To evaluate the practicality of the proposed blockchain protocol, we implement a full-fledged blockchain system in Python 3.5.3, which is carried out on a desktop with an Intel Core (TM) i5-4300 CPU @ 2.13 GHz and 8.0 GB RAM.
The blockchain system can achieve 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 rely on the PoW consensus mechanism as Ethereum Enterprise does.
We evaluate the performance of the blockchain system for chain validation in different scenarios. In order to measure the cost time of chain validation, we validate chains containing different number of blocks and redaction transactions. A new chain is created and validated 50 times in each experiment, and the cost time of chain validation is the arithmetic mean of the run time of all runs. Each chain consists of up to 50,000 blocks, which approximate a one-year snapshot of the Ethereum Enterprise. Each block includes 1000 transactions (Figures 11–14).(i)Overhead Compared to the Immutable Blockchain. In order to evaluate the overhead of the redactable blockchain protocol with no redactions performed compared to the immutable blockchain, in the series of experiments, the length of chains ranges from 10,000 to 50,000 blocks. As shown in Figure 11, the redactable blockchain protocol has only a more tiny overhead than the immutable blockchain. With the increase of the length of the chain, the overhead is smaller. The reason is that the only extra step of the redactable blockchain is to check if any votes are contained in the new block. The run time of this step is negligible compared to the time of chain validating when the length of the chain is larger enough.(ii)Overhead by the Number of Redactions. In order to evaluate the overhead of the redactable blockchain protocol with the increasing number of redactions compared to the redactable blockchain with no redaction, in the series of experiments, the number of redactions ranges from 1000 to 5000. As shown in Figure 12, the overhead is linear in the number of redactions because we need to collect the votes for the redaction in the voting phase.(iii)Overhead by the Number of Removals. In order to evaluate the overhead of the redactable blockchain protocol with the increasing number of removals compared to the redactable blockchain with no removal, in the series of experiments, the number of removals ranges from 1000 to 5000. As shown in Figure 13, the overhead is linear in the number of removals because the miner generating the new block needs to remove the harmful information from the previous block.(iv)Overhead by the Voting Parameter. In order to evaluate the overhead of the redactable blockchain protocol with different voting periods, in the series of experiments, we set that the number of redactions is 1000, and the threshold ratio of the votes is . As shown in Figure 14, the overhead is small and is most linear in the voting period.
8. Conclusions
In this paper, we proposed a fine-grained and controllably redactable blockchain 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 could specify a fine-grained access control structure about who could redact the transaction and which portions of the transaction could be redacted. Any user could initiate a transaction that contains the index of the block which included harmful information without spending transaction fees. If the harmful information is contained in a block, it was forced to be deleted by the miner who created the new block. The user who provided the index of the block could receive the reward which was borne by the malicious user. The malicious user would be blacklisted if rewards were not paid within a period of time, and any transaction about the user would not be performed later. Furthermore, the scheme supported not only the redaction of additional data but also UTXO. Finally, we demonstrated that the scheme was secure and feasible via formal security analysis and proof-of-concept implementation.
Note that the proposed fine-grained and controllably redactable blockchain protocol with harmful data forced removal is suitable for permissioned blockchains, such as Hyperledger, Ethereum Enterprise, Ripple, and Quorum. There is another type of blockchain called permissionless blockchain, such as Bitcoin and Ethereum. Constructing the redactable permissionless blockchain protocol is a challenge and an interesting open problem. In our future work, we will also focus on designing more sophisticated solutions to the redactable permissionless blockchain protocol.
Appendix
A. Security Definition of the Improved Policy-Based Sanitizable Signature
In the following, we give the security definition of the improved policy-based sanitizable signature. Due to the limited space, we select several security aspects to highlight, and the rest of the security aspects can be seen in [16].
Definition 6. (unforgeability). In order to formally describe the unforgeability of the signature, we introduce a game between the challenger and the adversary to show how the adversary is against the unforgeability of the signature. Trusted authority (group manager) is viewed as a challenger , and the unauthorized user is viewed as an adversary in our security definition. This game includes the following phases:(i)Setup phase: firstly, 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 . 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 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 the unforgeability of the signature if for any polynomial-time adversary , for sufficiently large n, where poly stands for a polynomial function.
Definition 7. (immutability). In order to formally describe the immutability of the signed data, we introduce a game between the challenger and the adversary to show how the adversary is against the immutability of the signed data. Trusted authority (group manager) is viewed as a challenger , and the authorized sanitizer is viewed as an adversary in our security definition. This game includes the following phases:(i)Setup phase: firstly, 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 the unforgeability of the signature if for any polynomial-time adversary , for sufficiently large n, where poly stands for a polynomial function.
Definition 8. (traceability). We say an improved policy-based sanitizable signature supports traceability if the trusted authority (group manager) can extract signer’s identity from any valid signature with nonnegligible probability.
B. Security Analysis of the Improved Policy-Based Sanitizable Signature
In this section, we analyze the security of the improved policy-based sanitizable signature in terms of unforgeability, immutability, and traceability.
Theorem 4. (unforgeability). Any PPT adversaries can forge a policy-based sanitizable signature for some message with negligible probability.
Proof. To prove unforgeability, we use 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. 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. Note that this also means that all proofs are now simulated, even though they still prove valid statements.(iii)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. As we only keep one additional value, i.e., , this is only an internal change. is negligible.(iv)Game 3: as Game 2, but we abort if the adversary was able to generate a signature on a string never generated by the signing oracle. Let this event be . Assume, towards contradiction, that event occurs. We can then construct an adversary which breaks the unforgeability of the underlying signature scheme, namely, receives of the signature scheme. This is embedded in , while all other values are generated as in Game 2. All oracles are simulated honestly, but . The only change is, however, that the generation of each is outsourced to the signature generation oracle. Then, whenever occurs, can return . These values can easily be compiled using ’s output, i.e., . Note that this already includes that the adversary cannot temper with . is negligible.(v)Game 4: as Game 3, but we abort if the adversary was able to generate for which should not have been derivable. Let this event be . Assume, towards contradiction, that event occurs. We can then construct an adversary which breaks the strong insider collision resistance of the used , namely, receives of the . This is embedded in , while all other values are generated as in Game 3. The GetSan oracle is simulated honestly. Calls to the oracle are done honestly, but the hash is generated using the oracle. Calls to the oracle are simulated as follows. If a key for a simulated sanitizer (obtained by a call to the GetSan oracle) is to be generated, it is rerouted to . If the adversary wants to get a key for itself, it is rerouted to the oracle, and the answer is embedded honestly in the response. Sanitization requests are performed honestly (but simulated proofs), with the exception that adaptions for simulated sanitizers are done using the oracle. So far, the distributions are equal. Then, whenever the adversary outputs such that the winning conditions are fulfilled, our reduction can return . The values can be compiled from and the transcript from the signing oracle (note that we already excluded that the adversary can temper with the hash ). is negligible.(vi)Game 5: as Game 4, but we abort if the adversary was able to generate but has never made a call . Let this event be .Assume, towards contradiction, that event occurs. We can then construct an adversary which breaks the unforgeability of used or the one-wayness of the used one-way function , namely, receives of and , and from its own challenger. This is embedded in (and, of course, the public parameters), while all other values are generated as in Game 4. is embedded in . For signing, the proofs are already simulated, and thus, is not required to be known. For each call to for keys for which the adversary knows the corresponding secret keys, calls its signature oracle to obtain such a key. For simulated sanitizers, those signatures do not need to be obtained as the proofs are already simulated. Then, whenever the adversary outputs , extracts values . If , can return to break the one-wayness of . In the other case, can return as its own forgery attempt for . If extraction fails or a wrong statement was proven, SSE does not hold. A reduction is straightforward. is negligible. Now, the adversary can no longer win the unforgeability game; this game is computationally indistinguishable from the original game, which concludes the proof.
Theorem 5. (immutability). For each PPT adversary, the advantage of generating valid signatures for altered immutable parts is negligible.
Proof. To prove immutability, we use a sequence of games:(i)Game 0: as Game 0 in [16].(ii)Game 1: as Game 0, and we abort if the adversary outputs such that the winning conditions are met. Let this event be .Assume, towards contradiction, that event occurs. We can then build an adversary which breaks the unforgeability of the used signature scheme, namely, we know that A (which also contains the length of the message and all nonmodifiable blocks along with their location), along with , is signed. As, however, by definition, the message must be different from any derivable message, A w.r.t. was never signed in this regard. Thus, was never signed by the signer.
Constructing a reduction is now straightforward. Our reduction receives the public key (along with the public parameters) from its own challenger. This public key is embedded as . All other values are generated honestly. If a signature is to be generated, asks its own oracle to generate that signature, embedding it into the response receives. At some point, returns . The forgery can be extracted as described above. is negligible. We stress that, by construction, a sanitizer always exists. Now, the adversary can no longer win the immutability game; this game is computationally indistinguishable from the original game, which concludes the proof.
Theorem 6. (traceability). 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 traceability 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. 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. Note that this also means that all proofs are now simulated, even though they still prove valid statements.(iii)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. As we only keep one additional value, i.e., , this is only an internal change. is negligible.(iv)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.
Data Availability
We thank the authors of [14] for providing their implementation to us. We emailed Dominic Deuber and Bernardo Magri and obtained the source code for their scheme named “Redactable Blockchain in the Permissionless Setting.” [14] We then extended and improved the source code to implement our scheme. We cannot expose the source code of the scheme in [14] without the permission of its authors.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
We thank the authors of [14] for providing their implementation to us. This work was supported by the National Natural Science Foundation of China (Grant nos. U1536205, 61472084, 61972094, and 62032005), National Key Research and Development Program of China (Grant no. 2017YFB0802000), Shanghai Innovation Action Project (Grant no. 16DZ1100200), Shanghai Science and Technology Development Funds (Grant no. 16JC1400801), Shandong Provincial Key Research and Development Program of China (Grant nos. 2017CXGC0701 and 2018CXGC0701), and the Young Talent Promotion Project of Fujian Science and Technology Association.