A Verifiable and Redactable Blockchain with Lightweight Storage and Permission Supervision

Abstract

As a promising decentralized paradigm, the verifiable and redactable blockchain offers a feasible solution for achieving authorized and controlled redaction of on-chain data. However, existing schemes suffer from rapidly expanding ledgers caused by authentication data structures and fail to strike a balance between permission supervision and redaction efficiency. In this paper, we propose a novel verifiable and redactable blockchain scheme that introduces a dual-level authentication architecture to achieve lightweight storage and permission supervision. To this end, we first design a dual-level authentication data structure that appends all blocks to a constant-size global tag, while supporting verifiable redaction and query over on-chain data. Likewise, we introduce a dual-level chameleon hash structure, which not only employs committee members holding sub-keys to redact on-chain data but also enables the certificate authority to use the master key to correct malicious redactions executed by corrupted committee members. Furthermore, we propose an efficient auditing protocol to enhance the integrity and consistency of the blockchain ledger during the process of synchronous circulation. Finally, both security analysis and performance evaluation prove that the proposed scheme is practical.

1. Introduction

Benefiting from various advantageous features, such as decentralization and immutability, the blockchain [1,2,3] provides a feasible solution for various trust issues in complex data service scenarios, such as digital currency, supply chain [4,5] management, insurance [6], public key infrastructure (PKI) systems [7,8], and energy systems. Among these characteristics, the immutability derived from the underlying cryptographic tools and data structure enables that the data cannot be modified once it has been recorded on the blockchain, thus ensuring the security and ledger consistency of the blockchain.

However, immutability is a double-edged sword, that is, it also brings a series of challenges and limitations for blockchain. First of all, malicious users may upload illegal or improper information to the blockchain [9,10], thereby polluting the blockchain environment. In addition, malicious attackers may exploit unmodifiable on-chain security vulnerabilities to launch attacks for reaping illicit profits, which will lead to massive financial losses for victims. Finally, increasingly sophisticated laws and regulations [11] have imposed higher security requirements for data circulation, such as “The right to be forgotten”, while the immutability conflicts with these requirements and cannot support legal implementation, thereby restricting the development of blockchain.

To this end, Ateniese et al. [12] proposed the concept of redactable blockchain, which adopts a chameleon hash function [13] to reconstruct the hash-chain structure of blockchain, thus enabling the regulator holding the trapdoor key to redact the on-chain data without changing the block hash value. Furthermore, they also provide a variant for public blockchain (i.e., permissionless setting) by employing the top 7 mining pools as participants and utilizing multi-party computation and secret sharing to achieve on-chain data modification without a central authority. Inspired by this, there is a series of related works was proposed, including access control [14,15,16,17,18], traceability [19,20,21,22,23], and self-management [24]. However, all of them cannot support the revocation of old data items, which incurs the issue of coexistence of multiple versions, meaning that a malicious full node may synchronize different ledger versions to other users, and  thus severely compromise the consistency of the blockchain ledger.

Fortunately, Tian et al. [25] proposed a verifiable redactable blockchain (VRBC) architecture, which introduces an authentication data structure to achieve verifiable redaction and query. Likewise, Shen et al. [26] proposed a verifiable and redactable blockchain with full redaction capabilities, achieving complete editability of block objects and verifiability of the blockchain state. Despite this, these schemes lead to a rapidly expanding ledger caused by the underlying authentication data structure. In this setting, the additional storage overhead will increase linearly with the size of the blockchain (i.e., block number). Moreover, the unbounded growth of the chain increases verification costs, severely degrading system performance, particularly under high transaction volumes.

1.1. Related Work

As shown in

Table 1. Comparisons of Redactable Blockchain.

Schemes	Setting	Authorization	Redactor	Verification	Query	Auditing	Supervision
AMVA17 [12]	Permissioned/less	CA/Committee	CA/Committee	×	×	×	×
PDS17 [27]	Permissioned	CA	CA	×	×	×	×
DMT19 [28]	Permissionless	N/A	All miners	×	×	×	×
DSSS19 [14]	Permissioned/less	CA/Users	Authorized users	×	×	×	×
PVN21 [19]	Permissioned	CA	Authorized users	×	×	×	🗸
MXNH22 [15]	Permissioned	Multi-CA	Authorized users	×	×	×	×
XNMX21 [20]	Permissioned	CA	Authorized users	×	×	×	🗸
JSZ21 [24]	Permissioned	CA	CA + All users	×	×	×	🗸
LZCX22 [21]	Permissioned	CA	Authorized users	×	×	×	🗸
TWKS22 [25]	Permissioned/less	CA/Committee	CA + Committee	🗸	🗸	🗸	×
SCLS23 [26]	Permissioned/less	CA/Committee	CA/Committee	🗸	×	×	×
XLXW23 [29]	Permissioned/less	CA/Committee	Authorized users	🗸	×	×	×
WDW25 [30]	Permissioned	CA	Authorized users	×	×	×	🗸
YCLT25 [31]	Permissioned	Committee	Committee + users	🗸	×	×	×
WPDW25 [32]	Permissioned/less	Committee	Committee + users	🗸	×	×	×
Our scheme	Permissioned/less	CA/Committee	CA + Committee	🗸	🗸	🗸	🗸

, Ateniese et al. [12] proposed the first redactable blockchain, which relies on one or more fixed authorities to execute the modification of on-chain data. For efficient permission distribution, Derler et al. [14] proposed a fine-grained and controlled-rewriting redactable blockchain, which adopts policy-based chameleon hashes (PCHs), to realize fine-grained control. To address the vulnerabilities of a single-authority model, Ma et al. [15] introduced the decentralized policy-based chameleon hash (DPCH). In their scheme, redaction permissions are distributed among multiple authorities, thus achieving fine-grained control in a decentralized setting. Afterward, Qin et al. [16] proposed the traceable decentralized policy-based chameleon hash to enhance security, enabling redactable blockchains with features of both decentralized privilege management and modifier accountability. For improving the efficiency of PCH, Yusoff et al. [18] proposed an efficient policy-based chameleon hash framework, which not only improves overall performance but also provides security against chosen-ciphertext attacks.

There is no doubt that permission management must be carried out simultaneously with permission distribution; otherwise, the problem of permission abuse will arise. Currently, there are mainly three research directions attempting to manage modification permissions in editable blockchains: limiting the number of modifications, designing supervision models, and establishing traceback accountability. Regarding the number of modifications, Xu et al. [20] proposed a redactable blockchain called KERB, which supports a limited number of modifications and adopts a cycle-based redaction framework with a monetary penalty mechanism. Similarly, Li et al. [21] proposed a redactable blockchain scheme (CCE-RB), which achieves regulation by limiting the number of times a user can perform redacts and enabling the revocation of their redaction permissions. In addition, Duan et al. [22] introduced novel t-time chameleon hash (t-CH) and signature (t-CS) schemes, where the trapdoor is exposed after exceeding t collisions, and used them to construct a controlled redactable blockchain protocol that supports a limited number of edits with a transparent setup. With regard to permission supervision, Jia et al. [24] introduced the Stateful Chameleon Hash with Revocable Subkey (sCHRS) as the core of a redactable blockchain scheme, which supports self-supervision and self-governance to prevent redactors from abusing their permissions. However, their approach of allowing users to freely modify their own data is impractical. This is because a malicious user could launch a denial-of-service (DoS) attack against the supervisory authority. Such behavior would not only create a heavy workload for the regulator but also severely compromise the consistency of the blockchain ledger. Focusing on traceback accountability, Panwar et al. [19] utilized a dynamic group signature scheme to construct an editable blockchain that is both revocable and traceable.

Nevertheless, while the aforementioned schemes effectively address the challenges of permission distribution and supervision, they generally overlook the management of historical data items following a redaction. Specifically, these approaches lack a mechanism to explicitly revoke outdated data items, inevitably leading to the coexistence of multiple versions on the chain, thereby compromising the consistency of the blockchain ledger.

To address this issue, Tian et al. [25] put forward a verifiable and redactable blockchain scheme supporting efficient querying and integrity auditing, which mitigates the resource waste and security risks caused by ledger inconsistencies. Shen et al. [26] proposed a verifiable redactable blockchain that supports full edit operations, including block appending, insertion, modification, and deletion. The scheme employs incentives to ensure the timely revision of block edits and invalidates historical versions by verifying the blockchain state. Xu et al. [29] introduced an efficient Merkle tree-based dynamic update verification mechanism, which enables rapid version checking and enforced update modifications. In 2025, Yang et al. [31] proposed a secure and efficient decentralized chameleon hash scheme based on Schnorr threshold signatures (CHSTs) to allow for collaborative data redaction by edge nodes. Furthermore, to  ensure ledger consistency, they designed a separate modification verification mechanism based on vector commitments. Wang et al. [32] proposed a resilient and redactable blockchain (RRB) that supports both transaction-level and block-level data modifications on-chain. By  employing an accumulator-based version detection mechanism, the RRB enables effective revocation of outdated data versions.

Although the aforementioned schemes effectively resolve the verifiability issue in redactable blockchains, they typically rely on heavy authentication data structures. In a distributed ledger setting, this dependence inevitably results in additional storage consumption. Such ledger expansion is particularly unfriendly to lightweight nodes, imposing high computational costs and storage burdens on clients. Therefore, it is considered of great significance to investigate a lightweight verifiable redactable blockchain.

1.2. Our Contribution

In this paper, we propose a verifiable and redactable blockchain with lightweight storage and permission supervision, including the following three contributions:

• We propose a novel blockchain architecture with a dual-level chameleon hashing structure for effective supervision, which enables the regulator holding the trapdoor key of inner hashing to redact the on-chain data, while allowing the certificate authority holding the outer hash trapdoor key to correct the malicious redaction executed by compromised regulators.
• We propose a dual-level authentication data structure for our dual-level redactable blockchain, in which all blocks are appended to a constant-size global tag, thus achieving lightweight storage while enabling verifiable data queries and updates over on-chain data.
• We propose an on-chain data auditing protocol, which allows blockchain nodes to verify the integrity and validity of the blockchain ledger before synchronizing it, thereby enhancing the security and ledger consistency of the blockchain system.

2. Preliminaries

2.1. Strong RSA Assumption

Definition 1

(Strong RSA Assumption). Given a security parameter λ, there is a product N of two distinct odd primes p and q, of λ/2-bit. And given a randomly sampled member $y\in {\mathbb{Z}}_N^{*}$, it is considered computationally infeasible to find a pair $(x,e)$ such that the equation $x^e\equiv y(modN)$ holds. The constraint for this problem is that $e>1$ can be any positive integer.

Lemma 1

(Shamir’s Trick [33]). Given $x,y\in {\mathbb{Z}}_N$ together with $a,b\in \mathbb{Z}$ such that $x^a=y^b(modN)$ and $gcd(a,b)=1$, there is an efficient algorithm for computing $z\in {\mathbb{Z}}_N$ such that $z^a=y(modN)$. Let $\alpha ,\beta \in \mathbb{Z}$ be integers such that $\alpha a+\beta b=1$. Then, $z=y^{\alpha }{x}^{\beta }$ is the desired number as $z^a=y^{\alpha a}{x}^{\beta a}=y^{\alpha a}{y}^{\beta b}=y^{\alpha a+\beta b}=y(modN)$.

2.2. Chameleon Hash Functions

For better security, Chen et al proposed a double-trapdoor chameleon hash function with efficient trapdoor collision and key exposure resistance. The concrete construction $\mathcal{CH}$$= (\mathsf{Setup}$$, \mathsf{KeyGen}$$, \mathsf{CH}$$, \mathsf{Col},$$\mathsf{Verify})$ [34] including five PPT algorithms, as follows.

• $\mathsf{Setup}\left(1^{\lambda }\right)\to \left(pp\right)$: On input security parameters $1^{\lambda }$, this algorithm outputs public parameters $pp$.
• $\mathsf{KeyGen}\left(pp\right)\to (TK,HK):$ On input public parameters $pp$, this algorithm outputs hash key ($TK$, $HK$).
• $\mathsf{CH}(m,HK)\to (h,r,Y)$: On input m and public hash key $HK$, this algorithm outputs a hash value h and verification string ($r,Y$).
• $\mathsf{Col}(TK,m^{\prime },m,r)\to (Y^{\prime },r^{\prime })$: On input a new data $m^{\prime }$ and an old m, a secret trapdoor key $TK$, outputs a collision $(m^{\prime },Y^{\prime },r^{\prime })$ for $(m,Y,r)$.
• $\mathsf{Verify}(m_{,}h,HK,Y,r)\to 0/1$: On input a data m, h, public hash key $HK$, and $(r,Y)$, this procedure outputs 1 if h is valid. Otherwise, it outputs 0.

2.3. Retrievable Homomorphic Verifiable Tags

To achieve optimal storage, Tian et al. [35] proposed the Retrievable Homomorphic Verifiable Tags. The concrete construction $\mathcal{RHVT}=(\mathsf{Setup}, \mathsf{KeyGen}, \mathsf{TagGen}, \mathsf{TagVerify}, \mathsf{Tag}\mathsf{Agg}, \mathsf{Ta}\mathsf{gAux}, \mathsf{TagRet}, \mathsf{AggTagUpdate})$ is an algorithm tuple containing eight polynomial-time algorithms, as follows:

• $\mathsf{Setup}\left(1^{\lambda }\right)\to \left(pp\right)$: Input the security parameter $1^{\lambda }$, then output a set of public parameters $pp$.
• $\mathsf{KeyGen}\left(1^{\lambda }\right)\to (vk,sk)$: On input a security parameter $\left(1^{\lambda }\right)$, the key generation algorithm outputs a public verification key $vk$ and a secret key $sk$.
• $\mathsf{TagGen}(sk,m)\to \sigma$: The tag generation algorithm takes as input $\mathsf{sk}$ and data item m, outputs an $\mathcal{RHVT}$ tag $\sigma$.
• $\mathsf{TagVerify}(vk,\sigma ,m)\to 0/1$: The tag verification algorithm takes as input $\sigma ,m$ and $vk$, outputs 1 if $\sigma$ is valid on m, and 0 otherwise.
• $\mathsf{TagAgg}$($vk,\sigma ,m,{\sigma }^{*})\to {{\sigma }^{*}}^{\prime }$. On input $(\sigma ,m)$ and an aggregated tag ${\sigma }^{*}$ $\left(\mathrm{with}\mathrm{initial}\right.$ $\left.\mathrm{state}1\right)$, if $\sigma$ is valid, the aggregation algorithm outputs a new aggregated tag ${{\sigma }^{*}}^{\prime }.$
• $\mathsf{TagAux}\left(vk,{\left\{m_i\right\}}_{iϵ[\ell ]},sϵ[\ell ]\right)\to {\mathsf{aux}}_{\mathsf{s}}$: The local auxiliary algorithm takes as input ${\left\{m_i\right\}}_{iϵ[\ell ]}$ and $sϵ[\ell ]$, outputs auxiliary information ${\mathsf{aux}}_{\mathsf{s}}$ for $m_s$, which will be used to retrieve its original tag ${\sigma }_s$ from ${\sigma }^{*}$.
• $\mathsf{TagRet}(vk,{\sigma }^{*},{\mathsf{aux}}_{\mathsf{s}},sϵ[\ell ])\to {\sigma }_s$: The tag retrieval algorithm takes as input ${\sigma }^{*}$, ${\mathsf{aux}}_{\mathsf{s}}$, $sϵ[\ell ]$ and the tag retrieval algorithm outputs the original $\mathcal{RHVT}$ tag of the s-th data item $m_s$.
• $\mathsf{AggTagUpdate}(vk,{\sigma }_i,{\sigma }^{*},{\sigma }_i^{\prime })\to {\sigma }^{\prime *}$: On input $vk$, ${\sigma }^{*}$, the tag ${\sigma }_i$, and a new tag ${\sigma }_i^{\prime }$, the aggregated tag update algorithm outputs a new aggregated tag ${\sigma }^{\prime *}$.

3. Problem Statement

This section presents the system architecture and the definitions of our proposed scheme.

3.1. System Architecture

There are five entities in our model:

• Certificate Authority (CA): A fully trusted entity in charge of system initialization and binding each block to a fixed-size tag. Meanwhile, it can deprive the redaction permission of a malicious regulator.
• Blockchain Miner (BM): The full nodes that can append new blocks to the blockchain ledger only when they win in the current consensus process, and all of them will maintain the entire ledger.
• Verifier/Auditor (VA): A light node (LN) that can query and verify on-chain data, or check the integrity of the blockchain ledger, and make requests for changes when necessary.
• Prover/Auditee (PA): A full node holds the entire blockchain ledger and is responsible for providing verifiable data query or ledger synchronization services.
• Redactor (R): A dynamic committee of elected members who serve in rotation as the regulator for each cycle, redacting on-chain data according to user requests. Their actions are supervised by the CA, which is responsible for correcting errors and revoking permissions in response to malicious behavior.

3.2. Definitions

Inspired by [24,35], we give the definition of our scheme based on a tag construction $\mathcal{RHVT}$ = $(\mathsf{Setup}$, $\mathsf{KeyGen}$, $\mathsf{TagGen}$, $\mathsf{TagVer}$$\mathsf{ify}$, $\mathsf{TagAgg}$, $\mathsf{TagAux}$, $\mathsf{TagRet}$, $\mathsf{AggTagUpdate})$ and the chameleon hash $\mathcal{CH}$ = $(\mathsf{Setup}$, $\mathsf{KeyGen}$, $\mathsf{CH}$, $\mathsf{Col}$, $\mathsf{Verify})$.

• As shown in Figure 1, a redactable blockchain consists of a sequence of blocks $B_i$ = $(h_{i-1}$, $r_{2,i}$, $r_{1,i}$, $Y_{1,i}$, $Y_{2,i}$, $sp{k}_I$, $m_i$, $h_{2,i}$, $h_{1,i},ct{r}_i,h_i)$, in which $h_{2,i}$, $h_{1,i},$$Y_{1,i},Y_{2,i},$ $sp{k}_I\in \mathbb{G}$, $r_{2,i}$, $r_{1,i}$, $h_{i-1}\in {\mathbb{Z}}_P^{*}$, $m_i\in {\{0,1\}}^{\lambda }$ and $ct{r}_i\in \mathbb{N}$. For each new block $B_i$, the miner adopts the Merkle root $m_i$ computed over the transactions $\{T_1,\dots ,T_X\}$ to generate inner hash value $h_{2,i}$ and outer hash value $h_{1,i}$ for the new block $B_i$. Finally, generate the block hash value $h_i$.

  $$\begin{array}{cc}\hfill & h_{2,i}=\mathsf{CH}(r_{2,i},Y_{2,i},m_i)\hfill \\ \hfill & h_{1,i}=\mathsf{CH}(r_{1,i},Y_{1,i},h_{2,i},sp{k}_I,h_{i-1})\hfill \\ \hfill & h_i=\mathsf{H}(h_{1,i},ct{r}_i)\hfill \end{array}$$

  where $h_{i-1}$ is the hash of the previous block and $r_{1,i},r_{2,i},Y_{1,i},Y_{2,i}$ is the validation string in $\mathcal{CH}$, and $ct{r}_i$ is the Nonce value of the block $B_i$, $sp{k}_I$ is the public key of cycle I, $h_i$ is the hash of the block $B_i$.

Based on the dual-level hash blockchain architecture, we further introduce the formalized definition for the proposed scheme, including ($\mathbf{Setup}$, $\mathbf{KeyGen}$, $\mathbf{Bind}$, $\mathbf{Redact}$, $\mathbf{Query}$, $\mathbf{Audit}$).

(1).

$\mathbf{Setup}\left(1^{\lambda }\right)\to$ ($pp$): Given security parameter $1^{\lambda }$, this algorithm outputs public parameters $pp$.

(2).

$\mathbf{KeyGen}\left(1^{\lambda }\right)$ → $(pk,sk,mpk,msk,sp{k}_1,ss{k}_1)$: On input $1^{\lambda }$, this algorithm outputs the following keys:

• A secret key $sk$ and a public key $pk$, which can be used to calculate tags by CA.
• An outer public key $mpk$ and an outer secret key $msk$, which are used by CA to calculate the outer hash value.
• A set of inner public key $sp{k}_1$ and a set of inner secret key $ss{k}_1$, which are used by the 1-th $R_1$ to compute the inner hash value.

(3).

$\mathbf{Bind}(pk,sk,mpk,sp{k}_I,m_i,h_{i-1})$ → $(h_{1,i},r_{2,i},r_{1,i},sp{k}_I,$$h_{2,i},Y_{2,i},Y_{1,i},{\sigma }_i,{\sigma }_I^{\prime *},{\delta }_I,{\delta }^{\prime *})$: On input $pk,sk,mpk,sp{k}_I,m_i$ and $h_{i-1}$, the bind algorithm outputs a $\mathsf{CH}$ value $h_{1,i}$ and a new tag cycle $\left({\sigma }_i,{\sigma }_I^{\prime *},{\delta }_I,{\delta }^{\prime *}\right)$:

• $\mathsf{CH}(m_i,sp{k}_I)$ → $(h_{2,i},r_{2,i},Y_{2,i})$: $R_I$ returns a inner hash value $h_{2,i}$ and its check string $(Y_{2,i},r_{2,i})$.
• $\mathsf{CH}(h_{i-1},sp{k}_I,h_{2,i},mpk)$ → $(h_{1,i},r_{1,i},Y_{1,i})$: $R_I$ returns a outer hash value $h_{1,i}$ and its check string $(Y_{1,i},r_{1,i})$.
• $\mathsf{Tagbind}(pk,sk,m_i,{\sigma }_I^{*},{\delta }^{*})$ → $\left({\sigma }_i,{\sigma }_I^{\prime *},{\delta }_I,{\delta }^{\prime *}\right)$. CA runs $\mathsf{TagGen}$ algorithms to generate $\mathcal{RHVT}$ inner layer tag ${\sigma }_i$ and outer layer tag ${\delta }_I$, and runs $\mathsf{TagAgg}$ algorithms to generate $\mathcal{RHVT}$ inner layer aggregated tag ${{\sigma }_I^{*}}^{\prime }$ and outer layer aggregated tag ${{\delta }^{*}}^{\prime }$. We adopted a dual-level authentication data structure. Cycling all blocks, set each k blocks as a cycle. $I=\lceil i/k\rceil$.

(4).

$\mathbf{Redact}$: The interaction protocol can update the validation character and update the inner and outer tags.

• $\mathsf{Col}(msk/ss{k}_I,m_i^{\prime },m_i,sp{k}_I,mpk)\to \left(r^{\prime }\right)$: The CA with $msk$ or the $R_I$ with $ss{k}_I$ runs $\mathsf{Col}$ algorithm to generate the updated verification string $r^{\prime }$. If it is the $R_I$ looking for the collision, $r^{\prime }=(Y_{2,i}^{\prime },r_{2,i}^{\prime })$. If it is the CA looking for the collision, $r^{\prime }=(Y_{1,i}^{\prime },r_{1,i}^{\prime },r_{2,i}^{\prime },h_{2,i}^{\prime })$.
• $\mathsf{TagUpdate}(pk,sk,m_i^{\prime },m_i,{\sigma }_i,{\sigma }_I^{*},{\delta }_I^{*},{\delta }^{*})$ → $({\sigma }_i^{\prime },$${\sigma }_I^{\prime *},$${\delta }_I^{\prime *},$${\delta }^{\prime *})$: CA runs $\mathsf{TagGen}$ algorithms to generate a new $\mathcal{RHVT}$ inner layer tag ${\sigma }_i^{\prime }$ for new $m_i^{\prime }$, and runs $\mathsf{AggTagUpdate}$ algorithms to generate a new inner layer aggregated tag ${\sigma }_I^{\prime *}$. For the outer layer, CA runs $\mathsf{TagGen}$ algorithms to generate a new $\mathcal{RHVT}$ outer layer tag ${\delta }_I^{\prime *}$ for new ${\sigma }_I^{\prime *}$, and runs $\mathsf{AggTagUpdate}$ algorithms to generate a new outer layer aggregated global tag ${\delta }^{\prime *}$.

(5).

$\mathbf{Query}$: Through this protocol, the correctness and validity of on-chain data can be verified, as follows:

• $\mathsf{Chal}\left(pp\right)\to s$: On input $pp$, this algorithm outputs the index s of the queried block.
• $\mathsf{Prove}\left(s\right)\to (m_s,au{x}_s)$: On input s, CA runs $\mathsf{TagAux}$ algorithm to generate the auxiliary information $au{x}_s$, and then outputs $(m_s,au{x}_s)$.
• $\mathsf{Verify}({\delta }^{*},{\sigma }_I^{*},m_s,au{x}_s)\to 0/1$: VA retrieves inner layer tag ${\sigma }_s$ and outer layer tag ${\delta }_I$ from aggregated ${\sigma }_I^{*},{\delta }^{*}$ by running $\mathsf{TagRet}$ algorithm, and then outputs the verification result $\mathsf{TagVerify}$$({\sigma }_s,m_s)\to 0/1$.

(6).

$\mathbf{Audit}$: To verify the integrity of the blockchain ledger, CA and PA perform the following interactive protocol:

• $\mathsf{Chal}\left(pp\right)\to Chal$: On input $pp$, this algorithm outputs a challenge $Chal$.
• $\mathsf{Prove}\left(Chal\right)\to (\pi ,{\left\{au{x}_s\right\}}_{s\in S})$: Upon receiving the challenge $Chal$, CA first identifies the index set S of the challenged data items and then proceeds to generate an integrity proof $\pi$ with the corresponding auxiliary information ${\left\{au{x}_s\right\}}_{s\in S}$.
• $\mathsf{Verify}({\delta }^{*},{\sigma }_I^{*},\pi ,{\left\{au{x}_s\right\}}_{s\in S})\to 0/1$: Upon receiving the input tuple $({\delta }^{*}$, ${\sigma }_I^{*}$, $\pi$, ${\left\{au{x}_s\right\}}_{s\in S})$, the VA runs $\mathsf{TagRet}$ algorithm for each $s\in S$ to retrieve the inner tag ${\sigma }_s$, and then outputs the verification result of $\pi$.

3.3. Threat Model

In this section, we define the threat model for our proposed scheme, consisting of three security goals, as follows.

• $\mathbf{Correctness}$: If the system parameters, the data structure, and the proof are honestly generated by the corresponding algorithms ($\mathsf{Setup}$, $\mathsf{KeyGen}$, $\mathsf{Bind}$, $\mathsf{Redact}$, and $\mathsf{Proof}$ respectively), then during the block query or blockchain auditing phase, the $\mathsf{Verify}$ procedure outputs 1 for any valid challenge $Chal$.
• $\mathbf{Soundness}$: If a prover successfully convinces a VA that the challenged block data is intact and valid in a query or auditing process. It must be true that the prover actually stores that data. Specifically, we define a soundness experiment between a challenger C and a PPT adversary $\mathcal{A}$, which consists of the following phases:

  –

  $Initialization$: The challenger C first generates public parameter $pp$, and sends $(pp,vk)$ to the adversary $\mathcal{A}$;

  –

  $Query$: $\mathcal{A}$ can adaptively make a polynomial number of $\mathsf{TagGen}$ queries to the challenger C. For each query on a data item $m_t$, C correctly generates its corresponding inner layer tag ${\sigma }_t$, and faithfully updates the entire hierarchy of aggregate tags, including the inner layer aggregate ${\sigma }_I^{*}$, the outer layer tag ${\delta }_I$, and the global aggregate ${\delta }^{*}$. C then returns the resulting individual tag ${\sigma }_t$ and its index t to $\mathcal{A}$.

  –

  $Challenge$: C constructs a query/audit challenge $Chal$ and submits it to $\mathcal{A}$, requiring $\mathcal{A}$ to return a corresponding proof for the data items designated by $Chal$.

  –

  $Verify$: C validates the proof $\pi$ against the challenge tuple $(Chal,C)$. The procedure outputs 1 for a successful validation and 0 otherwise.

• $\mathbf{Controlled}\mathbf{redaction}$: $\mathcal{A}$ cannot derive the trapdoor key $r_s=(r_{2,s},r_{1,s},h_{2,s},Y_{2,i},Y_{1,i})$ from a given collision $(m_s^{\prime },r_s^{\prime })$ for $(m_s,r_s)$. In addition, only the user holding the trapdoor key is able to generate new collisions $(m_s^{″},r_s^{″})$ for $(m_s,r_s)$.

4. The Proposed Scheme

In this section, we describe the concrete construction of the proposed scheme, as shown in Figure 2.

4.1. Overview

Existing schemes face two primary limitations. First, their reliance on authenticated data structures often leads to rapid ledger growth and significant storage overhead. Second, they typically struggle to strike an effective balance between robust permission supervision and redaction efficiency. To address these challenges, we propose a novel scheme based on a dual-level verifiable and redactable blockchain architecture, which is guided by two key objectives: achieving lightweight storage overhead and enabling effective permission supervision.

First, to reduce the storage overhead typically introduced by authenticated data structures, we introduce a dual-level authenticated data structure. Its core principle is that the blockchain data is grouped, and the tags within each group are aggregated together to form inner layer aggregation tags ${\sigma }_I^{*}$. Next, these inner layer aggregation tags are further used to generate their respective outer layer tags ${\delta }_I$, which are then aggregated together to form an outer layer global tag ${\delta }^{*}$. This hierarchical design is the key to achieving lightweight storage, as the final global tag ${\delta }^{*}$ maintains a constant size regardless of the number of blocks on the blockchain.

Secondly, for effective permission supervision, we utilize a dual-level chameleon hash structure. This establishes a hierarchical permission model, whose inner layer is managed by a redactor formed through an election in the system setup phase. In this architecture, we introduce a dynamic regulator committee that operates on a rotational basis, where the designated regulator’s hash public key is used to generate the inner layer hashes for all blocks within a given cycle. For convenience, we assume that a cycle consists of the generation of k new blocks. In the outer layer, a CA provides oversight, holding a master key to intervene and correct any malicious edits. This also empowers the CA to manage the committee, for instance, by removing malicious regulators and admitting new members. This two-tier approach is the key to striking a clear balance between redaction efficiency and robust governance, thus providing effective permission control.

4.2. The Concrete Construction

4.2.1. System Setup

Given one security parameter ($1^{\lambda }$, $1^{{\lambda }_1}$, $1^{{\lambda }_2}$), CA runs $\mathsf{Setup}$ algorithm to initialize system. First, CA establishes an RSA modulus $N=pq$ by selecting two $\lambda /2\mathrm{bits}$ primes p and q. Then he selects a generator g for the subgroup $Q{R}_N$ of ${\mathbb{Z}}_N^{*}$, and generates a group G of prime order $p_1$, with its generator being $g_1$. Next, CA picks a $(\lambda +{\lambda }_1+{\lambda }_2+2)$-bits prime e and computes a secret key d where $ed=1(mod\phi (N\left)\right)$, and sets the parameter $g_d=g^d(modN)$.

CA initializes two pseudo-random permutations/functions and defines three hash functions and a prime hash function [36]:

$$\begin{array}{c}\hfill \left\{\begin{array}{c}{\varphi }_1:{\{0,1\}}^{{\lambda }_1}\times {\{0,1\}}^{{\lambda }_2}\to {\{0,1\}}^{{\lambda }_1}\hfill \\ {\varphi }_2:{\{0,1\}}^{{\lambda }_1}\times {\{0,1\}}^{{\lambda }_2}\to {\{0,1\}}^{{\lambda }_2}\hfill \\ \mathsf{H}:{\{0,1\}}^{*}\to {\{0,1\}}^{{\lambda }_2}\hfill \\ {\mathsf{H}}_{\mathsf{Prime}}:{\{0,1\}}^{*}\to \mathsf{Prime}\left(\lambda \right)\hfill \end{array}\right.\end{array}$$

After that, it picks two elements ${\mathsf{name}}_{\mathsf{1}}, {\mathsf{name}}_{\mathsf{2}}\leftarrow {\mathbb{Z}}_N^{*}$ at random and then initializes two counters ${\mathsf{cnt}}_{\mathsf{1}}\leftarrow 1$, ${\mathsf{cnt}}_{\mathsf{2}}\leftarrow 1$, and two aggregated tags ${\sigma }^{*}\leftarrow 1$, ${\delta }^{*}\leftarrow 1$.

Furthermore, CA runs $\mathsf{KeyGen}$ algorithm to generate trapdoor keys x, y, $x_1$, $y_1$←${\mathbb{Z}}_{p_1}^{*}$, hash key $HK$ $=(X,Y)$ = $(g_1^x,g_1^y)$, $H{K}_1=(X_1,Y_1)=(g_1^{x_1},g_1^{y_1})$. Finally, it outputs $pk$ $=(N$, e, g, $g_1$, $g_d$, $HK$, ${\mathsf{name}}_{\mathsf{1}}$, ${\mathsf{name}}_{\mathsf{2}}$, $\mathsf{H}$, ${\mathsf{H}}_{\mathsf{Prime}}$, ${\varphi }_1$, ${\varphi }_2)$, $sk=(p, q, d, {\mathsf{cnt}}_{\mathsf{1}},$${\mathsf{cnt}}_{\mathsf{2}}, {\mathsf{u}}_{\mathsf{1}}^{*}, {\mathsf{u}}_{\mathsf{2}}^{*})$, $mpk=\left(HK\right)$, $msk$$=(x,y)$, $sp{k}_1$ $=\left(H{K}_1\right)$, $ms{k}_1$$=(x_1,y_1)$. The CA utilizes the key pair $\left(pk,sk\right)$ to perform tag operations. It uses the outer key pair $\left(mpk,msk\right)$ to perform outer hash function operations and manage the inner $R_I$. Additionally, it corresponds to the first inner key pair $\left(sp{k}_1,ss{k}_1\right)$ to $R_1$.

We assume that $R_1$ is the regulator of the I-th cycle, and it has the inner key pair $\left(sp{k}_I,ss{k}_I\right)$, $I=\lceil i/k\rceil$. For simplicity, in the following, we use $k=10$ as an example.

CA calculates the genesis block hash $h_0=\mathsf{H}\left(pp\right||ct{r}_0)$, and generates the genesis block $B_0$. Finally, CA broadcasts $B_0$ = $(h_0,ct{r}_0,pp)$ on the blockchain network.

4.2.2. Block Append

When BM wins the consensus, he first generates a new block $B_i$, and then runs $\mathbf{Bind}$ algorithm to append it to the blockchain.

• Hash binding: BM randomly selects two random values $r_{2,i}\leftarrow {\mathbb{Z}}_{P_1}^{*}$, $r_{1,i}\leftarrow {\mathbb{Z}}_{P_1}^{*}$ and computes the inner layer hash value $h_{2,i}$ and outer layer hash value $h_{1,i}$ of $B_i$.

  $$\left\{\begin{array}{c}{h}_{2,i}={(X_I·Y_I)}^{\mathsf{H}(m_i,Y_I)}·g_1^{r_{2,i}}\hfill \\ h_{1,i}={(X·Y)}^{\mathsf{H}(h_{2,i}\left|\right|X_I\left|\right|h_{i-1},Y)}·g_1^{r_{1,i}}\hfill \end{array}\right.$$

  (1)

  where $h_{i-1}$ = $\mathsf{H}(h_{1,i-1}$, $ct{r}_{i-1})$. Then, the block $B_i$ = $(h_{i-1}$, $h_{1,i}$, $m_i$, $r_{2,i}$, $r_{1,i}$, $Y_{1,i}=Y$, $Y_{2,i}=Y_I$, $h_{2,i}$, $sp{k}_I)$ is added to the blockchain.
• Tag binding: The data m is first indexed as $m_i$($i\leftarrow {\mathsf{cnt}}_{\mathsf{2}}$), and CA generates a tag ${\sigma }_i$ for each block, as follows.  

  $$\left\{\begin{array}{c}{\rho }_i=\mathsf{H}({\mathsf{name}}_{\mathsf{2}}\Vert i)\hfill \\ u_i={\mathsf{H}}_{\mathsf{Prime}}({\mathsf{name}}_{\mathsf{2}}\Vert i)\hfill \\ {\sigma }_i=g^{{\left(\frac{{\rho }_i+m_i}{u_i}\right)}^d}\left(\mathrm{mod}N\right)\hfill \end{array}\right.$$

  (2)
  Second, the tag ${\sigma }_i$ is aggregated by the CA into the inner layer tag ${\sigma }_I^{*}$, and $I=\lceil i/10\rceil$.

  $${\sigma }_I^{*}\leftarrow {\sigma }_I^{*}·{\sigma }_i=\prod _{t=1}^{{\mathrm{cnt}}_2}{g}^{{\left(\frac{{\rho }_i+m_i}{u_i}\right)}^d}\left(\mathrm{mod}N\right)$$

  (3)
  After that, CA updates ${\mathrm{cnt}}_2\leftarrow {\mathrm{cnt}}_2+1$. When the number of data added to inner aggregation tag ${\sigma }_I^{*}$ in cycle I reaches 10 (This group-binding mechanism is analogous to a confirmation process in a blockchain, providing enhanced fault tolerance and enabling the correction of erroneous blocks within the finalized group), the CA uses the inner aggregation tag to the outer tag, as follows.

  $$\left\{\begin{array}{c}{\widehat{\rho }}_I=\mathsf{H}({\mathsf{name}}_{\mathsf{1}}\Vert I)\hfill \\ {\widehat{u}}_I={\mathsf{H}}_{\mathsf{Prime}}({\mathsf{name}}_{\mathsf{1}}\Vert I)\hfill \\ {\delta }_I=g^{{\left(\frac{{\widehat{\rho }}_I+{\sigma }_I^{*}}{{\widehat{u}}_I}\right)}^d}\left(\mathrm{mod}N\right)\hfill \end{array}\right.$$

  (4)
  Then, CA aggregates ${\delta }_I$ to the global tag ${\delta }^{*}$ and updates the relevant data, as follows.

  $${\delta }^{*}\leftarrow {\delta }^{*}·{\delta }_I=\prod _{I=1}^{{\mathrm{cnt}}_1}{g}^{{\left(\frac{{\widehat{\rho }}_I+{\delta }_I^{*}}{{\widehat{u}}_I}\right)}^d}\left(\mathrm{mod}N\right)$$

  (5)

  $${\mathrm{cnt}}_1\leftarrow {\mathrm{cnt}}_1+1$$
  Finally, CA publishes the new block $B_i$, the inner tag ${\sigma }_i$, inner aggregation tag ${\sigma }_I^{*}$, outer layer tag ${\delta }_I$, and the global tag ${\delta }^{*}$ on the blockchain.
• Upon receiving the new blocks $B_i$ and their associated tags ${\sigma }_i$, ${\delta }_I$, all LNs will verify the inner and outer layer hash values and the tags, as follows.

  $$\left\{\begin{array}{c}{\sigma }_i^{e{u}_i}\stackrel{?}{=}{g}^{{\rho }_i+m_i}(modN)\hfill \\ {\delta }_I^{e{\widehat{u}}_I}\stackrel{?}{=}{g}^{{\widehat{\rho }}_I+{\sigma }_I^{*}}(modN)\hfill \\ h_{2,i}\stackrel{?}{=}{(X_I·Y_I)}^{\mathsf{H}(m_i,Y_I)}·g_1^{r_{2,i}}\hfill \\ h_{1,i}\stackrel{?}{=}{(X·Y)}^{\mathsf{H}(h_{2,i}\left|\right|X_I\left|\right|h_{i-1},Y)}·g_1^{r_{1,i}}\hfill \end{array}\right.$$

  (6)
  If Equation (6) holds, the LNs discards both ${\sigma }_i$ and ${\delta }_I$ for alleviate the storage cost and then adds $B_i$ to the local blockchain ledger.

4.2.3. Block Redaction

To redact the s-th block(e.g., replacing $m_s$ with $m_s^{\prime }$), one of the following processes will be executed by the regulator or CA.

• Regular Redaction: For a regular redaction requirement, $R_I$ computes the $k_s$ of the inner hash value $h_{2,s}$ to generate a valid hash collision.

  $$k_s=\mathsf{H}(m_s,Y_I)·(x_I+y_{2,s})+r_{2,s}mod{p}_1$$

  (7)
  Then, $R_I$ generates a one-time key $y_{2,s}^{\prime }={\mathsf{H}}_2(x_I,m_s^{\prime })$ and its hash key $Y_{2,s}^{\prime }=g_1^{y_{2,s}^{\prime }}$. And $R_I$ calculates the new inner layer verification value $r_{2,s}^{\prime }$.  

  $$r_{2,s}^{\prime }=k_s-\mathsf{H}(m_s^{\prime },Y_{2,s}^{\prime })·(x_I+y_{2,s}^{\prime })mod{p}_1$$

  (8)
  The collision block $B_s^{\prime }$ = $(h_{s-1}$, $h_{1,s}$, $m_s^{\prime }$, $r_{2,s}^{\prime }$, $r_{1,s}$, $Y_{1,s}$, $Y_{2,s}^{\prime }$, $h_{2,s}$, $sp{k}_I)$ for $B_s$ = $(h_{s-1}$, $h_{1,s}$, $m_s$, $r_{2,s}$, $r_{1,s}$, $Y_{1,s}$, $Y_{2,s}$, $h_{2,s}$, $sp{k}_I)$.
  When $m_s$ is replaced by $m_s^{\prime }$, CA updates the tag information for the new block information. First, CA generates an inner layer tag ${\sigma }_s^{\prime }$ for $m_s^{\prime }$, updates inner layer aggregated tag ${\sigma }_I^{*}$, and generates outer layer tag ${\delta }_I^{\prime }$ for ${\sigma }_I^{*}$, updates aggregated global tag ${\delta }^{*}$ (When $m_s$ belongs to the last group, and the last group is less than 10, only the inner tag needs to be updated).

  $$\left\{\begin{array}{c}{\sigma }_s^{\prime }=g^{{\left(\frac{{\rho }_s+m_s^{\prime }}{u_s}\right)}^d}(modN)\hfill \\ {\sigma }_I^{*}={\displaystyle \frac{{\sigma }_I^{*}}{{\sigma }_s}}·{\sigma }_s^{\prime }(modN)\hfill \\ {\delta }_I^{\prime }=g^{{\left(\frac{{\widehat{\rho }}_I+{\sigma }_I^{*}}{{\widehat{u}}_I}\right)}^d}(modN)\hfill \\ {\delta }^{*}={\displaystyle \frac{{\delta }^{*}}{{\delta }_I}}·{\delta }_I^{\prime }(modN)\hfill \end{array}\right.$$

  (9)
  Finally, CA publishes the new block $B_s^{\prime }$ and the updated tag (${\sigma }_I^{*},{\delta }^{*}$) on the blockchain.
• Correction: For a malicious redaction executed by a compromised regulator, CA selects a random number $r_{2,s}^{\prime }\leftarrow {\mathbb{Z}}_{p_1}^{*}$, and uses the master key to replace the subordinate key pair of the original $R_I$ to recalculate the inner layer hash $h_{2,s}^{\prime }$.

  $$h_{2,s}^{\prime }={(X·Y)}^{\mathsf{H}(m_s^{\prime },Y)}·g_1^{r_{2,s}^{\prime }}$$

  (10)
  And, CA computes the $K_s$ of the outer layer hash $h_{1,s}$.

  $$K_s=H_1(h_{2,s}\left|\right|X_I\left|\right|h_{s-1},Y)·(x+y_{1,s})+r_{1,s}mod{p}_1$$

  (11)
  Then, CA calculates $y_{1,s}^{\prime }=\mathsf{H}(x,h_{2,s}^{\prime }\left|\right|X\left|\right|h_{s-1})$, $Y_{1,s}^{\prime }=g^{y_{1,s}^{\prime }}$, and the new outer layer verification value $r_{1,s}^{\prime }$.

  $$r_{1,s}^{\prime }=K_s-\mathsf{H}(h_{2,s}^{\prime }\left|\right|X\left|\right|h_{s-1},Y_{1,s}^{\prime })·(x+y_{1,s}^{\prime })mod{p}_1$$

  (12)
  At this point, for the s-th block, the redaction authority of user $R_I$ (I = $\lceil s/10\rceil$) has been transferred to CA. The collision block $B_s^{\prime }$ = $(h_{s-1}$, $h_{1,s}$, $m_s^{\prime }$, $Y_{2,s}^{\prime }=Y$, $Y_{1,s}^{\prime }$, $r_{2,s}^{\prime }$, $r_{1,s}^{\prime }$, $h_{2,s}^{\prime }$, $sp{k}_I)$ for $B_s$ = $(h_{s-1}$, $h_{1,s}$, $m_s$, $Y_{2,s}$, $Y_{1,s}$, $r_{2,s}$, $r_{1,s}$, $h_{2,s}$, $sp{k}_I)$. And CA updates the tag information according to Equation (9).
• Update.block: A validity check based on Equation (6) is first performed by the LNs. If the check succeeds, they update the local blockchain ledger.

4.2.4. Block Query

The VA initiates a query for the data $m_s$ of the s-th block by executing the $\mathbf{Query}$ protocol, as follows. We define the set $W=\left(10\right(I-1)+1,10I)$.

First, The PA generates the inner and outer layer auxiliary information for the data $m_s$ (where $I=\lceil s/10\rceil$), as follows:  

$$\left\{\begin{array}{c}{\widehat{f}}_I={\sum }_{i\ne I}({\widehat{\rho }}_i+{\widehat{\sigma }}_i){\prod }_{k\ne \{i,I\}}{\widehat{u}}_k\hfill \\ {\widehat{F}}_I=g_d^{{\widehat{f}}_I}(modN)\hfill \\ f_s={\sum }_{i\ne s,i\in W}({\rho }_i+m_i){\prod }_{k\ne \{i,s\}}{u}_k\hfill \\ F_s=g_d^{f_s}(modN)\hfill \end{array}\right.$$

(13)

Then, VA gets the tuple ${\pi }_q=(m_s,F_s,{\sigma }_I^{*},{\widehat{F}}_I)$, and calculates ${\mathbf{u}}_I^{*}\leftarrow {\prod }_{1,i\in W}^i{u}_i$, ${\widehat{\mathbf{u}}}^{*}\leftarrow {\prod }_{1,}^I{\widehat{u}}_I$. It runs $\mathsf{TagRet}$ algorithm to retrieve the outer layer tag ${\delta }_I$ from the global tag ${\delta }^{*}$.

$$\left\{\begin{array}{c}{\widehat{u}}_I={\mathsf{H}}_{\mathsf{Prime}}({\mathsf{name}}_{\mathsf{1}}\Vert I)\hfill \\ {\widehat{\overline{u}}}_I={\widehat{\mathbf{u}}}^{*}/{\widehat{u}}_I(mod\phi \left(N\right))\hfill \\ x={{\delta }^{*}}^{{\widehat{\overline{u}}}_I}/{\widehat{F}}_I(modN)\hfill \\ y=g^{({\widehat{\rho }}_I+{\sigma }_I^{*})d}(modN)\hfill \\ {\delta }_I=\mathsf{Shamir}(x,y,a={\widehat{u}}_I,b={\widehat{\overline{u}}}_I)\hfill \end{array}\right.$$

(14)

If $gcd(a,b)=1$ and $x^a\equiv y^b(modN)$ the function Shamir $(x,y,a,b)$ outputs a value $z=y^{\alpha }{x}^{\beta }\in {\mathbb{Z}}_N$ where $\alpha a+\beta b=1$, such that.

$$\begin{array}{cc}\hfill z^a& =y^{\alpha a}{x}^{\beta a}=y^{\alpha a}{y}^{\beta b}=y^{\alpha a+\beta b}=y(modN)\hfill \end{array}$$

(15)

The value z is the ${\delta }_I$, and the VA verifies that the tag is valid.

$${\delta }_I^{e{\widehat{u}}_I}\stackrel{?}{=}{g}^{{\widehat{\rho }}_I+{\sigma }_I^{*}}(modN)$$

(16)

If the verification is valid, VA retrieves the ${\sigma }_s$ from the ${\sigma }_I^{*}$. Otherwise, it discards the tuple. The VA runs (17) to calculate the original label ${\sigma }_s$ and validate the tag.

$$\left\{\begin{array}{c}{u}_s={\mathsf{H}}_{\mathsf{Prime}}({\mathsf{name}}_{\mathsf{2}}\Vert s)\hfill \\ {\overline{u}}_s={\mathbf{u}}_I^{*}/u_s(mod\phi \left(N\right))\hfill \\ x={{\sigma }_I^{*}}^{{\overline{u}}_s}/F_s(modN)\hfill \\ y=g^{({\rho }_s+m_s)d}(modN)\hfill \\ {\sigma }_s=\mathsf{Shamir}(x,y,a=u_s,b={\overline{u}}_s)\hfill \end{array}\right.$$

(17)

$${\sigma }_s^{e{u}_s}\stackrel{?}{=}{g}^{{\rho }_s+m_s}(modN)$$

(18)

If the equation is invalid, the VA discards the block data $m_s$. Otherwise, he proceeds to verify the correctness of the queried block’s hash value.

$$\left\{\begin{array}{c}{h}_{2,s}\stackrel{?}{=}{(X_I·Y_I)}^{\mathsf{H}(m_s,Y_I)}·g_1^{r_{2,s}}\hfill \\ h_{1,s}\stackrel{?}{=}{(X·Y)}^{\mathsf{H}(h_{2,s}\left|\right|X_I\left|\right|h_{s-1},Y)}·g_1^{r_{1,s}}\hfill \end{array}\right.$$

(19)

If both Equations (19) are valid, the VA remains $B_s$ locally. Otherwise, he discards it.

4.2.5. Blockchain Auditing

The VA checks the integrity of the blockchain ledger by executing the $\mathbf{Audit}$ protocol, as follows.

• $\mathsf{Chal}$: VA selects three random elements $z\in \left[{\mathsf{cnt}}_{\mathsf{2}}\right]$ and $r_1,r_2\in {\{0,1\}}^{{\lambda }_2}$. Subsequently, VA publishes the $Chal=(z,r_1,r_2)$ to the blockchain.
• $\mathsf{Proof}$: In response to the $Chal$, PA generates Algorithm 1 and publishes the integrity proof $\pi$ for each group on the blockchain, while also transmitting the corresponding verification metadata ${\pi }_I=({\sigma }_I^{*},{\widehat{F}}_I,{\{F_s,y_s\}}_{s\in \left(z\right)})$ to VA via a secure off-chain channel.
• $\mathsf{Verify}$: Run Algorithm 2 for the proof of each group, if $\mathsf{flag}=0$, VA aborts this process. Otherwise, it verifies the challenged blocks’ correctness via Equation (19). If the verification is successful, VA issues a final audit result on the blockchain, indicating that the ledger is intact and valid.

Algorithm 1 Audit Proof Generation.

Input:  $\left(Chal\right)$ Output:  $({\pi }_I,{\sigma }_I^{*},{\widehat{F}}_I,{\{F_s,y_s\}}_{s\in \left(z\right)})$   1: Set $S\leftarrow \varnothing$ and ${\pi }_I\leftarrow 0$   2: for  $h=1;h\le z;h++$  do   3:     Compute $s={\varphi }_1(h,r_1)$ and $I\leftarrow \lceil s/10\rceil$   4:     if ($m_s\in Q_I$) then   5:         Set $S\leftarrow S\cup \left\{s\right\}$   6:         Compute $u_s\leftarrow {\mathsf{H}}_{\mathsf{Prime}}({\mathsf{name}}_{\mathsf{2}}\left|\right|s)$   7:         Compute ${\overline{u}}_s\leftarrow {\mathbf{u}}_I^{*}/u_s(mod\phi \left(N\right))$   8:         Calculate $f_s={\sum }_{j\ne s,j\in W}({\rho }_j+m_j){\prod }_{k\ne \{j,s\}}{u}_k$   9:         Compute $F_s=g_d^{f_s}(modN)$ 10:         Compute $y_s=g_d^{({\rho }_s+m_s)}(modN)$ 11:         Compute $b_s={\varphi }_2(h,r_2)$ 12:         Compute ${\pi }_I\leftarrow {\pi }_I+b_s{m}_s$ 13:     end if 14: end for 15: Compute ${\widehat{f}}_I={\sum }_{k\ne I}({\widehat{\rho }}_k+{\widehat{\sigma }}_k){\prod }_{l\ne \{I,k\}}{\widehat{u}}_k$ 16: Compute ${\widehat{F}}_I=g_d^{{\widehat{f}}_I}(modN)$

Algorithm 2 Audit Proof Verification.

Input:  $({\pi }_I,{\sigma }_I^{*},{\widehat{F}}_I,{\{F_s,y_s\}}_{s\in \left(z\right)})$ Output:  $(\mathsf{flag}=1/0)$   1: Set $a\leftarrow {\widehat{u}}_I={\mathsf{H}}_{\mathsf{prime}}({\mathsf{name}}_{\mathsf{1}}\left|\right|\mathsf{I})$   2: Set $b\leftarrow {\widehat{\overline{u}}}_I={\widehat{\mathbf{u}}}^{*}/{\widehat{u}}_I(mod\phi \left(N\right))$   3: Set $y=g_d^{(\widehat{{\rho }_s}+{\sigma }_I^{*})}(modN)$   4: Compute $x={{\delta }^{*}}^{{\widehat{\overline{u}}}_I}/{\widehat{F}}_I(modN)$   5: Compute ${\delta }_I=\mathsf{Shamir}(x,y,a,b)$   6: Set $\mathrm{flag}\leftarrow \mathsf{TagVerify}(\mathrm{pk},{\sigma }_I^{*},{\delta }_I)$   7: if  $\mathsf{flag}=1$  then   8:     for $i=1;i\le z;i++$ do   9:         Compute $s_i={\varphi }_1(i,r_1)$ and $I\leftarrow \lceil s_i/10\rceil$ 10:         if ($m_{s_i}\in Q_I$) then 11:            Compute $a\leftarrow u_{s_i}={\mathsf{H}}_{\mathsf{Prime}}({\mathsf{name}}_{\mathsf{2}}\left|\right|s_i)$ 12:            Compute $b\leftarrow {\overline{u}}_{s_i}={\mathbf{u}}_I^{*}/u_{s_i}(mod\phi \left(N\right))$ 13:            Compute $y\leftarrow y_{s_i}=g_d^{({\rho }_{s_i}+m_{s_i})}(modN)$ 14:            Compute $x\leftarrow x_{s_i}={{\sigma }_I^{*}}^{{\overline{u}}_{s_i}}/F_{s_i}(modN)$ 15:            Compute ${\sigma }_{s_i}=\mathsf{Shamir}(x,y,a,b)$ 16:            Compute $b_i={\varphi }_2(i,r_2)$ 17:         end if 18:     end for 19:     if ${\prod }_{i=1}^z{({\sigma }_{s_i}^{e{u}_{s_i}}/g^{{\rho }_{s_i}})}^{b_i}\equiv g^{{\pi }_I}(modN)$ then 20:         Set $\mathrm{flag}\leftarrow 0$ 21:     end if 22: end if

5. Security Analysis

Theorem 1.

(Correctness): The correctness property of our proposed scheme guarantees that proofs are accurately verified during the block query and auditing processes.

Proof. 

The correctness of this scheme relies on the underlying dual-level chameleon hash structure and dual-level authentication data structure. Specifically, both block query and blockchain auditing require first recovering the questioned original tag from the global aggregated label, and then conducting double-layer label verification and double-layer hash verification. The correctness of the proposed scheme is demonstrated in the following four steps:

Case 1 ($CorrectChameleonHash$): First, we have proved the correctness of the double-layer double-trapdoor chameleon hash function. For the inner layer,

$$\begin{array}{cc}\hfill h_{2,s}& ={(X_I·Y_I)}^{{\mathsf{H}}_1(m_s,Y_I)}·g_1^{r_{2,s}}\hfill \\ \hfill & =g_1^{(x_1+y_1)·{\mathsf{H}}_1(m_s,Y_I)}·g_1^{r_{2,s}}\hfill \\ \hfill & =g_1^{(x_1+y_1)·{\mathsf{H}}_1(m_s,Y_I)+r_{2,s}}.\hfill \end{array}$$

(20)

For the outer layer,

$$\begin{array}{cc}\hfill h_{1,s}& ={(X·Y)}^{{\mathsf{H}}_1(h_{2,s}\left|\right|X_I\left|\right|h_{s-1},Y)}·g_1^{r_{1,s}}\hfill \\ \hfill & =g_1^{(x+y)·{\mathsf{H}}_1(h_{2,s}\left|\right|X_I\left|\right|h_{s-1},Y)}·g_1^{r_{1,s}}\hfill \\ \hfill & =g_1^{(x+y)·{\mathsf{H}}_1(h_{2,s}\left|\right|X_I\left|\right|h_{s-1},Y)+r_{1,s}}.\hfill \end{array}$$

(21)

Case 2 ($CorrectTagRetrieval$): Then, we have proved the correctness of the outer and inner layer tag retrieval by the Shamir’s Trick. Because we used ${\mathsf{H}}_{\mathsf{Prime}}(·)$ in it, it’s easy to get a tuple $(a_I,b_I)$, where by calculating $gcd(a_I,b_I)=1$ and ${\alpha }_I{a}_I+{\beta }_I{b}_I=1$. For the outer layer, we check $x_I^{a_I}\stackrel{?}{=}{y}_I^{b_I}(modN)$, as follows.

$$\begin{array}{cc}\hfill x_I^{a_I}& ={\left({{\delta }^{*}}^{{\widehat{\overline{u}}}_I}/\widehat{F_I}\right)}^{{\widehat{u}}_I}(modN)\hfill \\ \hfill & ={\left(\prod _i{g}^{\left({\displaystyle \frac{{\widehat{\rho }}_i+{\sigma }_i^{*}}{{\widehat{u}}_i}}\right)d}\right)}^u/g^{{\widehat{f}}_I{\widehat{u}}_{I}d}\hfill \\ \hfill & =g^{{\sum }_{i}d({\widehat{\rho }}_i+{\sigma }_i^{*}){\prod }_{k\ne i}{u}_k}/g^{{\sum }_{i\ne I}d({\widehat{\rho }}_i+{\sigma }_i^{*}){\prod }_{k\ne i}{u}_k}\hfill \\ \hfill & =g^{d({\widehat{\rho }}_I+{\sigma }_I^{*}){\prod }_{k\ne I}{u}_k}\hfill \\ \hfill & =g_d^{({\widehat{\rho }}_I+{\sigma }_I^{*}){\widehat{\overline{u}}}_I}(modN).\hfill \end{array}$$

(22)

Specifically, when the conditions $y_I=g_d^{({\widehat{\rho }}_I+{\sigma }_I^{*})}$ and $b_I={\widehat{\overline{u}}}_I$ are met, the equation $x_I^{a_I}=y_I^{b_I}(modN)$ can be derived.

For the inner layer, when the conditions $y_s=g_d^{({\rho }_s+m_s)}$ and $b_s={\overline{u}}_s$ are met, the equation $x_s^{a_s}=y_s^{b_s}(modN)$ can be derived, as follows.

$$\begin{array}{cc}\hfill x_s^{a_s}& ={\left({{\sigma }_I^{*}}^{{\overline{u}}_s}/F_s\right)}^{u_s}(modN)\hfill \\ \hfill & ={\left(\prod _i{g}^{\left({\displaystyle \frac{{\rho }_i+m_i}{u_i}}\right)d}\right)}^u/g^{f_s{u}_{s}d}\hfill \\ \hfill & =g^{{\sum }_{i}d({\rho }_i+m_i){\prod }_{k\ne i}{u}_k}/g^{{\sum }_{i\ne s}d({\rho }_i+m_i){\prod }_{k\ne i}{u}_k}\hfill \\ \hfill & =g^{d({\rho }_s+m_s){\prod }_{k\ne s}{u}_k}\hfill \\ \hfill & =g_d^{({\rho }_s+m_s){\overline{u}}_s}(modN).\hfill \end{array}$$

(23)

Case 3 ($CorrectQuery$): We demonstrate the correctness of block query procedure: For the outer layer,

$${\delta }_I^{e{\widehat{u}}_I}={\left(y_I^{{\alpha }_I{a}_I}{x}_I^{{\beta }_I{a}_I}\right)}^e=g^{({\widehat{\rho }}_I+{\sigma }_I^{*})}(modN).$$

(24)

For the inner layer,

$${\sigma }_s^{e{u}_s}={\left(y_s^{{\alpha }_s{a}_s}{x}_s^{{\beta }_s{a}_s}\right)}^e=g^{({\rho }_s+m_s)}(modN).$$

(25)

Case 4 ($CorrectAudit$): The final step of our proof demonstrates the correctness of the blockchain auditing protocol. We begin by assuming $VA$ has successfully retrieved the tags $\left\{{\sigma }_{s_i}\right\}$ for all challenged block items $\left\{m_{s_i}\right\}$ specified by

$$\begin{array}{cc}\hfill \prod _{i=1}^z{\left({\sigma }_{s_i}^{e{u}_{s_i}}/g^{h_{s_i}}\right)}^{b_i}& =\prod _{i=1}^z{\left({\left(g^{\left({\displaystyle \frac{h_{s_i}+m_{s_i}}{u_{s_i}}}\right)d}\right)}^{e{u}_{s_i}}/g^{h_{s_i}}\right)}^{b_i}\hfill \\ & =\prod _{i=1}^z{\left(g^{(h_{s_i}+m_{s_i})}/g^{h_{s_i}}\right)}^{b_i}\hfill \\ & =g^{{\sum }_{i=1}^z{b}_i{m}_{s_i}}\left(\mathrm{mod}N\right).\hfill \end{array}$$

(26)

$Chal={\left\{(s_i,b_i)\right\}}_{i\in \left[z\right]}$, we can get Equation (26).

If $\rho ={\sum }_{i=1}^z{b}_i{m}_{s_i}$, we can get that

$$\prod _{i=1}^z{\left({\sigma }_{s_i}^{e{u}_{s_i}}/g^{h_{s_i}}\right)}^{b_i}=g^{\rho }(modN).$$

(27)

Based on the four cases proven above, we can conclude that the proposed scheme correctly handles both block query and auditing.    □

Theorem 2.

(Soundness): If the RSA problem remains hard and both hash functions, ${\mathsf{H}}_{\mathsf{1}}(·)$ and ${\mathsf{H}}_{\mathsf{prime}}(·)$, provide collision resistance, then under the random oracle model, our scheme achieves soundness for its block query and blockchain auditing protocol.

Proof. 

Since a block query is a special case of the block auditing protocol, the soundness of the former can be reduced to the soundness of the latter. In what follows, we will construct a series of a sequence of cryptographic games to prove the security of the blockchain auditing protocol.

${\mathbf{Game}}_{\mathbf{0}}$: We define the initial game, ${\mathbf{Game}}_{\mathbf{0}}$ as the interactive soundness game established in the threat model section.

${\mathbf{Game}}_{\mathbf{1}}$: This game is a slight modification of ${\mathbf{Game}}_{\mathbf{0}}$, where the challenger $\mathcal{C}$ now maintains two lists during the execution of game: a list $L_{inner}$ to record all legitimately generated inner tags ${\sigma }_i$, and a list $L_{outer}$ for all legitimately generated outer tags ${\delta }_I$. The game is terminated and $\mathcal{C}$ declares a failure if the adversary $\mathcal{A}$ submits a proof tuple $(m_s^{\prime },F_s^{\prime },{\sigma }_I^{{*}^{\prime }},{\widehat{F}}_I^{\prime })$ that enables $\mathcal{C}$ to retrieve a tag ${\delta }_I^{\prime }$, such that this retrieved tag ${\delta }_I^{\prime }$ is not present in the list $L_{outer}$.

Assuming an adversary $\mathcal{A}$ achieves a non-negligible advantage $ϵ>\mathrm{negl}\left(\lambda \right)$ between ${\mathsf{Game}}_{\mathsf{0}}$ and ${\mathsf{Game}}_{\mathsf{1}}$, we can construct a $\mathsf{PPT}$ adversary $\mathcal{B}$. $\mathcal{B}$ can solve the underlying RSA problem with a probability of $ϵ/q_{ro}-\mathrm{negl}\left(\lambda \right)$, where $q_{ro}$ denotes $\mathcal{A}$’s queries to the random oracle.

Setup phase, given an RSA instance $(N,\overline{e},y,y^d)$ to $\mathcal{B}$, $\mathcal{B}$’s goal is to find z such that $z^{\overline{e}}=y(modN)$. And $\mathcal{A}$ first interacts with $\mathcal{B}$ by responding to its $\mathsf{TagGen}$ queries for various data items, which are organized into groups. We denote the set of groups for which $\mathcal{A}$ makes these legitimate, regular queries as T. Subsequently, $\mathcal{A}$ commits to a challenge set L, for which it will attempt to forge a global aggregated tag. We suppose that an admissible adversary $\mathcal{A}$ [37], who is expected to target a group $J^{\prime }\in L$, $J^{\prime }\notin T$ without ever querying it to the $\mathsf{TagGen}$ oracle. The simulator $\mathcal{B}$ then initializes ${\mathsf{H}}_{\mathsf{Prime}}$ as a random oracle. For all groups, it generates the corresponding outer layer primes: ${\widehat{u}}_I=H_{Prime}({\mathrm{name}}_1\parallel I)$ for the regular groups $I\in T$, and ${\widehat{u}}_J^{\prime }=H_{Prime}({\mathrm{name}}_2\parallel J)$ for the challenge groups $J\in L$. The soundness of this hierarchical scheme fundamentally relies on the integrity of its outer aggregation layer. A successful forgery must, at its core, compromise an outer layer tag. Therefore, our proof logically focuses on reducing the soundness to the hardness of forging an outer layer tag. Among the oracle queries for the challenge groups, $\mathcal{B}$ guesses the group index $J^{\prime }$ that $\mathcal{A}$ will target. It then sets the corresponding outer layer prime ${\widehat{u}}_{J^{\prime }}^{\prime }\leftarrow \overline{e}$ for this group and computes g as $g=y^{{\prod }_{I\in \left[T\right]}{\widehat{u}}_I}(modN)$. The resulting verification key $(N,g)$ is then transmitted to $\mathcal{A}$.

Query phase, $\mathcal{B}$ faithfully simulates the $\mathsf{TagGen}$ oracle. For any queries corresponding to the regular groups T, $\mathcal{B}$ generates and returns inner and outer tags to $\mathcal{A}$. Then $\mathcal{A}$ outputs a forgery, consisting of a global tag ${\delta }^{*}$ and a proof tuple $\pi =(m_s^{\prime },F_s^{\prime },{\sigma }_{J^{\prime }}^{\prime *},\widehat{F_{J^{\prime }}^{\prime }})$ corresponding to a challenge query s within the challenge group $J^{\prime }$. If the check on $\pi$ succeeds, $\mathcal{B}$ computes z; otherwise, it aborts.

$$z=\mathsf{Shamir}\left(x={\left({\delta }^{*}\right)}^{e{\prod }_{J\in \left[L\right],J\ne J^{\prime }}{\widehat{u}}_J^{\prime }},y,a={\widehat{u}}_{J^{\prime }}^{\prime },b\right).$$

(28)

and $b={\prod }_{I\in \left[T\right]}{\widehat{u}}_I{\sum }_{J\in \left[L\right]}({\widehat{\rho }}_J^{\prime }+{\sigma }_J^{\prime *}){\prod }_{K\in \left[L\right],K\ne J}{\widehat{u}}_K^{\prime }$.

We now prove that the computed z is a valid solution $z^{{\widehat{u}}_{J^{\prime }}^{\prime }}=y\left(\mathrm{mod}N\right)$. According to Shamir’s Trick lemma, we only need to demonstrate that two conditions hold: $x^a=y^b\left(\mathrm{mod}N\right)$ and $gcd(a,b)=1$. For the first condition.

$$\begin{array}{cc}\hfill x^a& ={\left({\delta }^{*}\right)}^{e{\prod }_{J\in \left[L\right]}{\widehat{u}}_J^{\prime }}\hfill \\ \hfill & =g^{{\sum }_{J\in \left[L\right]}({\widehat{\rho }}_J^{\prime }+{\sigma }_J^{\prime *})·\left({\prod }_{K\in \left[L\right],K\ne J}{\widehat{u}}_K^{\prime }\right)}\left(\mathrm{mod}N\right)\hfill \\ \hfill & ={\left(y^{{\prod }_{I\in \left[T\right]}{\widehat{u}}_I}\right)}^{{\sum }_{J\in \left[L\right]}({\widehat{\rho }}_J^{\prime }+{\sigma }_J^{\prime *})·\left({\prod }_{K\in \left[L\right],K\ne J}{\widehat{u}}_K^{\prime }\right)}\left(\mathrm{mod}N\right)\hfill \\ \hfill & =y^b\left(\mathrm{mod}N\right).\hfill \end{array}$$

(29)

For the second condition, to prove $gcd(a=\overline{e},b)=1$, we note that $\overline{e}$ is a prime and $b>\overline{e}$. Therefore, it is sufficient to show that $b\mathrm{mod}a\ne 0$.

$$\begin{array}{cc}\hfill bmoda& \equiv \prod _{I\in T}{\widehat{u}}_I\sum _{J\in \left[L\right]}\left({\widehat{\rho }}_J^{\prime }+{\sigma }_J^{\prime *}\right)\prod _{k\ne J}{\widehat{u}}_K^{\prime }\hfill \\ \hfill & =\prod _{I\in \left[T\right]}{\widehat{u}}_I\left(\left({\widehat{\rho }}_{J^{\prime }}^{\prime }+{\sigma }_{J^{\prime }}^{\prime *}\right)\prod _{k\ne J^{\prime }}{\widehat{u}}_K^{\prime }\right)\mathrm{mod}a\ne 0.\hfill \end{array}$$

(30)

As calculated in Equation (30), this inequality holds due to the collision resistance of the hash function ${\mathsf{H}}_{\mathsf{Prime}}(·)$.

Since both conditions are met, $\mathcal{B}$ can successfully apply the extended euclidean algorithm to find integers $(\alpha ,\beta )$ s.t. $a\alpha +b\beta =1$. The final solution is then computed as $z=y^{\alpha }{x}^{\beta }$, which is the correct $\overline{e}$-th root of y.

$$z^{\overline{e}}=y^{a\alpha }{x}^{a\beta }=y^{a\alpha }{y}^{b\beta }=y^{a\alpha +b\beta }=y\left(\mathrm{mod}N\right)$$

(31)

This concludes the proof of soundness for the proposed scheme.    □

Theorem 3.

(Controlled redaction): The dual-layer dual-trapdoor chameleon hash scheme proposed in this paper ensures that only the owner holding the trapdoor key can redact the blockchain. This scheme can effectively resist adversaries using hash collisions to extract trapdoor keys or forge new collisions.

Proof. 

The security of the proposed scheme is derived from its dual-level chameleon hashing structure. Specifically, the mechanism must address three critical challenges: first, preventing an adversary without a key from computing a hash collision to perform illicit modifications; second, ensuring that collision-based modifications can only be executed by the authorized redactor holding the trapdoor key; and third, mitigating malicious operations that could result from a compromised or leaked secret key. The security of our scheme can be directly attributed to three corresponding properties of the underlying double-trapdoor chameleon hash family [34]: First, its collision resistance makes it computationally infeasible for an adversary without a key to find a hash collision, thus preventing the illicit modifications outlined in the first challenge. Second, the trapdoor collision property ensures that only the authorized redactor holding the trapdoor key can efficiently compute such collisions, thereby satisfying the second requirement. Finally, key-exposure freeness guarantees that a compromised secret key cannot be used to forge collisions for hashes generated with other keys, effectively mitigating the third risk.

Due to space limitations, we omit the detailed proof. For more details, please refer to the reference [34].    □

6. Performance Analysis

In this section, we evaluate the performance of the proposed scheme from both theoretical analysis and implementation.

6.1. Theoretical Analysis

To better evaluate the performance, we selected Scheme [25] and Scheme [26] as comparative experiments, and defined some symbols in

Table 2. Notations.

Notation	Description
n	Total count of blocks on the blockchain
m	Quantity of transactions per standard block
q	The branching factor of the q-ary BAT
k	Number of blocks per cycle
N	Dimensionality of the family vector
z	Total nodes within the audited path union
c	Number of groups involved in the z data blocks under audit.
s	Number of redacted blocks
ℓ	Height of the redacted/queried node within the BAT
l	Height of the MHT in the block
H	Cost overhead of running a hash function H
$H_p$	Cost overhead of hashing a string to a prime
M	Cost overhead of mining a standard block
EC	The cost of the elliptic curve algorithm
EEA	Cost overhead of executing an extended euclidean algorithm
Exp	Cost overhead of an exponentiation operation
Pair	Computational cost for a bilinear pairing operation
$\left|G\right|$	Storage size of the element in G
$|Z_p|$	Storage size of the element in $Z_p$
$|Z_N|$	Storage size of the element in $Z_N$
$\left|Tx\right|$	Storage size of the transaction in a standard block
$\left|BH\right|$	Storage size of the block header in a standard block

. Based on these definitions, we proceed to analyze the selected scheme’s communication and storage costs (

Table 3. Comparisons Of Communication and Storage Costs.

Schemes	Communication Costs					Storage Costs
	Setup	Bind	Redact	Query	Auditing	FN	LN
VRBC	$1\left|BH\right|+$	$1\left|BH\right|+$	$1\left|BH\right|+$	$1\left|BH\right|+$	$z\left(1\right|BH|+$	$n\left(\right|BH|+$	$n\left(\right|BH\left|\right)$
[25]	$m\left|Tx\right| +4(N+1)\left|G\right|$	$m\left|Tx\right| +2|Z_p| +(q+1)|G|$	$m\left|Tx\right| +2\left(\right|Z_p| + |G\left|\right)$	$m\left|Tx\right| +4|Z_p| +(\ell +4)|G|$	$m\left|Tx\right|)+(3\ell +1)\left(\right|Z_p| + |G\left|\right)$	$m\left|Tx\right|)+n\left(\right|Z_p| +3|G\left|\right)$	$+n\left(\right|Z_p| +3|G\left|\right)$
SCLS	$1\left|BH\right|+$	$1\left|BH\right|+$	$1\left|BH\right|+$	$n\left(\right|BH|+$	-	$n\left(\right|BH| +m|Tx\left|\right)+$	$n\left(\right|BH\left|\right)+$
[26]	$m\left|Tx\right| +3\left|G\right| + |Z_p| +2|Z_N|$	$m\left|Tx\right| +3\left|G\right| + |Z_p|$	$m\left|Tx\right| +10\left|G\right| +3|Z_p|$	$m\left|Tx\right|)+n(3\left|G\right| + |Z_p\left|\right)$		$(n-s)\left(3\right|G| + |Z_p\left|\right)+s\left(10\right|G| +3|Z_p\left|\right)$	$(n-s)\left(3\right|G| + |Z_p\left|\right)+s\left(10\right|G| +3|Z_p\left|\right)$
Our	$1\left|BH\right| +m\left|Tx\right|$	$1\left|BH\right| +m\left|Tx\right|$	$1\left|BH\right| +m\left|Tx\right|$	$1\left|BH\right| +m\left|Tx\right|$	$z\left(1\right|BH| +m|Tx\left|\right)+2z|Z_p|$	$n\left(1\right|BH| +m|Tx\left|\right)$	$n\left|BH\right| +n\left(5\right|G| +2|Z_p\left|\right)$
scheme	$+4|Z_p| +2|Z_N| +4|G|$	$+2|Z_p| +4|Z_N| + |G|$	$+|Z_p| +4|Z_N| +2|G|$	$+3|Z_N| +5|G| +2|Z_p|$	$+(5z+c)\left|G\right| +(cz+2z)\left|z\right|$	$+n\left(5\right|G| +2|Z_p\left|\right)+(\lfloor n/k\rfloor +1)|Z_N|$	$+(\lfloor n/k\rfloor +1)|Z_N|$

) and compare the computational overhead against the selected schemes (

Table 4. Comparisons Of Computation Costs.

Schemes	System Setup	Block Append		Block Redaction		Block Query		Blockchain Auditing
		Bind	Verify	Redact	Verify	Prove	Verify	Prove	Verify
VRBC	$1M+2qH$	$1H+q(2H$	$(2^{l+1}+q)H$	$2H+(\ell +1)$	$(2^{l+1}+\ell )H$	$q\ell H+(2N$	$2^{l+1}H+1H$	$q\rho H+(2N$	$\rho (2^{l+1}+l)H$
[25]	$+3NExp$	$+Exp)$	$+1H+(N+1)Exp$	$(H+Exp)$	$+(\ell +1)Exp$	$-1)Exp$	$+(\ell +2)(Exp+Pair)$	$-1)Exp$	$(\rho +1)(Exp+Pair)$
SCLS	$1M+H$	$2H+2EC+2Exp$	$(2^{l+1}+1)H$	$2H_p+H+EEA$	$(2^{l+1}+1)H$	-	$n((2^{l+1}+1)H$	-	-
[26]	$+3EC+2Exp$		$+2EC+2H_p$	$+9Exp+2EC$	$+2EC+2H_p$		$+H_p+2EC)+Exp$
Our	$1M+H$	$2H+(1+1/k)$	$(2^{l+1}+1)H$	$4EEA$	$(2^{l+1}+1)H$	$(k+n/k)H_p$	$2H_p+2H$	$(2z+c)Exp$	$(6z+6c)Exp$
scheme	$+3Exp$	$(H+H_p)+(5+1/k)Exp$	$+6Exp$	$+3H+3Exp$	$+6Exp$	$+2Exp$	$+4EEA+14Exp$	$+(zk+c(n/k\left)\right)H$	$+(2c+3z)EEA+\left(c\right(n/k)+zk)H$

).

In the system setup phase, the computation costs are 1M + $2q$H + 3NExp for [25], and 1M + H + 3EC + 2Exp for [26], while our proposed scheme requires 1M + H + 3Exp to generate the parameters for the dual-layer dual-trapdoor chameleon hash and tags. Meanwhile, the additional communication cost of our scheme is 4$|Z_p|$ + 2$|Z_N|$ + 4|G|, which is not significantly different from the other two. Therefore, our scheme has an advantage in the initialization phase.

In the block append phase, compared to the 1H + q(2H + Exp) required by [25] and the 2H + 2EC + 2Exp by [26], our scheme on average requires 2H + (1 + 1/k)(H + $H_p$) + (5 + 1 + 1/k)Exp to calculate the dual-layer chameleon hash and bind the block to the dual-level authentication data structure, which enables both effective permission supervision and lightweight storage. Additionally, a computational cost of ($2^{l+1}$ + 1)H + 6Exp is required in our scheme to validate the new block. Meanwhile, the communication cost is constant for all schemes.

In the block redaction phase, the redaction cost is 2H + ($\ell +1$)(H + Exp) for [25] and 2$H_p$ + H + EEA + 9Exp + 2EC for [26]. And the redaction cost of our scheme is 4EEA + 3Exp + 3H, verification cost is ($2^{l+1}$ + 1)H + 6Exp. Because our scheme not only computes hash collisions but also two tag update operations, which ensures that the tag is always bound to the most up-to-date on-chain data. Meanwhile, the communication cost is constant for all schemes in the block redaction.

Block queries can be divided into a proof generation phase and a verification phase. For the proof generation phase, the computation cost is $q\ell$H + (2N − 1)Exp for [25] and ($k+n/k$)$H_p$ + 2Exp for our scheme. In our scheme, the proof generation cost is related to k and n. When the number of elements k within a cycle is fixed, the time cost increases with an increasing number of blocks n. The more blocks there are on the blockchain, the longer it takes to generate a proof. Conversely, when n is fixed, the smaller the value of k, the longer the proof generation time. For the proof verification phase. In contrast to [26], which requires returning the entire chain, our scheme and [25] achieve a constant-level verification cost, which ensures that the cost does not increase with the growth of the blockchain. For the communication cost, Table 3 highlights a significant disparity: Scheme [26] exhibits a linear growth $O\left(n\right)$ in data transmission as the blockchain length increases. In contrast, our scheme maintains a constant communication complexity $O\left(1\right)$, independent of the blockchain scale n. This theoretical advantage implies that the communication cost of the query process will be significantly reduced as on-chain blocks continue to grow.

Blockchain auditing can be divided into the proof generation and verification phases. For the proof generation phase, the computation cost is $q\rho$H + (2N − 1)Exp for [25] and (2z + c)Exp + (zk + c(n/k))H for our scheme. During the proof verification phase, the computation cost is (6z + 6c)Exp + (2c + 3z)EEA + (c(n/k) + $zk$)H for our scheme. In our scheme, the proof generation cost is related to k, z, and n. This is because a dual-level authentication data structure is adopted, which ensures that as the number of on-chain blocks increases, a larger k leads to a slower growth in cost.

Moreover, the FNs and LNs in our scheme incur an additional storage cost. This cost is composed of n(5$\left|G\right|$ + 2$|Z_p|$) for the dual-level chameleon hashing structure and (⌊n/k⌋ + 1)$|Z_N|$) for the dual-level authentication data structure. Notably, the latter component decreases as the parameter k increases. This total overhead is significantly smaller than the size of a standard block, thus achieving lightweight storage.

In terms of communication complexity, specifically for system setup, block appending, content redaction, and block query, the  communication overhead (i.e., the size of transmitted proofs and tags) remains constant. This ensures that the bandwidth consumption for these routine operations is stable and completely independent of the blockchain length. Regarding the auditing phase, the communication cost is linearly correlated with the security parameter z to guarantee valid verification, yet it remains decoupled from the total ledger size. Furthermore, to minimize redundant data transmission, our architecture is designed to share on-chain “challenge-response” instances between the query and auditing protocols. This strategy effectively avoids the on/off-chain resource waste caused by repeated audit requests within the same period, thereby optimizing the overall bandwidth usage for distributed synchronization.

Parameter analysis (k and z): Based on the theoretical analysis above, the selection of parameters k and z presents a critical trade-off between security and computational efficiency. We conducted the following discussion:

• Cycle Size (k): As indicated in the Block Query, Blockchain auditing and Storage analysis, increasing k significantly slows the growth rate of proof generation costs (dominated by the $n/k$ term) and reduces the storage burden on Nodes. Therefore, for permissionless settings (where the chain length n grows indefinitely and storage is costly), a larger k is recommended to ensure scalability and minimize the size of global tags. Conversely, for permissioned settings with high-performance nodes, a smaller k is acceptable to achieve finer-grained permission.
• Audit Challenge (z): Our analysis shows that the auditing cost increases linearly with z. However, a larger z is necessary to achieve higher confidence. As [12]’s work, when the proportion of corrupted blocks in the file under audit is 1%, the integrity auditing process achieves a precision of 95% when 300 blocks are sampled, which increases to 99% as the number of challenged blocks reaches 460. Consequently, In real-world deployments, users should prioritize security by selecting $z=460$ for critical data, while $z=300$ may suffice for general-purpose auditing where speed is prioritized.

6.2. Implementation

To visually assess performance, we designed and carried out a set of experiments that measure the cost of each scheme across various stages.

To evaluate the performance of the proposed scheme, we conducted relevant tests on the Windows 10 operating system, with hardware specifications including an 11th Gen Intel(R) Core(TM) i5-11500 CPU @ $2.70$ GHz processor and $8.00$ GB of RAM. The entire scheme was implemented using Python $3.11$. During implementation, we utilized Python’s standard hashlib library to perform hash computations, the cryptography library to generate $RSA$ key pairs, and the sympy library to assist with certain auxiliary calculations. For cryptographic primitives, the scheme adopts $SHA$-256 as the standard hash function for generating block/transaction hashes. The master keys are based on the $RSA$ algorithm, with a key length of 2048 bits. These parameter choices are made to meet the relevant security requirements. All experiments focus solely on measuring the execution time of the scheme’s core functionalities, excluding any communication overhead. To ensure the accuracy and stability of the results, each measurement was independently repeated 20 times, and the average value was recorded.

System Setup: At this phase, the time cost is spent on generating the parameters $pp$ and creating the genesis block. In Figure 3a, the running time of the system setup operation is provided. As observed, the running time of schemes [25,26], and our scheme does not vary significantly with the number of transactions. Meanwhile, the computational cost of our scheme remains consistent for different values of k. The results of the experiment show that the system setup cost of all comparison schemes is independent of the number of transactions, and the system setup cost of our scheme is independent of the cycle size k.

Block Append: In Figure 3b, we can see that the computational cost of blockchain append in our scheme and [25,26] are both constant. Meanwhile, in our scheme, the block generation time for $k=20$ is slightly lower than that for $k=10$, due to the reduced number of outer tag computations when there are more data entries within a group. From Figure 3c, the verification time for all three schemes is independent of the transaction volume. Overall, the additional overhead in the block append phase is acceptable.

Block Redaction: As shown in Figure 4, we can see that the redaction and verification cost of [25] increases as the index of the editing block increases, while the computational and verification cost of our scheme and [26] are both constant. Meanwhile, in our scheme, the size of k does not affect the redaction and verification costs. Because the group size has nothing to do with the redaction process. In

Table 5. Comparisons of computation costs in the Correction.

k	10	20	30	40
Runtime (s)	0.0375	0.03864	0.03791	0.03913

, we compare the average running time of different correction processes under different numbers of group elements k (Since scheme [25,26] do not have this functionality, no comparison with them is involved). It can be seen that as the number of data entries k within a cycle increases, the time to correction is also constant, which is because the correction process only involves modifying the permissions of the erroneous blocks, and has nothing to do with the other blocks within the cycle.

Block Query: In Figure 5, the time cost is divided into proof generation and verification. For proof generation, ref. [26] needs to return the entire blockchain data, so the proof generation cost in Figure 5a is 0 s. The time cost for proof generation by [25] remains approximately constant at around $0.0793$ s. In our scheme, proof generation involves all blockchain data entries, causing the time cost to grow as the number of blocks increases. Meanwhile, under different values of k, the larger the k, the slower the growth rate. This is consistent with our previous analysis. Furthermore, Figure 5b shows that the verification cost of our scheme and [25] are constant, while that of [26] increases linearly with the growth of the number of blocks. As a result, we can conclude that as the blockchain data grows, our query costs are within the acceptable range.

Blockchain Auditing: In Figure 6, the time cost is divided into auditing, proof generation, and verification. In Figure 6a, we tested the generation costs of proofs for different challenge blocks for various schemes. As observed, the time required for generating audit proofs for both our scheme and [25] will increase with the growing number of challenged blocks. (Since the scheme [26] does not have this functionality, no comparison with it is involved.) Furthermore, in the proof generation process, we will set the challenge blocks to 460. In Figure 6b,c, for both our scheme and Scheme [25], the overhead of proof generation and verification scales with the increasing number of blocks. In the proof generation phase, our scheme, under different values of k, the larger the k, the slower the growth rate, which is consistent with our previous analysis. Both schemes exhibit an increase in running time as the blockchain extends in length. However, our proposed scheme consistently requires more time compared to the other. This is because the majority of our computing costs are spent on retrieving the disputed block tags. Compared with the advantages of lightweight storage and permission supervision, the increase in the cost of the audit part is acceptable. This enables our solution to achieve the design goal of integrating lightweight storage, permission supervision, and public auditing.

6.3. Result Overview

Specifically regarding system setup and redaction, our scheme demonstrates constant computational complexity that is unaffected by transaction volume or blockchain length. Regarding block appending, although the computational overhead is slightly influenced by the cycle size k, it remains constant with respect to the blockchain length, ensuring stable performance independent of the growing ledger. Furthermore, the proposed design achieves minimal overhead for verification processes, offering a distinct efficiency advantage in these high-frequency maintenance operations compared to the comparative schemes.

Unlike the constant-time routine operations, the computational costs for block Query and auditing naturally increase with the growth of the blockchain ledger. Crucially, however, our experiments demonstrate that the cycle size parameter k serves as an effective tuning mechanism: as the blockchain scale expands, a larger k yields a slower growth rate in proof generation costs compared to a smaller k, thereby offering better scalability for large-scale deployments. Regarding the auditing phase, although the additional costs are non-negligible, they represent an acceptable trade-off for maintaining the rigorous security and stability of a redactable blockchain. Nevertheless, exploring more efficient authentication structures to further reduce verification time remains an important direction for our future work.

7. Discussion

Our scheme relies on a trusted Certificate Authority (CA) to manage the outer layer of the chameleon hash and supervise the redaction committee. In a consortium blockchain setting, the CA is typically a highly credible entity (e.g., a government regulator or a consortium board). To further strengthen the robustness of our system beyond the standard consortium assumptions, we provide a discussion on mitigating the potential risks associated with CA management. If the CA’s master secret key ($msk$) is compromised, an adversary could arbitrarily modify the ledger, undermining the system’s immutability. To mitigate this risk, threshold cryptography can be introduced in the practical deployment. Instead of a single entity holding the complete $msk$, the key can be split using a $(t,n)$ threshold sharing scheme and distributed among n stakeholders. This ensures that the compromise of a single or a minority of CA nodes does not compromise the security of the entire system, thereby enhancing the robustness of the permission supervision.

8. Conclusions

We propose a verifiable and redactable blockchain with lightweight storage and permission supervision. This scheme integrates flexible block content redaction, lightweight storage, and dual-layer authority supervision based on a committee and a central authority. Additionally, it supports blockchain state verification, data querying, and auditing through hierarchical authentication tags, offering broad application prospects. Finally, experimental results demonstrate that tuning the cycle size k effectively reduces the computational overheads of querying and auditing, which is significant for improving the practicality of verifiable redactable blockchains.