Privacy-Preserving Redactable Blockchain for Internet of Things

In the traditional blockchain system, data is public and cannot be redacted. With the development of blockchain technology, the problem that the data cannot be altered will be more serious once it is written on the chain. Recently, some redactable blockchain schemes have been proposed. However, most of the schemes are based on the public blockchain, and the users’ identities and transaction data may be disclosed. To solve the problem of privacy disclosure, we propose a privacy-preserving transaction-level redactable blockchain. In the proposed scheme, symmetric encryption and ring signature are used to protect transaction data and the users’ identities, respectively. In order to prove the legality of data redaction, the transaction sender can reveal the invalid users’ identities and transaction data in an anonymous environment. To construct a transaction-level redactable blockchain, the users only need to replace a single transaction to complete the data redaction instead of replacing the entire block. &e experimental results show that the proposed scheme saves 20% of the redaction time compared to the previous privacy-preserving blockchains, so the redaction efficiency is higher.


Introduction
In January 2009, blockchain was invented as the underlying technology of Bitcoin [1], which merged the important achievements in some fields such as modern cryptography and distributed network. After the emergence of Bitcoin, the blockchain network has supported massive transfer transactions steadily in a purely distributed manner [2]. Especially, the combinations of blockchain technology and the Internet of things (IoT) begin to appear in large numbers, which proves that the blockchain is a good solution to the basic needs of distributed networks [3,4]. For example, the blockchain is used to ensure the safety and anticounterfeiting traceability of the food supply chain [5].
With the wide application of blockchain technology in E-government, military, and medical fields [6][7][8], the problem that the data cannot be altered will be more serious.
e continuous growth of data in the blockchain leads to a dramatical increase in storage space and data verification cost, which will result in the continuous decline of the number of the full-nodes and intensify the trend of centralization in blockchain. Moreover, the computational overhead for the nodes to verify historical data will also increase, which is unfriendly to some IoT devices with limited computing resource [9]. erefore, redacting or deleting the useless data will be an important means to improve the performance and scalability of the blockchain.
Recently, some redactable blockchains have been proposed [10,11]. However, the users' identities and transactions are public. Even if the IoT devices simply apply pseudonyms when acting in the blockchain, they can only provide limited identity privacy. e adversary can still trace the transparent block data to find out the relations between the identities and transactions and analyze the real identities of the users [12]. Moreover, in the process of data redaction, the personal information of the redactors may be revealed. Due to the wide applications of IoT devices, the data owners do not want to leak the identity privacy or business secrets to their competitors. erefore, it is extremely important to propose a privacy-preserving redactable blockchain to simultaneously protect the privacy of the users and rectify the incorrect data.

Privacy-Preserving
Blockchain. An important feature of blockchain is data transparency, which means that the identity and transaction data in public blockchain are transparent. However, for some companies or users, data is extremely important to maintain their strong competitiveness, and sharing data may bring some security challenges.
erefore, more and more privacy-preserving mechanisms on blockchain have been proposed by researchers. At present, the most popular solutions to protect the identity privacy are ring signature [13], mixing services [14], and noninteractive zero-knowledge proof [15], and the most common methods to protect the data privacy include zeroknowledge proof, homomorphic encryption, and commitment schemes [16].

Redactable Blockchain.
In [10], the concept of redactable blockchain is first raised. e main idea of their protocol was to keep the block hash link compatible with the current state when a redaction happens. ey use a special hash function called chameleon hash [17] to replace the traditional collision-resistant hash function, where collisions of the hash can be computed with trapdoors. us, a collision can be calculated to keep the hash linked as usual. In this work, the authors improve the chameleon hash protocol and solve the key exposure problem in the previous chameleon hash and also provide the formal security analysis of their new protocol. However, in this scheme, a trusted-party is needed to control the trapdoor of chameleon hash, which violates the idea of decentralization of the blockchain, and the redaction operation does not represent the opinions of the whole system. Moreover, this scheme can only realize data redaction at the block-level. Once a data is redacted, the whole block needs to be replaced.
Later, Deuber et al. proposed a history dependent redactable scheme [11], which is dependent on the history of the transaction data. ey propose a redactable protocol in the permissionless setting, which can be integrated to Bitcoin easily. e scheme preserves the original transaction merkle root to keep the hash linked if a block is altered. In their scheme, complex cryptographic tools or trusted parties are not used, and the experiment proves that their scheme is an efficient and feasible protocol. However, in this scheme, consensus-based voting is used during the process of redaction, and this will lead to the privacy disclosure of the redactor. Moreover, this scheme also realizes data redaction at the block-level, but not on the transaction-level. Once a data is redacted, the whole block needs to be replaced.
Most of the redactable blockchains are realized on the block-level, which means that transactions can only be redacted by a block as a unit. Recently, a transaction-level redactable blockchain was proposed [18], where only the hash collision of the redacted transaction should be found.
ey propose a policy-based chameleon hash, which combines the ciphertext-policy attributed based encryption (CP-ABE) algorithm with a chameleon hash scheme. In their scheme, the attributes of a user should satisfy the access structure of the CP-ABE algorithm [18]. e chameleon hash collision can only be found when a user obtains the short-term and the long-term trapdoors at the same time.
However, all of the solutions to blockchain redaction ignore the issue of data privacy disclosure. Recently, a deletable blockchain was proposed \cite{cai2019privacy}, where the identities and transactions of the users are well protected when a block is deleted. In order to delete a block in an anonymous environment, the real identities or the transaction data are disclosed through traceable ring signature or Petersen commitment. Moreover, a linkable multisignature scheme was proposed to prevent the disclosure of the users' identities, which can trace an adversary if he generates a signature more than one time. However, the block can only be deleted by the sender of a transaction but cannot be redacted. us, it is urgent and meaningful to propose a redactable blockchain without disclosing the identities and transaction data of the users.

Our Contributions
(1) We propose a privacy-preserving redactable blockchain protocol without disclosing the identities and transaction data of the users. A threshold ring signature and a symmetric encryption algorithm are separately used to protect the users' identities and transaction data. (2) e proposed blockchain is a fine-grained transaction-level redactable one. e block data can be redacted on the transaction level instead of block level, which means that other transactions in the block do not need to be changed when one transaction is redacted.
(3) We formalize four security requirements for a privacy-preserving redactable blockchain including identity privacy, data privacy, chain quality, and common prefix and prove that our proposed protocol is provably secure based on symmetric encryption and threshold ring signature. (4) e efficiency of the proposed protocol is demonstrated by a series of experiments. e result shows that the time of redacting a transaction is about twice that of creating a block, and the proposed protocol can save about 20% of computational costs than the previous ones.

Preliminaries
Some definitions and algorithms utilized in the proposed protocol are introduced in this section.

An Introduction of Blockchain.
Assume that B j−1 , B j , B j+1 are three adjacent blocks in a blockchain. As shown in Figure 1, the j-th block is denoted as B j � 〈s j , x j , ctr j 〉. e block can point to its previous block through the hash value s j ∈ 0，1 { } k . All of the transactions packaged in a block are contained in x j ∈ 0，1 { } * , and ctr ∈ N is the result of the PoW puzzle [20]. e users check whether the block B j is valid or not by the following inequality: where the parameter D is the target difficulty coefficient of the PoW consensus mechanism. H 1 , A blockchain is composed of a series of blocks, which have solved the PoW puzzle. e newly created block points to its previous block through the hash value. We denote the length of a chain len(C), and the rightmost block of chain C can be denoted as len(C) � 〈x ′ , s ′ , ctr ′ 〉. It should be noted that a blockchain can be an empty chain, which is denoted as C � E.
e chain C will be updated as block B j+1 is generated and validated by the users, and at present, the last block of the chain C ′ is the block B j+1 . For any q ≥ 0, C q is denoted as the chain after deleting the rightmost q blocks. Note that C q can be an empty chain if q is larger than n, where n is the length of a chain C. If the prefix of chain C 1 is C 2 , we write C 1 ≼C 2 .

Redactable Protocol in the Public Blockchain.
In this subsection, we introduce a redactable blockchain protocol [11], which will be used in our paper. e main contribution is that it preserves the old state o j � H 2 (s j , x j ) of a block, which is actually the merkle root of the old transactions. As shown in Figure 2, a block is linked to its predecessor by two links, an old hash link (solid arrow) and a new hash link (dashed arrow), and s j+1 � H 1 (ctr j , H 2 (s j , x j ), o j ) holds [11]. When the block B j is redacted, the new hash link between the block B j and B j+1 is broken (marked by a red cross) because s j+1 ≠ H 1 (ctr j , H 2 (s j , x * j ), o j ). However, B j+1 can still point to B j successfully through the old hash link (solid arrow) since the merkle root of the old transaction (old state) is still preserved. e reason is shown as follows: Please see reference [11] for the details.

reshold Ring Signature.
e following algorithms are commonly included in a (t, n) threshold ring signature (TRS) scheme, where t (0 ≤ t ≤ n) is the value of the threshold, n is the number of the ring members, and t < n [21]: TRS_Setup: on input security parameter λ, it outputs the public keys pk 1 , . . . , pk n and private keys sk 1 , . . . , sk n of n ring members TRS_Sign: on input a message m ∈ 0，1 { } * , a ring containing n members with n public keys pk 1 , . . . , pk n , and private keys sk 1 , . . . , sk n of t members, it outputs a threshold ring signature σ on the message m TRS_Verify: on input a message m, a signature σ and public keys pk 1 , . . . , pk n of n members in a ring, it outputs 0 or 1 to indicate accepting or rejecting the signature

Privacy-Preserving Redactable Blockchain
is section describes a privacy-preserving redactable blockchain protocol Γ ' , which can redact the block data on the transaction-level without disclosing the transaction data and the identities of the users.

Syntax of Privacy-Preserving Redactable Blockchain.
We construct a privacy-preserving redactable blockchain protocol Γ ′ , which contains the following four algorithms:

Our Proposed Protocol.
In the proposed protocol, a regular transaction is denoted as tx � 〈E K (m), RSig〉, where m is the transaction data including the input and output of a transaction, E(·) is a symmetric encryption algorithm, E K (m) is the ciphertext of the transaction data using a key K and RSig is a ring signature to protect the identity privacy of the users. H: e block data is denoted as x � tx 1 , tx 2 , . . . , tx p , where p is the number of the transactions packaged in each block.

Proposing a Redaction Request.
Once a user joins in the blockchain system, he needs to generate a public key as his identity, and a private key, which will be used to generate a signature. If a miner wants to participate in a redaction Transaction data x j+1 Proof of work ctr j+1 Figure 1: Block structure in a blockchain.

Previous hash (s j )
Proof of work (ctr j ) Transaction data (x j *) Security and Communication Networks process, he can apply for the key generation algorithm of the threshold ring signature system to get another key pair when he joins the blockchain system. e key generation algorithm is executed by a trusted party, such as certification authority (CA). It should be noted that the private key generated by the user as the identity is different from that generated by the TRS system, where the former is used to generate the ring signature RSig to protect the identity of the users, and the latter is used to generate the threshold ring signature TRS to allow redacting a transaction in a block. If a user wants to propose a redaction request for the transaction tx i in block B j , he discloses the transaction encryption key K and the encrypted transaction data m first. en, he generates a new transaction m ′ , picks up a new encryption key K ′ , and calculates H(m, K ′ , m ′ , K), , ring signature RSig ′ and a ring signature S on H(m, K ′ , m ′ , K). Next, the user generates an initial can- Finally, the user broadcasts the redaction request r j,i � 〈j, i, tx * i , m, K〉 to the whole network. Note that two ring signatures are both generated by the data owner, who randomly chooses two rings including some users on the chain, and compute the signatures by the public keys of these users.

Joining a Redaction
Operation. When a miner in the blockchain receives a redaction request, he invokes Algorithm 1 Γ ′ .validateReq to judge whether the redaction request is valid or not. If the redaction request is valid, he votes for the redaction by putting his vote result in the latest block he mines. If the number of miners who approve of the redaction request exceeds the threshold t of the threshold ring signature, these miners generate a threshold ring signature TRS jointly on the redaction message. Finally, a final candidate transaction tx * * i is generated and broadcasted to the network, where tx * * i � tx * i ‖TRS.

Validating a Redaction Operation.
Everyone can verify whether a final candidate transaction is valid or not by invoking Γ ′ .validateCandTx (Algorithm 2). If the final candidate transaction tx * * i is valid, the user replaces the old transaction tx i in block B j with the final candidate transaction tx * * i in their local chain. e process of redacting a transaction is shown in Figure 3.

Protocol Description
In this subsection, we introduce each algorithm in the proposed protocol in detail. Algorithm  Algorithm 4 describes how to validate a block B in our system. All of the transactions in the block should be checked using some predefined validation rules. In line 2, this algorithm checks whether the block B has solved the PoW puzzle or not. If the block has been redacted before, the old state of B should be checked to judge whether the block has solved the PoW puzzle or not.

Security Analysis
e following contents provide security analysis of our privacy-preserving redactable blockchain protocol Γ ′ . e original public redactable blockchain protocol Γ satisfies two security requirements: chain quality and common prefix. Supposing that the protocol is a secure and reliable system, the proposed protocol Γ ′ also satisfies these two requirements. Most importantly, Γ ′ can protect the users' identities and transaction data simultaneously. e following description will clearly illustrate that the proposed protocol is provably secure based on threshold ring signature, symmetric encryption, and the blockchain protocol proposed in [11].

Identity Privacy.
e subsection states that the users' identities are private in our protocol. Input：Chain C, a final candidate transaction tx * * i , an index j of the block   can guess the users' identities successfully with a probability of more than 1/2, the simulator B can distinguish the identities of the real signers with a probability of more than 1/2, and it contradicts the anonymity of the threshold ring signature. erefore, it is impossible for the adversary A to guess the identities of the signers in a threshold ring signature successfully with a probability of more than 1/2, and the proposed redactable protocol can protect the users' identities effectively.

Data Privacy.
e subsection states that the transaction data in our blockchain system is private.

Theorem 2. e redactable blockchain scheme realizes the privacy of transaction data if the symmetric encryption algorithm is indistinguishable against chosen plaintext attack (IND-CPA) secure.
Proof. e game is executed between an adversary A and a simulator B. Assuming that adversary A can guess the transaction data with a nonnegligible probability in the proposed protocol, the simulator B can distinguish the plaintext with a nonnegligible probability in the symmetric encryption scheme: Input: Chain C � (B 1 , B 2 , . . . , B n ) of length n. Output: 0/1 (1) j: � n; (2) if j � 1 then (3) return vali da teBlock(B 1 ); (4) while j ≥ 2 do (5) Parse B j � 〈s j , x j , ctr j , o j 〉;

Security and Communication Networks
Setup. e simulator sets up the blockchain system and generates a symmetric encryption algorithm E and an encryption key K and then sends the public parameters E to the adversary. e encryption key K is kept secret itself.
Oracle Queries. e adversary simulates the following oracles: Encryption Oracle. e adversary sends the plaintext of transaction data m to the simulator. e simulator returns the corresponding ciphertext tx: � 〈E K (m), RSig〉, where E K (m) is the ciphertext of m by using the symmetric encryption algorithm, and RSig is the ring signature of the simulator on the ciphertext E K (m).

Challenge.
Adversary has never been queried in the Encryption oracles. Next, the simulator B generates the ring signature RSig * on the ciphertext E K b (m b ) and transmits the transaction ciphertext tx * : suming that A can guess the transaction data successfully with a probability of more than 1/2, the simulator B can distinguish the ciphertext of two plaintexts with a probability of more than 1/2, and it contradicts the IND-CPA security of the symmetric encryption schemes. erefore, it is impossible for the adversary A to guess the plaintext of transaction data successfully with a probability of more than 1/2, and the proposed redactable protocol can protect the transaction data effectively.

Chain Quality.
is property points out that the proportion of adversary blocks in a blockchain is limited by the computing capabilities held by the adversaries.

Definition 1.
e property of (μ, ℓ) chain quality is parameterized byμ ∈ R andℓ ∈ N, which states that, for any part of the chain composed by ℓ continuous blocks held by the honest party, the proportion of adversarial blocks is at most μ, where μ is used to evaluate the computing capabilities of the adversaries. Theorem 3. Γ ′ satisfies (μ, ℓ)-chain quality if the public immutable blockchain satisfies (μ, ℓ)-chain quality for any (t, n) threshold ring signature where t/n > μ.
Proof. Proof. Different from the public immutable blockchain, we provide the function of transaction redaction in an anonymous environment. In order to increase the proportion of malicious blocks in the chain and break the chain quality property, adversary A could redact an honest transaction tx i of block B j into a malicious transaction tx * * i . We prove that the probability of replacing an honest transaction with a malicious one by the adversary A is negligible.
Suppose that adversary A proposes an initial candidate transaction tx * i to an honest transaction tx i of block B j . Limited by computing resources, the adversary A can only mine μ ratio of blocks during the phase of threshold ring signature generation. However, the proposed scheme requires that the ratio of redaction supporters to generate the threshold ring signature has to be at least t/n, where t/n > μ.
e adversary A cannot be approved by t honest users and generate a valid (t, n) threshold ring signature TRS. erefore, the adversary A needs to create an "honest looking" initial candidate transaction tx where H is a collision-resistant hash function. Next, the adversary A deceives the honest users, and the honest users ensure the initial candidate transaction tx * i by generating a threshold ring signature TRS. en, the adversary A creates the final candidate transaction tx * * i � tx * i ‖TRS successfully and redacts the chain with the "honest looking" final candidate transaction tx * * i . However, the chance of creating such a transaction tx * i is negligible, since it violates the collision-resistance property of the hash function H. To sum up, the proof of eorem 3 is established.

Common Prefix.
e property of common prefix is parameterized by k ∈ N, which states that if there are two honest users, and they hold two different chains C 1 and C 2 respectively, the number of the far right different blocks of these two chains is at most k. e game is also executed between an adversary A and a simulator B.
Definition 2. For any two different chains C 1 and C 2 held by two honest users U 1 and U 2 respectively, it holds that As shown in (3), C k 1 and C k 2 are denoted as the chain resulting from deleting the k far right blocks of chain C 1 and C 2 .
However, Definition 2 cannot be used directly in our new redactable protocol Γ ′ . Consider that if a redaction request r i,j and the corresponding final candidate transaction tx * * i were approved, an honest user U 1 updates the chain C 1 at time t 1 and he replaces the old transaction tx i with tx * * i in his local chain. However, another honest user U 2 may not update the chain C at time t 1 timely. In this case, C k 1 ⊀C 2 and C k 2 ⊀C 1 , which violates Definition 3. erefore, a new definition was described as follows for the new privacy-preserving redactable protocol Γ ′ . Note that the redacted block is denoted as B * j .
Definition 3. For any two different chains C 1 and C 2 held by two honest users U 1 and U 2 respectively, it holds that (1) C k 1 ≼C 2 and C 2 ≼C 1 (2) For any redacted block B * j ∈ C (l 2 −l 1 )+k 1 and B * j ∉ C k 2 , or block B * j ∈ C (l 2 −l 1 )+k 2

Security and Communication Networks
Theorem 4. Γ ′ satisfies the property of k-editable common prefix if the public immutable blockchain satisfies the property of k-common prefix.
Proof. Proof. Assume that the adversary A proposes a final candidate transaction tx * * i to redact an honest block B j in chain C 2 . e chain C 2 is redacted by an honest user U 1 later. However, the adversary A cannot create another final candidate transaction tx i * * ≠ tx * * i such that H(tx i * * ) � H(tx * * i ) because of the collision-resistance property of hash function H. Since the final candidate transaction tx * * i is accepted by the honest user U 1 , it must be the case that tx * * i contains a valid threshold ring signature TRS and is approved by most of the honest users in the system. To sum up, the proof of eorem 4 is established.

Experiments
Several experiments are executed to test the efficiency of our work. We give the time of block redaction and block generation and compare the efficiency of the proposed protocol with that of the previous ones. We mainly focus on the timeconsuming operations in these protocols, and the most expensive operations for generating and redacting a block are separately solving the PoW puzzle and generating a threshold ring signature.
We conduct our experiments on a computer with a 64bit Win 10 operating system, 8.0 GB RAM and Intel(R) Core(TM) i7-5500 CPU @ 2.4 GHz processor. We use the IntelliJ IDEA 2020 compiler and Java language to implement our programs. e JPBC 2.0.0 library is used to generate elliptic curve groups and pairings. e elliptic curve groups and pairings are used in the threshold ring signature scheme [22]. e AES algorithm is used to encrypt the transaction data.
We test multiple times to get the average values as the final measurement results from each experiment. It should be noted that the number of the consecutive zero of the hash prefixes is defined as the difficulty level. For example, the difficulty level is 5 when the number of consecutive zeros of the hash prefixes is 5.

Time Consumption of Generating a Block and Redacting a
Transaction. We first test the computational overhead for generating a block. As shown in Figure 4, the overhead of generating a block is almost a constant, i.e., 2.894 s and 15.127 s, when the difficulty level is set as 4 and 6, respectively. e reason is that the overheads of generating a block depend on the difficulty of the POW puzzle instead of the percentage of the users participating in the redaction operation. We also test the overheads for redacting a transaction, which is much more important, and the time to redact a transaction actually determines the efficiency of our proposed scheme. As shown in Figure 5, the time consumption increases when the percentage of the users participating in a redaction operation grows, and the time consumption of redacting a transaction is not affected by the difficulty. e reason is that the time of redacting a transaction is mainly determined by the time of generating a (t, n) threshold ring signature, which depends on the value of threshold t.
In Table 1, we give the time of redacting a transaction when the difficulty level is 5 and the percentage of the users participating in the redaction operation is 80%. e experimental results indicate that the average time of generating a block and redacting a transaction is separately 4580 ms and 7088 ms, and the time of redacting a transaction is about twice that of generating a block. erefore, redacting data on a block is efficient in the proposed protocol.
In order to describe the change of the block structure before and after the block is redacted more clearly, the block 23 is used as an example to illustrate what happens when a block is redacted. e original block information from block 22 to block 24 in the current blockchain is shown in Figure 6. Suppose that the second transaction in block 23 needs to be redacted. In order to redact the transaction, the owner of transaction tx 2 discloses the encrypted transaction data and the encryption key as the redacting reasons, and then a new transaction tx * 2 is generated to replace the old transaction tx 2 . Moreover, the POW puzzle of the new block 23 * is solved. e users in the blockchain reached a consensus to   Figure 7.

Efficiency Comparison.
is experiment is intended to compare the efficiency of our proposed redactable protocol with that of [11,19], where a privacy-preserving deletable blockchain and a public redactable blockchain are proposed.
In the following experiments, we generate redactable and deletable chains. e length of these two chains and the number of block modifications are the same in each experiment. As shown in Figure 8, the number of block redactions or deletions ranges from 10 to 40, and the overhead ratio is from 76% to 84%, and thus the average time of a redaction in the proposed protocol is about 80 percent of that in the deletable chains [19]. e reason is that our protocol needs to generate a ring signature only once, and the protocol in [19] needs to generate a traceable ring signature twice. erefore, a transaction redaction is more efficient in the proposed protocol than that of deleting a block in [19].
To compare the efficiency of our work and that of [11], we both generate privacy-preserving redactable and public redactable chains. e length of these two chains and the number of block modifications are kept the same. As shown in Figure 9, the number of redactions ranges from 10 to 40, and the overhead ratio is from 30% to 41%, and thus the average time of redacting a transaction in the proposed protocol is about three times that in the public chains [11]. e reason is that our protocol uses more time-consuming operations, including the threshold ring signature and symmetric encryption in the redacting process to protect identities and data of the users. erefore, the proposed protocol spends more time than the protocol in [11].
Next, we give a time comparison of redaction for these three protocols, and the results are shown in Table 2. We can see that, in the protocol of [19], it takes an average of 8904 ms to delete a block. However, the protocol can only delete the whole block by the data owner, and it cannot redact a single  transaction in the block. In our protocol, it takes an average of 7088 ms to redact a transaction, which is about 79.6% of the time for deleting a block in [19]. In the protocol of [11], it takes an average of 2552 ms to redact a transaction, which is about 36.0% of the time for redacting a transaction in the proposed redactable blockchain. However, the identities of the users and the transaction data are all public in the protocol of [11]. us, the proposed protocol can realize the redaction on the transaction-level, while the identities of the users and transaction data are also private.
Finally, we compare the proposed protocol with those in [11,19], and the results are shown in Table 3. It is concluded that our protocol provides the function of transaction redaction, transaction deletion without disclosing the identities of the users and the transaction data. Although the protocol in [19] realizes the deletion of block data, the transaction redaction is not allowed. In the protocol of [11], transaction redaction is allowed, but the identities of the users and transaction data are public. e proposed protocol constructs a transaction-level redactable blockchain, and the      users only need to replace a single transaction to complete the data redaction instead of replacing the entire block. However, the protocol [11,19] can only achieve block-level redactable blockchain.

Conclusion
In this paper, we propose a privacy-preserving redactable blockchain based on the old state of the block. A symmetric encryption algorithm and a threshold ring signature are separately used to protect the transaction data and the users' identities during the process of redaction. All of the users can check whether a redaction operation is valid or not according to the threshold ring signature and the old link of the redacted block. e experiments' results indicate that the proposed protocol is efficient and effective, and the identities of the users and the transaction data are also private.

Data Availability
All data are included within the article.

Conflicts of Interest
e authors declare that they have no conflicts of interest.