IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL.
17, 2022
Redactable Blockchain From Decentralized
Chameleon Hash Functions
Meng Jia , Jing Chen , Kun He , Ruiying Du, Li Zheng, Mingxi Lai, Donghui Wang , and Fei Liu
Abstract— Blockchain is a technology with decentralization
and immutability features and has been employed for auditing
by many applications. However, immutability sometimes limits
the application of blockchain technology. For example, vulner-
able smart contracts on blockchain cannot be redacted due
to immutability. The existing redactable blockchain solutions
either have a low efficiency or violate the decentralization
feature. Moreover, those solutions lack mechanisms for tracing
redaction history and checking block consistency. In this paper,
we present an efficient redactable blockchain with traceability
in the decentralized setting. Specifically, we propose a decen-
tralized chameleon hash function for redactable blockchain
that every redaction must be approved by multiple blockchain
nodes. We also design a redactable blockchain structure that
maintains all redactions of a block and encodes the redacted
blocks into an RSA accumulator. Then, we propose an efficient
block consistency check protocol based on the RSA accumulator.
Finally, we conduct experiments and compare our scheme with
another decentralized redactable blockchain to demonstrate that
our solution is efficient in practice.
Index Terms— Redactable blockchain, decentralization,
chameleon hash.
I. I NTRODUCTION
T HE blockchain technology introduced by Nakamoto [1]
has been instantiated as decentralized systems like Bit-
coin and Ethereum. Recently, researchers have designed var-
ious applications [2] based on those blockchain systems,
such as identity management [3], [4], smart city [5], and
e-health [6]. All these applications rely on the immutability
of blockchain systems, which means that the transactions
(e.g., identities, sensor data, and health information) stored
in the blocks cannot be tampered with once they reach a
consensus.
However, immutability also raises some problems in prac-
tice. On the one hand, some blockchain systems have encoun-
tered illegal transactions in practice, such as the famous
Manuscript received 18 January 2022; revised 6 May 2022; accepted 10 July
2022. Date of publication 20 July 2022; date of current version 8 August
2022. This work was supported in part by the National Key Research and
Development Program of China under Grant 2021YFB2700200; in part by
the Fundamental Research Funds for the Central Universities under Grant
2042022kf1195 and Grant 2042022kf0046; in part by the National Natural
Science Foundation of China under Grant U1836202, Grant 62076187, and
Grant 62172303; and in part by Huawei Technologies Company Ltd. The
associate editor coordinating the review of this manuscript and approving it
for publication was Prof. Debdeep Mukhopadhyay. (Corresponding authors:
Jing Chen; Kun He.)
Meng Jia, Jing Chen, Kun He, Ruiying Du, Li Zheng, and Mingxi
Lai are with the Key Laboratory of Aerospace Information Secu-
rity and Trusted Computing, Ministry of Education, School of Cyber
Science and Engineering, Wuhan University, Wuhan 430072, China
(e-mail: jiameng@whu.edu.cn; chenjing@whu.edu.cn; hekun@whu.edu.cn;
duraying@126.com; zhengli1998@whu.edu.cn; lmx001@whu.edu.cn).
Donghui Wang and Fei Liu are with Huawei, Beijing 100031, China (e-mail:
wangdonghui124@huawei.com; liufei19@huawei.com).
Digital Object Identifier 10.1109/TIFS.2022.3192716
1556-6021 © 2022 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
2771
“The DAO” attack in Ethereum caused by vulnerable smart
contracts [7], which even lead to a hard fork to eliminate
negative effects. On the other hand, many applications need
a mechanism to redact transactions. For example, identity
certificates stored on the blockchain may be revoked due
to the compromise of certificate authorities [8]. Therefore,
it is necessary to design a redactable blockchain, in which
transactions or blocks storing transactions can be redacted
without affecting other transactions and blocks.
The existing redactable blockchain solutions can be divided
into two categories according to redacting permissions: cen-
tralized and decentralized. In the centralized setting, a trans-
action or a block is redacted by one blockchain node [9].
However, these solutions have the single point of failure
problem, e.g., the blockchain node is compromised or offline.
In the decentralized setting, a transaction or a block is redacted
by many blockchain nodes collaboratively. The existing decen-
tralized solutions adopted either voting mechanisms [10] or
threshold chameleon hash functions [11]. Based on the voting
mechanism, any blockchain node can propose to redact a block
or a transaction and the proposal reaches a consensus after
generating threshold blocks for voting [10]. However, it takes
a long time to vote for the proposal and to check whether a
redaction reaches a consensus by traversing the blocks. Based
on the threshold chameleon hash function, every blockchain
node holds a part of the chameleon hash key and the threshold
blockchain nodes can redact a block collaboratively [11]. It is
efficient to check whether a redaction reaches a consensus by
comparing the chameleon hashes of the redacted block and
the original block.
Unfortunately, existing solutions based on the threshold
chameleon hash functions have three problems. First, those
solutions either leak the private key after a redaction [9]
or rely on a trusted party for chameleon hash key genera-
tion and distribution [11], which violates the decentralization
of blockchain systems. Moreover, they do not consider the
dynamics of blockchain nodes in the blockchain systems.
Second, those solutions cannot provide redaction history for
traceability, which is important for the management of the
data (e.g., certificates) life cycle and the audit of redactions.
Third, they do not consider block consistency, which means
that blockchain nodes may still maintain the original blocks.
A straightforward approach for block consistency is traversing
the blocks and checking the redaction log (e.g., the redaction
request) on-chain. However, it is inefficient especially as the
blockchain is grown.
In this paper, we present an efficient redactable blockchain
in the decentralized setting. Specifically, the blockchain nodes
generate the chameleon hash key collaboratively and update
 2772
the shares regularly to accommodate the new blockchain nodes
and to withdraw the shares from offline nodes. To redact a
block, the threshold blockchain nodes work collaboratively
with the chameleon hash key, record the redaction request
and history, and insert the redacted blocks into an RSA
accumulator. Finally, the blockchain nodes can check whether
a block is redacted with the proofs of the RSA accumulator.
The main contributions are as follows.
• To tackle the trust party problem, we propose a decentral-
ized chameleon hash function where the key is generated
by multiple blockchain nodes collaboratively without any
trusted party. Considering the dynamics of nodes, we fur-
ther extend the decentralized chameleon hash function to
support threshold redacting and proactive updating.
• To solve the traceability problem, we design a new struc-
ture that links the redaction history of one block to form a
redaction chain. Moreover, this design is compatible with
most existing blockchain systems.
• To solve the block consistency problem, we develop
a block consistency check protocol based on the RSA
accumulator, in which whether a block is redacted can
be determined in a constant time by a membership/
non-membership proof.
• We conduct experiments on our redactable blockchain
and compare it with another decentralized solution.
The experimental results demonstrate that our redactable
blockchain is efficient in practice.
This paper is organized as follows. We introduce the sys-
tem model, threat model, and design goals in Section II.
In Section III, we describe some backgrounds and building
blocks. Then, we present our redactable blockchain solution
in Section IV. In Section V and Section VI, we analyze
the security and evaluate the performance of our proposal,
respectively. Finally, we review related work in Section VII
and conclude our work in Section VIII.
II. P ROBLEM S TATEMENT
A. System Model
There are two kinds of entities in our system: blockchain
node and client. Their functions are as follows.
• A blockchain node generates transactions, maintains the
redactable blockchain, and provides services to clients.
Particularly, the full node is a special kind of blockchain
node that generates blocks.
• A client refers to an entity that may not belong to the
blockchain system. The client checks whether a block has
been redacted through blockchain nodes before it uses the
data stored on the blockchain.
We suppose that all blockchain nodes hold public keys of
the full nodes and know their online statuses, and the full
nodes will not be offline during the execution of a protocol.
Moreover, all protocols are executed in a synchronous setting,
where the full nodes can get the data from each other in a short
time. In permissionless blockchain systems, such as Bitcoin,
the full nodes can be determined by enumerating the entities
that have generated blocks. In other words, it is not necessary
to discover all full nodes (which is impossible in realistic
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 17, 2022
permissionless blockchain systems), but to have enough full
nodes in our system so that the compromised full nodes will
not exceed a threshold.
B. Threat Model
From the practical perspective, we assume that the capabil-
ities of an adversary are as follows.
• The adversary can eavesdrop and tamper with messages
between the blockchain nodes in an untrusted network.
• The adversary can control a number of blockchain nodes,
but cannot control more than 51% computing power in
the blockchain system.
• The adversary may compromise full nodes at any time,
but the number of compromised full nodes cannot exceed
the threshold. Moreover, it cannot calculate the random-
ness without the private key of the chameleon hash.
C. Design Goals
We aim to design a redactable blockchain in the decentral-
ized setting that satisfies the following goals.
• Decentralization. Redacting a block must be approved
by the full nodes that exceed a threshold and reach a
consensus in the blockchain system.
• Traceability. The life cycle of all transactions is honestly
recorded in the blockchain and can be efficiently audited.
• Efficiency. The processes of redacting blocks and check-
ing block consistency can be efficiently executed.
III. P RELIMINARIES
A. Blockchain Structure
We describe an abstraction of the structure employed in
the existing blockchain systems, such as Bitcoin, Ethereum,
and Fabric. A blockchain is composed of a number of blocks,
each of which consists of two parts: header and body. The
header consists of two fields (note that we ignore other fields
in this abstraction), prev_hash and m_root, where the
former is the header’s hash value of the preceding block and
the latter is the summary of the corresponding body. The body
consists of a number of transactions. All blocks form a chain
by prev_hash and the index of a block in the chain is called
its height (the height is increased one by one from the genesis
block whose height is 1).
In the existing blockchain systems, prev_hash is com-
puted via a collision-resistant hash function, such as SHA-256,
to ensure that no one can redact the blocks. Moreover, all
transactions in a body constitute a Merkle hash tree and
m_root is the root of that tree to ensure that no one can
redact the transactions.
B. Digital Signature
Let DS = (KeyGen, Sign, Verify) be a digital signature
scheme [12].
• ( pk, sk) ← KeyGen(1λ ). With the input of a security
parameter λ, this algorithm outputs a pair of public and
private keys ( pk, sk).
 JIA et al.: REDACTABLE BLOCKCHAIN FROM DECENTRALIZED CHAMELEON HASH FUNCTIONS
• σ ← Sign(sk, m). With the input of a private key sk and
a message m, this algorithm outputs a signature σ .
• δ ← Verify( pk, m, σ ). With the input of a public key pk
and a message-signature pair (m, σ ), this algorithm out-
puts a bit δ where 0/1 indicates that the message-signature
pair is invalid/valid.
C. RSA Accumulator
RSA accumulator is a data structure that encodes a set
into a short digest and provides efficient membership and
non-membership proofs [13]. We employ parts of the pro-
posed RSA accumulator schemes [13], [14] which supports
efficient membership and non-membership proof update and
consists of eight algorithms ACC = (PPGen, Insert,
GenMem, GenNonMem, CheckMem, CheckNonMem,
UpdateMem, UpdateNonMem) as follows.
• (N, g1 , acc) ← PPGen(1λ ). With the input of a security
parameter λ, this algorithm generates a random modulus
N = p1 q1 of length λ where p1 , q1 , p12−1 , q12−1 are all
primes, a group G1 of quadratic residues modulo N, a set
X λ that denotes the set of all primes in Z2λ−2/2 , and
outputs the random modulus N, a random initial digest
g1 ∈ G1 and a digest acc ← g1 .
• acc  ← Insert(acc, x). With the input of a digest acc and
an element x, this algorithm outputs an updated digest
acc ← accSH(x) mod N, where SH is a special hash
function that maps x into a prime in X λ .
• π ← GenMem(g1 , acc, S, x). With  the input of an
γ ized setting. To solve the trusted party problem, we propose a
initial digest g1 and a digest acc = g1 i=1 SH(x i ) of a set
S = {x 1 , . . . , x γ }, and an element x ∈ S, this algorithm
outputs a membership proof π ← acc1/SH(x).
• π ← GenNonMem(g1 , S, x). With the input of the
initial digest g1 , a set S = {x 1 , . . . , x γ }, and an element
x ∈ / S, this algorithm outputs a non-membership proof
π ← (a = a0 , b = g1−a1 ) ∈ Z2λ−2/2 × G1 , where a0 and
γ
a1 are random integers that satisfy a0 · i=1 SH(x i ) +
a1 · SH(x) = 1.
• δ ← CheckMem(acc, x, π). With the input of a digest
acc of a set S, an element x, and a membership proof π,
this algorithm outputs δ ← 1 to indicate x ∈ S if acc =
π SH(x) and δ ← 0 otherwise.
• δ ← CheckNonMem(g1 , acc, x, π). With the input of
an initial digest g1 and a digest acc of a set S, an element
x, and a non-membership proof π = (a, b), this algorithm
outputs δ ← 1 to indicate x ∈ / S if acca = bSH(x) g1 mod
N and δ ← 0 otherwise.
• π  ← UpdateMem(acc, x, π, x̂). With the input of the
digest acc, an element x, the membership proof π of the
element x, and an element x̂ to be inserted, this algorithm
outputs a new membership proof π  ← π SH(x̂) mod N if
acc ← Insert(acc, x̂) and acc = π SH(x), and π  ← ⊥
otherwise.
• π  ← UpdateNonMem(g1 , acc, x, π, x̂). With the input
of the initial digest g1 , the digest acc, an element x
not in the accumulator, a non-membership proof π =
(a, b) of the element x and an element x̂ = x to be
inserted, this algorithm generates two integers â0 and
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
2773
r0 such that â0 SH(x̂) + r0 SH(x) = 1, and outputs a
new non-membership proof π  ← (â, b̂) if accSH(x̂)â =
b̂SH(x) g1, where â = â0 a mod SH(x), b̂ = accr b mod N
and âSH(x̂) = r SH(x) + a.
To reduce the computational complexity of getting each mem-
bership and non-membership proof from O(γ ) to O(1), the
blockchain nodes can maintain them locally and update them
by UpdateMem and UpdateNonMem after every element
insertion. The correctness and security are proved in [13], [14].
D. Gap Diffie-Hellman
Let G be a cyclic multiplicative group of prime order p
and g is a generator of G. A Diffie-Hellman tuple on G is the
four tuple (g, g x , g y , g x y ), where x, y ∈ Z∗p . We review the
following two problems about the Diffie-Hellman tuple.
• Computational Diffie-Hellman (CDH) problem [15]:
Given (g, g x , g y ), where x, y ∈ Z∗p , to calculate g x y .
• Decisional Diffie-Hellman (DDH) problem [16]: Given
(g, g x , g y , g z ), where x, y, z ∈ Z∗p , to decide whether
gx y = gz .
We say G is a Gap Diffie-Hellman (GDH) group if the
DDH problem can be solved in polynomial time but there is
no polynomial time algorithm to solve the CDH problem with
non-negligible probability [17], [18].
IV. R EDACTABLE B LOCKCHAIN
A. Overview
We aim to design a redactable blockchain in the decentral-
decentralized chameleon hash function in Section IV-B, where
no entity can restore the chameleon hash key. To solve the
traceability and block consistency problems, we present a
redactable blockchain structure in Section IV-C, which links
the redaction history of a block and records the redacted blocks
in an RSA accumulator. Based on the decentralized chameleon
hash function and the redactable blockchain structure, we pro-
pose our redactable blockchain solution in Section IV-D.
Specifically, we design an efficient block consistency check
protocol based on the RSA accumulator.
B. Decentralized Chameleon Hash Function
The existing chameleon hash functions and their variants
are designed for the centralized setting, in which there is
an entity that possesses the private key for redaction [19].
However, in an (especially permissionless) blockchain system,
it is difficult to specify such an entity due to the requirement
of decentralization. To tackle this problem, we develop a
cryptographic primitive, called decentralized chameleon hash
function, that no entity can restore the private key even
with numerous adaptions. We first present the syntax of
decentralized chameleon hash function and then describe an
instantiation.
1) Syntax: We use {outi }ti=1 ← Protocol({i n i }ti=1 ) to
represent a protocol executed by t participants {P1 , . . . , Pt },
where the input and output of Pi are i n i and outi ,
respectively. A decentralized chameleon hash function
DCH = (KeyGen, Hash, ReHash, Adapt, Verify) consists
of the following five protocols and algorithms.
 2774 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 17, 2022
• { pk, ski }ti=1 ← KeyGen({1λ , 1t }ti=1 ). In this key genera-
tion protocol, each participant Pi takes as input a security
parameter λ and the number of participants t, and outputs
a public key pk and a share of the corresponding private
key ski .
• (r, h) ← Hash( pk, m). This hashing algorithm takes as
input a public key pk and a message m, and outputs a
randomness r and a hash h.
• h ← ReHash( pk, (m, r )). This rehashing algorithm
takes as input a public key pk and an original
message-randomness pair (m, r ), and outputs a hash h.
• {r  }ti=1 ← Adapt({sk i , pk, (m, r ), m  }ti=1 ). In this adap-
tation protocol, each participant Pi takes as input its share
ski , a public key pk, a message-randomness pair (m, r ),
and an adapted message m  , and outputs an adapted
randomness r  .
• δ ← Verify( pk, (m, r ), (m  , r  )). This verification algo-
rithm takes as input a public key pk, an original message-
randomness pair (m, r ), and an adaption (m  , r  ), and
outputs a bit δ where 0/1 indicates that the adaption
(m  , r  ) is invalid/valid.
The correctness of decentralized chameleon hash function
requires that for all { pk, ski }ti=1 ← KeyGen({1λ, 1t }ti=1 ),
all m, m  ∈ {0, 1}∗ , all (r, h) ← Hash( pk, m), and
all {r  }ti=1 ← Adapt({ski , pk, (m, r ), m  }ti=1 ), we have
ReHash( pk, (m, r )) = h and Verify( pk, (m, r ),
(m  , r  )) = 1.
2) Instantiation: Let G be a GDH group of prime order
p (depended on the security parameter λ), g is a generator
of G, and ID : {0, 1}∗ → Z∗p , we give an instantiation of
decentralized chameleon hash function based on a traditional
chameleon hash function proposed by Chen et al. [20].
a) Key generation: With the input of a security parameter
λ and the number of participants t, the participant Pi (i ∈
{1, . . . , t}) executes as follows. t −1
• Select a (t − 1)-degree polynomial f i (x) = j
j =0 ai, j x ,
∗
where ai,0 , . . . , ai,t −1 ∈ Z p are random coefficients.
• Send ( f i (ID(P j )), (g f i (ID( P1 )) , . . . , g f i (ID( Pt )) ), g ai,0 ) to
participant P j , where i ∈ {1, . . . , t} \ {i }.
• When receiving ( f j (ID(Pi )), (g f j (ID( P1 )) , . . . , g f j (ID( Pt )) ),
g a j,0 ) from participant P j , check
t whether (g, f j (ID(Pi )),
g f j (ID( Pi )) ) is correct and k=1 g λk · f j (ID( Pk )) = g a j,0
 ID( P j )
holds, where λk = tj =1, j =k ID( P j )−ID( Pk ) .
 t
• Output the public key g ← s
j =1 g a j,0 , where s =
t t
j =1 a j,0 , and the private key si ← j =1 f j (ID(Pi )) =
f (ID(Pi )), where f (x) = tj =1 f j (x).
b) Hashing: With the input of a public key g s and a
message m ∈ {0, 1}∗ , this algorithm first computes u ←
H(g s , m), where H : G × {0, 1}∗ → G is a cryptographic hash
function, and selects a random integer e ∈ Z∗p . Then, it outputs
the randomness r = (g e , g se ) and the hash h ← g e u m .
c) Rehashing: With the input of a public key g s and
an original message-randomness pair (m, r = (g e , g se )), this
algorithm computes u ← H(g s , m) and outputs the hash
h ← ge um .
d) Adaptation: With the input of a share si ,
a public key g s , an original message-randomness pair
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
(m, r = (g e , g se )), and an adapted message m  ∈ {0, 1}∗ , the
participant Pi (i ∈ {1, . . . , t}) executes as follows.
 
• Calculate g e ← g e u m−m , where u ← H(g s , m).

• Calculate ηi ← (g e )λi ·si , where λi =
t ID( P j )
j =1, j  =i ID( P j )−ID( Pi ) , and send ηi to participant
P j , where j ∈ {1, . . . , t} \ {i }.
• When receiving (η1 , . . . , ηi−1 , ηi+1 , . . . , ηt ), calculate
 t
g se ← j =1 η j and output the adapted randomness

r = (g , g ).e  se 
e) Verification: With the input of a public key g s ,
an original message-randomness pair (m, r = (g e , g se )), and
 
an adaption (m  , r  = (g e , g se )), this algorithm computes
 
u ← H(g s , m). Then it outputs 1 if g e u m = g e u m and
 
(g, g s , g e , g se ) is a Diffie-Hellman tuple and 0 otherwise.
C. Redactable Blockchain Structure
To support the traceability of redacted transactions and the
verification of block consistency, we design a new structure for
organizing blocks that contain redactable transactions, which
also changes the fields in the block header, as shown in
Fig. 1. Note that our design is compatible with the blockchain
structure described in Section III-A, which means that most
existing blockchain systems (e.g., Bitcoin and Ethereum) can
be upgraded to be redactable.
1) Block Organization: Instead of replacing the original
transactions or the corresponding blocks when redacting,
we retain all original data for traceability. More specifically,
a replica of a block is generated for redaction, in which
original transactions are replaced with redacted ones. Then,
the original block and the redacted block form a redaction
chain and are placed at the height of the original block in
the blockchain. Each redaction chain can be extended with
a replica of the latest redacted block, which enables the
traceability property.
To limit the influence of redaction, the redacted block
headers should have the same hash value as the original one,
which means that the field prev_hash in the subsequent
blocks do not need to be redacted. To this end, we change the
function that generates prev_hash from the traditional hash,
such as SHA-256 in Bitcoin, to the decentralized chameleon
hash (see Section IV-B). Therefore, a block in the redactable
blockchain points to the preceding block and all redactions of
the preceding block at the same time.
2) Block Header: According to our block organization,
we modify the field prev_hash and extend three new fields
in the block header as follows.
• prev_hash: This field stores the header’s hash value
of the preceding block. The hash value is computed via
the decentralized chameleon hash function. All block
headers at different heights form a chain by this field
as in traditional blockchain systems.
• last_hash: This field stores the header’s hash value
of the block that is redacted to the current block. The
hash value is computed via the hash function for the RSA
accumulator. All block headers at the same height form
a redaction chain by this field.
• acc: This field stores the digest of the RSA accumulator,
which encodes the value on last_hash in all blocks.
 JIA et al.: REDACTABLE BLOCKCHAIN FROM DECENTRALIZED CHAMELEON HASH FUNCTIONS
Fig. 1. Redactable blockchain structure, where m_root represents the Merkle hash root as in traditional blockchain systems. The blocks ➀, ➂, and ➄ are
at the same height and form a redaction chain. The transaction t x1 in the block ➀ is redacted to t x1 in the block ➂ through the redaction request t xreq1
contained in the block ➁ and the redacted block ➀ is also recorded in the block ➁ by computing acc2 = acc1 last_hash 3 . Similarly, the transactions t x2 and
t x3 in the block ➂ are redacted to t x2 and t x3 in the block ➄ through the redaction request t xreq2 contained in the block ➃ and the redacted block ➂ is
recorded in the block ➃ by computing acc4 = acc2 last_hash 5 .
Fig. 2. Deployment of redactable blockchain.
That means we can check whether a block has been
redacted through this field. It is necessary since a block
cannot point to subsequent redactions in our design (we
do not really redact a block for traceability).
• rand: This field stores the randomness used in a
chameleon hash value to ensure that the original block
and all its subsequent redactions can be at the same
height, i.e., they have the same chameleon hash value.
D. Phases in Redactable Blockchain
Now we are ready to present our redactable blockchain
solution, which consists of five phases: initialization, share
update, block generation, block redaction, and consistency
check, as shown in Fig. 2. Considering the dynamics of full
nodes in practice (e.g., the joining and leaving of the full
nodes), we extend the decentralized chameleon hash function
proposed in Section IV-B to support threshold redacting and
proactive updating.
1) Initialization: In this phase, the blockchain nodes ini-
tialize the RSA accumulator and prepare the cryptographic
keys used in the system. Specifically, all nodes generate
public-private key pairs for signing and verifying the trans-
actions as in traditional blockchain systems. Moreover, the
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
2775
full nodes generate the public-private pair of chameleon hash
function collaboratively for redacting the blocks.
a) RSA accumulator initialization: The blockchain nodes
generate the parameters of the RSA accumulator collabo-
ratively by (N, g1 , acc) ← ACC.P PGen(1λ ) and record
(acc, g1, N) in the genesis block. The blockchain nodes use
the methods in [21] and [22] to generate N and g1 in
a decentralized manner respectively, and they maintain the
blockchain only if some full node stores these parameters in
the genesis block.
b) Digital signature key generation: A blockchain
node P generates a pair of public-private keys ( pk DS DS
P , sk P )
λ
by DS.KeyGen(1 ). Then, the blockchain node publishes the
public key pk DS P and keeps the private key sk DS P secret. For
simplicity, we use ID(P) to denote of the identity of the
blockchain node ID( pk DS ∗ ∗
P ), where ID : {0, 1} → Z p is the
function described in Section IV-B.
c) Chameleon hash key generation: Suppose there are n
ordered full nodes, denoted as {P1 , . . . , Pn }. For our purpose,
we can sort n full nodes by the hash values of their identities
and the timestamp of the current block. The chameleon hash
key generation in our redactable blockchain consists of three
steps. First, the first t full nodes execute the key generation
protocol of the decentralized chameleon hash function to
share a secret key. Then, considering that an adversary may
compromise t − 1 full nodes before and in the share update
phase separately, the full nodes adapt the threshold to 2t − 1
(2t −1 > (t −1)+(t −1)) for share update. Third, the secret key
is re-shared among n full nodes to support threshold redacting,
which means that any t  out of n full nodes can redact a block
collaboratively, where t  ≥ t.
Step 1. The full nodes {P1 , . . . , Pt } generate the chameleon
hash keys {g s , si }ti=1 ← DCH.KeyGen({1λ , 1t }ti=1 ), where
t ≤ n2 .
Step 2. Full nodes {P1 , . . . , P2t } execute {F(x,
ID(Pi ))}2ti=1 ← Transform({2t − 1, si }i=1 ) as follows.
t
• Full node Pi selects a (2t − 1)-degree polynomial
 −1
Fi (ID(Pi ), y) = si + 2tj =1 bi, j y j , where i ∈ {1, . . . , t}
∗
and bi,1 , . . . , bi,2t −1 ∈ Z p .
 2776 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 17, 2022

• Full node Pi sends (Fi (ID(Pi ), ID(P j )), (g Fi (ID( Pi ), Algorithm 1 Block Generation
ID( P1 )) , . . . , g Fi (ID( Pi ),ID( P2t )) ), g si )) to full node P ,
j 1: procedure G EN R EQ (B, t x, g s , g)
where i ∈ {1, . . . , t} and j ∈ {1, . . . , 2t} \ {i }. 2: header , r  , acc ← GetHR(B)
• When receiving (F j (ID(P j ), ID(Pi )), (g F j (ID( P j ), 3: pr ev_hash ← DCH.ReHash(g s , (header  − r  , r  ))
ID( P1 )) , . . . , g F j (ID( P j ),ID( P2t )) ), g s j )) from full node P ,
j 4: if DH(g, g s , r  ) then
full node Pi checks the correctness by a similar way 5: for i tem in t x do
in the key generation protocol of the decentralized 6: if RedactTx(i tem) then
chameleon hash function in Section IV-B. 7: last_hash  ← GetSH(i tem)
• Full node Pi outputs a (t − 1)-degree polynomial 8: acc ← ACC.Insert(acc , last_hash  )
F(x, ID(Pi )) with t shares (F1 (ID(P1 ), ID(Pi )),. . . , 9: end if
Ft (ID(Pt ), ID(Pi ))), where i ∈ {1, . . . , 2t}. 10: end for
Step 3. Full nodes {P1 , . . . , Pn } execute {F(ID(Pi ), 11: acc ← acc
y)}ni=1 ← HandOut(F(x, ID(Pi ))}2t i=1 ) as follows. m_r oot ← MHT(t x)
 F ID( P1 ),
12:
 $
• Full node Pi sends
 F(ID(P j ), ID(P i )), g 13: e ← Z∗p
ID( Pi )   r ← (g e , g se )
,. . . , g F (ID( Pn ),ID( Pi )) , g F (0,ID( Pi )) ) to full node 14:

P j , where i ∈ {1, . . . , 2t} and j ∈ {1, . . . , n} \ {i }.
• When receiving (F(ID(P j ), ID(Pi )), (g F (ID( P1 ),
ID( Pi )) ,. . . , g F (ID( Pn ),ID( Pi )) ), g F (0,ID( Pi )) ))
from full
node P j , full node Pi checks the correctness by a similar
way in the key generation protocol of the decentralized
chameleon hash function in Section IV-B.
• Full node Pi outputs a (2t − 1)-degree polynomial
F(ID(Pi ), y) with 2t shares (F(ID(Pi ), ID(P1 )), . . . ,
F(ID(Pi ), ID(P2t ))), where i ∈ {1, . . . , n}.
2) Share Update: The full nodes may join or leave the
blockchain network and an adversary may steal more than
t shares over time to restore the private key s. Therefore,
the full nodes need to proactive the shares regularly [23].
We describe the process of adapting (t, n) to (t  , n  ) (t  ≥ t

and t  ≤ n2 ), where t  and n  are the new threshold and
number of total full nodes, respectively. This process requires
the participation of all full nodes, denoted as {P1 , . . . , Pn }.
Suppose t full nodes (P1 , . . . , Pt ) that hold the shares
F(ID(P1 ), y), . . . , F(ID(Pt ), y) from the previous period and
2t  −t active full nodes (Pt +1 , . . . , P2t  ) that generate the latest
blocks are selected to update shares.
Step 1. Full nodes {P1 , . . . , P2t  } execute {F  (x,
 
ID(Pi )}2t i=1 } ← Zero(F(ID(Pi ), y), t − 1}i=1 ) as follows.
t
• Full nodes {P1 , . . . , P2t  } execute the similar steps

{F(x, ID(Pi ))}2t i=1 ← HandOut(F(ID(Pi ), y)}ti=1 ),
 
{R(ID(Pi ), y)}i=1 ← Transform({t  − 1, 0}2t
2t
i=1 ) and

{R(x, ID(Pi )}2t i=1 ← HandOut({R(ID(Pi ), y)}i=1 ) to
2t
chameleon hash key generation in Section IV-D.1, where
R(x, y) is a random (t  − 1, 2t  − 1)-degrees polynomial
of R(0, 0) = 0.
• Full node Pi outputs a (2t  − 1)-degree polynomial
F  (x, ID(Pi )) = F(x, ID(Pi )) + R(x, ID(Pi )) where i ∈
{1, . . . , 2t  }.
Step 2. Full nodes {P1 , . . . , Pn } execute the similar
 
step {F  (ID(Pi ), y)}ni=1 ← HandOut({F(x, ID(Pi )}2t i=1 to
step 3 in chameleon hash key generation in Section IV-D.1.
The private key shares are updated from F(x, y) to
F  (x, y) = F(x, y) + R(x, y) of degree (t  − 1, 2t  − 1) and
F  (0, 0) = F(0, 0) = s.
3) Block Generation: Any blockchain node can generate
a transaction and sign it with DS.Sign. Then, it broadcasts
the transaction to all full nodes. We suppose that the latest
15: header ← Con( pr ev_hash, ⊥, m_r oot, acc, r )
16: return (header, t x)
17: end if
18: return ⊥
19: end procedure
block on-chain is the block B of height height − 1. Then,
a full node P packages valid transactions t x and performs the
Algorithm 1 to generate the original block of height height
with the structure described in Section IV-C.
First, the full node P gets the block header header , and the
 
fields rand r  = (g e , g se ) and acc acc from the block B
(Line 2). Next, the full node P calculates the chameleon
hash pr ev_hash of the block (Line 3) and checks whether
 
(g, g s , g e , g se ) is a Diffie-Hellman tuple (Line 4). Then, the
full node checks whether the transactions t x contain valid
redaction requests, and inserts the last_hash  in the valid
redaction requests into acc (Line 5-9). Then, it generates
the Merkle hash root m_r oot of transactions (Line 10) and
calculates the randomness r = (g e , g se ) with a random number
e (Line 11-12). Finally, the full node P follows the consensus
to complete the block header (Line 13) and returns the block
(header, t x) of height height (Line 14).
After generating the block, every blockchain node
updates the RSA accumulator acc locally with
ACC.UpdateMem() and ACC.UpdateNonMem() for
membership/non-membership proofs.
4) Block Redaction: The full nodes can redact transactions
in the blocks that are not redacted, but they can only redact
a block at one time. When a full node P needs to redact
transactions t x in a block B of height height, it first checks
whether B is redacted with the RSA accumulator acc locally.
If the block B is not redacted, the full node P performs the
protocol shown in Fig. 3 to redact it.
First, the full node P and the blockchain nodes generate new
transactions t x  = (t x 1 , . . . , t x γ ) to replace transactions t x =
(t x 1 , . . . , t x γ ) addressed by addrt x = (addrt x1 , . . . , addrt xγ )
in the block B. Then, the full node P checks the signatures
of (t x i , t x i ) (i ∈ {1, . . . , γ }) by DS.Verify to ensure that
the transactions are generated by the same blockchain node
or t x i is signed by the full node P (Step ➀). Then, the full

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
 JIA et al.: REDACTABLE BLOCKCHAIN FROM DECENTRALIZED CHAMELEON HASH FUNCTIONS
Fig. 3. Block redaction protocol.
Algorithm 2 Redaction Request Generation
1: procedure G EN R EQ (height, addrt x , t x  , B)
2: m_r oot, header ← Upd(B, addrt x , t x  )
3: last_hash  ← SH(header )
4: r eq ← (height, last_hash  , addrt x , t x  , m_r oot)
5: return r eq
6: end procedure
node P performs Algorithm 2 to generate the redaction request
(Step ➁). Specifically, the full node P replaces the transactions
addressed by addrt x with new transactions t x  in the block B,
and generates the new Merkle hash root m_r oot  (Line 2).
Then, it calculates the hash last_hash  of the redacted block
header header = ( pr ev_hash, last_hash, m_r oot, acc, r )
(Line 3). Finally, the full node P generates and returns the
redaction request r eq = (last_hash  , addrt x , t x  , m_r oot  )
(Line 4-5).
Then, the full node P sends the redaction request r eq to
other full nodes {P1 , . . . , Pn }\{P}. After receiving the request
r eq, the full nodes {P1 , . . . , Pn } locate block B by last_hash 
and perform the same way as P to check whether B has been
redacted. Then, they verify the γ pairs of transactions (t x i , t x i )
(i ∈ {1, . . . , γ }). If the full nodes {P1 , . . . , Pt  } agree with the
redaction r eq, they return (ID(P1 ), . . . , ID(Pt  )) to P, where
t  ≥ t and t is the threshold of the private key (Step ➂). Then,
the t  +1 full nodes {P, P1 , . . . , Pt  } calculate the new random-
 
ness r  = (g e , g se ) with DCH.Adapt({si , g s , ((header0 −
t +1
r0 ), r0 ), ( pr ev_hash, last_hash  , m_r oot  , acc)}i=1 ), where
header0 and r0 are the block header and randomness of the
original block of height height, and {s1 , . . . , st  +1 } are shares
of {P, P1 , . . . , Pt  } (Step ➃-➆).
Finally, the full node P generates the hashes hash t x  =
(H(t x 1 ), . . . , H(t x γ )) and packages data = (addrt x , hash t x  ,
m_r oot  , last_hash  , r  ) into a transaction t xreq (Step ➇), and
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
2777
Fig. 4. Consistency check protocol.
broadcasts it in the blockchain network (Step ➈). The request
data is valid as long as 1 ← DCH.Verify(g s , (header −
r, r ), (( pr ev_hash, last_hash  , m_r oot  , acc), r  )). Then, the
full node packages the transaction t xreq in a block as shown
in Section IV-D.3. After t xreq is on-chain, all blockchain
nodes redact the block header header to header  ←
( pr ev_hash, last_hash  , m_r oot  , acc, r  ) (Step ➉).
5) Consistency Check: Redactions result in different blocks
at the same block height, the clients need to check whether
a block B has been redacted when they check the validity of
the block from the blockchain nodes.
As shown in Fig. 4, the client sends the query
(height, hash B ) to a blockchain node, where hash B =
H(header ) is the hash of the block header header (Step ➀).
Then, the blockchain node locates the block B and the
proof locally with the query. If the block has been
redacted, the blockchain node gets the membership proof
(hash B , π) locally or calculates it by π ← ACC.GenMem
(g1 , acc, S, hash B ), and acc is the digest of all redacted
blocks S. Otherwise, the blockchain node gets the
non-membership proof (hash B , π = (a, b)) with the similar
way. Then, it returns the block B and the proof to the client
(Step ➁). After receiving the block and the membership/non-
membership proof, the client first checks the transactions and
the integrity of the block (Step ➂). If it is valid, the client
can check the consistency of the block by ACC.CheckMem
(acc, hash B , π) or ACC.CheckNonMem(g1 , acc, hash B ,
(a, b)) locally or check it with the help of a blockchain node
(Step ➃-➆).
To reduce the computational complexity on the client side,
the client first generates a random prime number l ← {0, 1}len
(len ∈ Z∗p ) and sends (l, hash B ) to the blockchain node P
(Step ➃). The blockchain node P calculates (e1 , Q 1 ) and
returns them to the client if the block has been redacted, where
SH(hash B ) = l · q1 + e1 and Q 1 = π q1 . If the block has
not been redacted, the blockchain node calculates (e1 , e2 ) and
(Q 1 , Q 2 ) and returns them to the client, where SH(hash B ) =
l·q1 +e1 , a = l·q2 +e2 and Q 1 = b q1 , Q 2 = accq2 (Step ➄-➅).
Finally, the client checks whether Q l2 · acce2 = Q l1 · be1 g1
(Step ➆). If the membership proof is correct, the block has
been redacted. If the non-membership proof is correct, the
block has not been redacted.
 2778
V. S ECURITY A NALYSIS
We examine our redactable blockchain with respect to the
design goals in Section II through the following theorems.
Theorem 1 (Decentralization): Under the threat model in
Section II-B, redacting a block must be approved by the full
nodes that exceed a threshold and reach a consensus in the
blockchain system, if the underlying chameleon hash function
is collision-resistant.
Proof: (sketch) Redacting a block needs to calculate the
new message-randomness pair with the private key s. There-
fore, the decentralization of our redactable blockchain relies
on the proposed decentralized chameleon hash function.
To calculate the randomness of the chameleon hash,
an entity uses either the existing adaptions or the private
key. For the former case, the security of our decentral-
ized chameleon hash function is reduced to the underlying
chameleon hash function. Specifically, the existing adaptions
 
are a number of g e ·s , where g e consists of a hash of a
message. As no entity can find the hash collisions of the
message m, the existing adaptions are useless to forgery the
randomness.
For the latter case, in the steady state, the private  −1 keyi
s is encoded into a polynomial F(x, 0) = s + ti=1 ai x
of degree t − 1, and n blockchain nodes hold shares
((ID(P1 ), F(ID(P1 ), 0)), . . . , (ID(Pn ), F(ID(Pn ), 0))) of the
polynomial F(x, 0). According to Lagrange’s interpolation
theorem, it needs more than t − 1 shares to restore the private
key s. Therefore, the adversary cannot restore the private
key as it only gets at most t − 1 shares. In the process of
updating the private key, a blockchain node can get at most
two polynomials F(i, y) of degree 2t −1 and F(x, i ) of degree
t −1 at the same time. The blockchain node cannot restore the
private key as it only holds one share of (t, n) and one share
of (2t, n) threshold secret shares, respectively. Moreover, the
adversary can get t − 1 shares of the old polynomial F(x, 0)
and t −1 shares of the updated polynomial F  (x, 0). However,
it still cannot restore the private key which is the same as in
the steady state.
In conclusion, redacting a block must be approved by the
full nodes that exceed a threshold and reach a consensus in
the blockchain system.
Theorem 2 (Traceability): Under the threat model in
Section II-B, the life cycle of all transactions is honestly
recorded in the blockchain and can be efficiently audited, if the
hash functions are collision-resistant.
Proof: (sketch) Note that all block headers at the same
height form a redaction chain by the field last_hash, which
is calculated by the hash function SH in the RSA accumulator,
and all transactions are summarized in the header by the
field m_root, which is calculated by the hash function in
the Merkle hash tree. Since the hash functions are collision-
resistant, these fields ensure that the life cycle of all trans-
actions is honestly recorded. Moreover, all transactions can
be efficiently audited with proofs of RSA accumulator and
Merkle hash tree.
VI. E VALUATION
We develop a proof of concept implementation in Python
(version 3.6.9) to evaluate our solution. Blockchain nodes
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 17, 2022
Fig. 5. Time of Proof-of-Work consensus (calculating the nonce) with
different targets and numbers of blocks in Bitcoin and our solution.
and clients are deployed on a server with Intel Xeon
Gold 5218 CPU @2.30GHz and 32GB DDR4, and Ubuntu
18.04 64bit operating system. To evaluate the efficiency of
our solution, we conduct experiments and compare it with
RB-ABE [24] and RBPS [10] in terms of block generation
(Section VI-A), redaction (Section VI-B) and consistency
check (Section VI-C). Furthermore, to evaluate whether the
RSA accumulator will affect the efficiency as the redactable
blockchain is extended, we conduct experiments to evaluate
the performance of the RSA accumulator. We repeat the
experiments 1000 times and record the average value to reduce
the experimental errors.
A. Efficiency of Block Generation
Our solution has replaced the inner hash function in the
Proof-of-Work blockchain with a chameleon hash function
that is mostly exponentiation operations. To provide a relevant
difficulty value in the redactable blockchain based on the
Proof-of-Work, we conduct experiments to study the time of
block generation in Bitcoin (the same for RBPS [10]) and our
solution.
In Bitcoin, block generation consists of calculating the
Merkle root and the previous hash, and Proof-of-Work based
on the hash function. In our solution, it consists of calcu-
lating the Merkle root and the previous chameleon hash,
updating the RSA accumulator, and Proof-of-Work based
on the chameleon hash function. The time of updating the
RSA accumulator (insertion) is shown in Section VI-D.1,
and the time is negligible because of the limited number
of insertions in a block and the batching techniques [13].
We further adjust the targets (difficulty equals target in the
genesis block divided by the current target) and numbers of
blocks and compare the time of Proof-of-Work in Bitcoin and
our solution. As shown in Fig. 5, the time of calculating the
nonce increases with the number of blocks and decreases of
targets. Our solution consumes more time than Bitcoin with
the same targets because Proof-of-Work in our solution is
mostly exponentiation operations that are less efficient than
hash operations in Bitcoin.
Therefore, our solution can set a larger target to improve
the efficiency of block generation in the redactable blockchain
based on Proof-of-Work.
B. Efficiency of Block Redaction
To evaluate the efficiency of block redaction, we con-
duct experiments to study the time of block redaction in
 JIA et al.: REDACTABLE BLOCKCHAIN FROM DECENTRALIZED CHAMELEON HASH FUNCTIONS
Fig. 6. Time of adaption and verification for redacting a transaction with
different numbers of attributes in RB-ABE [24].
Fig. 7. Time for proposing and voting when redacting a block with different
thresholds in RBPS [10].
Fig. 8. Time of an adaption and verifying the adaption with different
thresholds in our solution.
RB-ABE [24], RBPS [10] and our solution. Particularly,
we ignore the network latency.
In RB-ABE, the time consists of adapting the randomness
and verifying the adaption, we adjust the number of attributes
to evaluate the respective time. As shown in Fig. 6, the time
of adaption increases with the number of attributes, and the
time of verification remains stable. According to our analysis,
the verification only checks the chameleon hash, which means
anyone who holds the attributes can redact the corresponding
transactions and cannot achieve accountability.
In RBPS, a blockchain node proposes a redaction request,
and the other blockchain nodes vote for it in the next several
blocks. We adjust the number of blocks for voting and record
the time for appending the proposal and votes on-chain.
As shown in Fig. 7, the time of proposing and voting increases
with the number of blocks. The time for voting may be even
more in practice as the interval for blocks can be several
seconds (e.g., 14s in Ethereum) or minutes (e.g., 10min in
Bitcoin), while it is less than 0.01s in our proof of concept
implementation.
In our solution, the time consists of an adaption for a
part of the new randomness, a combination for the threshold
parts, proposing a redaction request, and verification for the
chameleon hash of the adaptions. For the adaption, combina-
tion and verification, we adjust the thresholds of full nodes
and test the respective time. As shown in Fig. 8, the time
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
2779
Fig. 9. Time of checking whether a block is redacted with different number
of blocks behind the original block in RBPS [10].
Fig. 10. Time of checking the membership/non-membership proofs with
different numbers of redacted blocks in our solution.
for adaption and combination increases with the threshold,
and adaption consumes the most time because of the massive
calculation for Lagrangian coefficients. Moreover, the time of
verifying a block remains stable when the threshold increases,
which means the thresholds do not affect the consensus
efficiency of the redaction on-chain. The time of proposing
a redaction request equals the latency of a block, and it is less
than 0.01s in our proof of concept implementation.
Compared with our solution, the centralized RB-ABE con-
sumes less time, but ours is in the decentralized setting, and
the decentralized RBPS consumes much more time than our
solution.
C. Efficiency of Consistency Check
RB-ABE needs not consistency check as they redact trans-
actions locally and do not reach a consensus on the redactions
in the network. We conduct experiments to study the time of
consistency check in RBPS and our solution.
In RBPS, it consists of checking the redaction request
and votes for the request. The blockchain node traverses the
blocks after the original block for the request and the votes.
We adjust the number of blocks where the request and votes
lie after the original block and record the time for the check.
As shown in Fig. 9, the time of checking the consistency of a
block increases with the number of blocks, which means the
efficiency of the consistency check decreases as the blockchain
is grown. Moreover, if a block has not been redacted, the
blockchain nodes need to traverse all blocks after the original
block to confirm it.
In our solution, there are two kinds of proofs and the
blockchain nodes maintain them locally. The membership
proofs are for redacted blocks, and the non-membership proofs
are for blocks that have not been redacted. We fix the length
of a block header’s hash in the RSA accumulator to 256 bits.
For the redacted blocks, we adjust the number of elements
 2780
T IME C OMPLEXITY AND T IME (S ECONDS ) OF A LGORITHMS W ITH D IFFERENT N UMBER OF E LEMENTS
Fig. 11. Space cost of membership proof for all elements and each element
with different numbers of elements in the RSA accumulator.
in the RSA accumulator. As shown in Fig. 10, the time of
checking a membership/non-membership proof on the client
side is constant with the number of redacted blocks in the RSA
accumulator, which means that consistency check is efficient
on the client side even with lots of redactions. Moreover, the
time is even smaller with the length of l in Section IV-D.5.
Therefore, the client can set a shorter l to reduce the time of
checking the consistency of a block.
Compared with our solution which is about 10ms for
membership proof and 20ms for non-membership proof, RBPS
consumes much more time for checking the consistency of a
block and it is about 200s for 30k blocks, and RBPS is less
efficient when the blockchain is grown.
D. Performance of RSA Accumulator
We conduct experiments to evaluate the algorithm efficiency
and the space cost of the RSA accumulator.
1) Efficiency: We analyze the time complexity of algorithms
in the RSA accumulator (Section III-C) and conduct experi-
ments to evaluate the efficiency of these algorithms.
As shown in Table. I, the time complexity for gen-
erating membership proof and non-membership proof is
O(n). However, the efficiency keeps stable (O(1)) if the
blockchain nodes maintain the proofs locally and update
them with UpdateMem and UpdateNonMem after each
insertion. Then, we conduct experiments to evaluate the
efficiency of these algorithms. Specifically, we adjust the
number of elements, and test the time for inserting an ele-
ment (Insert), generating (GenMem and GenNonMem),
checking (CheckMem and CheckNonMem), and updating
(UpdateMem and UpdateNonMem) an element’s member-
ship proof and an element’s non-membership proof. As shown
in Table. I, the time for insertion, checking and updating mem-
bership proof and non-membership proof remain stable when
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 17, 2022
TABLE I
Fig. 12. Space cost of different numbers of non-membership proofs with
different numbers of elements in the RSA accumulator.
the number of elements in the RSA accumulator increases,
which means the efficiency of the RSA accumulator will not
decrease when the redacted blocks increase or when the chain
is extended.
2) Space Cost: Considering the space cost, RSA accumula-
tor supports membership proofs and non-membership proofs.
For the membership proofs, we adjust the number of ele-
ments in the RSA accumulator and test the space cost for all
elements and each element. As shown in Fig. 11, the space
for all elements increases with the number of elements in the
RSA accumulator, and the space for each element remains
stable (about 0.97KB) when the number of elements in the
RSA accumulator increases.
For the non-membership proofs, we adjust the number
of elements (the blocks that have been redacted) in the
RSA accumulator and test the space for different num-
bers of non-membership proofs (the blocks that have not
been redacted). As shown in Fig. 12, the space for all
non-membership proofs increases with the number of non-
membership proofs, and the space for each non-membership
proof remains stable (about 0.98KB per proof) when the
number of elements in the RSA accumulator increases.
In conclusion, our solution is much more efficient than
RBPS for block redaction and consistency check in the
decentralized setting, and the redactable blockchain is stable
and the chain extension do not affect the efficiency. More-
over, the blockchain nodes can set a larger target to improve
the efficiency of block generation in our solution based on
Proof-of-Work.
VII. R ELATED W ORK
In 2017, Ateniese et al. [9] proposed the first redactable
blockchain, and subsequent research on the work emerged
endlessly [10], [11], [24]–[31]. According to the redacting
 JIA et al.: REDACTABLE BLOCKCHAIN FROM DECENTRALIZED CHAMELEON HASH FUNCTIONS 2781

TABLE II
T HE C OMPARISON OF R EDACTABLE B LOCKCHAIN

permissions, we divide the related works into two categories:
centralized and decentralized. We have listed 12 solutions, six
of them adopted centralized settings, and the rest including
our solution adopted decentralized settings. For these solu-
tions, we show (i) whether there is a centralized authority,
(ii) who can redact the blockchain, (iii) the key technology,
(iv) whether the committee is dynamic after the initialization
setup, (v) whether it achieves accountability, (vi) whether the
key is used without exposure, (vii) whether the redaction
reaches on-chain consensus, (viii) the time complexity of
consistency check in Table. II.
A. Centralized Setting
In a centralized setting, only one organization or several
blockchain nodes are allowed to redact the blocks or transac-
tions in the blockchain.
To redact a blockchain, Ateniese et al. [9] introduced the
chameleon hash into the blockchain and only one central-
ized organization that holds the private key can redact the
blocks. To alleviate the single point of failure for redaction,
Dousti and Küpçü [25] proposed that several authorities can
redact the blockchain. To achieve flexible permissions con-
trol, Derler et al. [24] proposed the ciphertext-policy attribute-
based chameleon hash function, the attribute authority issues
the attribute private keys to the blockchain nodes. When
the blockchain node uploads the redactable transactions,
it encrypts the ephemeral trapdoor with access structure, and
the private keys with corresponding attributes can redact the
transactions. Moreover, the consensus is performed locally,
which means that every blockchain node holds different data.
One attribute authority may cause the single point of failure
problem, and Zhang et al. [26] introduced multiple attribute
authorities to issue the attribute private keys to the blockchain
nodes. However, the CP-ABE scheme cannot achieve account-
ability, Tian et al. [29] and Chen et al. [20] adopted and fur-
ther extended the ciphertext-policy attribute-based chameleon
hash function with accountability or modification times.
The centralized setting is efficient in practice, and it is
suitable for some situations where an authority needs to
manage or control the blockchain. However, the centralized
solution has a single point of failure problem, if the authority
is compromised, the blockchain may be controlled by the
adversary. Moreover, existing systems based on permissionless
blockchain such as the digital currency are decentralized and
cannot be controlled by an authority. Moreover, the client can-
not know whether the transaction is redacted unless it traverses
the entire blockchain, which is costly for the blockchain nodes.
B. Decentralized Setting
In a decentralized setting, any blockchain node can request
to redact the blocks and the malicious redaction can be filtered
by multiparty consensus. According to the key technology,
the decentralized solutions can be divided into two categories:
consensus on voting ( [10]) and chameleon hash-based ([9],
[11], [30], [31] and ours).
1) Consensus Voting Mechanism: Deuber et al. [10] intro-
duced the voting mechanism. A blockchain node gener-
ates a redaction request for a block or a transaction, and
other blockchain nodes vote for the redaction by storing
the hash of the redaction request in the generated blocks
(e.g, 1024 blocks). Therefore, it takes a long time to vote
and check the validation of a redaction, as they need to be

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
 2782 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 17, 2022
confirmed by traversing the transactions for the redaction log,
and the efficiency will decrease as the number of transactions
increases.
2) Chameleon Hash Function: Huang et al. [30] and
Wu et al. [31] adopted (n, n) adopted threshold scheme
based on ring signature and lattice in the chameleon hash
respectively. Each redaction must be approved by the pre-
defined n blockchain nodes, and any blockchain node that
is offline makes the redaction fail. Zhang et al. [11] adopted
(t, n) threshold chameleon hash algorithm to modify the
transactions. However, the key generation algorithm requires
a trusted dealer, which means that the dealer holds the whole
private key. Ateniese et al. [9] proposed that the pre-defined
blockchain nodes generate the chameleon hash private key
collaboratively. When a blockchain node needs to redact a
block, it collects the threshold shares and restore the private
key to redact the block. However, the key may be exposed,
which means that anyone can redact the blocks once the private
key is restored.
The comparison is shown in Table. II. Each chameleon
hash-based solution except ours has some of the following
drawbacks: (i) the key generation relies on a centralized party,
(ii) the committee holding the chameleon hash key is settled
in the setup phase and does not consider the dynamic nature
of nodes joining/leaving the network, (iii) the key is exposed
with several redactions, (iv) the scheme does not consider
the consistency check problem. Our solution has settled all
the problems of the chameleon hash based solutions, and our
solution is more efficient than RBPS [10] as we have shown
in the Section VI-B and VI-C.
VIII. C ONCLUSION
To solve the problems of traceability and block consis-
tency in the redactable blockchain, we propose a redactable
blockchain in the decentralized setting. Our solution is based
on a decentralized chameleon hash function and an efficient
consistency check protocol based on the RSA accumulators.
The security analysis and experimental results show that our
proposal provides efficient redaction and block consistency
check in practice.
R EFERENCES
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Decen-
tralized Bus. Rev., p. 21260, 2008.
[2] A. Imteaj, M. H. Amini, and P. M. Pardalos, Foundations of Blockchain:
Theory and Applications. Springer, 2021.
[3] J. Chen, S. Yao, Q. Yuan, K. He, S. Ji, and R. Du, “CertChain:
Public and efficient certificate audit based on blockchain for TLS
connections,” in Proc. IEEE Conf. Comput. Commun. (INFOCOM),
Apr. 2018, pp. 2060–2068.
[4] M. Y. Kubilay, M. S. Kiraz, and H. A. Mantar, “CertLedger: A new
PKI model with certificate transparency based on blockchain,” Comput.
Secur., vol. 85, pp. 333–352, Aug. 2019.
[5] C. Cai, Y. Zheng, Y. Du, Z. Qin, and C. Wang, “Towards private,
robust, and verifiable crowdsensing systems via public blockchains,”
IEEE Trans. Dependable Secure Comput., vol. 18, no. 4, pp. 1893–1907,
Aug. 2021.
[6] G. S. Aujla and A. Jindal, “A decoupled blockchain approach for
edge-envisioned IoT-based healthcare monitoring,” IEEE J. Sel. Areas
Commun., vol. 39, no. 2, pp. 491–499, Feb. 2021.
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
[7] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks on ethereum
smart contracts (SoK),” in Proc. Eur. Joint Conf. Theory Pract. Softw.
(POST), 2017, pp. 164–186.
[8] M. Jia et al., “PROCESS: Privacy-preserving on-chain certificate sta-
tus service,” in Proc. IEEE Conf. Comput. Commun. (INFOCOM),
May 2021, pp. 1–10.
[9] G. Ateniese, B. Magri, D. Venturi, and E. R. Andrade, “Redactable
blockchain–or–rewriting history in bitcoin and friends,” in Proc. IEEE
Eur. Symp. Secur. Privacy (EuroS&P), Apr. 2017, pp. 111–126.
[10] D. Deuber, B. Magri, and S. A. K. Thyagarajan, “Redactable blockchain
in the permissionless setting,” in Proc. IEEE Symp. Secur. Privacy (SP),
May 2019, pp. 124–138.
[11] J. Zhang et al., “Serving at the edge: A redactable blockchain with fixed
storage,” in Proc. Web Inf. Syst. Appl. (WISA), 2020, pp. 654–667.
[12] K. Gjøsteen and T. Jager, “Practical and tightly-secure digital signatures
and authenticated key exchange,” in Proc. Annu. Int. Cryptol. Conf.
(CRYPTO), 2018, pp. 95–125.
[13] D. Boneh, B. Bünz, and B. Fisch, “Batching techniques for accumulators
with applications to IOPs and stateless blockchains,” in Proc. Annu. Int.
Cryptol. Conf. (CRYPTO), 2019, pp. 561–586.
[14] J. Li, N. Li, and R. Xue, “Universal accumulators with efficient non-
membership proofs,” in Proc. Appl. Cryptography Netw. Secur. (ACNS),
2007, pp. 253–269.
[15] A. Joux and K. Nguyen, “Separating decision Diffie–Hellman from
computational Diffie–Hellman in cryptographic groups,” J. Cryptol.,
vol. 16, no. 4, pp. 239–247, Sep. 2003.
[16] D. Boneh, “The decision Diffie–Hellman problem,” in Proc. Algorithmic
Number Theory, 3rd Int. Symp. (ANTS), 1998, pp. 48–63.
[17] T. Okamoto and D. Pointcheval, “The gap-problems: A new class of
problems for the security of cryptographic schemes,” in Proc. Int.
Workshop Public Key Cryptography (PKC), 2001, pp. 104–118.
[18] W. Castryck, J. Sotáková, and F. Vercauteren, “Breaking the decisional
Diffie–Hellman problem for class group actions using genus theory,” in
Proc. Annu. Int. Cryptol. Conf. (CRYPTO), 2020, pp. 92–120.
[19] J. Camenisch, D. Derler, S. Krenn, H. C. Pöhls, K. Samelin, and
D. and Slamanig, “Chameleon-hashes with ephemeral trapdoors and
applications to invisible sanitizable signatures,” in Proc. Public-Key
Cryptography (PKC), 2017, pp. 152–182.
[20] X. Chen, F. Zhang, H. Tian, B. Wei, and K. Kim, “Discrete logarithm
based chameleon hashing and signatures without key exposure,” Comput.
Elect. Eng., vol. 37, no. 4, pp. 614–623, 2011.
[21] D. Boneh and M. Franklin, “Efficient generation of shared RSA keys,”
J. ACM, vol. 48, no. 4, pp. 702–722, Jul. 2001.
[22] E. K. Kogias, D. Malkhi, and A. Spiegelman, “Asynchronous distributed
key generation for computationally-secure randomness, consensus, and
threshold signatures,” in Proc. ACM SIGSAC Conf. Comput. Commun.
Secur., Oct. 2020, pp. 1751–1767.
[23] S. K. D. Maram et al., “CHURP: Dynamic-committee proactive secret
sharing,” in Proc. ACM SIGSAC Conf. Comput. Commun. Secur.,
Nov. 2019, pp. 2369–2386.
[24] D. Derler, K. Samelin, D. Slamanig, and C. Striecks, “Fine-grained and
controlled rewriting in blockchains: Chameleon-hashing gone attribute-
based,” in Proc. Netw. Distrib. Syst. Secur. Symp., 2019, pp. 1–51.
[25] M. S. Dousti and A. Küpçü, “Moderated redactable blockchains: A
definitional framework with an efficient construct,” in Proc. Data
Privacy Manage., Cryptocurrencies Blockchain Technol. (DPM/CBT),
2020, pp. 355–373.
[26] Z. Zhang, T. Li, Z. Wang, and J. Liu, “Redactable transactions in
consortium blockchain: Controlled by multi-authority CP-ABE,” in
Proc. Inf. Secur. Privacy (ACISP), 2021, pp. 408–429.
[27] Y. Jia, S.-F. Sun, Y. Zhang, Z. Liu, and D. Gu, “Redactable blockchain
supporting supervision and self-management,” in Proc. ACM Asia Conf.
Comput. Commun. Secur., May 2021, pp. 844–858.
[28] S. Xu, J. Ning, J. Ma, X. Huang, and R. H. Deng, “K-time modifiable
and epoch-based redactable blockchain,” IEEE Trans. Inf. Forensics
Security, vol. 16, pp. 4507–4520, 2021.
[29] Y. Tian, N. Li, Y. Li, P. Szalachowski, and J. Zhou, “Policy-based
chameleon hash for blockchain rewriting with black-box account-
ability,” in Proc. Annu. Comput. Secur. Appl. Conf. (ACSAC), 2020,
pp. 813–828.
[30] K. Huang et al., “Building redactable consortium blockchain for indus-
trial Internet-of-Things,” IEEE Trans. Ind. Informat., vol. 15, no. 6,
pp. 3670–3679, Jun. 2019.
[31] C. Wu, L. Ke, and Y. Du, “Quantum resistant key-exposure free
chameleon hash and applications in redactable blockchain,” Inf. Sci.,
vol. 548, pp. 438–449, Feb. 2021.
 JIA et al.: REDACTABLE BLOCKCHAIN FROM DECENTRALIZED CHAMELEON HASH FUNCTIONS
Meng Jia received the B.S. degree in computer
science and technology from Wuhan University,
Wuhan, China, in 2018, where she is currently pur-
suing the Ph.D. degree with the School of Cyber Sci-
ence and Engineering. Her research interests include
blockchain and applied cryptography.
Jing Chen received the Ph.D. degree in computer
science from the Huazhong University of Science
and Technology, Wuhan. He has been working as a
Full Professor with Wuhan University since 2015.
He has published more than 100 research papers in
many international journals and conferences, such
as IEEE T RANSACTIONS ON D EPENDABLE AND
S ECURE C OMPUTING, IEEE T RANSACTIONS ON
I NFORMATION F ORENSICS AND S ECURITY, IEEE
T RANSACTIONS ON M OBILE C OMPUTING, IEEE
T RANSACTIONS ON C OMPUTERS , IEEE T RANS -
ACTIONS ON PARALLEL AND D ISTRIBUTED S YSTEMS , USENIX Security,
CCS, and INFOCOM. His research interests in computer science are in the
areas of network security and cloud security. He acts as a Reviewer for many
journals and conferences, such as IEEE T RANSACTIONS ON I NFORMATION
F ORENSICS AND S ECURITY, IEEE T RANSACTIONS ON C OMPUTERS , and
IEEE/ACM T RANSACTIONS ON N ETWORKING.
Kun He received the Ph.D. degree in computer sci-
ence from the Computer School, Wuhan University.
He is currently an Associate Professor with Wuhan
University. He has published more than 20 research
papers in many international journals and confer-
ences, such as IEEE T RANSACTIONS ON C OMPUT-
ERS , IEEE T RANSACTIONS ON D EPENDABLE AND
S ECURE C OMPUTING, IEEE T RANSACTIONS ON
M OBILE C OMPUTING, IEEE T RANSACTIONS ON
PARALLEL AND D ISTRIBUTED S YSTEMS , USENIX
Security, CCS, and INFOCOM. His research inter-
ests include cryptography, network security, mobile computing, and cloud
computing.
Ruiying Du received the B.S., M.S., and
Ph.D. degrees in computer science from Wuhan
University, Wuhan, China, in 1987, 1994, and
2008, respectively. She is currently a Professor
at the School of Cyber Science and Engineering,
Wuhan University. She has published more than
80 research papers in many international journals
and conferences, such as IEEE T RANSACTIONS
ON PARALLEL AND D ISTRIBUTED S YSTEMS ,
International Journal of Distributed and Parallel
Systems, INFOCOM, SECON, TrustCom, and NSS.
Her research interests include network security, wireless networks, cloud
computing, and mobile computing.
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on January 18,2024 at 19:45:25 UTC from IEEE Xplore. Restrictions apply.
2783
Li Zheng received the B.S. degree in computer
science and technology from Wuhan University,
Wuhan, China, in 2020, where he is currently pursu-
ing the Ph.D. degree with the School of Cyber Sci-
ence and Engineering. His research interests include
blockchain and applied cryptography.
Mingxi Lai received the B.S. degree in computer
science and technology from Hunan University,
Hunan, China, in 2020. He is currently pursuing the
M.S. degree with the School of Cyber Science and
Engineering, Wuhan University, Wuhan, China. His
research interest includes blockchain.
Donghui Wang received the master’s degree in com-
puter science from Jilin University. She is currently
a Senior Engineer with Huawei Technologies Com-
pany Ltd. She has more than ten years’ experience in
research, security, analysis, and system design under
various security projects. Her current research inter-
ests include blockchain, telecom network security,
and privacy protection.
Fei Liu received the master’s degree in computer
science from Shandong Industry University. She
is currently a Distinguished Engineer at Huawei
International Private Ltd. She has over 17 years’
experience of research and design in telecommuni-
cation, mobile services, terminals, and cyber security
through 2G to 5G. She is working on 6G end-
to-end security policy and technologies, including
trust model, security framework and architecture,
AAA, and AI for security.